Эта публикация открывает цикл из двух материалов. Здесь базовая часть для новичков, а во второй статье — будут продвинутые советы по RAG, агентам и другим более сложным сценариям.
Каждую неделю в тредс или на реддите кто-то жалуется: «Попросил ChatGPT (Gemini, Grok, клод, нужное подчеркнуть) написать сопроводительное письмо, а получил кринж из штампов. Ну и фигня эта ваша нейронка». В комментах топикстартеру задают резонные вопросы: «Какой системный промпт ты писал? Контекст давал? Примеры приложил? Tone of voice описал?» А в ответ — тишина.
Эта статья про то, как не быть таким персонажем и перестать обижаться на ИИ.
Почему я ее пишу: я контент-маркетолог в Cloud.ru, и так уж получилось, что промпт-инженер (у меня и справка есть). Работаю с LLM каждый день уже более трех лет, долго сотрудничала с нашей ML-командой и хорошо представляю, как вводные на естественном языке трансформируются в выдачу. Часто разбираю чаты коллег, у которых не получилось добиться чего-то от LLM, и помогаю им составлять эффективные промпты под разные задачи.
А еще веду блок про правильное использование ИИ в нашей внутренней школе авторов. В этой статье решила собрать опыт, который закрывает 70% проблем тех, кто пообщался с машиной, получил неудовлетворительный результат и теперь доверяет ей разве что рецепт курочки на ужин.
Иллюзия «сделай красиво/хорошо/лучше»: zero-shot против few-shot
В книжках и постах про ИИ часто приводят метафору: общение с моделью похоже на работу с гиперактивным джуном, у которого тяжелая форма амнезии.
Да, он что-то знает, готов работать, но при этом забывает то, что вы говорили десять минут назад, и без подробного брифа сделает как получится.
Поэтому первый и самый частый способ получить плохой результат — это дать модели голую формулировку без примеров. На профессиональном жаргоне это называется zero-shot prompting и, по сути, переводится как «угадай, что я имел в виду».
Допустим, продакт-менеджер решает, не привлекая внимания санитаров разработчиков, модифицировать простой скрипт на сайте. Кидает кусок кода в нейронку с нулевым промптом: «Добавь сюда поп-ап при клике».
Нейросеть выдает результат. Менеджер копипастит это на сайт, но ничего не работает. Он начинает закидывать ошибки обратно в чат, ИИ предлагает новые варианты, код обрастает костылями, и все становится только запутаннее. Приходится звать на помощь коллег.
В чем была проблема? На старом сайте крутится легаси на jQuery. Но менеджер не дал контекста, а языковая модель решила блеснуть знаниями. Она увидела код и подумала: «Какой jQuery, бро? Держи ванильный JS. Я все переписала, добавила тайм-ауты для анимации, блеск!» А валидировать ответ менеджеру просто не хватает экспертности: он не отличает $('#btn') от document.querySelector('#btn').
Но менеджер и не должен в этом разбираться. Проблема возникает на шаг раньше: прежде чем открывать окно чата с ИИ, вы обязаны провести базовую разведку и собрать контекст своими руками.
Такой подход называется few-shot prompting. Когда вы не просто описываете задачу, а добавляете к ней несколько примеров того, как должен выглядеть хороший результат. Потому что нейросеть — это не системный аналитик и не экстрасенс. Вы не можете делегировать ей сбор исходных данных.
Вам не нужно разбираться в тонкостях архитектуры, но вы должны иметь максимум фактуры, которую отдадите в промпт. Не знаете стек? Подойдите к разработчику и спросите: «На чем работает этот лендинг?» Или используйте чит-код для нетехнарей: сделайте ваш самый первый промпт диагностическим.
Не просите сразу генерировать код, а напишите так:
«Вот кусок кода с нашего старого сайта. Я не разработчик. Проанализируй его и скажи, какой язык или библиотеки тут используются. Затем составь для себя же строгий список ограничений, которым ты будешь следовать, когда я попрошу тебя этот код изменить, чтобы не сломать сайт».
ИИ сам проанализирует контекст, сам напишет для себя ограничения — и только после этого вы ставите ему задачу. Сбор контекста — это ваша зона ответственности.
Плюс учитывайте, что законы Мерфи в работе с нейросетями никто не отменял. Если что-то может быть сделано через альтернативные места, оно будет сделано через альтернативные места.
Была у меня история из жизни: на работе у мужа есть летняя школа для детей, где им объясняют, что такое алгоритмы. Волонтер собирает детишек за столом, на котором лежит батон в упаковке, нож и масло. Задача — давать инструкции так, чтобы в конце получился бутерброд. Что вы думаете? Все уже ломается на стадии «Возьми нож в руку и нарежь батон».
То же самое работает для любой роли.
Пример: дизайнер просит покритиковать макет.
❌ Без референсов и ограничений получит банальные советы вроде «улучшите контрастность», «увеличьте отступы», «поиграйте со шрифтами».
✅ С приложенным гайдлайном и примерами будут конкретные замечания по типографике и сетке.
Если задуматься, то ничего нового здесь нет. В любой нормальной команде тимлиды годами учат стажеров и джунов правильно просить помощи: «Опиши задачу и всё, что уже попробовал, приложи логи или скрин ошибки, скажи, какого результата ждешь». Половина вопросов в этот момент отваливается сама: пока человек формулирует проблему, он сам же ее и решает. Есть целая культура, как правильно задавать вопросы, — от знаменитого How To Ask Questions The Smart Way до внутренних регламентов в чатах поддержки.
Универсальное правило здесь в том, что модель сама никогда не догадается. Она всегда подставит среднее по обучающей выборке, а это уныло. И чтобы вытащить из этого среднего что-то полезное, одного приема мало. Хороший промпт — это комбинация нескольких слоев: роли, аудитории, контекста, формата, ограничений.
Условия хорошего промпта
Когда вы пишете: «Ты senior backend engineer с опытом высоконагруженных систем», то происходит сдвиг весов — токены, связанные с профессиональной лексикой и паттернами, получают более высокую вероятность. Ответ становится более предметным, модель начинает использовать обороты, которые в обучающей выборке встречались рядом со словосочетанием «senior backend».
Второй важный пункт — определять аудиторию. «Объясни архитектуру kubernetes-кластера так, чтобы понял джун-фронтендер» и «Опиши ту же архитектуру для CTO, который принимает решение о бюджете» — это два разных текста.
Хорошая структура промпта будет такой:
Роль — кто ты сейчас.
Контекст — что происходит вокруг задачи.
Аудитория — для кого результат.
Сама задача — что конкретно нужно.
Формат вывода — как должен выглядеть ответ.
Ограничения — чего точно не делать.
Выглядит как ТЗ для подрядчика. По сути, это оно и есть. Он сделает ровно то, что написали, а не то, что имели в виду между строк.
Например, возьмем абстрактный, но узнаваемый кейс: «Помоги разобраться с инцидентом, у нас сервис ночью лег».
В zero-shot-варианте модель даст общую отписку: посоветует посмотреть логи, проверить инфраструктуру, сетевые проблемы, базу данных. Полезность такого ответа стремится к нулю.
А теперь добавим контекста по схеме «роль — данные — пример — формат»:
Комбопромпт для постмортема
Ты SRE с опытом расследования инцидентов в распределенных системах.
Мне нужен детальный разбор инцидента (постмортем) по падению сервиса оплаты.
Контекст:
— Сервис: оплата (payment‑service.
— Стек: Go, PostgreSQL, Kafka, Kubernetes.
— Время инцидента: с 03:12 до 03:47 по времени YYYY-MM-DD (инцидент можно считать начавшимся, когда сильно выросли latency и error rate.
** Что у меня есть:
1. Логи application‑сервиса оплаты за период 03:05–03:55 (чуть шире инцидента):
(В реальном запросе вставляем сюда свои настоящие логи за 03:05–03:55.)
2. Описание графиков метрик за тот же период (латентность, ошибки, лаг и т. п.):
(В реальном запросе даем свои реальные числа или краткое описание «на графике видно, что…».)
3. Детали инцидента и действий команды:
```text
Инцидент:
— start: 03:12;
— end: 03:47.
Алерты:
— 03:13 — алерт "payment: error_rate > 5% for 5m (current: 22%)" в PagerDuty;
— уведомление пришло в slack-канал #prod-incidents.
Действия во время инцидента:
— 03:15 — перезапустили deployment payment-service (2 pod’а);
— 03:20 — увеличили реплики с 2 до 4;
— 03:28 — вручную рестартнули Kafka consumer;
— 03:35 — отключили часть трафика (feature flag для одного из методов оплаты);
— 03:47 — метрики вернулись в норму, инцидент закрыли.
```
4. Краткое описание архитектуры сервиса оплаты:
```text
payment-service:
— принимает синхронные HTTP-запросы /api/payments;
— пишет транзакцию в PostgreSQL (таблица payments + несколько вспомогательных);
— после успешного коммита отправляет событие в Kafka (topic=payments-events);
— отдельный consumer читает payments-events и дергает сторонний PSP.
db:
— max_connections=200, для payment-service пул 50;
— есть ночной репорт, который иногда сильно грузит базу.
kafka:
— один consumer group payments-consumer, autoscale нет;
— retry на уровне consumer’а: 3 попытки, дальше сообщение уходит в DLQ.
```
5. Пример моего старого постмортема / желаемый стиль (я прикладываю кусок текста, можно анонимизированный, чтобы было видно, как оформлять разделы, таймлайн и action items).
***
Что нужно сделать
Сделай, пожалуйста, постмортем по той же структуре, к которой я привык:
1. Таймлайн событий
— по минутам / крупным шагам: что увидели в метриках, какие ошибки в логах, какие действия предпринимали.
2. Корневая причина (Root Cause)
— четкая формулировка одной-двумя фразами;
— обоснование по логам и метрикам (какие строки / какие графики на это указывают).
3. Что сработало в обнаружении
— какие алерты/метрики помогли;
— что было сделано быстро и правильно.
4. Что не сработало
— где было позднее срабатывание;
— каких сигналов или алертов не хватало;
— где нас подвела наблюдаемость или процессы.
5. Action items с приоритетами
— список задач в формате:
— [P1] ... — критично, надо сделать в первую очередь;
— [P2] ... — важно, но не горит;
— [P3] ... — nice to have / улучшения.
— привязка к конкретным проблемам, обнаруженным в инциденте (алерты, код, конфигурация PostgreSQL/Kafka/Kubernetes, дашборды).
Если каких‑то данных, на твой взгляд, не хватает для уверенной корневой причины, явно напиши в конце раздела «Корневая причина», какие именно наблюдения/метрики/логи нужно еще собрать, и сформулируй их в виде TODO.Разница в выдаче будет огромная, так как мы сдвинули распределение вероятностей в сторону профессионального технического языка и конкретного формата.
Конфликт промптов: иерархия инструкций
В реальном ИИ-продукте на одну модель давит сразу несколько слоев инструкций:
System prompt — то, что задает промпт-инженер продукта: «Ты ассистент банка, отвечаешь только на финансовые вопросы, не материшься, не обсуждаешь политику».
Developer prompt — дополнительные технические инструкции от разработчиков, формат вывода, подключенные инструменты.
User message — то, что пишет пользователь.
Tool calls — результаты вызовов функций, RAG-чанки и прочие данные, которые подмешиваются в контекст.
Чем ниже слой, тем меньше доверия. System выигрывает у user. Поэтому ассистент банка не будет обсуждать политику и выдавать секретные промокоды, даже если вы очень вежливо попросите.
На нашей конференции GoCloud в апреле мы как раз делали стенд, где участники пытались взломать упрощенную версию Гига-помощника — заставить его обойти ограничения и поделиться промокодом. Для этого нужно было использовать системный промпт и избегать слов, на которые реагировали guardrails.
Знание слоев помогает:
Трезво оценивать, что ассистент может сделать, а чего не может. Если что‑то запрещено на уровне системы, нет смысла бесконечно переформулировать запрос, так как дело не в вашем ТЗ.
Формулировать вопросы в рамках роли ассистента. Не просите сломать правила, а ищите максимально полезное действие внутри допустимого лимита.
Меньше разочаровываться. Помните, что отсутствие ответа — не баг, а осознанное ограничение продукта.
Контекст-инжиниринг
В начале статьи мы говорили про продакта, решившего исправить старый скрипт на jQuery. Мы выяснили, что главная задача, перед тем как идти к нейросети, — собрать контекст. Но у этого правила есть другая, не менее разрушительная крайность.
С появлением моделей с контекстом в миллион токенов появилось искушение: «А давайте запихнем всю документацию и переписку из мессенджера в промпт — и пусть сам разбирается».
Остановитесь, это плохая идея по трем причинам:
Токены небесплатны. Большой контекст превращается в большой счет.
Производительность падает. Чем больше контекст, тем медленнее ответ (в инженерии это называется TTFT — Time To First Token).
Даже модель с миллионом токенов помнит начало контекста хуже, чем конец. Качество извлечения информации просаживается посередине очень длинных промптов. Такое явление получило название lost in the middle.
На рынке появилось даже отдельное направление — context engineering как развитие промпт-инжиниринга. Идея в том, что хороший промпт — это не магическая фраза, а правильно собранный контекст: что положили, что выкинули, как сжали историю, в каком порядке расставили.
Практические правила:
Самое важное помещайте в начало или в конец промпта, но не в середину.
Длинные документы прогоняйте через дешевые быстрые модели для суммаризации (создания выжимки) и только потом отдавайте результат в дорогой основной промпт.
Историю длинных диалогов сжимайте автоматически, не отправляйте все сообщения подряд.
Системный промпт держите коротким и плотным, без вежливых фраз и лирических отступлений.
Все вышесказанное — про текст. А как работать с промптами для визуала?
Промпты для картинок
Тут работает тот же принцип: плохие промпты дают плохие или просто очень примитивные результаты.
Структура хорошего промпта для картинки будет напоминать постановку кадра на съемочной площадке:
Subject — кто или что главное в кадре.
Action — что субъект делает.
Environment — где это происходит.
Style — фотореализм, акварель, киберпанк, конкретный референс.
Composition — план, ракурс, композиция.
Lighting — освещение.
Negative — чего точно не должно быть.
Отдельная боль — стереотипы, которые модель тащит из обучающих данных. На запрос «врач в кабинете» вы получите мужчину средних лет в белом халате.
«Бизнесмен» — он же, только в костюме и на фоне большого города.
Лечится явным описанием в промпте: возраст, телосложение, одежда, окружение, цвет кожи, волос, глаз и так далее.
Но стереотипы и шаблоны — это про то, что модель видела в обучении. Есть другая проблема: в любой компании есть огромный пласт того, что она не видела никогда, — внутренние документы, регламенты, проектная история, переписка с клиентами.
Именно поэтому индустрия массово обвешивает модели RAG-системами, чтобы модель опиралась на внутренние документы. Но об этом в следующей части.
Итоги и чек-лист грамотного юзера
LLM — это компилятор текста. Очень мощный, удобный, но компилятор. Качество выхода зависит от качества входа. Если на входе вы пишете: «Сделай круто, причеши, покрути», на выходе будет причесанное и перекрученное нечто, которое, скорее всего, вас разозлит.
А вот структурированный промпт с ролью, контекстом, примерами и форматом приведет к более предсказуемому и ожидаемому результату.
Поэтому навык писать ТЗ для машины — это новая базовая инженерная грамотность. И чтобы все вышесказанное не растворилось в потоке текста, держите компактный чек-лист.
Как лучше ставить ТЗ для ИИ
На постановке задачи:
Задайте роль — «Ты Senior X с опытом Y».
Опишите аудиторию — для кого результат.
Дайте контекст — что вокруг задачи, что делали, что получилось, какие ошибки.
Приложите примеры — два-три «как надо» и один «как точно не надо».
На итерации:
Не пытайтесь починить плохой результат добавлением «постарайся лучше». Чините структуру промпта.
Если просите факты, то требуйте источники и проверяйте сами.
Если результат получился слишком общим, добавьте отраслевую специфику в контекст.
Один и тот же запрос на разных моделях даст разные результаты. Пробуйте.
Антипаттерны: как точно не надо
«Сделай красиво» без референсов и примеров — модель сделает усредненно.
«Подумай хорошенько» — никак не помогает. Помогает Chain-of-Thought с явной структурой рассуждения.
Шесть противоречащих ролей в одном системном промпте: «Будь дружелюбным, но строгим, формальным, но игривым, точным, но гибким» — модель сходит с ума и ловит галлюцинации.
Контекст в 10 000 токенов, в котором главное — на 9 000-й строке (lost in the middle помните?).
Запрос актуальных данных без подключенного поиска — модель, скорее всего, соврет правдоподобными цифрами.