Одна и та же задача, два запроса. «Добавь ретраи в клиент» — и через минуту в проекте появляется своя обёртка с экспоненциальной задержкой, хотя в соседнем модуле уже лежит готовая. «В internal/client/http.go добавь ретраи по образцу internal/queue/retry.go, только для 5xx и таймаутов, максимум три попытки; конфиг не расширяй» — и правка приходит такой, какой нужна.

Разница здесь не в вежливости и не в «магических словах». Она в том, сколько неизвестного вы оставили модели додумывать: каждое додуманное решение — это круг правок, а круги стоят дороже, чем полминуты на формулировку.

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

Что говорят данные

Про промпты для кода есть два исследования, и вместе они дают более честную картину, чем каждое по отдельности.

Первое — разбор паттернов на датасете DevGPT: реальные диалоги разработчиков с моделью, привязанные к пул-реквестам и issue на GitHub. Авторы препринта 2025 года выделили семь структур запроса — персона, рецепт, шаблон, автоматизация вывода, голая инструкция, контекст с инструкцией и вопрос — и сравнили их на 3 515 закрытых пул-реквестах и 5 261 закрытом issue. Лучшие показатели у «контекста с инструкцией» и «рецепта», причём рецепт добирался до результата за 7,07 сообщения против 11,16 у обычного вопроса. Различия между паттернами статистически значимы.

Второе — работа с конференции EASE 2025. Там взяли 7 583 файла кода из тех же диалогов и прогнали по метрикам сопровождаемости, надёжности и безопасности, сравнив zero-shot, chain-of-thought и few-shot. Значимой разницы между паттернами не нашли.

Вывод из двух работ вместе такой: структура промпта экономит ваши итерации, а не улучшает код. Она сокращает путь до нужного результата — и не заменяет ни тестов, ни статического анализа, ни человека на ревью. Что смотреть на ревью такого кода, разбираем отдельно в статье про проверку AI-кода.

Паттерн 1. Контекст, потом инструкция

Самый доказанный и самый скучный. Сначала обстановка: где мы, на чём, что уже есть, что нельзя ломать. Потом — конкретное действие.

Anthropic формулирует то же самое через ролевую метафору: относитесь к модели как к сильному, но новому сотруднику, который не знает ваших норм и договорённостей. Новому сотруднику вы не скажете «почини логин» — вы скажете, где логин живёт и что в нём считается сломанным.

Было:

Почини баг с логином

Стало:

Пользователи жалуются: после истечения сессии логин падает.
Смотри auth-поток в src/auth/, в первую очередь обновление токена.
Сначала напиши падающий тест, который воспроизводит проблему, потом чини.

Второй запрос длиннее на три строки и снимает четыре развилки: где искать, что считать багом, с чего начать, как понять, что готово.

Когда не нужно: на разведке. Расплывчатый вопрос вроде «что бы ты здесь улучшил» иногда вытаскивает то, о чём вы не догадались бы спросить, — но это другой режим работы, не производство.

Паттерн 2. Критерий, который агент проверит сам

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

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

Было:

Напиши функцию валидации email

Стало:

Напиши validateEmail. Примеры: user@example.com — true,
invalid — false, user@.com — false.
После реализации прогони тесты и покажи вывод.

Требование «покажи вывод» не формальность. Читать доказательство быстрее, чем перепроверять работу самому, и это единственный способ доверять сессии, за которой вы не следили.

Когда не нужно: если проверки не существует и придумать её нельзя. Тогда это сигнал не про промпт, а про задачу: результат, который нечем проверить, нечем и принять.

Паттерн 3. Опора на существующий код

Модель не знает, какой из пяти способов принят у вас. Она выберет самый распространённый в интернете — и добавит в проект шестой. Отсюда лавина дублей: своя обёртка над HTTP, вторая функция форматирования даты, третий способ валидации.

Лечится указанием на образец. Не «как принято в проекте», а конкретный файл.

Было:

Добавь виджет календаря

Стало:

Посмотри, как сделаны виджеты на главной, HotDogWidget.php — хороший пример.
По этому же образцу сделай календарь: выбор месяца и перелистывание года.
Новых библиотек не подключай, только те, что уже есть в проекте.

Постоянную часть таких указаний — где лежит общий код, какие библиотеки под запретом, что нельзя трогать — незачем повторять в каждом промпте. Она выносится в файл правил проекта: AGENTS.md, CLAUDE.md или .cursor/rules. Промпт тогда занимается только текущей задачей.

Паттерн 4. Разведка, план, потом код

Самый дорогой класс ошибок — не кривая реализация, а аккуратная реализация не той задачи. Она стоит целой сессии, потому что обнаруживается в конце.

Разводится тем, что исследование и написание кода разносятся по разным шагам. Anthropic описывает это как цикл из четырёх фаз: разведка, план, реализация, коммит. Сначала модель только читает и отвечает на вопросы, ничего не меняя. Потом составляет план — и его вы правите, пока это ещё текст, а не диффы по восьми файлам.

