Техническое задание нейросетью: сценарии и ловушка

Нейросеть превращает устный запрос заказчика в структурированное ТЗ, находит в готовом документе противоречия и пропуски, формулирует критерии приёмки и переводит формулировки бизнеса на язык разработки. Полный прогон одного ТЗ — примерно 8 000 входных и 3 000 выходных токенов: 0,088 ₽ на ставке 8 ₽ за миллион и 0,33 ₽ на 30 ₽. Главная ловушка одна: без прямого запрета модель дописывает то, чего заказчик не говорил.

Ниже — четыре сценария по отдельности, разбор ловушки с придуманными требованиями, две рабочие таблицы и расчёт на потоке заданий.

Что модель делает с ТЗ, а что остаётся человеку

Ответ короткий: модель работает с текстом требований, человек — с их содержанием.

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

Обе беды — про обработку текста, и здесь модель полезна. Она держит в поле зрения весь документ целиком, не устаёт к десятой странице и не считает, что «это и так понятно».

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

Как превратить устный запрос заказчика в структуру

На вход идёт расшифровка встречи или заметки, на выход — черновик с фиксированными разделами и пометками о том, чего не хватает.

Работающая последовательность состоит из трёх шагов.

Шаг первый: разложить сказанное на требования. Одно требование — одно предложение, без союза «и». Реплика «нужен личный кабинет с выгрузкой и уведомлениями» распадается на три требования с разной ценой.

Шаг второй: разметить источник. У каждого требования отметка, из какой реплики оно выросло. Без этого через неделю не отличить сказанное заказчиком от додуманного аналитиком.

Шаг третий: собрать в разделы. Роли, сценарии, интеграции, данные, нефункциональные требования, ограничения, что в объём не входит.

Раздел «что не входит в объём» на практике важнее остальных: он оформляет то, о чём на встрече договорились устно. Про подготовку самой расшифровки есть разбор в статье протокол совещания нейросетью.

Как найти в ТЗ дыры и противоречия

Это самый надёжный сценарий из четырёх, потому что противоречие — формальное свойство текста, а не вопрос вкуса.

Просить нужно конкретные типы находок, а не «проверь документ»:

• два требования к одному объекту с разными значениями;
• требование без указания, кто его выполняет и когда;
• формулировка со словами «быстро», «удобно», «как у конкурента» — то есть без порога;
• сценарий без ветки отказа: что происходит, когда данных нет или сервис недоступен;
• упоминание сущности, которая нигде не описана;
• сроки, не согласованные с объёмом.

Вот как это выглядит на типовых формулировках заказчика.

Таблица читается как шаблон вопросов на следующую встречу. Смежный сценарий — сверка двух редакций документа — разобран в статье сравнение документов нейросетью.

Главная ловушка: модель дописывает то, чего вы не говорили

Это не мелкая неточность, а системное свойство, и оно ломает весь сценарий, если о нём не знать.

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

Цена ошибки высокая, потому что вскрывается она на приёмке: подрядчик сделал по документу, заказчик не помнит, чтобы такое просил. Общая механика этого сбоя разобрана в статье галлюцинации нейросети.

Что помогает.

Прямой запрет в инструкции. Формулировка вида «если данных нет — пиши «не указано» и не предлагай значение по умолчанию» меняет поведение заметно. Без неё модель по умолчанию достраивает.

Отдельный раздел «не указано». Всё недостающее собирается в один список в конце документа, а не растворяется по тексту. Этот список — повестка следующей встречи.

Отметка источника у каждого требования. Требование без ссылки на реплику заказчика считается предложением аналитика и помечается как предложение.

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

Проверка занимает минуту: попросите вернуть только те требования, у которых источник пуст. Если список оказался коротким, а документ длинным, инструкция не сработала.

Как сформулировать критерии приёмки

Критерий приёмки состоит из трёх частей: измеримое условие, способ проверки и тот, кто проверяет. Формулировка без способа проверки критерием не является.

Пример пары «требование — критерий» для учётного веб-сервиса:

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

Как перевести ТЗ с языка бизнеса на язык разработки

Перевод идёт в обе стороны, и обе полезны.

От бизнеса к разработке. «Чтобы менеджер видел, кто из клиентов давно не платил» превращается в описание выборки, периодичности её расчёта, места отображения и поведения при отсутствии данных. Модель делает черновик такого разворачивания за минуту.

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

Общее правило для обоих направлений: перевод не создаёт новых требований. Если при разворачивании появилась сущность, которой не было в исходной формулировке, она идёт в раздел «не указано», а не в тело документа.

Про соседний класс задач — генерацию кода по требованиям — есть разбор в статье нейросеть для написания кода.

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

Считаем полный цикл на один документ: 8 000 токенов на вход — расшифровка встречи, текущая редакция ТЗ и инструкция — и 3 000 токенов на выход.

Ставки каталога на 13 сентября 2026 года, одинаковые на вход и на выход. Даже верхняя строка таблицы — это 13,20 ₽ за месячный поток аналитика, поэтому выбирать здесь стоит по качеству разбора, а не по ставке.

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

Что делать, если заказчик не отвечает на уточняющие вопросы

Типичная ситуация: список «не указано» собран, отправлен, ответа нет неделю. Соблазн — закрыть пробелы разумными значениями и двигаться дальше.

Рабочий компромисс другой. Пропуск закрывается допущением, но допущение оформляется явно: отдельный блок «принятые допущения» с формулировкой «если до такой-то даты не поступит других указаний, реализуется такой вариант».

Модель хорошо пишет такие блоки, потому что это шаблонная работа. Важно, что допущение остаётся видимым и датированным, а не растворяется в тексте требований.

Частые ошибки

ТЗ просят «написать». Получают правдоподобный документ про абстрактный проект, в котором половина требований придумана.

Не задают запрета на достраивание. Самая дорогая ошибка сценария, разобранная выше.

Проверяют документ целиком одним запросом. Разбор на противоречия, критерии приёмки и перевод — три разные задачи с разными инструкциями.

Принимают критерии без способа проверки. «Интерфейс удобный» проходит в документ и всплывает на приёмке спором.

Не ведут раздел «что не входит». Устные договорённости о границах объёма не переживают смену состава команды.

Как понять, что ТЗ стало лучше

Число вопросов от подрядчика после старта. Прямая метрика качества документа: хорошее ТЗ снимает вопросы заранее.

Доля пунктов, вызвавших спор на приёмке. Считается по протоколу приёмки и показывает, сколько критериев были непроверяемыми.

Время от встречи до первой редакции документа. Здесь выигрыш виден сразу: черновик собирается за час вместо дня.

Экономию в рублях по ставке модели считать бессмысленно — она измеряется копейками. Выигрыш в том, что вопросы задаются до начала работ, а не после.

Чего мы не утверждаем

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

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

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

Что нужно, чтобы попробовать

Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов и без зарубежной карты. Оплата российской картой в рублях, один ключ на весь каталог.

Платные текстовые модели доступны сразу на приветственном бонусе: взять последнее закрытое ТЗ, прогнать его на противоречия и сравнить находки со списком реальных проблем проекта можно без пополнения. Это самая честная проверка сценария, потому что ответ уже известен.

Что держать в голове

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

Главная ловушка — тихое достраивание пропусков. Без прямого запрета, отметки источника и отдельного раздела «не указано» документ выглядит полнее, чем есть, и расплата приходит на приёмке.

Стоимость сценария на потоке аналитика измеряется рублями в месяц, поэтому смысла экономить на позиции нет. Как мы проверяем факты и почему у каждой цифры стоит дата — на странице о проекте. Завести ключ: keydealer.ru/login.