Техническое задание для нейросети: как описать проект до кода

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

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

Первая часть: описать событие и ожидаемый исход

Запишите воспроизводимый путь без персональных данных: посетитель выбирает задачу, материал, формат и обработку камня, затем видит предварительную оценку. Что должно произойти при смене материала? Какие данные попадут менеджеру для точной сметы? Это полезнее формулировки «сделай удобнее». Если причина ошибки пока неизвестна, не объявляйте её в задании как факт.

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

Вторая часть: назвать источник правды

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

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

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

Этот каркас заполняют фактами своего проекта. Скобки нельзя отдавать модели как разрешение самой решить бизнес-правило. Если источник неизвестен, это первый вопрос исследования; задание ограничивается поиском и выводом, пока владелец не определил правило.

Третья часть: границы правки и доступа

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

Границы должны соответствовать задаче. Слишком узкий список файлов может мешать исправить все места класса ошибки. Укажите, что агент вправе найти дополнительные зависимости и сообщить о них. Решение о расширении объёма принимается после поиска связей.

Четвёртая часть: приёмка результата

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

git diff --check
git diff --stat
npm run build

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

Как это выглядит в работе

На снимке калькулятора «Кара-тау Групп» видны выбор задачи, образец плиты и обещание оценки по материалу, распилу и обработке. Точная смета следует после уточнения технического задания.

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

Что делать, когда исполнитель нашёл противоречие

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

Когда правило оказалось неполным, действуйте по порядку:

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

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

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

Нужно ли писать техническое задание на десятки страниц?

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

Можно ли попросить нейросеть самой найти требования?

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

Что включить в задание для изменения базы?

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

Как сформулировать критерий приёмки без знания кода?

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

Почему готовый шаблон промпта иногда вреден?

Он скрывает отсутствие фактов. Если не заполнены источник цены, права или ожидаемое поведение, агенту придётся угадать важное решение.

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