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

В этой статье
Меня зовут Арина Михална, и я считаю, что спецификация для Claude Code проваливается не потому, что она плохо написана, а потому что в ней нет критериев приёмки и явных границ — агент честно делает то, что написано, но не то, что ты имел в виду. Хорошая спека — это не абзац текста про фичу, а пять обязательных разделов: цель, контекст, ограничения, критерии приёмки, что не трогать. Ниже — шаблон и чек-лист, по которым можно проверить свою спеку за пять минут.

Почему «хорошая на вид» спека всё равно проваливается
Смотришь на спецификацию — вроде всё есть: что делать, зачем, какой стек. А Claude Code через полчаса выдаёт код, который технически работает, но не решает задачу. Знакомо.
Дело в том, что «подробно» и «однозначно» — разные вещи. Спека может быть на три экрана текста с описанием фичи, дизайна, пользовательских историй — и при этом ни строчки о том, как понять, что задача закончена. Агент дочитывает описание, пишет код, запускает — компилируется, тесты (если есть) зелёные — и останавливается. Он сделал ровно то, что было формально написано. Просто написано было не то, что нужно на самом деле.
Сама несколько раз ловила себя на том, что пишу спеку как для человека — рассчитываю, что агент «поймёт по контексту», что фича должна работать вот так, а не только компилироваться. Не понимает. Контекст для него — это буквально то, что лежит в файле, а не то, что я держу в голове.
Вторая причина провала — отсутствие явных границ. В спеке написано «добавь пагинацию к списку заказов», а не написано, что при этом нельзя трогать существующий API-контракт. Агент добросовестно меняет и то, и другое — и ты получаешь сломанный фронтенд, который об этом контракте ничего не знал.
CLAUDE.md, spec.md, Plan Mode, Beads — кто за что отвечает
Частая путаница — все эти форматы решают разные задачи, и смешивать их означает получить кашу вместо системы. Разложу по таблице, чтобы не гадать каждый раз, что куда писать.
| Формат | Что решает | Живёт как | Когда применять |
|---|---|---|---|
| CLAUDE.md | постоянный контекст проекта: стек, конвенции, структура папок | файл в корне репо, обновляется редко | всегда, для любого проекта в Claude Code |
| spec.md (разовая спека) | конкретная задача/фича: цель, ограничения, критерии приёмки | одноразовый файл, коммитится и архивируется | одна фича, один разработчик, задача на 1–3 сессии |
| Plan Mode | план действий агента перед правкой кода, обсуждается до запуска | временный, живёт в сессии чата | быстрая задача, план нужен для контроля, но не для истории |
| Spec Kit | структурированный цикл Specify → Plan → Tasks с шаблонами | набор файлов в репозитории, версионируется в git | команда, задачи регулярные, нужна воспроизводимость процесса |
| Beads | трекер задач с жизненным циклом (open → in progress → done) для агентов | база задач, синхронизируется между сессиями | параллельная работа нескольких агентов/сессий, поток задач |
Если ты один и задача разовая — не тащи в проект Spec Kit ради ритуала, файла spec.md на пять разделов достаточно. Если у тебя команда и агенты работают параллельно над разными кусками — вот тут уже нужен трекер типа Beads, иначе задачи теряются между сессиями.
Разобралась, где путают спецификацию с файлом памяти проекта — но это только один из способов, где агент теряет контроль.
В канале регулярно разбираю похожие истории на живых примерах: где Claude Code уходит не туда и как это ловить до того, как он всё сломал — , полезно держать в голове при любой работе с агентом.
здесь про снос аккаунта из-за похожей невнимательности к деталям
Шаблон спецификации, который реально работает
Вот структура, которую можно скопировать в spec.md прямо сейчас. Пять разделов, ни одного лишнего — заказчик хорошей спеки хочет пять минут на её написание, а не два часа документации ради документации.
# Спецификация: {{название фичи}}
## Цель
{{что должно работать после выполнения — одно предложение}}
## Контекст
{{зачем это нужно, какая проблема решается, ссылка на
issue/задачу если есть}}
## Ограничения
- {{технические рамки: какие библиотеки/паттерны
использовать}}
- {{что должно остаться совместимым — API, схема БД,
контракты}}
## Критерии приёмки
- [ ] {{проверяемое условие 1 — что можно
запустить/увидеть}}
- [ ] {{проверяемое условие 2}}
- [ ] {{проверяемое условие 3}}
## Не трогать
- {{файлы/модули/API, которые агент не должен менять}}
Разберу на примере: добавляем пагинацию в список заказов в интернет-магазине.
# Спецификация: пагинация списка заказов
## Цель
Список заказов в админке грузит по 20 штук на странице
вместо всех 4000 сразу.
## Контекст
Страница /admin/orders виснет на 8+ секунд при загрузке,
потому что тянет
все заказы разом. Нужна постраничная навигация без изменения
существующего API-контракта.
## Ограничения
- Использовать существующий query-параметр `page` в роуте,
он уже зарезервирован
- Не менять формат ответа API — только добавить поля total и
pageCount
- Стиль пагинации — как на странице /admin/products, там уже
есть готовый компонент
## Критерии приёмки
- [ ] Страница /admin/orders грузится быстрее 1 секунды при
4000+ заказах
- [ ] Переключение страниц не перезагружает всю страницу
(SPA-навигация)
- [ ] Существующие тесты на /admin/orders всё ещё зелёные
- [ ] Прямая ссылка вида /admin/orders?page=3 открывает
нужную страницу
## Не трогать
- API-контракт GET /api/orders (другие клиенты на него
завязаны)
- Компонент фильтрации заказов выше таблицы
Разница с типичной спекой из топа выдачи — здесь критерии приёмки проверяемы буквально, без интерпретаций. «Быстрее 1 секунды» агент может замерить сам, а «страница должна быть удобной» — не может, и в итоге придумывает удобство по своему разумению.
Чек-лист: спека готова к передаче агенту
Перед тем как бросить файл в Claude Code, прогони его по этим семи пунктам. Если хотя бы два не выполнены — спека не готова, доработай, не запускай.
- Цель формулируется одним предложением, без «и», «а также», «в том числе».
- Есть хотя бы один критерий приёмки, который можно проверить автоматически (тест, команда, метрика).
- Есть хотя бы один критерий, который проверяется глазами (внешний вид, поведение UI).
- Явно написано, какие файлы/модули/контракты трогать нельзя.
- Указаны технические ограничения (библиотеки, паттерны, совместимость), а не оставлены «на вкус агента».
- Спека не смешана с постоянным контекстом проекта — в ней нет описания стека или структуры папок (это в CLAUDE.md).
- Спеку можно прочитать за 2 минуты — если длиннее, скорее всего в неё влезла лишняя вода вместо конкретики.

