Как составить ТЗ для ИИ-разработчика: шаблон для новичка

Ты открыл Claude Code, написал «сделай Змейку» — и получил что-то странное: змейка уползает за экран, счёт не сохраняется, а управление работает только на английской раскладке. Или вообще не работает. Ты переписываешь промпт десять раз, ИИ каждый раз добавляет новые фичи, но старые ломаются. Знакомо?

Проблема не в ИИ и не в тебе. Проблема в том, что у вас не было общего понимания задачи. Человек-подрядчик на собеседовании уточнил бы детали, а ИИ догадывается на основе того, что написано в чате. Поэтому даже для нейросети, которая пишет код, нужно техническое задание — ТЗ.

Разбираем, как составить ТЗ для программиста-ИИ: из чего оно состоит, чем отличается от классического ТЗ для фрилансера и какие ошибки чаще всего делают новички. Если искал, как правильно составить ТЗ или как составить ТЗ на разработку сайта, — этот же подход и шаблон подойдут. В конце — готовый шаблон и пример на проекте «Змейка».

Понимание структуры ТЗ полезно независимо от того, кто пишет код: искусственный интеллект, фрилансер или ты сам через несколько месяцев. Когда цель, пользователь, функции, ограничения и критерии приёмки зафиксированы на бумаге, проект перестаёт плыть по течению и обретает форму.

Зачем ТЗ нужно даже когда код пишет ИИ

Многие новички в вайбкодинге думают: раз код пишет искусственный интеллект, можно просто описать желаемое своими словами, и он всё поймёт. Иногда так и происходит — для простейших задач. Но как только проект становится чуть сложнее кнопки «привет, мир», без чёткой постановки задачи начинается хаос.

ИИ не читает мысли

Claude Code видит только то, что ты ему написал. Если ты напишешь «сделай красивую Змейку», для тебя «красивая» может означать неоновые скины и плавную анимацию, а для ИИ — зелёный фон и чёрные границы. ИИ не знает твоих предпочтений, не видел референсов в твоей голове и не может угадать, какая механика тебе нравится. Он берёт самую вероятную интерпретацию слова, и она редко совпадает с твоей.

Контекст ограничен

У любой нейросети есть контекстное окно — объём текста, который она может держать в рабочей памяти одновременно. Если ты сначала сказал одно, потом ещё пять раз изменил требования, часть информации может потеряться или исказиться. Чёткое ТЗ помогает вернуться к исходной договорённости и не превращать чат в бесконечную переписку.

Промпты и ТЗ — разные инструменты

Промпт — это команда, которую ты даёшь прямо сейчас: «добавь таблицу рекордов». ТЗ — это документ, в котором записано, как должно работать готовое приложение в целом. Правильно написанные промпты работают внутри ТЗ: каждый промпт решает конкретную задачу, а ТЗ говорит, к чему вы идёте. Без ТЗ промпты превращаются в хаотичные «а давай ещё вот это».

ТЗ экономит время и нервы

Когда требования зафиксированы, ИИ реже делает лишнее. Не нужно десять раз переделывать одно и то же, потому что «я же имел в виду другое». Не нужно объяснять одни и те же ограничения для каждой новой функции. Достаточно один раз описать проект — и дальше ссылаться на документ.

ТЗ помогает контролировать качество

В ТЗ прописываются критерии приёмки — то есть признаки того, что задача сделана. Без них ты не знаешь, когда можно перестать править и перейти к следующему этапу. С ними проверка превращается в простой чек-лист: работает ли управление на стрелках? Сохраняется ли рекорд? Открывается ли игра на телефоне?

ТЗ учит мыслить как продакт

Когда ты пишешь ТЗ, ты вынужден сформулировать цель, аудиторию, функции и ограничения. Это полезный навык не только для работы с ИИ, но и для любых проектов: сайтов, приложений, игр. В курсе skillmake мы используем Змейку как учебный проект именно потому, что она маленькая, но при этом требует продуманного ТЗ.

