Модель не знает, что вы считаете хорошим результатом, пока вы не показали контекст и критерии. Но и огромный промпт не заменяет ясных требований. В этом модуле мы разложим бриф на постоянный контекст проекта и маленькие рабочие задачи.
Постоянный контекст и задача — разные вещи
Постоянный контекст объясняет, что это за продукт, для кого он, какие решения приняты и какие действия опасны. Он живёт рядом с проектом — например, в README.md или поддерживаемом редактором файле инструкций проекта.
Рабочая задача касается одного изменения: добавить выбор услуги, исправить отправку формы, проверить состояние ошибки. Она должна быть небольшой и иметь условие приёмки.
Не помещайте в файл проекта секреты, реальные заявки клиентов или инструкции вроде «всегда меняй всё». Контекст должен помогать агенту сориентироваться, а не выдавать лишние полномочия.
Формула задачи
- Контекст: какие файлы и поведение относятся к изменению?
- Результат: что пользователь сможет сделать?
- Ограничения: что не менять, какие состояния сохранить?
- Критерии приёмки: какие наблюдаемые случаи должны пройти?
- Проверка: как запустить изменённую часть и увидеть результат?
Пример запроса
Добавь на существующую страницу услуги форму: услуга, имя и контакт. Используй текущие стили и не меняй навигацию. До отправки проверь обязательные поля и показывай сообщение рядом с полем, которое нужно исправить. После успешной отправки покажи подтверждение; если сервер вернул ошибку, не показывай успех и дай повторить запрос. Сначала изучи связанные файлы и предложи короткий план. После согласования меняй только эти файлы, перечисли diff и напиши, как проверить три состояния: успех, пустой контакт, ошибка запроса. Пока не подключай оплату или реальную CRM.
Хороший признак — агент может назвать файлы, состояния и способ проверки. Если ответ звучит «я всё сделаю», спросите о плане, не разрешая менять проект вслепую.
Рабочий цикл
прочитать контекст → попросить план → выполнить один шаг → посмотреть diff
↑ ↓
зафиксировать решение ← проверить сценарии ← запустить проектПеред новым рисковым шагом создайте checkpoint в Git или в механизме вашей среды. После шага проверьте именно изменённые места: не полагайтесь только на текстовый отчёт агента.
Если агент ушёл не туда
Остановите серию правок. Напишите, что конкретно не совпало с критерием, назовите неожиданные файлы и попросите не менять их. Сначала восстановите устойчивую версию или отмените неверный diff, потом повторите запрос меньшего размера. Не просите «поправь всё красиво»: это не ограничивает область изменений.
Практика
- Создайте
README.mdили файл инструкций с аудиторией, сценарием, выбранным стеком, запрещёнными секретами и командой запуска. - Сохраните шаблон запроса.
- Попросите агента изменить только текст кнопки и получить план до изменения кода.
- Посмотрите список файлов и разницу с предыдущей версией.
- Повторите на одном критерии из брифа и запустите результат.
Артефакт: контекст проекта README.md + одна задача агенту с критериями и проверкой.
Самопроверка
- Сможет ли другой человек отличить постоянные правила от текущей задачи?
- Указаны ли конкретные ограничения и изменяемая область?
- Есть ли проверка, которую можно выполнить без доверия отчёту модели?