Одна идея этого урока: качество результата агента определяется до первой строки кода – качеством постановки задачи.
Знакомая ситуация
Ты пишешь агенту: «Сделай страницу записи на практикум». Через пять минут страница готова – красивая. Но поля не те, оплата не подключена, а что делать с записавшимся дважды – агент решил по-своему.
Ты начинаешь длинную переписку: «нет, поле телефона обязательное… нет, после оплаты письмо… нет, повторная запись – показать, что уже записан». Десять итераций спустя фича работает. Всё это можно было сказать заранее – одним экраном текста. Агент не угадывает требования, он их дорисовывает наугад.
Спецификация (spec) – это твои решения из всего курса, записанные до старта: что за проблема, где границы, какие краевые случаи, как поймём, что готово. Агент строит ровно настолько хорошо, насколько хороша постановка.
Из чего состоит спека
Ничего нового изобретать не нужно – это сборка инструментов из прошлых модулей в один короткий документ:
1
Проблема и пользователь problem & userКто и зачем этим пользуется (урок 4). «Куратор школы отмечает оплаты вручную и тратит час в день» – агент сразу понимает, что оптимизировать.
2
Границы и данные boundaries & data modelКакие модули затрагиваем, какие не трогаем, что происходит с данными (уроки 7–8). «Модуль оплат не трогать, только читать из него статус».
3
Краевые случаи edge casesЧто делать в неудобных сценариях (урок 6): повторная запись, оплата не прошла, мест нет. Не перечислишь ты – агент решит сам, и молча.
4
Критерии приёмки acceptance criteria«Фича готова, когда…» – проверяемый список. «Готово, когда: запись создаётся, письмо уходит, повторная запись показывает статус». Это и планка для агента, и твой чек-лист на приёмке.
Важно: хорошая спека – не роман. Полстраницы структурированных пунктов бьют три страницы прозы: агенту легче следовать списку, а тебе легче проверить, что ничего не забыто. Официальные практики Claude Code говорят то же самое про полезные спеки: они самодостаточны, называют границы и «что вне скоупа» и заканчиваются проверкой, что фича работает.
Постоянная память проекта
Часть постановки не меняется от задачи к задаче: стек, стиль, твои принципы, ограничения. Повторять их в каждом промпте – работа мидла. Для этого есть файл правил проекта (project memory) – CLAUDE.md и аналоги. Агент читает его в начале каждой сессии: это его «должностная инструкция».
Правила обращения с этим файлом – из официальных практик:
Коротко и по делу. Для каждой строки спроси: «Если убрать – агент начнёт ошибаться?» Нет – убирай. Раздутый файл правил хуже пустого: важное тонет в шуме, и агент игнорирует половину.
Только то, что нельзя вычислить из кода. Твои принципы (например, «глубокие модули, минимум сложности»), запреты («модуль оплат не трогать без явного разрешения»), неочевидные грабли проекта.
Ухаживай как за кодом. Агент нарушил правило – проверь: может, оно сформулировано мутно или утонуло в длинном файле. Правь и подрезай регулярно.
Получается двухэтажная постановка: постоянные правила живут в файле проекта, переменная часть – короткая спека конкретной задачи. Вместе они закрывают 90% вопросов, которые агент иначе решил бы за тебя.
Джун · промпт из одной строки«Сделай страницу записи». Все решения агент принимает сам, потом десять итераций «нет, не так». Время экономится на постановке и теряется на переделках – с процентами.
Мидл · длинный промпт каждый разПишет подробную простыню под каждую задачу, заново повторяя стек, стиль и принципы. Работает, но дорого: половина текста кочует из промпта в промпт, а структуры всё равно нет – что-то да забудется.
Сеньор · спека по шаблону + правила в файлеПостоянное – в файле правил проекта, переменное – в короткой структурированной спеке: проблема, границы, краевые случаи, критерии приёмки. Минимум слов, максимум решений.
Проверь себя
1. Ты ставишь агенту задачу «добавь в бота выдачу домашних заданий». Что из этого важнее всего дописать в постановку?
Тон сообщений легко поправить потом, а вот краевые случаи агент молча решит сам – и не так (урок 6). Расписывать реализацию – значит делать работу агента за него: КАК – его зона (урок 19). Твоя зона – поведение системы в неудобных сценариях и проверяемое «готово».
2. Агент третий раз подряд нарушает правило из твоего файла правил проекта – например, снова трогает модуль оплат. Наиболее вероятная причина?
По официальным практикам это типовой диагноз: в перегруженном файле правил инструкции теряются, и агент игнорирует половину. Лечение – не дописывать, а подрезать: убрать всё, без чего агент не ошибается, а критичное правило сформулировать коротко и однозначно. Смена модели мутную постановку не чинит.
3. Что из этого должно жить в файле правил проекта, а не в спеке конкретной задачи?
В файл правил идёт только то, что верно для каждой сессии: стиль, ограничения, принципы. Конкретная кнопка и критерий приёмки конкретной фичи – это спека задачи: они устареют, а файл читается каждый раз и не должен копить мусор.
Что говорить агенту уже сегодня
Перед задачей: вот спека: проблема, границы, краевые случаи, критерии приёмки – задай вопросы, если чего-то не хватает, прежде чем строить
Собрать спеку диалогом: я хочу сделать [фичу] – проинтервьюируй меня про краевые случаи и компромиссы, потом составь короткую спеку
Завести память проекта: создай файл правил проекта: стек, мои принципы, что запрещено трогать – коротко, только то, что нельзя понять из кода
Гигиена правил: проверь файл правил проекта: что можно убрать без потери, какие правила сформулированы неоднозначно?
Источники
Anthropic, Best practices for Claude Code – эффективный CLAUDE.md, точный контекст в промптах, «пусть агент проинтервьюирует тебя» и самодостаточные спеки.