Промпты для технического задания: как превратить неполный бриф в требования и проверки

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

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

Однократный запрос уже сохранил основные условия и открытые вопросы. Цепочка дала явные ID требований, связи с фактами и отдельные критерии приёмки. В конце модель правильно классифицировала 12 из 12 CSV-примеров: три допустимых файла и девять блокировок. Это проверка рассуждения по тексту, а не работающего импорта. Преимущество цепочки по точности этот опыт не доказывает.

Учебный бриф: что известно и чего пока нет

Проект «Маяк» вымышленный. Нужно описать импорт товарного каталога из CSV, но без реализации, реальной загрузки товаров, новых API и платных действий. В исходнике восемь подтверждённых фактов с ID F01–F08.

Полный учебный бриф можно скачать отдельно. Пример корректной строки: A1;Лампа;100.50;2 под заголовком sku;name;price;stock.

Пять вопросов U1–U5 остались без согласованного ответа:

1. Какой максимальный размер файла и сколько в нём может быть строк?
2. За какое время должна завершаться обработка?
3. Что делать с SKU, уже существующим в каталоге?
4. Каковы валюта и правила округления?
5. Какие нужны роли и журналирование?

Запрет дублей внутри входного файла не отвечает на вопрос о совпадении с существующим каталогом. Эти два условия нельзя объединять. Аналогично формат цены с точкой не задаёт валюту и не разрешает автоматически округлять значение до двух знаков.

Как проходил опыт

Практика выполнена в ChatGPT 19 октября 2026 года. В чате A отправили один запрос написать техническое задание по брифу. В отдельном чате B — четыре последовательных запроса: выделить факты и вопросы, составить требования, добавить критерии и проверить их на CSV-примерах. Новых повторов и выбора удачного ответа не было.

Ответы учебного заказчика зафиксировали заранее: «U1–U5 пока не согласованы. Не назначать их значения самостоятельно; оставить в списке открытых вопросов. Дополнительных требований к F01–F08 нет». Это входное условие, а не ответ модели и не неожиданное уточнение после просмотра результата. Файл ответов заказчика входит в рабочий комплект.

Количество ID показывает устройство документов. Оно не означает, что 33 критерия лучше 13 или что программа прошла 33 теста. Реализацию импорта мы не писали и не запускали.

Отдельное ограничение: текста B01 нет, поэтому нельзя оценить, насколько хорошо модель задала вопросы на первом шаге. B02–B04 получены в том же чате; содержание возможного скрытого ответа B01 неизвестно. Продолжение чата не превращает неотобразившийся ответ в успешно проверенный.

Пять точных промптов из опыта

Ниже — назначение каждого сообщения и ссылка на полный текст без редакторских исправлений. A01 — самостоятельный вариант в новом чате. B01–B04 — последовательная цепочка в другом чате. В этих файлах уже находятся наши учебные данные: перед применением к своему проекту замените бриф и примеры, сохранив разделение фактов, неизвестных и предложений.

A01. Сразу получить черновик ТЗ

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

Далее передавался весь бриф. Скачать точный A01 с брифом (TXT).

Даже этот короткий запрос содержал важное ограничение: неизвестное нельзя додумывать. Полученный ответ сохранил F01–F08 и U1–U5, а его 13 критериев AT уже были связаны с исходными фактами. Поэтому мы не описываем однократный запрос как заведомо слабый вариант.

B01. Разделить факты и вопросы

Не пиши полное ТЗ сразу. Выдели подтвержденные факты F01–F08, неизвестные U1–U5 и возможные противоречия. Для каждого вопроса объясни, какое требование или проверка зависит от ответа. Не назначай сроки, стек, валюту и роли самостоятельно.

После этого шёл тот же бриф. Скачать точный B01 (TXT).

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

B02. Получить требования с происхождением

После фиксированных ответов заказчика модель получила инструкцию:

Сформулируй ТЗ по подтвержденным фактам. Каждому требованию дай ID и ссылку на F01–F08. Не превращай вопросы U1–U5 в факты. Отдельно укажи границы учебного проекта. Пока не пиши приемочные сценарии.

Скачать полный B02 с ответами заказчика (TXT).

На этом шаге появились 20 требований REQ и пять ограничений LIM. Связи с F01–F08 позволяют задать предметный вопрос: «Какой факт разрешает это требование?» Если источника нет, условие нужно вернуть в предложения или вопросы заказчику. Ссылка на номер факта сама по себе тоже требует проверки: содержание требования должно из него следовать.

B03. Добавить наблюдаемые критерии приёмки

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

Скачать точный B03 (TXT).

В ответе было 33 критерия AC со ссылками на существующие REQ/LIM. Польза здесь в возможности проследить цепочку «факт → требование → проверка». Приёмка не должна заканчиваться словами «система корректно обрабатывает файл»: нужно назвать вход, результат и состояние каталога.