По материалам: разбор spec-driven development на Analytics Vidhya, практики работы с Claude Code от Anthropic, репозиторий Spec Kit на GitHub.
Читайте также
- Как проверять код после AI-агента: чек-лист 2026
- Claude Code API в 2026: как подключить, сколько стоит и когда он нужен
- Подписка Claude Code в 2026: тарифы и что входит
- Как установить Claude Code в 2026: пошаговый гайд для новичков
- На портале «Мастерская нейросетей»: Как зарабатывать на нейросетях с Claude Code без навыков программирования
Если после чек-листа спека всё ещё кажется тебе шаткой — это нормальный сигнал, не повод стыдиться. Я, Арина Михална, регулярно пишу про то, как вообще строить работу с агентами так, чтобы они не разваливали задачи по мелочам, в канале «А.М. решает вопросы» — там разбираю живые случаи, а не абстрактные советы. В боте у меня лежит гайд по установке Claude из России и по первым шагам с агентом — забрать его можно за подписку на канал, подписаться и получить доступ к разборам.
Чек-лист: что у тебя теперь есть
- Понимаешь, почему хорошая на вид спецификация не спасает от провала задачи
- Знаешь разницу между CLAUDE.md, spec.md, Plan Mode и Beads — и когда что применять
- Имеешь готовый шаблон спецификации с обязательными разделами
- Умеешь проверить спеку по чек-листу перед тем, как отдавать её агенту
- Понимаешь, куда именно закладывать критерии приёмки, чтобы Claude Code сам понял, что закончил
Частые вопросы
Почему Claude Code не следует спецификации, даже если она подробная?
Обычно потому, что в спеке нет критериев приёмки — агент не понимает, когда задача закончена, и останавливается на "код запустился" вместо реального результата. Вторая причина — размытые границы: не написано, чего агент точно не должен трогать.
Чем плохой CLAUDE.md отличается от хорошей спецификации задачи?
CLAUDE.md — это постоянный контекст о проекте (стек, конвенции, структура папок), он живёт годами. Спецификация — одноразовый документ под конкретную фичу с целью, ограничениями и критериями приёмки. Путать их — частая ошибка.
Нужен ли Spec Kit или Beads, если я работаю один на маленьком проекте?
Для маленькой одноразовой задачи хватит спецификации в виде markdown-файла из 5 разделов. Spec Kit и Beads оправданы, когда задач много, команда больше одного человека или проект живёт месяцами и спеки нужно версионировать.
Как понять, что спецификация готова передавать агенту?
Прогони её по чек-листу: есть цель одним предложением, явные ограничения, критерии приёмки, которые можно проверить автоматически или глазами, и список того, что агент не должен трогать. Если хотя бы этого нет — спека не готова.
Можно ли просто написать длинный промпт вместо файла спецификации?
Для задачи на 10 минут — можно. Для фичи, которая займёт несколько сессий Claude Code, промпт в чат теряется и забывается контекстом. Файл спецификации в репозитории переживает перезапуск сессии и коммитится вместе с кодом.
Следующий шаг
Собери свой сайт за вечер
Свой сайт на Claude за один вечер — и продавай такие же от 30 000 ₽. 8 уроков в записи, без кода и без дизайнера.
Хочу сайт за вечерИли просто следи
А.М. решает вопросы — 5 000+ подписчиков, разборы Claude каждый день.
Подписаться в Telegram

