Зачем ИИ-инструменту техническое задание?
ИИ-инструменты разработки быстро выдают что-то похожее на готовый продукт. В этой скорости и подвох: получив расплывчатую просьбу, инструмент заполняет каждый пробел своими догадками, а каждый новый запрос может незаметно отменить прежнее решение. ТЗ даёт и инструменту, и вам постоянную точку отсчёта. Когда результат начинает «уплывать», вы сверяетесь с документом, а не с тем, что помните из вчерашнего чата.
Технический язык не нужен, нужна конкретика. «Приложение для записи» — это пожелание. «Посетитель выбирает услугу, дату и свободное время, оставляет имя и телефон и видит подтверждение» — это то, что инструмент может собрать, а вы — проверить. Если вы только осваиваете такой способ работы, на курсе вайб-кодинга отрабатывают именно этот шаг: как превратить идею в инструкции, которым инструмент сможет следовать.
Храните ТЗ файлом внутри проекта, а не только в переписке. Большинство инструментов умеют читать файлы проекта, а документ, который лежит рядом с кодом, переживёт новую сессию, смену инструмента или нового человека в команде.
Что описать в ТЗ для вайб-кодинга?
Пользователи и их главная задача. Назовите каждый тип пользователя и одно дело, ради которого он приходит. Прототип с одним пользователем и одной задачей довести до ума гораздо проще, чем с несколькими ролями и админкой.
Экраны и шаги. Перечислите экраны в том порядке, в каком их видит пользователь, и что на каждом можно сделать. Хватит грубого наброска или списка. Отдельно напишите, чего сознательно нет — например, личных кабинетов, оплаты или уведомлений, — чтобы инструмент не добавил их по своей инициативе.
Данные. Что сохраняется, какие поля обязательны и что не сохраняется никогда. Если прототип работает с личными данными, скажите это прямо и решите, где эти данные хранятся. Не вставляйте реальные данные клиентов и секретные ключи ни в запросы, ни в код.
Ошибки. Что будет, если поле пустое, время уже занято, связь оборвалась или пользователь нажал кнопку дважды? ИИ-инструменты обычно строят только «счастливый путь», если им не сказать иначе, а ломается прототип перед живыми людьми как раз на этих случаях.
Критерии готовности. Для каждого шага запишите пример приёмки обычными словами: «посетитель записывается на свободное время и видит его в подтверждении; следующему посетителю это время уже не предлагается». Именно это вы будете проверять после каждого изменения.
Как собирать прототип проверяемыми шагами?
Не просите всё приложение сразу. Разбейте ТЗ на небольшие шаги, каждый из которых даёт то, что можно открыть и попробовать: первый экран с фиксированными данными, потом сохранение, потом сообщения об ошибках, потом второй экран. После каждого шага проверяйте примеры приёмки для всего, что уже собрано, а не только для нового: исправление в одном месте часто ломает другое.
С первого шага пользуйтесь системой контроля версий и сохраняйте рабочее состояние перед каждой новой просьбой. Если изменение что-то сломало, вы вернётесь одним действием, а не будете просить инструмент починить собственную починку. Ведите в ТЗ и короткий журнал: что просили, что изменилось, что проверили.
Когда прототип становится важным — появляются реальные пользователи или настоящие данные, — остановитесь и проверьте его как следует. О том, как проверить прототип после вайб-кодинга, — отдельная статья: права доступа, работа с данными и ошибки, на которые стоит посмотреть второй раз. А если прототип подтвердил идею и должен стать продуктом, разработка MVP обычно начинается с того же ТЗ — это экономит время обеим сторонам.
Как писать запросы к ИИ по ТЗ?
Каждый запрос должен ссылаться на одну часть ТЗ и один шаг. Назовите экран или правило, над которым работаете, приложите примеры приёмки и скажите, что менять нельзя. «Добавь сообщение о занятом времени; форму записи и сохраняемые поля не трогай» оставляет инструменту куда меньше простора, чем «почини запись».
Если инструмент предлагает то, чего в ТЗ нет, решайте осознанно: либо добавьте это в ТЗ со своим примером приёмки, либо откажитесь. Именно незаписанные «мелочи» превращают небольшой прототип в код, который никто до конца не понимает.
Частые ошибки
- Один огромный запрос. Просьба собрать всё приложение сразу оставляет инструменту слишком много решений и не даёт понять, откуда взялась ошибка.
- Только «счастливый путь». ТЗ без описания ошибок даёт прототип, который работает на демонстрации и ломается у первого реального пользователя.
- ТЗ только в чате. Инструкции, разбросанные по длинной переписке, теряются в следующей сессии. Держите ТЗ файлом в проекте.
- Нет сохранённой рабочей версии. Без контроля версий неудачное изменение можно исправить только новыми запросами, и каждый рискует сломать что-то ещё.
Шаблон ТЗ для вайб-кодинга
Шаблон, который можно адаптировать под ваш проект.
| Раздел | Что написать |
|---|---|
| Цель | Одна задача, которую прототип должен позволить выполнить. |
| Пользователи | Каждый тип пользователя и зачем он приходит. |
| Экраны | Экраны по порядку, действия на каждом и то, чего нет. |
| Данные | Что сохраняется, какие поля обязательны и что не сохраняется никогда. |
| Ошибки | Пустые поля, конфликты, обрыв связи, повторные нажатия. |
| Готовность | Примеры приёмки обычными словами для каждого шага. |
| Журнал | Каждая просьба, что изменилось и что проверили. |
Чек-лист: ТЗ для вайб-кодинга
- Запишите цель и главную задачу пользователя одним предложением.
- Перечислите экраны по порядку и то, что сознательно не входит.
- Опишите данные, включая то, что нельзя сохранять.
- Добавьте ошибки до первого запроса, а не после первого сбоя.
- Напишите примеры приёмки и проверяйте их все после каждого шага.
- Храните ТЗ в проекте и сохраняйте рабочее состояние перед каждым изменением.
Пример: прототип записи небольшими шагами
Владелица салона хочет проверить онлайн-запись. Первая попытка — один запрос «сделай приложение для записи». В результате появляются личные кабинеты, панель статистики и страница оплаты, о которых никто не просил, а два посетителя по-прежнему могут записаться на одно и то же время.
Вторая попытка начинается с ТЗ на одну страницу: один пользователь, три экрана, поля данных, ошибки и примеры приёмки. Инструмент собирает прототип за несколько небольших шагов, каждый из которых сверяется с примерами. Двойную запись ловят на шаге, где добавляется сохранение, — пока её ещё легко исправить.
