Многие жалуются, что ИИ-программирование работает не так хорошо — код, который выдаёт Claude Code, всегда кажется немного не тем. Проблема обычно не в ИИ. Проблема в том, что требования были выражены слишком размыто.
Открытый Spec-Kit (Spec-Driven Development Toolkit) от GitHub решает именно эту проблему. Его основная философия настолько проста, что почти скучна: сначала напишите спецификацию, потом пишите код.
Но именно эта «скучная» философия меняет то, как многие люди сотрудничают с ИИ.
Он не учит вас кодить — он учит вас «говорить понятно»
Spec-Kit — это не ещё один ассистент ИИ-программирования. Это тулчейн, который учит вас общаться с ИИ.
Весь рабочий процесс состоит из четырёх шагов:
- Specify: Определите, что вы хотите сделать
- Plan: Спланируйте, как это сделать
- Tasks: Разбейте на маленькие задачи
- Implement: Выполните и реализуйте
Звучит очень похоже на повседневную работу продакт-менеджера. Но разница в том, что Spec-Kit структурирует эти шаги в формат, который ИИ может понять.
Четыре сценария: как использовать
Запуск нового проекта: Раньше вы говорили ИИ «собери мне React-проект», и он мог высыпать кучу конфигураций, которые вам не нужны. Теперь запустите uvx --from git+https://github.com/github/spec-kit.git specify init my-project. Он проведёт вас через заполнение проблемы, которую решает проект, выбор стека технологий и ключевых функциональных модулей. Сгенерированный spec.md становится единой основой для всего последующего ИИ-программирования.
Разработка сложных фич: Допустим, вы делаете «систему пользовательских разрешений». Сначала создайте файл спецификации, определите модель разрешений (RBAC/ABAC), перечислите ресурсы и операции для контроля, опишите граничные условия. Когда спецификация написана, проблема в основном продумана. Затем пусть ИИ пишет код — обычно он работает с первого раза.
Командное сотрудничество: Кто-то в команде использует Claude Code, кто-то Cursor, кто-то Copilot. Стили кода разбросаны. Решение Spec-Kit — сделать spec.md единственным источником правды (single source of truth). Независимо от того, кто пишет код, все сначала читают один и тот же файл спецификации, и выводы ИИ-инструментов становятся архитектурно согласованными.
Рефакторинг легаси-проектов: Унаследовав чужой старый код, используйте команду specify analyze для анализа структуры кода, генерации документов спецификации и идентификации модулей для рефакторинга. Сначала извлеките основную бизнес-логику в спецификацию, затем пусть ИИ перепишет с нуля, без исторического багажа.
Четыре практических совета
- Не делайте спецификации слишком детальными: Уточняйте «что», а не «как». Излишняя детализация на самом деле ограничивает креативность ИИ. «Перенаправление на главную после успешного входа» — достаточно. Не нужно писать «вызов API, проверка status===200…»
- Используйте ИИ для написания спецификаций: Сначала пообщайтесь с ИИ о требованиях, пусть он организует их в структурированный документ. Сам процесс чата — это уже уточнение требований.
- Спецификации — это живые документы: Напишите черновую версию → ИИ генерирует код → обнаружьте проблемы, обновите спецификацию → итерируйте. Это не контракт, который вы подписали и забыли.
- Используйте вместе с CLAUDE.md:
spec.mdопределяет «что»,CLAUDE.mdопределяет «как». Вместе ИИ пишет код, который выглядит так, как будто вы написали его сами.
Когда он вам не нужен
Простые скрипты, быстрые прототипы, изменение нескольких строк кода — просто скажите ИИ напрямую, не нужно запускать Spec-Kit.
Позиционирование Spec-Kit ясно: ИИ — просто исполнитель, вы — архитектор. Он помогает вам хорошо играть роль архитектора, превращая размытые идеи в исполняемые структурированные документы, а затем передавая их ИИ для реализации.