ТЗ для нейросети — это задание кодинг-агенту, а не описание будущего ИИ-продукта. Если вы ищете, как составить техническое задание на разработку чат-бота или ИИ-агента для бизнеса, это другая тема. Здесь — документ, по которому Cursor, Claude Code или другой агент пишет код вашего проекта. Его ещё называют спецификацией для ИИ.
Почему агенты плохо понимают обычное ТЗ#
Обычное ТЗ часто написано в свободной форме: «нужен лендинг с шапкой, главным экраном, блоком преимуществ и формой обратной связи, дизайн современный, адаптивный». Человек-разработчик в таком случае задаст вопросы. Агент обычно не спрашивает, а додумывает:
- какой стек использовать;
- сколько карточек в блоке преимуществ и что в них;
- как шапка выглядит на телефоне;
- куда уходит заявка из формы;
- когда работа считается законченной.
Каждое такое додумывание — место, где результат может разойтись с тем, что вы имели в виду. Документация Claude Code формулирует это прямо: агент останавливается, когда работа выглядит законченной, а если проверить её нечем, проверкой становитесь вы сами.
Структурированное ТЗ: в чём разница#
Структурированное ТЗ отличается от обычного не объёмом, а формой. Каждый раздел отвечает на один вопрос, и каждый элемент описан по одному образцу. В ранней статье ProtoSpec о структурированном ТЗ мы делили его на три уровня. Они остались в основе шаблона ниже:
- глобальные параметры — стек, оформление, общие требования к адаптивности;
- описание каждого элемента — что содержит, как выглядит на разных экранах, какая разметка;
- связи — порядок блоков, переходы между ними, общие компоненты.
Тот же подход используют сами разработчики инструментов. В Kiro у каждой спецификации три файла: requirements.md с пользовательскими историями и критериями приёмки, design.md с архитектурой и tasks.md с планом задач. В GitHub Spec Kit работа идёт по цепочке: принципы проекта один раз, затем для каждой функции — спецификация, план, задачи и реализация. Для небольшого проекта хватит одного файла, но логика та же: сначала что и зачем, потом как, потом по шагам.
Чем ТЗ для нейросети отличается от других документов#
| Документ | Для кого | Что главное |
|---|---|---|
| ТЗ по ГОСТ | стороны договора | порядок приёмки, сроки, документация |
| Бриф для студии | дизайнер и менеджер | цели бизнеса, аудитория, референсы |
| ТЗ на ИИ-агента как продукт | команда разработки бота | сценарии диалога, интеграции, метрики качества |
| ТЗ для нейросети | кодинг-агент | цель, границы задачи, стек, проверяемые критерии готовности |
ТЗ, спецификация, PRD: это одно и то же?#
Почти. PRD (product requirements document) — документ о продукте: зачем он нужен и что должен уметь. Спецификация добавляет техническую часть: как это устроено. ТЗ для нейросети — практичная смесь обоих, урезанная до того, что нужно агенту для работы. Название не важно, важно, чтобы документ отвечал на вопросы, которые агент иначе решал бы наугад.
Шаблон ТЗ для кодинг-агента#
Восемь разделов. В квадратных скобках — что заменить, в строках с > — подсказка, её можно удалить.
# ТЗ: [название проекта или функции]
## 1. Цель
> Одна-две фразы: что должно появиться и зачем.
[Что делаем и какую проблему это решает.]
## 2. Пользователи и сценарии
> Кто пользуется и что делает по шагам.
- [Пользователь] открывает [страницу], делает [действие], получает [результат].
## 3. Что входит / что не входит
Входит:
- [функция 1]
- [функция 2]
Не входит:
- [что агент не должен делать, даже если это «логично»]
## 4. Стек и ограничения
- Стек: [язык, фреймворк, база, хостинг].
- Ограничения: [без новых зависимостей / без бэкенда / только эти библиотеки].
- Секреты и ключи — только в переменных окружения, не в коде.
## 5. Данные
> Какие данные есть, откуда берутся, где хранятся.
- [сущность]: [поля].
## 6. Интерфейс
> Экраны или блоки по порядку. Для каждого — что в нём и как он ведёт себя на телефоне.
1. [Экран или блок]: [содержимое].
## 7. Критерии готовности
> Только то, что можно проверить: команда, сценарий, видимый результат.
- [команда сборки или тестов] проходит без ошибок.
- [сценарий]: [ожидаемый результат].
## 8. Порядок задач
1. [Первая задача] — готово, когда [критерий].
2. [Вторая задача] — готово, когда [критерий].
Почему так:
- «Не входит» — самый полезный раздел. Агент склонен улучшать то, о чём его не просили. Прямой запрет дешевле, чем откат.
- Критерии готовности — то, что агент может проверить сам. «Работает быстро» — не критерий. «Сборка проходит, форма отправляет заявку, на ширине 360 px ничего не съезжает» — критерий.
- Порядок задач нужен, чтобы отдавать ТЗ по частям. Одна задача за раз — меньше шансов, что агент сделает половину всего.
Документация Claude Code советует то же самое: лучшие спецификации самодостаточны, называют затронутые файлы и интерфейсы, прямо говорят, что вне задачи, и заканчиваются проверкой, которая доказывает, что функция работает.
Пример заполненного ТЗ#
Для примера возьмём небольшой проект: калькулятор стоимости услуг для мастерской по ремонту техники. Цены в примере условные.
# ТЗ: калькулятор стоимости ремонта
## 1. Цель
Страница, на которой клиент выбирает устройство и вид ремонта, видит
примерную стоимость и оставляет заявку. Мастерская получает меньше звонков
с вопросом «сколько стоит».
## 2. Пользователи и сценарии
- Клиент выбирает тип устройства (телефон, ноутбук, планшет), затем вид
ремонта из списка для этого устройства и видит цену «от».
- Клиент вводит имя и телефон, нажимает «Отправить заявку» и видит
сообщение «Заявка отправлена».
## 3. Что входит / что не входит
Входит:
- выбор устройства и вида ремонта, вывод цены «от»;
- форма заявки: имя, телефон, выбранная услуга подставляется сама;
- проверка телефона: не меньше 10 цифр.
Не входит:
- онлайн-оплата, личный кабинет, админка;
- отправка SMS;
- любые страницы, кроме калькулятора.
## 4. Стек и ограничения
- Astro, статическая сборка, без своего бэкенда.
- Заявки уходят в сервис форм [название сервиса], адрес формы — в переменной окружения.
- Без UI-библиотек, стили — обычный CSS.
## 5. Данные
- Прайс в файле src/data/prices.json: устройство → список { ремонт, цена_от }.
- Цены меняет владелец, правя только этот файл.
## 6. Интерфейс
1. Заголовок и одна фраза о мастерской.
2. Калькулятор: два выпадающих списка и строка «Стоимость: от [N] ₽».
3. Форма заявки под калькулятором.
На телефоне всё в одну колонку, от 360 px.
## 7. Критерии готовности
- npm run build проходит без ошибок.
- При смене устройства список ремонтов обновляется, цена пересчитывается.
- Пустую форму и телефон короче 10 цифр отправить нельзя, ошибка видна под полем.
- Тестовая заявка приходит в сервис форм с выбранной услугой.
- В коде нет адреса формы и ключей, только переменная окружения.
## 8. Порядок задач
1. Каркас страницы и файл прайса — готово, когда сборка проходит.
2. Калькулятор — готово, когда цена меняется при выборе.
3. Форма и проверка — готово, когда тестовая заявка доходит.
4. Вёрстка на телефоне — готово, когда на 360 px ничего не съезжает.
Пример ТЗ на одностраничный сайт — на странице как сделать сайт с помощью нейросети, на Telegram-бота — в задаче Telegram-бот с помощью нейросети.
Как отдать ТЗ агенту#
- Положите ТЗ файлом в проект, например
docs/spec.md. Файл переживёт любой чат, а ссылку на него можно дать в каждом промте. В Cursor файл подключают через@. - Первый промт — не «сделай», а «прочитай и спроси». Включите режим плана: в Cursor он выбирается в поле ввода (Shift+Tab перебирает режимы), в Claude Code — тем же Shift+Tab, пока в строке состояния не появится
plan mode on. В этом режиме агент изучает проект и задаёт вопросы, но не меняет файлы. - Проверьте план. В Cursor план открывается как Markdown-файл, его можно поправить руками до запуска.
- Отдавайте задачи по одной из раздела «Порядок задач» и после каждой проверяйте критерий готовности.
Короткий промт для первого шага:
Прочитай ТЗ в @docs/spec.md. Код пока не пиши.
1. Задай вопросы по всему, что неясно, противоречиво или не указано.
2. После моих ответов предложи план: какие файлы создашь и в каком порядке,
у каждого шага — критерий готовности из раздела 7.
Начнём с первой задачи только после моего «ок».
Подробная версия с разбором — в промте «сначала план».
Разбивка ТЗ на задачи#
Если проект больше одной страницы, вынесите задачи в отдельную таблицу. Её удобно отдавать агенту по строке и отмечать сделанное.
| № | Задача | Готово, когда | Как проверить |
|---|---|---|---|
| 1 | [задача] | [критерий] | [команда или сценарий] |
| 2 | [задача] | [критерий] | [команда или сценарий] |
Правило простое: если строку «как проверить» нечем заполнить, задача сформулирована слишком размыто. Разбейте её или уточните.
Из ТЗ в AGENTS.md: что куда#
ТЗ описывает, что сделать в этом проекте или этой функции. Файл правил описывает, как работать в проекте всегда. Агент читает правила в начале каждого разговора, поэтому туда переносят то, что не меняется от задачи к задаче:
| Остаётся в ТЗ | Переносится в AGENTS.md |
|---|---|
| цель, сценарии, интерфейс | стек и структура папок |
| что входит и не входит в эту задачу | команды сборки, тестов, линтера |
| критерии готовности задачи | общие запреты: секреты не в коде, без лишних зависимостей |
| порядок задач | что сделать перед словом «готово» |
Как устроен файл правил и что в нём писать — на странице AGENTS.md. Составить его по готовому проекту можно промтом для создания AGENTS.md.
Может ли нейросеть сама написать ТЗ#
Может, если использовать её как интервьюера. Документация Claude Code предлагает такой приём для крупных функций: дать короткое описание, попросить агента подробно расспросить вас о реализации, интерфейсе, крайних случаях и компромиссах, а в конце записать спецификацию в файл. Код по ней лучше писать уже в новом разговоре, с чистым контекстом.
Промт-интервью, который работает в любом чате или агенте:
Я хочу сделать [коротко: что за проект или функция].
Помоги составить ТЗ для кодинг-агента. Задавай вопросы по одному,
не больше 10 вопросов, начиная с самых важных: цель, сценарии, что не входит,
стек, данные, критерии готовности. Не предлагай функции, о которых я не говорил.
Когда вопросы закончатся, собери ТЗ по разделам:
1. Цель 2. Пользователи и сценарии 3. Что входит / что не входит
4. Стек и ограничения 5. Данные 6. Интерфейс 7. Критерии готовности 8. Порядок задач.
Критерии готовности пиши только проверяемые: команда, сценарий или видимый результат.
Что проверить за нейросетью:
- не появились ли в «Входит» функции, которых вы не называли;
- можно ли проверить каждый критерий готовности;
- не противоречат ли ограничения стеку;
- заполнен ли раздел «Не входит».
Частые ошибки в ТЗ для нейросети#
- «Сделай красиво». Вкус не передаётся словами. Дайте образец, скриншот или конкретику: цвета, шрифт, отступы.
- Нет критериев готовности. Агент закончит, когда ему покажется, что всё готово.
- Всё одной задачей. Большое ТЗ, отданное целиком, агент выполнит неравномерно. Делите на шаги.
- Нет списка «не делать». Агент добавит админку, авторизацию или новую библиотеку, потому что так «правильно».
- Не указан стек. Агент выберет сам, и не обязательно то, что вы потом сможете поддерживать.
- ТЗ живёт только в чате. Через несколько десятков сообщений старые детали сжимаются и теряются. Держите ТЗ файлом в проекте.
ТЗ для команды и студии#
Если ТЗ пишет не один человек, а студия или команда, тот же шаблон становится общим форматом. Менеджер собирает с заказчиком цель, сценарии и состав страниц, разработчик дописывает стек и критерии, а агент получает документ, в котором каждый раздел на своём месте. Заказчик видит, что входит и что не входит, ещё до начала работы, и споров об объёме становится меньше.
Источники: Claude Code — рекомендации по работе, Cursor — режим Plan, Cursor — руководство по работе с агентами, Kiro — спецификации, GitHub Spec Kit, AGENTS.md.