Перейти к основному содержимому
Средний

Разработка на основе спецификаций со Spec Kit

Вайб-кодинг — «собери мне дашборд», принимаешь всё, что вернулось, — отлично работает, пока фича не становится большой. Тогда агент начинает дрейфовать: он забывает раннее решение, заново изобретает функцию или выдаёт что-то, что технически запускается, но не является тем, что вы имели в виду. Разработка на основе спецификаций (Spec-Driven Development, SDD) — это решение, которое в 2026 году прижилось у всего сообщества агентного кодинга: вместо того чтобы относиться к промпту как к одноразовому, вы делаете письменную, проверяемую спецификацию источником истины и поручаете агенту генерировать код из неё.

Открытый Spec Kit от GitHub превращает эту идею в конкретный рабочий процесс, который вы можете запустить прямо внутри Claude Code уже сегодня.

What you'll learn
  • Понять, что такое разработка на основе спецификаций и какую проблему она решает
  • Пройти фазы Spec Kit: constitution → specify → plan → tasks → implement
  • Установить Specify CLI и подключить его к Claude Code
  • Знать опциональные контрольные точки качества (clarify, analyze, checklist)
  • Решить, когда SDD стоит затраченных усилий, а когда от неё лучше отказаться

Почему спецификации, а не просто промпты​

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

  • Дрейф — агент противоречит раннему решению, потому что нигде его не записал. Спецификация — это память.
  • Неоднозначность — «сделай красиво» означает десять разных вещей. Принуждение оформить требования в прозу выявляет пробелы до того, как появится код, где их дёшево исправить.
  • Непроверяемые диффы — сгенерированный PR на 2000 строк трудно оценить. Проверенная спецификация + план делают дифф ожидаемым, а не неожиданным.

Ментальная модель: намерение — это ценная, долговечная вещь; код — это нижестоящий, регенерируемый артефакт. SDD — это дисциплинированный родственник собственного Plan Mode у Claude Code — сначала планируй, потом строй — масштабированный до целой фичи и сохранённый в файлы вашего репозитория.

Рабочий процесс Spec Kit​

Spec Kit структурирует фичу как короткий конвейер слэш-команд. Каждая из них записывает Markdown-артефакты в ваш репозиторий (в каталог .specify/), так что каждая фаза поддаётся проверке и контролю версий.

Guided walkthrough1 of 5
  1. Запустите /speckit.constitution один раз на проект. Эта команда записывает управляющие принципы — стиль кода, планку тестирования, архитектурные непреложности — в .specify/memory/constitution.md. Каждая последующая фаза сверяется с ними, так что это ваш долговечный страховочный барьер (воспринимайте его как CLAUDE.md, сфокусированный на принципах).

Опциональные контрольные точки качества​

Ещё три команды затягивают цикл, когда фича имеет высокую цену ошибки:

  • /speckit.clarify — допрашивает спецификацию на предмет недоопределённых областей и задаёт вам целевые вопросы до планирования. Лучше всего запускать сразу после specify.
  • /speckit.analyze — перекрёстно проверяет спецификацию, план и задачи на согласованность и пробелы в покрытии.
  • /speckit.checklist — генерирует чек-лист валидации, чтобы «готово» было определено и поддавалось проверке.
Pro tip
  • Запускайте /speckit.clarify перед /speckit.plan — устранять неоднозначность дешевле всего до того, как зафиксирована архитектура.
  • Относитесь к каждому сгенерированному артефакту как к PR: прочитайте его, исправьте и только потом переходите к следующей фазе.
  • Коммитьте артефакты .specify/ — это проверяемая запись намерения, стоящего за кодом.

Запуск с Claude Code​

Spec Kit поставляется с CLI под названием Specify, который встраивает слэш-команды в ваш проект. Он поддерживает более 30 кодинг-агентов, в том числе Claude Code.

Guided walkthrough1 of 3
  1. Используйте uv, чтобы установить его из репозитория. (Нужны Python + uv.)

Install the Specify CLI (uv)

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

Scaffold spec-driven workflow into a project

# new project
specify init my-feature

# or in the current repo
specify init --here

Then, inside Claude Code, run the pipeline

/speckit.constitution Establish principles: TypeScript strict, tests for every public function, no secrets in code.
/speckit.specify Build a CSV export for the reports page: users pick a date range and download a CSV of matching rows.
/speckit.clarify
/speckit.plan Next.js App Router, server action for the query, stream the CSV; no new dependencies.
/speckit.tasks
/speckit.implement
Watch out
  • Точный флаг выбора агента для specify init меняется от релиза к релизу — сверьтесь с quickstart в README, а не копируйте флаг вслепую.
  • SDD не отменяет необходимость проверять: прочитайте сгенерированный код и запустите его. Спецификация делает дифф проверяемым, но не автоматически правильным.
  • Никогда не помещайте секреты или учётные данные в спецификацию, план или конституцию — они коммитятся как любой другой файл.

Когда её использовать (и когда нет)​

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

What you'll learn
  • Берите SDD для: фич с нуля, многофайловых сборок, всего, что должен проверить коллега, или работы, которую вы передадите флоту субагентов.
  • Пропускайте SDD для: одноразовых скриптов, крошечных правок, исследовательского одноразового кода — обычный промпт или Plan Mode быстрее.
  • Brownfield тоже работает: направьте /speckit.specify на улучшение существующей кодовой базы, а не только на новые проекты.
SDD at a glance
Нажмите Enter или пробел, чтобы перевернуть карточку. Используйте стрелки влево и вправо для перехода между карточками.Показан термин.
1 / 5

Проверь себя​

Check yourself

0/3
  1. В чём основная идея разработки на основе спецификаций?
  2. Какая фаза Spec Kit должна фиксировать технологический стек и архитектуру?
  3. Когда разработка на основе спецификаций не стоит накладных расходов?
Key takeaways
  • Разработка на основе спецификаций делает источником истины проверяемую спецификацию, а не промпт, убивая дрейф, неоднозначность и непроверяемые диффы.
  • Spec Kit от GitHub (Specify CLI) приносит SDD в Claude Code в виде слэш-команд /speckit.*.
  • Конвейер таков: constitution → specify → (clarify) → plan → (analyze) → tasks → (checklist) → implement, и каждая фаза записывает поддающиеся проверке артефакты.
  • Держите ЧТО/ПОЧЕМУ в спецификации, а КАК — в плане; проверяйте каждый артефакт как PR, прежде чем двигаться дальше.
  • Используйте её для больших, неоднозначных или проверяемых фич; пропускайте для одноразовой работы — и всегда всё равно проверяйте сгенерированный код.

Далее​

  • Plan Mode — встроенный, более лёгкий цикл «планируй, прежде чем строить»
  • Slash Commands — как команды /speckit.* вписываются в систему команд Claude Code
  • CLAUDE.md & Memory Files — идея «принципы как память», стоящая за конституцией
  • Subagents — передайте проверенный список задач флоту агентов
  • Coding & Software Development — мышление «проверяй всё», от которого зависит SDD

Источники и дополнительное чтение​