Для крупной фичи есть приём сильнее — попросить модель проинтервьюировать вас и записать спецификацию. Она спросит про краевые случаи, компромиссы и UI, о которых вы не думали, а дальше эту спецификацию исполняет уже чистая сессия. Полезные спеки самодостаточны: называют файлы и интерфейсы, явно объявляют, что вне объёма, и заканчиваются сквозной проверкой.

Когда не нужно: когда правку можно описать одним предложением. Опечатка, лишний лог, переименование — на них планирование только добавляет накладных расходов.

Паттерн 5. Рецепт вместо цели

Тот самый паттерн, который в исследовании DevGPT доходил до результата быстрее прочих. Работает там, где вы знаете последовательность шагов, а модели остаётся её исполнить. Задача перестаёт быть поиском решения и становится работой по списку.

Было:

Перенеси проект на новую версию линтера

Стало:

1. Обнови eslint и конфиг до девятой версии.
2. Переведи .eslintrc на flat config, старый файл удали.
3. Прогони линтер, выпиши категории ошибок, не правя их.
4. Останови работу и покажи список.

Четвёртый шаг важнее первых трёх: он ставит контрольную точку до того, как модель начнёт массовые правки. Без него вы получите двести исправленных файлов и никакого способа понять, что там произошло.

Когда не нужно: если шагов вы не знаете. Тогда сначала паттерн 4 — пусть шаги предложит модель, а вы их отредактируете.

Паттерн 6. Ограничитель

Свежие модели склонны делать больше, чем просили: заводить лишние файлы, добавлять слои абстракции, закладывать гибкость на будущее, которое не наступит. Anthropic называет это прямо и рекомендует давить явной инструкцией — та же проблема с другой стороны видна на ревью, где половина диффа не относится к задаче.

Рабочая формулировка ограничителя состоит из четырёх запретов:

Не делай больше, чем просили:
— объём: никаких соседних улучшений и рефакторингов «заодно»;
— документация: не добавляй комментарии и аннотации в код, который не менял;
— защитное программирование: не обрабатывай ситуации, которые не могут случиться;
— абстракции: не заводи хелперы для одноразовых операций.

Отдельный пункт — про тесты. Модель умеет проходить тест, не решив задачу: захардкодить ожидаемые значения, подстроиться под конкретные входы, обойти проблему вспомогательным скриптом. Anthropic прямо предлагает добавлять в промпт, что тесты проверяют корректность, а не определяют решение, и что о невыполнимой задаче нужно сказать, а не обходить её. Формулировка звучит бюрократично, но экономит примерно один инцидент в квартал.

Как это собирается в один запрос

Паттерны не выбираются — они складываются. Обычная задача выглядит так:

[контекст] Сервис на Go, Fiber + GORM. Экспорт отчётов лежит в
internal/service/report.go, сейчас синхронный и валит запрос на больших выборках.

[задача] Сделай экспорт фоновым: постановка в очередь, статус по job id.

[образец] Очередь уже есть — internal/queue, посмотри, как в ней сделан
воркер импорта, и сделай так же.

[границы] Схему БД не трогай, новых зависимостей не добавляй,
API существующих ручек не меняй.

[проверка] Напиши тест на два случая: успех и падение воркера с ретраем.
Прогони go test ./internal/... и покажи вывод.

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

Чего паттерны не чинят

  • Качество кода. Данные EASE 2025 недвусмысленны: по метрикам сопровождаемости и безопасности разница между паттернами теряется в шуме. Промпт — про скорость договорённости, а не про надёжность результата.
  • Забитый контекст. Если вы третий раз подряд поправляете модель в одной сессии, дело уже не в формулировке: в контексте лежат все провальные подходы, и они тянут ответы вниз. Новая сессия с промптом, вобравшим всё выясненное, почти всегда обгоняет длинную переписку.
  • Незнание своего проекта. Промпт «сделай по образцу» требует, чтобы вы знали образец. Здесь модель не помощник, а усилитель: она усиливает и понимание, и его отсутствие.
  • Неверную задачу. Идеально сформулированный запрос на ненужную фичу выполняется идеально.

С чего начать на этой неделе

Возьмите три последние задачи, которые пришлось переделывать после генерации, и посмотрите, чего не хватало в исходном запросе. Почти всегда это одно из трёх: не назван файл, не назван образец, не назван критерий готовности.

Дальше заведите себе черновик из пяти строк — контекст, задача, образец, границы, проверка — и неделю заполняйте его на каждой нетривиальной задаче. Что повторяется во всех промптах, переносите в файл правил проекта, там ему и место.

В IT-ХОЗЯЕВА такие черновики участники разбирают на еженедельном воркшопе по вайбкодингу: приносят промпт и получившийся дифф, смотрим, где потерялась формулировка. Практический контекст задач, на которых это отрабатывается, — в разборе вайбкодинга на практике, а выбор инструмента под такой процесс — в сравнении Cursor, Claude Code и Windsurf. Разобрать процесс на своём проекте можно с ментором — это входит в тариф ХОЗЯИН за 2000 ₽/мес.