B04. Проверить документ на конкретных файлах

Проверь требования и критерии на 12 учебных CSV-примерах ниже. Для каждого укажи ожидаемый исход, ошибочное поле/строку при наличии и состояние каталога. Не запускай импорт и не пиши код. Найди пропуски или противоречия в своем ТЗ; исправления перечисли отдельно, сохранив исходные формулировки для сравнения.

Затем шли все 12 примеров. Скачать точный B04 вместе с CSV (TXT).

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

Что показали 12 CSV-примеров

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

Все 12 исходов совпали с эталоном: три допустимых файла и девять блокировок. B04 сохранил ведущие нули, различил дробный и целый остаток, указал обе строки дубля и не предложил молча сохранить одну из них. В смешанном T12 явно заблокировал и корректную строку A1.

При этом A01 не получил идентичную серию из 12 CSV. Сравнивать его неизвестный результат с 12/12 у B04 нельзя. Статическая классификация также не подтверждает, что приложение действительно распознает кодировку, покажет предпросмотр, сохранит каталог или откатит изменения.

Где в критериях остались пробелы

Нечисловая цена не получила отдельного раннего критерия

В B03 не было отдельного AC для price=abc. На шаге B04 модель правильно отнесла T07 к блокировкам и предложила добавить AC-034. Это конкретное расширение покрытия, а не доказательство, что первоначальные критерии были полными.

У однократного A01 критерий AT-07 уже описывал недопустимый числовой формат. Поэтому этот эпизод не подтверждает, что цепочка лучше предотвращает пропуски.

Отдельное предлагаемое дополнение, не подмена исходного ответа:

При price=abc в строке 2 весь файл блокируется. Диагностика указывает строку 2, поле price и причину «нечисловое значение». Каталог не меняется. Основания: F04, F05, F07.

Примеры удаления пробелов были показаны неявно

В извлечённом тексте B03 у AC-009 вход выглядел как 00123 без видимых краевых пробелов. У AC-019 были записаны ABC1 и ABC1, что демонстрирует обычный дубль, но не делает удаление пробелов видимым. Нельзя установить, потерялись ли пробелы при генерации, отображении или извлечении.

В B04 исходные T03 и T11 были трактованы верно. Для будущего ТЗ лучше записать отдельно: «до нормализации — \u0020A1\u0020, после — A1», пояснив, что \u0020 здесь обозначает обычный пробел, а не буквальные символы CSV. Это редакционное предложение для наглядности, а не исправленный первый ответ модели. В скачиваемых T03 и T11 сохранены настоящие краевые пробелы.

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

Как применить промпты к своему брифу

Сначала выделите подтверждённые условия и присвойте им короткие ID. Отдельно перечислите неизвестные. Если ограничение ещё обсуждается, не включайте его в факты даже ради более законченного документа.

Вместо учебных ответов заказчика передайте реальные согласованные решения. Если решения нет, оставьте вопрос открытым и укажите, что без него нельзя проверить. Не подставляйте произвольные «до 10 МБ», «за 3 секунды» или «только администратор»: это новые требования, которые должен принять ответственный человек.

Применимый шаблон для другого проекта:

По брифу ниже отдели факты F01… от неизвестных U1… . Сначала задай вопросы, влияющие на требования и проверки. После моих ответов сформулируй требования с ID и источниками. Для каждого критерия укажи вход, ожидаемый результат и состояние данных. Не назначай неподтверждённые лимиты, сроки, роли и правила. Предложения помечай отдельно. Бриф: [ваши условия].

Перед передачей ТЗ разработчику проверьте:

1. Каждое обязательное условие имеет подтверждённый источник, а не только аккуратный ID.
2. Вопросы заказчику не превратились в готовые значения.
3. В критериях есть допустимые и недопустимые входы, включая крайние случаи.
4. Пробелы, ведущие нули и пустые значения показаны однозначно.
5. При ошибке описано состояние всего набора данных, а не только сообщение пользователю.
6. Текстовая проверка отделена от тестов реализованной программы.

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

Что можно заключить

Однократный запрос в этом опыте уже дал содержательный черновик с основными условиями и неизвестными. Цепочка сделала требования и проверки более явно связанными, а проверка на 12 примерах помогла увидеть отдельный пробел и неясность записи пробелов. Но у нас нет одинакового контрольного прогона для A01, повторов и текста B01, поэтому обещать повышение точности от многошагового промпта нельзя.

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

Приложение: кадры учебного опыта

Ниже показаны отдельные видимые фрагменты первых ответов. Снимки не заменяют полный текст и независимую проверку; изображённый импорт не запускался.