Из чего состоит хорошее ТЗ

Хорошее техническое задание не обязано быть огромным. Для учебного проекта вроде Змейки хватит одной-двух страниц. Главное — охватить пять базовых блоков. Если какой-то из них пропущен, вероятность недопонимания резко растёт.

1. Цель проекта

Зачем вообще делается это приложение? Какую проблему оно решает? Для кого? Цель должна быть одним-двумя предложениями, понятными без технических терминов.

Пример для Змейки:

Цель не говорит, как именно делать игру. Она объясняет, зачем она нужна. Это помогает ИИ не уходить в ненужные функции.

2. Целевой пользователь

Кто будет пользоваться продуктом? Какой у него опыт? На каком устройстве он заходит? Этот блок нужен, чтобы принимать решения по интерфейсу и функциональности.

Пример:

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

3. Функциональные требования

Это список того, что приложение должно уметь делать. Лучше разбить на обязательное и желательное.

Такой формат удобен и тебе, и ИИ: сразу видно, что важнее, а что можно отложить.

4. Ограничения и требования к технологиям

Здесь описывается, в рамках какого стека ведётся разработка, какие сервисы использовать, а какие нет, какие браузеры поддерживать.

Пример:

• Игра пишется на чистом HTML, CSS и JavaScript без фреймворков.
• Хранение данных — только localStorage в браузере.
• Никакого бэкенда и баз данных на первом этапе.
• Поддержка последних версий Chrome, Firefox, Safari, Edge.
• Адаптивная вёрстка: экран игры не должен выходить за границы viewport.

Ограничения защищают проект от разрастания. Без них ИИ может предложить подключить Supabase, React, Webpack и Redux ради простой игры.

5. Критерии готовности

Это самый важный блок для новичка. Критерии готовности — это чек-лист, по которому проверяется результат. Если все пункты выполнены, задачу можно считать сделанной.

Пример для Змейки:

• Змейка движется плавно, без рывков.
• Управление работает на стрелках клавиатуры и на экранных кнопках телефона.
• При поедании еды змейка удлиняется на один сегмент.
• При столкновении со стеной или собой появляется экран «Игра окончена».
• Текущий счёт отображается во время игры.
• Лучший результат сохраняется после перезагрузки страницы.
• Игра открывается и работает на десктопе и мобильном браузере.
• В коде нет ошибок в консоли браузера.

Критерии должны быть проверяемыми. Фраза «игра красивая» не подходит, потому что красота субъективна. А вот «цвет фона — тёмно-серый, еда — красный круг, змейка — зелёная линия» — уже проверяемо.

Дополнительно: пользовательские сценарии

Иногда полезно описать, как пользователь проходит через приложение шаг за шагом. Это называется пользовательским сценарием.

Пример:

1. Пользователь открывает страницу и видит поле с змейкой и кнопку «Начать игру».
2. Нажимает кнопку — змейка начинает двигаться.
3. Управляет движением, собирает еду, счёт растёт.
4. Врезается в стену — появляется экран окончания с итоговым счётом и кнопкой «Играть снова».
5. Нажимает «Играть снова» — игра перезапускается, рекорд сохраняется.

Сценарии помогают ИИ понять порядок действий и состояния интерфейса.

Шаблон ТЗ пошагово с примером на проекте Змейка

Ниже — универсальный шаблон, который подходит для большинства учебных проектов. Можно копировать его в отдельный файл и заполнять для каждой новой задачи. Мы сразу покажем, как он заполняется на примере игры «Змейка».

Шаблон

# Техническое задание: [Название проекта]

## 1. Цель проекта
[Одно-два предложения о том, зачем делается проект и какую проблему решает.]

## 2. Целевой пользователь
[Кто будет пользоваться продуктом, на чём, какой у него опыт.]

## 3. Функциональные требования
### Обязательные (MVP)
- [Функция 1]
- [Функция 2]
...

