Вы придумали приложение, подробно объяснили идею ChatGPT и получили несколько сотен строк кода. Программа запускается, интерфейс выглядит прилично. Но затем выясняется, что данные исчезают после перезагрузки страницы, нужной функции нет, а исправление одной ошибки ломает другую. Хотя нейросеть вроде бы выполнила просьбу.
Таких проблем будет меньше, если заранее подготовить техническое задание. Причём для небольшого проекта хватит обычного текстового документа. Разберём, как превратить идею в понятную спецификацию, какие требования действительно нужны ИИ и как использовать готовое ТЗ для поэтапной разработки приложения.
Зачем нейросети техническое задание и чем оно отличается от промпта
Техническое задание, или ТЗ, описывает, какую программу нужно создать, как она должна работать и по каким признакам можно проверить результат. В нём фиксируют функции, пользовательские сценарии, ограничения, структуру данных и требования к качеству.
Допустим, вы просите нейросеть: «Сделай сервис для учёта расходов». Непонятно, нужна ли регистрация, где хранить информацию, как считать суммы и должны ли записи синхронизироваться между устройствами.
Модель может создать страницу с временным списком покупок, который исчезает после обновления. Или предложить облачную базу данных и стороннюю систему авторизации, хотя вам нужен небольшой инструмент для собственного компьютера.
ТЗ позволяет заранее определить такие решения. При этом промпт и техническое задание выполняют разные задачи. Промпт представляет собой конкретный запрос к ИИ: написать функцию, исправить ошибку или составить план. ТЗ содержит требования ко всему проекту и используется на протяжении разработки.
В 2026 году такой подход поддерживают и инструменты агентного программирования. Например, GitHub Spec Kit помогает организовать разработку на основе спецификаций (Spec-Driven Development, SDD). Сначала описываются требования, затем создаются план и задачи, после чего ИИ-агент реализует программу.
Для небольшого приложения устанавливать специальные инструменты необязательно. Обычный Markdown-документ можно передать ChatGPT, Codex, Claude Code или другому помощнику.
Что должно быть в ТЗ для генерации кода
Хорошее техническое задание отвечает на основные вопросы. Что пользователь должен делать? Какие данные нужны приложению? Где они хранятся? Как программа обрабатывает ошибки? Что считается готовым результатом?
Удобнее разделить документ на несколько частей.
| Раздел ТЗ | Что указать |
|---|---|
| Назначение | Для кого создаётся программа и какую задачу решает. |
| Функциональные требования | Действия пользователя и реакция приложения. |
| Пользовательские сценарии | Последовательность действий и ожидаемый результат. |
| Структура данных | Поля, типы данных и ограничения. |
| API | Способы обмена данными между интерфейсом и сервером. |
| Технические ограничения | Языки, библиотеки, база данных, среда запуска. |
| Нефункциональные требования | Безопасность, совместимость, доступность и производительность. |
| Критерии приёмки | Проверки, подтверждающие выполнение задания. |
Функциональные требования описывают возможности приложения. Например, пользователь может создать запись, изменить её или удалить. Нефункциональные требования определяют условия работы: данные должны сохраняться после перезапуска, интерфейс должен корректно отображаться на телефоне, а ошибочный ввод не должен приводить к сбою.
Не каждому проекту нужны все разделы. Если вы создаёте простой калькулятор на HTML и JavaScript, отдельное описание API или базы данных излишне. Но при разработке сервиса с серверной частью такие сведения помогают согласовать взаимодействие компонентов.
Важнее всего формулировать проверяемые требования. Фраза «Приложение должно работать быстро» слишком расплывчата. Полезнее указать конкретную операцию и допустимое время выполнения в определённых условиях, если производительность действительно важна.
Как составить ТЗ для ИИ: пошаговый пример веб-сервиса
Разберём процесс на небольшом приложении «Мои расходы». Пользователь записывает покупки, выбирает категорию, просматривает историю и общую сумму расходов. Сервис будет работать локально на одном компьютере.
Ниже приведены требования для учебного проекта. Такой пример можно использовать как основу собственного ТЗ, заменяя функции, данные и технологии под свою задачу.
-
Шаг 1. Определите цель и границы проекта.
Сначала объясните, для кого предназначена программа, где она запускается и какие возможности пока не нужны.
Название: «Мои расходы», версия 1.0.
Назначение: веб-сервис для ручного учёта личных расходов.
Пользователь: один человек на собственном компьютере.
Среда: браузер и локальный сервер.
В первую версию не входят: регистрация, синхронизация между устройствами, подключение банков, импорт выписок и совместный доступ.
Так нейросеть заранее узнает масштаб проекта. Если не обозначить границы, она может добавить ненужные функции и зависимости.
-
Шаг 2. Опишите пользовательские сценарии.
Сценарий объясняет, что человек делает в программе и какой результат ожидает. Для нашего сервиса достаточно трёх основных действий.
- Добавление расхода. Пользователь вводит дату, сумму, категорию и необязательный комментарий. После сохранения запись появляется в списке.
- Просмотр истории. Приложение показывает расходы от последних дат к ранним и рассчитывает общую сумму.
- Удаление. Пользователь нажимает «Удалить», подтверждает действие, после чего запись исчезает, а итог пересчитывается.
Здесь уже определены некоторые особенности интерфейса. Например, удаление требует подтверждения, а список сортируется по дате.
-
Шаг 3. Сформулируйте функциональные требования.
Теперь превратим сценарии в конкретные правила. Каждому требованию присвоим идентификатор, чтобы впоследствии было проще проверять результат.
- F-01. Форма содержит дату, сумму в рублях, категорию и необязательный комментарий.
- F-02. Доступны категории «Еда», «Транспорт», «Другое».
- F-03. Сумма должна быть положительной, с точностью до двух знаков после запятой. Разрешены запятая и точка как десятичные разделители.
- F-04. После успешного сохранения запись появляется в списке без перезагрузки страницы.
- F-05. Расходы сортируются по дате по убыванию. При одинаковой дате первой отображается запись с большим идентификатором.
- F-06. Общая сумма автоматически обновляется после добавления и удаления записи.
- F-07. Данные сохраняются после перезапуска приложения.
- F-08. При ошибке сохранения программа показывает сообщение и оставляет введённые значения в форме.
Последнее требование особенно полезно. Без него модель может очищать форму сразу после нажатия кнопки, даже если данные не сохранились.
-
Шаг 4. Опишите структуру данных.
Нейросеть должна понимать, какие сведения приложение хранит для каждой покупки. Это называют моделью данных.
Поле Тип Назначение idЦелое число Уникальный идентификатор записи. dateДата Дата расхода в формате YYYY-MM-DD. amount_kopecksЦелое число Положительная сумма в копейках. categoryСтрока Одна из разрешённых категорий. noteСтрока Необязательный комментарий до 200 символов. Почему сумма хранится в копейках? Так можно выполнять денежные расчёты с целыми числами, избегая неточностей двоичной арифметики с плавающей точкой. Например, 1250 рублей 50 копеек будут представлены числом
125050.Укажем также, что введённая пользователем сумма преобразуется в копейки по десятичным разрядам, а допустимость значения проверяется на сервере.
-
Шаг 5. Опишите API.
API (Application Programming Interface) определяет, как интерфейс обменивается информацией с сервером. В нашем проекте браузер будет отправлять HTTP-запросы, а сервер работать с базой данных.
Метод и адрес Действие Результат GET /api/expensesПолучить расходы. HTTP 200, массив JSON. POST /api/expensesДобавить расход. HTTP 201, новая запись. DELETE /api/expenses/{id}Удалить расход. HTTP 204, без тела ответа. JSON представляет собой текстовый формат обмена структурированными данными. Пример запроса на создание расхода:
{ "date": "2026-11-11", "amount_kopecks": 125050, "category": "Еда", "note": "Обед" }Отдельно укажем поведение при ошибках. При некорректных данных сервер возвращает HTTP 422 с описанием проблемы. Попытка удалить несуществующую запись приводит к HTTP 404.
Для более крупных проектов API можно описать в формате OpenAPI. Он позволяет формализовать адреса, параметры, схемы данных и ответы сервера.
-
Шаг 6. Зафиксируйте технологии и ограничения.
Теперь определим инструменты, которые нейросеть должна использовать при разработке.
Интерфейс: HTML, CSS и JavaScript без фронтенд-фреймворков.
Сервер: Python 3 и FastAPI.
База данных: SQLite через стандартный модуль sqlite3.
Запуск: локально на 127.0.0.1, интерфейс и API обслуживаются одним сервером.
Язык интерфейса: русский.
Адаптивность: страница должна корректно отображаться при ширине экрана от 320 пикселей.
Безопасность: проверка данных на сервере, параметризованные SQL-запросы, безопасный вывод пользовательского текста.
Тестирование: pytest для серверной части и API.
SQLite подходит для нашего локального приложения, поскольку не требует отдельного сервера базы данных. FastAPI предоставляет инструменты описания API и проверки входных данных.
Поскольку приложение не предусматривает авторизацию, публиковать его в открытом интернете без переработки системы доступа нельзя.
-
Шаг 7. Добавьте критерии приёмки.
Критерии приёмки позволяют проверить, соответствует ли готовая программа ТЗ. Здесь особенно полезны конкретные входные данные и ожидаемые результаты.
- A-01. При вводе суммы 1250,50 сохраняется 125050 копеек. В интерфейсе отображается 1250,50 рубля.
- A-02. Расходы отображаются по дате от новых к старым, при равных датах по убыванию id.
- A-03. После перезапуска сервера все сохранённые записи остаются доступны.
- A-04. Нулевая и отрицательная суммы, неправильная дата и неизвестная категория отклоняются с HTTP 422.
- A-05. После удаления записи общая сумма уменьшается на её значение.
- A-06. При удалении несуществующего идентификатора API возвращает HTTP 404.
- A-07. При отсутствии расходов отображается «Записей пока нет», итоговая сумма равна нулю.
- A-08. Серверные тесты проходят успешно, интерфейс проверен при ширине 320 пикселей.
Теперь у нас есть полноценное ТЗ первой версии. Нейросеть знает, какие функции реализовать, как хранить информацию, какие технологии применять и как проверить готовность приложения.
Как передать техническое задание ChatGPT и получить работающий код
Можно прикрепить готовое ТЗ и попросить нейросеть создать приложение целиком. Для маленьких проектов такой вариант иногда подходит. Но при большом количестве файлов лучше двигаться поэтапно, чтобы проще находить ошибки и контролировать изменения.
В рекомендациях GitHub по работе с Copilot также советуют давать модели необходимый контекст, разделять сложные задачи и проверять результаты.
1. Проверьте ТЗ на противоречия.
Изучи приложенное техническое задание. Пока не пиши код. Найди противоречия, недостающие требования и решения, которые невозможно однозначно определить по документу. Раздели замечания на критические и второстепенные. Предложи уточнения, но не меняй требования самостоятельно.
Например, нейросеть может обнаружить, что в одном разделе предусмотрена работа без интернета, а в другом требуется обязательное обращение к внешнему сервису. Исправьте противоречия в самом документе до начала разработки.
2. Получите план реализации.
Используй утверждённое ТЗ версии 1.0. Предложи структуру проекта и последовательность разработки. Для каждого этапа укажи создаваемые файлы, реализуемые требования и необходимые тесты. Пока не генерируй код.
План поможет определить зависимости между компонентами. Например, прежде чем создавать форму сохранения расходов, полезно согласовать формат запросов к серверу.
3. Поручайте написание кода по этапам.
Реализуй первый этап утверждённого плана: сервер FastAPI, создание таблицы SQLite и модель расхода согласно ТЗ. Добавь необходимые тесты. Не создавай клиентский интерфейс и функции из следующих этапов. Покажи структуру проекта и команды запуска.
После проверки первой части переходите к следующей. В обычном ChatGPT сохранять файлы и запускать программу, возможно, придётся самостоятельно. ИИ-агент с соответствующими разрешениями способен выполнять эти действия непосредственно в проекте.
4. Сравните полученный результат с ТЗ.
Проверь реализацию по утверждённому техническому заданию. Для требований F-01...F-08 и критериев A-01...A-08 укажи статус: выполнено, не выполнено или не проверено. Приведи соответствующие файлы и тесты. Если тесты не запускались, сообщи об этом. Не добавляй новые функции.
Такой отчёт облегчает проверку, но не заменяет реального тестирования. Модель может ошибиться при анализе собственного кода.
Для проектов с большим количеством требований можно попробовать GitHub Spec Kit. В его руководстве описана последовательность от подготовки спецификации до планирования, выполнения задач и проверки результата.
Как проверять выполнение ТЗ и обновлять требования
Даже подробная спецификация не гарантирует, что нейросеть напишет правильный код с первого раза. Зато теперь программу можно проверять по заранее определённым правилам.
Для этого полезно связать каждое требование с реализацией и тестом. Например, F-03 о проверке суммы должно подтверждаться тестами с положительными, нулевыми и отрицательными значениями. F-07 о сохранении данных проверяется повторным чтением записей после перезапуска приложения.
Не стоит ограничиваться сообщением агента «Все тесты пройдены». Убедитесь, что тесты действительно запускались, проверяли нужные сценарии и выполнялись без ошибок.
Если требования меняются, сначала обновите ТЗ. Допустим, после первой версии вы хотите добавить фильтрацию расходов по категориям. Запишите новое функциональное требование, определите поведение фильтра и критерии приёмки. Затем попросите ИИ реализовать изменение, сохранив прежние функции.
Чаще всего при работе с техническим заданием встречаются следующие ошибки:
- Слишком общие формулировки. «Красивый интерфейс» или «надёжное хранение» не объясняют, какой результат требуется.
- Противоречивые условия. Например, одновременное требование работать полностью офлайн и обязательно получать данные из внешнего API.
- Избыточный функционал. В первую версию пытаются включить регистрацию, уведомления, аналитику и десятки второстепенных возможностей.
- Отсутствие обработки ошибок. ТЗ описывает только успешные действия пользователя.
- Неограниченные изменения. Агенту разрешают переработать весь проект ради исправления одной функции.
- Устаревшая спецификация. Новые договорённости остаются в переписке, а документ не обновляется.
Для небольшого проекта удобно хранить ТЗ в файле spec.md рядом с исходным кодом. Изменения можно фиксировать через Git. Отдельно полезно вести список идей для будущих версий, чтобы нейросеть не начинала реализовывать их раньше времени.
И ещё один момент: если вы работаете с корпоративным приложением, не включайте в передаваемое нейросети ТЗ настоящие пароли, токены, закрытые ключи и персональные данные без необходимости и проверки условий использования сервиса. Для описания структуры достаточно вымышленных примеров.
Вопросы и ответы
Как составить ТЗ для нейросети, чтобы она написала программу?
Опишите назначение приложения, функции, пользовательские сценарии, структуру данных, технические ограничения и критерии приёмки. Затем попросите ИИ проверить требования и подготовить план разработки.
Чем ТЗ для ИИ отличается от обычного технического задания?
Основные принципы одинаковы. Для ИИ особенно полезны однозначные требования, примеры данных, ограничения на изменения и проверяемые результаты. Так модель получает меньше возможностей самостоятельно додумывать детали.
Может ли ChatGPT самостоятельно составить техническое задание?
Да. Опишите идею приложения и попросите ChatGPT задать уточняющие вопросы, а затем подготовить ТЗ. Предложенные требования, технологии и ограничения необходимо проверить до начала разработки.
В каком формате лучше передавать ТЗ нейросети?
Для небольших проектов подходит Markdown или обычный текст с разделами и списками. Документ можно приложить файлом или вставить в чат. Для сложных API дополнительно используют спецификации OpenAPI.
Нужно ли указывать язык программирования в ТЗ?
Если технологии уже выбраны, укажите языки, библиотеки и существенные ограничения совместимости. Если предпочтений нет, можно попросить ИИ предложить несколько вариантов реализации с объяснением различий.
Что такое критерии приёмки в техническом задании?
Это проверяемые условия, которым должна соответствовать программа. Например, запись должна сохраняться после перезапуска, а неверный ввод приводить к установленной ошибке. На основе этих условий составляют тесты.
Может ли нейросеть создать приложение по одному ТЗ?
Для небольшого проекта иногда достаточно одного подробного задания. Но даже хорошее ТЗ не гарантирует отсутствие ошибок. Надёжнее разделить разработку на этапы, запускать тесты и сравнивать результат с утверждёнными требованиями.
