Как использовать нейросеть для написания технического задания

Любое техническое задание (ТЗ) для разработчика начинается одинаково: заказчик представляет результат в голове, но не может чётко его сформулировать. Написать ТЗ с помощью ИИ проще всего через интервью: модель задаёт уточняющие вопросы, а потом собирает ответы в структурированный документ. Ниже — промпты для каждого шага, код для API, типичные ошибки и чек-лист проверки.

Зачем это нужно

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

Без ТЗ разработчик пишет код, потом выясняется, что задумано было другое, и часть работы переделывается. С ТЗ требования согласованы до начала. Модель помогает ещё на этапе идеи: задаёт вопросы, о которых вы не подумали, и показывает противоречия, пока они ничего не стоят.

Структура процесса

1. Вы описываете идею — главную цель и основные требования.
2. Модель спрашивает уточняющие вопросы. Вы отвечаете.
3. На основе ответов модель генерирует ТЗ. Вы проверяете и правите.
4. Результат — готовый документ для разработчика.

На каждом этапе вы остаётесь хозяином процесса, модель — помощник, который помнит детали и напоминает о недосказанном.

Шаг 1: промпт для интервью — как написать ТЗ с помощью ИИ

Вы даёте модели роль интервьюера. Вот примерный промпт:

Откройте чат в браузере↗ и вставьте этот промпт. Если хотите провести интервью из терминала или встроить его в свой инструмент, используйте API — ниже простой цикл, который хранит историю диалога:

from openai import OpenAI

client = OpenAI(
    base_url="https://api.zukko.pro/v1",
    api_key="fetch_ваш_ключ"
)

prompt = """Ты опытный техлид. Твоя задача — взять интервью о новом проекте 
и составить на основе ответов техническое задание.

Задай 5–7 уточняющих вопросов, чтобы понять:
1. Что ровно нужно сделать (цель и результат)
2. Кто будет этим пользоваться (пользователи)
3. Какие ограничения (бюджет, время, технологии)

Шаг 2: отвечаете на вопросы

Модель начнёт спрашивать. Отвечайте честно и подробно. Если что-то ещё не знаете — скажите.

Хорошие ответы:

• "Система для управления проектами для небольших команд (2–10 человек)"
• "Интегрируется с Slack, основная работа в веб-интерфейсе"
• "Бюджет ≈ $50k, сроки 4 месяца, стек — React + Node.js"

Плохие ответы:

• "Как ChatGPT, но лучше" (что значит «лучше»?)
• "На Python" (почему?)
• "Быстро, дёшево, красиво" (конкретные цифры?)

Модель будет уточнять. Чем конкретнее ответы, тем меньше в ТЗ окажется додуманного моделью.

Шаг 3: генерация ТЗ

После интервью попросите модель составить ТЗ. Вот промпт:

Отправьте этот промпт в том же диалоге, где шло интервью. Модель вернёт черновик ТЗ — именно черновик, который нужно проверить.

Шаг 4: проверка и правка

Не отправляйте ТЗ разработчику без проверки. Ищите:

1. Логические дыры. «Система автоматически отправляет уведомления» — а кому именно? Если это не описано, это дыра.
2. Выдуманные детали. Модель может выдумать фичу, которую вы не обсуждали. Проверьте каждый пункт.
3. Неточные технологии. Если вы не говорили про React, модель может его предложить. Уточните.
4. Недостаточно деталей. «Интеграция с Slack» — это что? Отправка уведомлений? Двусторонняя синхронизация?

Попросите модель переделать части, которые вызвали вопросы:

Типичные ошибки и как их избежать

Ошибка 1: Слишком общее описание идеи

Неправильно: "Соцсеть для программистов"

Правильно: "Соцсеть, где программисты делятся решениями технических проблем. Основные функции — поиск по тегам (язык, тема), кэширование популярных ответов, интеграция с GitHub профилями. Целевая аудитория — фрилансеры и сотрудники небольших стартапов, которым нужны решения быстрее, чем гуглить Stack Overflow."

По размытому описанию модель заполнит пробелы догадками. Дайте ей материал.

Ошибка 2: Игнорирование противоречий

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

Вопрос модели: "Что важнее — цена или надёжность?"

Ваш ответ: "Надёжность критична. Если нужно, повысим бюджет."

После такого ответа попросите модель пересмотреть раздел об архитектуре.

Ошибка 3: Недостаток информации о пользователях

Модель не может угадать, кто будет пользоваться системой. Расскажите:

• Сколько пользователей?
• Из какого региона?
• Какой уровень техподготовки?
• Как часто они будут использовать?

"Система для управления проектами" и "Система для управления проектами для 50 разработчиков в стартапе, которые привыкли к Jira, но хотят проще" — это совсем разные требования.

Ошибка 4: Доверие к выдуманным обоснованиям

Модель может написать: "Используем язык X для максимальной производительности, потому что Y." Это звучит убедительно, но может быть неправдой.

Проверяйте:

• Реальная ли это фишка языка?
• Вы это вообще говорили про язык?
• Подтверждается ли это документацией или вашим опытом?

Если сомневаетесь — задайте модели наводящий вопрос:

Готовый шаблон для вашего первого ТЗ

Вот полный процесс в одном промпте для чата:

Скопируйте этот шаблон, вставьте ваши ответы, отправьте модели.

Где брать модель: чат или API

Для первого раза используйте чат в браузере:

• https://zukko.pro/app/chat↗
• Откройте, вставьте промпт, отвечайте на вопросы.
• Оплата идёт с того же баланса, что и запросы через API.

Когда нужно автоматизировать (например, генерировать ТЗ для 100 идей):

• Используйте API через Python или curl.
• Сохраняйте результаты в файлы или базу.

Для API нужен ключ: создайте его на странице API-ключи↗ и подключите по инструкции из быстрого старта↗.

Сколько это стоит: интервью и черновик ТЗ — это несколько десятков сообщений. Допустим, весь диалог с повторной отправкой истории занял 60 000 входных и 8 000 выходных токенов (точные цифры смотрите в usage ответа или в разделе «Использование» кабинета). На claude-sonnet-5 это (60 000 × 0.3 + 8 000 × 0.3) / 1 000 000 = $0.0204.

Контрольный список перед отправкой ТЗ разработчику

• Проверено каждое требование — оно из наших ответов, не выдумка?
• Архитектура конкретна — не размыты ли компоненты?
• Сроки и бюджет указаны?
• API/интеграции описаны с примерами?
• Критерии приёмки ясны (можно ли по ним проверить готовность)?
• Нет ли противоречий (типа «дёшево и надёжно на миллион»)?
• Разработчик может прочитать его без доп. вопросов?

Если все пункты — да, ТЗ готово.

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

Может ли модель заменить менеджера продукта?

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

Выдумывает ли модель детали при написании ТЗ?

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

Как часто нужно переспрашивать модель, чтобы убедиться?

Один раз на каждый крупный блок ТЗ. Спросите: «Какие из этих требований я не обсуждал с тобой? Что ты добавил сам?» Ответ модели тоже нужно сверить с перепиской — она может ошибиться и здесь.

Какую модель выбрать для интервью — Claude или GPT?

Заранее сказать нельзя. Проведите одно и то же интервью на claude-sonnet-5 и gpt-5.6-sol (обе по $0.3 за 1M токенов) и сравните, чьи вопросы полезнее и в чьём черновике меньше выдуманного. Актуальный список — GET https://api.zukko.pro/v1/models или справка по моделям↗.