### Желательные (после MVP)
- [Функция 3]
- [Функция 4]
...

## 4. Ограничения и технологии
- [Стек]
- [Запрещённые технологии]
- [Требования к браузерам/устройствам]

## 5. Критерии готовности
- [ ] [Проверяемый пункт 1]
- [ ] [Проверяемый пункт 2]
...

## 6. Пользовательские сценарии
1. [Шаг 1]
2. [Шаг 2]
3. [Шаг 3]

## 7. Референсы
- [Ссылка или описание]

Пример заполнения для Змейки

# Техническое задание: браузерная игра «Змейка»

## 1. Цель проекта
Создать простую браузерную игру «Змейка» для новичков, которая работает
на компьютере и телефоне, сохраняет лучший результат и помогает пройти
путь от идеи до готового приложения с помощью ИИ.

## 2. Целевой пользователь
Новичок без опыта программирования. Играет в основном на телефоне,
иногда на компьютере. Ожидает понятного управления без инструкций.

## 3. Функциональные требования
### Обязательные (MVP)
- Игровое поле 20×20 клеток.
- Змейка движется автоматически, игрок меняет направление.
- Управление на десктопе: стрелки клавиатуры.
- Управление на мобильном: свайпы вверх/вниз/влево/вправо.
- Поедание еды увеличивает длину змейки и счёт на 1.
- Столкновение со стеной или собой заканчивает игру.
- Экран окончания с итоговым счётом и кнопкой «Играть снова».
- Текущий счёт виден во время игры.
- Лучший результат сохраняется в localStorage браузера.

### Желательные (после MVP)
- Звуковые эффекты при поедании и проигрыше.
- Несколько цветовых тем.
- Таблица рекордов с именами игроков (на этапе с Supabase).

## 4. Ограничения и технологии
- HTML5, CSS3, чистый JavaScript (без фреймворков).
- Хранение данных только через localStorage.
- Без бэкенда и сторонних API на этапе MVP.
- Поддержка современных браузеров: Chrome, Firefox, Safari, Edge.
- Адаптивный дизайн: игра помещается на экране телефона без горизонтальной прокрутки.

## 5. Критерии готовности
- [ ] Змейка движется плавно с фиксированной скоростью.
- [ ] Стрелки клавиатуры меняют направление движения.
- [ ] Свайпы на телефоне меняют направление движения.
- [ ] Еда появляется в случайной свободной клетке.
- [ ] При поедании еды змейка растёт, счёт увеличивается.
- [ ] При столкновении со стеной или собой игра останавливается.
- [ ] Появляется экран «Игра окончена» с итоговым счётом.
- [ ] Кнопка «Играть снова» перезапускает игру.
- [ ] Лучший результат сохраняется после закрытия и открытия страницы.
- [ ] Игра корректно отображается на экранах от 320 px до 1920 px.
- [ ] В консоли браузера нет ошибок.

## 6. Пользовательские сценарии
1. Пользователь открывает страницу, видит поле, змейку, счёт и кнопку «Старт».
2. Нажимает «Старт», змейка начинает двигаться вправо.
3. Игрок нажимает стрелку вверх, змейка поворачивает.
4. Змейка съедает еду — счёт становится 1, змейка удлиняется.
5. Змейка врезается в стену — появляется экран окончания.
6. Игрок нажимает «Играть снова», игра начинается заново, лучший результат сохранён.

## 7. Референсы
- Классическая Змейка на старых мобильных телефонах.
- Минималистичный интерфейс без лишних элементов.

Как использовать шаблон с ИИ

1. Заполни шаблон самостоятельно. Даже если не всё получается идеально, попытка описать проект уже даёт пользу.
2. Дай ИИ первый вариант ТЗ и попроси дополнить. Например: «Вот моё ТЗ на Змейку. Проверь, чего не хватает, и предложи улучшения.»
3. Обсуди с ИИ непонятные моменты. Если ты не знаешь, стоит ли добавлять звуки, спроси: «Какие риски у добавления звуков на этапе MVP?»
4. Зафиксируй финальную версию. Сохрани её в файл tz.md в папке проекта. Это будет ваша договорённость.
5. Давай промпты, ссылаясь на ТЗ. Например: «Согласно ТЗ, раздел 3, добавь управление свайпами для мобильных устройств. Ограничения из раздела 4: без фреймворков.»

