Есть соблазн свести тему «как правильно работать с ИИ» к списку хаков: «пиши промпт вот так», «добавь роль в начало», «проси думать по шагам». Эти техники работают, но они вторичны. Первично — то, кем является сам инженер до того, как он открыл чат с моделью. ИИ не компенсирует нехватку экспертизы, он её усиливает или обнажает — в зависимости от того, что вы в него вкладываете.

Ниже — две группы факторов: фундамент специалиста и практика формулирования задач. Первое определяет, *какие* вопросы вы вообще способны задать. Второе — как эти вопросы упаковать, чтобы ИИ решал именно вашу задачу, а не похожую на неё.

Фундамент: то, что нельзя быстро наверстать промптом

Терминология — это протокол связи, а не украшение речи.
Разница между «соединение зависло» и «сокет в состоянии CLOSE_WAIT» — это разница между поиском по всему пространству возможных проблем и точным попаданием в конкретный класс поведения системы. Модель распознаёт термин как ссылку на устоявшуюся модель поведения технологии. Расплывчатая формулировка — это расплывчатый ответ, каким бы умным ни был ИИ по другую сторону.

Интуиция, выросшая из среды, а не из документации.
Есть разница между человеком, который знает, что chmod меняет права, и человеком, у которого при столкновении с проблемой доступа рефлекторно всплывает «а какой тут umask», «а не ACL ли дело», «а не SELinux ли контекст» — ещё до того, как вопрос сформулирован словами. Эта интуиция чаще всего родом из многолетнего погружения в *NIX-среду, а не из курсов. Она определяет полноту вопроса, который вы зададите ИИ. Модель не ответит на вопрос, который вам не пришло в голову задать.

Академическая база — это фреймворк для проверки ответа, а не багаж для резюме.
Понимание CAP-теоремы, уровней OSI, теории графов, основ распределённых систем даёт критерий: когда ответ ИИ противоречит фундаментальным ограничениям, вы это замечаете сразу, а не после инцидента в проде. Кроме того, теоретическая база позволяет свести конкретную гибридную проблему к известному паттерну — а с паттернами модель работает существенно точнее, чем с ситуативным описанием «у нас тут всё специфично».

Итог этого раздела: без такого фундамента специалист либо формулирует задачу неточно (ИИ решает не ту проблему, но убедительно), либо не может отличить правдоподобный, но неверный ответ от корректного. Это самый частый источник «ИИ мне наврал» — на деле проверка ответа требует ровно той экспертизы, которую пытались делегировать модели.

Практика: как упаковать задачу, если фундамент есть

Явный контекст среды.
Версии, дистрибутив, managed или bare-metal, CNI, конкретный ingress-контроллер. Без этого получаете технически верный, но нерелевантный вашей инфраструктуре ответ.

Формулировка результата, а не только симптома.
Не «под падает», а «CrashLoopBackOff, вот describe и логи, нужно понять — OOMKill или fail liveness probe, и получить фикс для конкретного манифеста».

Артефакты вместо пересказа.
Реальный YAML, лог, трейс ошибки целиком — а не пересказ своими словами. Пересказ теряет именно те детали (отступы, коды ошибок, порядок событий), которые критичны для точного ответа.

Декомпозиция вместо одного гигантского запроса.
«Настрой весь CI/CD с нуля» — плохая постановка. План → этапы pipeline → secrets management → rollback strategy, по шагам. Ошибки ловятся на раннем этапе, а не после того, как всё уже собрано.

Знание типичных слепых зон модели.
Изменения после cutoff (deprecations в API), нюансы конкретного облачного провайдера (особенно IAM), небезопасные default-конфигурации «из коробки». Зная эти зоны риска, вы заранее просите перепроверить именно их.

Явные ограничения.
«Без downtime», «без root», «под конкретный compliance», бюджетный лимит — если не сказать, получите общий best practice, который может не подходить именно вам.

Синтез

Промпт-инжиниринг для DevOps — это не набор трюков поверх пустоты. Это способ эффективно передать модели то, что уже есть в голове у грамотного инженера: точная терминология, интуиция среды, теоретические рамки для проверки. Тот, кто вырос в *NIX и защитил основы CS, тратит на итерации с ИИ в разы меньше времени не потому, что знает «правильные заклинания», а потому что говорит с моделью на языке предметной области — без потерь при переводе в обе стороны: ни при формулировке вопроса, ни при оценке ответа.