Эта публикация открывает цикл из двух материалов. Здесь базовая часть для новичков, а во второй статье — будут продвинутые советы по 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, который принимает решение о бюджете» — это два разных текста.

Хорошая структура промпта будет такой:

1. Роль — кто ты сейчас.

2. Контекст — что происходит вокруг задачи.

3. Аудитория — для кого результат.

4. Сама задача — что конкретно нужно.

5. Формат вывода — как должен выглядеть ответ.

6. Ограничения — чего точно не делать.

Выглядит как ТЗ для подрядчика. По сути, это оно и есть. Он сделает ровно то, что написали, а не то, что имели в виду между строк.

Например, возьмем абстрактный, но узнаваемый кейс: «Помоги разобраться с инцидентом, у нас сервис ночью лег».

В 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. Мы выяснили, что главная задача, перед тем как идти к нейросети, — собрать контекст. Но у этого правила есть другая, не менее разрушительная крайность.

С появлением моделей с контекстом в миллион токенов появилось искушение: «А давайте запихнем всю документацию и переписку из мессенджера в промпт — и пусть сам разбирается». 

Остановитесь, это плохая идея по трем причинам:

1. Токены небесплатны. Большой контекст превращается в большой счет.

2. Производительность падает. Чем больше контекст, тем медленнее ответ (в инженерии это называется TTFT — Time To First Token).

3. Даже модель с миллионом токенов помнит начало контекста хуже, чем конец. Качество извлечения информации просаживается посередине очень длинных промптов. Такое явление получило название lost in the middle.

На рынке появилось даже отдельное направление — context engineering как развитие промпт-инжиниринга. Идея в том, что хороший промпт — это не магическая фраза, а правильно собранный контекст: что положили, что выкинули, как сжали историю, в каком порядке расставили.

Практические правила:

• Самое важное помещайте в начало или в конец промпта, но не в середину.

• Длинные документы прогоняйте через дешевые быстрые модели для суммаризации (создания выжимки) и только потом отдавайте результат в дорогой основной промпт.

• Историю длинных диалогов сжимайте автоматически, не отправляйте все сообщения подряд.

• Системный промпт держите коротким и плотным, без вежливых фраз и лирических отступлений.

Все вышесказанное — про текст. А как работать с промптами для визуала?

Промпты для картинок

Тут работает тот же принцип: плохие промпты дают плохие или просто очень примитивные результаты.

Структура хорошего промпта для картинки будет напоминать постановку кадра на съемочной площадке:

• Subject — кто или что главное в кадре.

• Action — что субъект делает.

• Environment — где это происходит.

• Style — фотореализм, акварель, киберпанк, конкретный референс.

• Composition — план, ракурс, композиция.

• Lighting — освещение.

• Negative — чего точно не должно быть.

Отдельная боль — стереотипы, которые модель тащит из обучающих данных. На запрос «врач в кабинете» вы получите мужчину средних лет в белом халате.

 «Бизнесмен» — он же, только в костюме и на фоне большого города.

Лечится явным описанием в промпте: возраст, телосложение, одежда, окружение, цвет кожи, волос, глаз и так далее.

Но стереотипы и шаблоны — это про то, что модель видела в обучении. Есть другая проблема: в любой компании есть огромный пласт того, что она не видела никогда, — внутренние документы, регламенты, проектная история, переписка с клиентами. 

Именно поэтому индустрия массово обвешивает модели RAG-системами, чтобы модель опиралась на внутренние документы. Но об этом в следующей части.

Итоги и чек-лист грамотного юзера

LLM — это компилятор текста. Очень мощный, удобный, но компилятор. Качество выхода зависит от качества входа. Если на входе вы пишете: «Сделай круто, причеши, покрути», на выходе будет причесанное и перекрученное нечто, которое, скорее всего, вас разозлит. 

А вот структурированный промпт с ролью, контекстом, примерами и форматом приведет к более предсказуемому и ожидаемому результату.

Поэтому навык писать ТЗ для машины — это новая базовая инженерная грамотность. И чтобы все вышесказанное не растворилось в потоке текста, держите компактный чек-лист.

Как лучше ставить ТЗ для ИИ

На постановке задачи:

1. Задайте роль — «Ты Senior X с опытом Y».

2. Опишите аудиторию — для кого результат.

3. Дайте контекст — что вокруг задачи, что делали, что получилось, какие ошибки.

4. Приложите примеры — два-три «как надо» и один «как точно не надо».

На итерации:

1. Не пытайтесь починить плохой результат добавлением «постарайся лучше». Чините структуру промпта.

2. Если просите факты, то требуйте источники и проверяйте сами.

3. Если результат получился слишком общим, добавьте отраслевую специфику в контекст.

4. Один и тот же запрос на разных моделях даст разные результаты. Пробуйте.

Антипаттерны: как точно не надо

• «Сделай красиво» без референсов и примеров — модель сделает усредненно.

• «Подумай хорошенько» — никак не помогает. Помогает Chain-of-Thought с явной структурой рассуждения.

• Шесть противоречащих ролей в одном системном промпте: «Будь дружелюбным, но строгим, формальным, но игривым, точным, но гибким» — модель сходит с ума и ловит галлюцинации.

• Контекст в 10 000 токенов, в котором главное — на 9 000-й строке (lost in the middle помните?).

• Запрос актуальных данных без подключенного поиска — модель, скорее всего, соврет правдоподобными цифрами.