VibeeРезультат агента меняет не длина промпта и не «магические» фразы, а четыре вещи: есть ли проверка, которую он может запустить сам; названы ли конкретные файлы; описан ли симптом вместо готового диагноза; и ограничены ли рамки задачи. Всё остальное — вторично.
Ниже — правки формулировок с примерами «до» и «после» и объяснением, почему именно это меняет поведение.
Одна вещь важнее остальных
Дайте агенту проверку, которую он может запустить сам.
Агент останавливается, когда работа выглядит сделанной. Если проверять умеете только вы, то вы и есть цикл проверки: каждая ошибка ждёт, пока вы её заметите. Как только появляется что-то, что возвращает «прошло» или «не прошло», цикл замыкается без вас: агент делает, запускает, читает результат и повторяет, пока не сойдётся.
Проверкой может быть что угодно, что даёт читаемый сигнал: набор тестов, код возврата сборки, линтер, скрипт, сравнивающий вывод с эталоном, скриншот против макета.
| До | После |
|---|---|
| напиши функцию, которая проверяет email | напиши функцию validateEmail. примеры: user@example.com — true, invalid — false, user@.com — false. после реализации запусти тесты и покажи вывод |
| сделай, чтобы дашборд выглядел лучше | [скриншот] сделай по этому макету. сними скриншот результата, сравни с исходным, перечисли различия и исправь |
| сборка падает | сборка падает с ошибкой [текст ошибки]. почини и убедись, что сборка проходит. лечи причину, а не глуши симптом |
Отдельная просьба, которая экономит время: требуйте не утверждения «готово», а доказательства — вывод теста, команду и её результат, скриншот. Прочитать доказательство быстрее, чем перепроверять всё самому, и это работает даже для сессий, за которыми вы не следили.
Пять правок формулировки
| Правка | До | После |
|---|---|---|
| Сузить область | добавь тесты для foo.py | напиши тест для foo.py на случай, когда пользователь разлогинен. без моков |
| Указать источник ответа | почему у ExecutionFactory такой странный интерфейс? | посмотри историю git по ExecutionFactory и расскажи, как этот интерфейс сложился |
| Сослаться на образец | добавь виджет календаря | посмотри, как сделаны виджеты на главной, HotDogWidget.php — хороший пример. сделай по тому же образцу виджет календаря, без новых библиотек |
| Описать симптом | почини баг с логином | пользователи жалуются: после истечения сессии логин не проходит. смотри src/auth/, особенно обновление токена. сначала напиши падающий тест, который это воспроизводит, потом чини |
| Назвать границы | приведи в порядок эту страницу | правь только шаблон страницы и её стили. общие стили и другие страницы не трогай. если понадобится изменить что-то за этими границами — сначала скажи |
Логика везде одна: вы отдаёте не задачу, а задачу вместе с контекстом, который иначе агент будет угадывать. Угадывает он уверенно и правдоподобно — в этом и проблема.
Сначала план, потом код
Если сразу отпустить агента писать код, он может уверенно решить не ту задачу. Разделение помогает: сначала «прочитай и разберись», потом «предложи план», и только потом «делай».
- Разведка. «прочитай src/auth и объясни, как устроены сессии и вход. заодно посмотри, как хранятся секреты».
- План. «хочу добавить вход через Google. какие файлы меняются, как выглядит поток сессии, составь план».
- Реализация. «сделай по своему плану. напиши тесты на обработчик колбэка, запусти набор тестов и почини падения».
- Фиксация. Коммит с внятным сообщением.
План стоит времени, поэтому его не нужно требовать всегда. Правило простое: если изменение можно описать одним предложением — план лишний. Если задача трогает несколько файлов, вы не уверены в подходе или плохо знаете этот код — план окупается.
Симптом вместо диагноза
Самая частая ошибка формулировки — отдать агенту свою гипотезу вместо наблюдения. «Похоже, кэш не инвалидируется, почини кэш» звучит полезнее, чем «после сохранения список обновляется через раз», но работает хуже: агент примет вашу гипотезу за факт и будет чинить кэш, даже если дело не в нём.
Рабочий порядок: сначала симптом и способ воспроизвести, потом (отдельной фразой) ваша гипотеза с пометкой, что это догадка. Тогда агент проверит её, а не будет от неё отталкиваться.
Правила проекта вместо повторов
Всё, что вы объясняете агенту второй раз, должно переехать в файл правил проекта: CLAUDE.md у Claude Code, AGENTS.md у Codex. Он читается в начале каждой сессии.
| Класть в файл | Не класть |
|---|---|
| команды, которые нельзя угадать (как собрать, как запустить тесты) | всё, что видно из кода |
| правила стиля, отличающиеся от общепринятых | стандартные соглашения языка |
| договорённости репозитория: ветки, коммиты, куда что класть | подробная документация API — на неё лучше ссылку |
| особенности окружения: нужные переменные, странности сборки | то, что часто меняется |
| принятые архитектурные решения и их причина | пересказ структуры файлов |
Главное ограничение — длина. Раздутый файл приводит к обратному эффекту: важные правила теряются в шуме, и агент начинает игнорировать половину. Проверочный вопрос к каждой строке: «если это убрать, агент начнёт ошибаться?» Нет — строку в удаление. Если одно правило упорно игнорируется, скорее всего файл просто слишком длинный.
Контекст как расходник
Контекст агента — конечный ресурс, и он тратится на всё: ваши сообщения, прочитанные файлы, вывод команд. По мере заполнения качество падает: агент начинает «забывать» ранние инструкции и чаще ошибаться. Отсюда несколько практических правил.
- Сбрасывайте контекст между несвязанными задачами. Одна сессия — одна тема.
- Два неудачных исправления подряд — сигнал начать заново. Контекст уже забит неудачными попытками; чистая сессия с промптом, учитывающим то, что вы узнали, почти всегда лучше длинной сессии с накопленными правками.
- Разведку отдавайте подагентам. Они читают файлы в своём контексте и возвращают выжимку, а ваш основной контекст остаётся чистым для работы.
- Не просите «исследовать» без границ. Неограниченное «разберись, как тут всё устроено» съедает контекст сотнями файлов.
Заготовки, которые работают
Интервью перед большой задачей. Вместо того чтобы писать спецификацию самому, попросите агента вытащить её из вас вопросами: «хочу сделать [коротко]. подробно проинтервьюируй меня: техническая реализация, интерфейс, крайние случаи, риски и компромиссы. не задавай очевидных вопросов, копай в сложное. когда закроем всё — запиши готовую спецификацию в SPEC.md». Дальше — новая сессия с чистым контекстом и готовым файлом.
Ревью чужими глазами. «проверь дифф против PLAN.md: всё ли из требований реализовано, есть ли тесты на перечисленные крайние случаи, не изменилось ли что-то за рамками задачи. пиши только пробелы, стилистические предпочтения не нужны». Важно, чтобы проверял не тот же контекст, который писал: агент, видевший ход собственных рассуждений, наследует и собственную ошибку.
Массовая однотипная правка. Сначала «составь список файлов, которые нужно перевести, и запиши в files.txt», потом цикл с неинтерактивным запуском по одному файлу. Отладьте формулировку на двух-трёх файлах, прежде чем запускать на двух тысячах.
Что не работает
- Роль вместо задачи. «Ты опытный сеньор с 20-летним стажем» не добавляет знаний. Добавляет их ссылка на конкретный файл.
- Вежливость и угрозы. Ни «пожалуйста», ни «это очень важно» не меняют результат. Меняет — критерий проверки.
- Огромный промпт вместо файла правил. То, что повторяется каждую сессию, должно жить в репозитории, а не в вашем буфере обмена.
- «Сделай хорошо». У модели нет вашего определения «хорошо». Есть либо пример, либо проверка, либо ни того ни другого.
- Одна формулировка на все инструменты. Промпт настраивается под конкретную обвязку: у одних агентов сильнее план-режим, у других — неинтерактивный запуск.
Когда формулировки настроены, следующим узким местом становится проверка результата — как проверять код от ИИ. Что именно агент делает с правами на файлы, разобрано в статье про ИИ-агентов, а порядок действий для первого проекта — в вайбкодинге с нуля. Разница между инструментами по этой части — в сравнении Claude Code и Codex.