Такой подход работает гораздо лучше, чем бесконечные «а давай ещё». ИИ получает структуру, а ты — контроль.

Если на каком-то этапе ИИ предлагает функцию, которой нет в ТЗ, не соглашайся автоматически. Спроси себя: она нужна для MVP или отвлекает от цели? Если отвлекает — скажи ИИ отложить её. Это защищает проект от разрастания и помогает довести основную идею до рабочего состояния.

Чем ТЗ для ИИ отличается от ТЗ для фрилансера-человека

Классическое техническое задание для человека-подрядчика обычно объёмное: там могут быть диаграммы, схемы баз данных, подробные макеты, сроки, этапы оплаты, штрафы. Для ИИ многое из этого лишнее, а кое-что, наоборот, важнее.

Скорость и формат

Человеку нужно время, чтобы прочитать ТЗ, задать вопросы, оценить сроки. ИИ читает мгновенно и сразу может приступить к выполнению. Поэтому ТЗ для ИИ может быть короче и живее. Его можно писать в виде markdown-списков, таблиц и чек-листов.

Контекстное окно вместо долгой памяти

Человек помнит, о чём вы договаривались неделю назад. ИИ помнит только то, что помещается в контекст. Поэтому в ТЗ для ИИ важно кратко повторять ключевые ограничения в начале каждого нового промпта или использовать постоянную память: в Claude Code она включена по умолчанию и подхватывается в начале каждой сессии.

ИИ не догадывается о неявных требованиях

Человек, увидев «сделай форму обратной связи», может предположить, что нужна валидация email и сообщение об успешной отправке. ИИ может сделать форму без валидации, если ты явно не сказал. Поэтому в ТЗ для ИИ важно не оставлять требования на догадки.

Итеративность

С фрилансером обычно сначала утверждают ТЗ, потом ждут результат. С ИИ можно работать итерациями: сделал MVP по ТЗ, проверил, дополнил ТЗ, сделал следующую версию. Это нормально. Главное — после каждой итерации обновлять документ, чтобы контекст не расползался.

Больше примеров и меньше абстракций

