Кратко: Все ведущие инструменты сегодня советуют один порядок: сначала спецификация, потом код. У Claude Code есть режим планирования, в котором он только читает и планирует; у Lovable есть режим Plan, который пишет план до того, как трогать код; у GitHub есть Spec Kit, который отделяет то, что нужно пользователю, от того, как это строить. Хорошая спецификация для AI-инструмента содержит границы и то, что не входит, пользовательские истории с критериями приёмки, модель данных, роли и права и способ проверить, что всё работает. Роли и права инструменты не просят, и именно там рождаются уязвимости.
Почему AI нужна спецификация больше, чем человеку
Разработчик-человек, если чего-то не знает, спросит. AI-инструмент пойдёт дальше. Он выберет наиболее вероятную догадку и построит на ней экран, таблицу и API. Когда окажется, что догадка была неверной, на ней уже будут стоять три слоя.
Есть и обратная проблема: инструмент делает ровно то, что попросили. Если в запросе написано «список заказов», он построит список заказов. Что пользователь не должен видеть чужие заказы, написано не было, поэтому и не построено.
Спецификация для AI-инструмента не длиннее обычной. Она просто должна быть более явной. Всё, что человек понял бы из контекста, нужно прописать.
Что рекомендуют сами инструменты
| Инструмент | Что советует сделать до кода |
|---|
| Claude Code | Режим планирования, в котором инструмент только читает и планирует. Для крупных задач документация рекомендует, чтобы инструмент проинтервьюировал вас и записал файл SPEC.md, а реализацию запускать уже в новой сессии. По документации хорошая спецификация называет файлы и интерфейсы, указывает, что находится вне границ, и заканчивается сквозной проверкой. |
| Lovable | Режим Plan, который составляет план до начала работы с кодом: ключевые решения, допущения, компоненты, модель данных и порядок реализации. Его рекомендуют использовать для крупных изменений и при проектировании базы данных. |
| Cursor | Файлы правил внутри проекта, которые инструмент читает при каждом запросе: соглашения, архитектура, запреты. |
| GitHub Spec Kit | Цепочка из спецификации, плана и задач. Спецификация описывает, что нужно пользователю и зачем, без привязки к технологиям. Каждая неясность помечается, и к концу таких открытых пометок остаться не должно. |
| Kiro | Три файла: требования с критериями приёмки, проект с архитектурой и потоками данных и задачи, за которыми можно следить |
Что должно быть в спецификации
- Что за продукт и для кого. Одно предложение: кто пользователь, какая у него проблема, какое главное действие.
- Границы и что не входит. Что мы строим сейчас и, так же явно, чего мы не строим. Без второго списка инструмент сам начнёт расширять границы.
- Пользовательские истории с критериями приёмки. В проверяемой форме: дано состояние, когда пользователь совершает действие, тогда система отвечает так.
- Модель данных. Сущности, важные поля и связи между ними. Это то, что потом менять дороже всего.
- Роли и права. Кто что видит, кто что меняет, и что происходит, если кто-то пытается открыть чужое.
- Интеграции. Какие есть внешние системы, что между ними передаётся и какой источник у каждого поля.
- Как проверяем. Хотя бы один сквозной сценарий на каждую возможность, включая сценарий, в котором пользователь пытается сделать то, что ему запрещено.
Дыра, которую оставляют инструменты
Ни в одном из руководств инструментов роли и права не выделены отдельным разделом спецификации. Ближе всего Lovable с состояниями «вошёл» и «не вошёл». Это не мелочь: уязвимость, при которой любой пользователь читает чужие данные, самая частая проблема приложений, собранных с AI.
Поэтому в спецификации, которую пишем мы, права это обязательный раздел с таблицей: роль, что видит, что меняет, что запрещено. И для каждой строки «запрещено» есть сценарий проверки.
Как это выглядит на практике
- Разговор об анализе требований: что нужно бизнесу, кто пользователи, какие данные.
- Письменная спецификация в формате, который инструмент читает: границы, истории, данные, права, проверки.
- Инструмент строит план по спецификации, а человек проверяет этот план до того, как будет написан код.
- Реализацию проверяют по критериям приёмки, включая запрещённые сценарии.
Спецификация остаётся живой: когда требование меняется, его сначала меняют в спецификации, а потом в коде. Иначе через месяц спецификация описывает другую систему.
Частые вопросы
Нужна ли спецификация, если работать с Lovable или Claude Code?
Да, и даже больше, чем обычно. AI-инструмент заполняет каждый пробел догадкой и строит на её основе код. Сами инструменты рекомендуют сначала планировать, а потом писать код: у Claude Code есть режим планирования, у Lovable есть режим Plan.
Чем спецификация для AI-инструмента отличается от обычной?
Она должна быть более явной: всё, что человек понял бы из контекста, например кто что может видеть, нужно прописать. И она должна быть в формате, который инструмент читает, с проверяемыми критериями приёмки.
Что в спецификации самое важное?
Модель данных и права. Неверную модель данных потом менять дороже всего, а непрописанные права это самый частый источник уязвимостей в приложениях, собранных с AI.
Что такое spec driven development?
Это подход, при котором спецификацию пишут до кода, а план и задачи строят на её основе. GitHub Spec Kit и Kiro построены вокруг этого подхода, а Claude Code и Lovable поддерживают его через режимы планирования.
Кто пишет спецификацию, я или инструмент?
Вы оба. Инструмент может проинтервьюировать вас и набросать черновик, но решения, особенно о том, кто что может делать, должен принимать человек, который знает бизнес.
С чего начать
Напишите одним предложением, что это за продукт и для кого он нужен, а затем перечислите роли в системе и что каждая из них может видеть. Именно с этих двух строк начинается любая хорошая спецификация.
Написать мне
По теме: Разработка и внедрение CRM, IT-консалтинг, Зачем нужен архитектор