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