Человеку достаточно написать «минималистичный дизайн». ИИ лучше показать: «Фон — тёмно-серый (#1a1a1a), текст — белый (#ffffff), акценты — зелёный (#4ade80) и красный (#f87171)». Конкретика снижает количество догадок.

ТЗ для ИИ — живой документ

Не нужно пытаться написать ТЗ раз и навсегда. С ИИ оно скорее похоже на дорожную карту: уточняется по ходу движения. Главное — фиксировать изменения, а не держать всё в голове.

Типичные ошибки при составлении ТЗ

Ошибки в ТЗ стоят дороже, чем кажется. Исправить формулировку в документе — дело пяти минут. Переделывать половину приложения после того, как ИИ всё сделал не так — гораздо дольше.

Ошибка 1. Размытые формулировки

❌ Плохо: «Сделай красивую игру.» ✅ Хорошо: «Игровое поле 20×20 клеток, фон тёмно-серый (#1a1a1a), змейка зелёная (#4ade80), еда красная (#f87171), шрифт без засечек.»

Слова «красиво», «удобно», «современно», «качественно» разные люди понимают по-разному. ИИ — тоже. Заменяй субъективные оценки на конкретные параметры.

Ошибка 2. Нет критериев приёмки

❌ Плохо: «Добавь таблицу рекордов.» ✅ Хорошо: «После проигрыша показывать таблицу из 10 лучших результатов с именем игрока, счётом и датой. Новый рекорд должен попадать в таблицу и сохраняться после перезагрузки страницы.»

Без критериев ты не знаешь, когда задача готова. А ИИ не знает, когда можно остановиться.

Ошибка 3. Слишком большой объём за один раз

❌ Плохо: «Сделай полноценное приложение с игрой, авторизацией, платежами и админкой.» ✅ Хорошо: «Сначала сделай MVP: игру с локальным рекордом. Авторизацию и общую таблицу рекордов добавим на следующем этапе.»

ИИ лучше справляется с небольшими чёткими задачами. Большой объём приводит к тому, что часть требований теряется или реализуется криво.

Ошибка 4. Отсутствие ограничений

❌ Плохо: «Используй любые технологии.» ✅ Хорошо: «Используй HTML, CSS и JavaScript без фреймворков. Храни данные в localStorage. Бэкенд не нужен.»

Без ограничений ИИ может выбрать React, Next.js, Supabase и Docker для простой страницы. Это замедлит разработку и усложнит поддержку.

Ошибка 5. Игнорирование пользователя

❌ Плохо: «Сделай игру для себя.» ✅ Хорошо: «Игра для новичков без опыта. Управление должно работать на телефоне свайпами, без инструкций.»

Когда непонятно, для кого продукт, ИИ принимает решения в пользу среднего пользователя — который может не совпадать с твоим.

Ошибка 6. Смешение цели и способа

❌ Плохо: «Сделай кнопку зелёной.» (это способ, а не цель) ✅ Хорошо: «Сделай так, чтобы пользователь сразу понимал, куда нажимать для старта игры.»

Иногда конкретный способ нужен, но часто лучше описать результат, а способ оставить ИИ. Особенно если ты не уверен, как лучше.

Ошибка 7. Изменение требований без обновления ТЗ

Ты договорился об одном, но в процессе решил добавить звуки, потом скины, потом онлайн-таблицу. Если не обновлять ТЗ, через несколько итераций ИИ забудет исходные ограничения, и проект разрастётся. После каждого существенного изменения возвращайся к документу.

Ошибка 8. Нет сценариев использования

Без сценариев ИИ реализует функции по отдельности, но может упустить, как они связаны. Пользовательский сценарий показывает последовательность действий и помогает увидеть пробелы.

Ошибка 9. Слишком много технического жаргона

Если ты новичок, не обязан знать все термины. Лучше описать поведение простыми словами, а технические детали доверить ИИ или уточнить вместе. Например, вместо «реализуй debounce для обработчика свайпов» напиши «сделай так, чтобы случайные касания не ломали управление».

Ошибка 10. Отсутствие проверки результата

Даже хорошее ТЗ не гарантирует идеальную реализацию. Всегда проверяй результат по критериям приёмки: открой на телефоне, проверь сохранение рекорда, посмотри консоль на ошибки.

Как применять ТЗ в работе с Claude Code

В курсе skillmake мы работаем с Claude Code — ИИ-ассистентом, который пишет и редактирует код прямо в редакторе. Вот как использовать ТЗ в этом процессе.

Шаг 1. Создай файл ТЗ

В папке проекта создай файл TZ.md или README.md и запиши туда всё по шаблону. Это будет отправная точка. При старте сессии Claude Code сам читает только CLAUDE.md, поэтому добавь в него строку @TZ.md — файл ТЗ подтянется в контекст вместе с ним, без ручной пересылки. Что реально загрузилось, показывает команда /context в разделе Memory files.

Шаг 2. Отправь ТЗ первым сообщением

Когда начинаешь новый чат или сессию, сначала дай ИИ прочитать ТЗ. Если ты подключил файл через CLAUDE.md, документ уже в контексте — сразу проси план MVP; вручную отправлять ТЗ нужно в чатах без такой связки. Например:

Шаг 3. Делай задачи маленькими

Не проси сразу реализовать всё ТЗ. Разбей на этапы: сначала базовое движение змейки, потом еду и рост, потом столкновения, потом интерфейс и сохранение рекорда.

Шаг 4. Ссылайся на ТЗ в каждом промпте

Не повторяй всё ТЗ каждый раз, но указывай раздел. Например:

Шаг 5. Обновляй ТЗ после изменений

Если в процессе решил добавить звук, внеси его в раздел «Желательные функции» или «Обязательные», если это критично. Если изменил цвета — обнови референсы. Документ должен отражать актуальное состояние проекта.

Шаг 6. Проверяй по критериям

Когда ИИ говорит, что задача готова, пройдись по чек-листу из раздела 5. Если что-то не работает — дай конкретный промпт с описанием проблемы и ожидаемым поведением.

Пример промпта по ТЗ

Такой промпт сразу даёт ИИ контекст, ограничения и критерий успеха.

Частые вопросы

Нужно ли ТЗ, если я просто пишу промпт в Claude Code?

Для одноразовых задач вроде «исправь отступ» — нет. Но для любой задачи, которая влияет на логику или интерфейс приложения, ТЗ нужно. Даже короткое: цель, функции, критерии готовности. Это экономит время и снижает количество итераций.

Чем ТЗ отличается от промпта?

Промпт — это конкретное действие прямо сейчас. ТЗ — это общий план продукта. Промпт решает задачу, ТЗ описывает продукт. Хорошие промпты работают внутри ТЗ: каждый берёт из документа конкретное требование и просит его реализовать.

Можно ли давать ТЗ частями?

Можно и нужно. Особенно на старте, когда ты ещё не до конца представляешь масштаб. Напиши ТЗ на MVP, реализуй его, протестируй, а потом дополняй документ новыми функциями. Главное — фиксировать договорённости, чтобы они не терялись.

Какие критерии приёмки нужны для простой игры?

Минимальный набор: управление работает, правила игры реализованы, счёт отображается, игра заканчивается при проигрыше, результат сохраняется, нет ошибок в консоли, интерфейс не ломается на телефоне. Каждый пункт должен быть проверяемым.

Что делать, если ИИ не понял ТЗ?

Уточни формулировку. Скорее всего, где-то была двусмысленность. Разбей требование на более мелкие шаги, добавь пример или референс, перефразируй субъективные слова в конкретные параметры. Исправляй не только промпт, но и само ТЗ.

Подходит ли этот шаблон для ТЗ на разработку сайта?

Да, структура универсальна. Для сайта в функциональных требованиях будут страницы и блоки, в ограничениях — выбранный конструктор или фреймворк, в критериях — адаптивность, скорость загрузки, корректность форм. Если ты ищешь, как составить ТЗ на разработку сайта, этот же шаблон поможет: замени игровые механики на страницы и контент.

Заключение + чек-лист

Умение составить ТЗ — один из главных навыков вайбкодера. ИИ может написать код, но только ты решаешь, что именно должно получиться. Чёткое техническое задание превращает работу с Claude Code из бесконечного угадывания в предсказуемый процесс.

Главное помнить: ТЗ — это не формальность для другого человека, а инструмент управления собственным проектом. Оно помогает тебе самому понять, чего хочешь, а ИИ — сделать именно это.

Если хочешь научиться писать хорошие промпты под ТЗ — почитай статью как писать промпты для Claude Code. Если интересно, как сохранять контекст между сессиями — изучи материал про постоянную память.

Чек-лист «ТЗ готово к работе с ИИ»

• Написана цель проекта в 1–2 предложениях.
• Описан целевой пользователь и его устройства.
• Есть список обязательных функций.
• Есть список желательных функций, отложенных на потом.
• Прописаны технологии и ограничения.
• Есть проверяемые критерии готовности.
• Описан пользовательский сценарий.
• Добавлены референсы или примеры.
• ТЗ сохранено в файле проекта.
• Каждое требование можно проверить «да/нет».
• Нет субъективных оценок вроде «красиво» без конкретики.
• После изменений ТЗ обновляется.