С чего начать ТЗ на ИИ-агента?
Начните с проблемы пользователя и одного наблюдаемого результата. Запишите, кто запускает процесс, что он передаёт на вход, какой результат принимает и что происходит дальше. Формулировка «создать умного помощника» не даёт критериев разработки. Рабочая постановка ограничивает одну задачу, аудиторию и цену ошибки.
Если процесс ещё не выбран, сначала используйте план внедрения ИИ-агента от процесса до пилота.
Как описать пользователей и сценарий?
Для каждой роли укажите момент запуска, цель, доступные данные и ожидаемое действие. Не объединяйте клиента, оператора и администратора в одного абстрактного пользователя: у них разные права и критерии успеха. Добавьте основной маршрут и два-три исключения, где агент должен уточнить данные или передать задачу человеку.
- Роль и контекст запуска.
- Входные данные и обязательные поля.
- Ожидаемый результат и следующий шаг.
- Исключения и владелец эскалации.
Какие входы и источники указать?
Перечислите разрешённые документы, базы и сервисы, их владельцев, формат, свежесть и ограничения. Отдельно укажите запрещённые источники и персональные данные. Если агент получает неполный вход, ТЗ должно требовать уточнение или остановку, а не свободное достраивание критичного факта моделью.
Как описать tools и полномочия?
Для каждого инструмента зафиксируйте назначение, параметры, возможный ответ, ошибку и допустимый эффект. Разделите чтение и изменение. Отправка, публикация, удаление, оплата и изменение прав должны иметь предварительный просмотр и подтверждение человека непосредственно перед вызовом. Общая фраза «интегрировать CRM» для ТЗ недостаточна.
Для внешних подключений используйте карту проверки MCP-сервера.
Что считать готовым результатом?
Опишите обязательные поля, формат, источники или доказательства, допустимую длину и условия отказа. Результат должен быть проверяемым без чтения внутреннего хода рассуждения. Для черновика укажите, кто утверждает его; для структурированной записи — схему и валидацию; для рекомендации — основания и ограничения.
Форму результата помогает определить output contract в SKILL.md.
Какие нефункциональные требования нужны?
Зафиксируйте предел времени ответа, доступность, хранение журналов, размещение данных, роли доступа, версионирование и порядок отключения. Не назначайте произвольные цифры без бизнес-основания. Требование должно объяснять, какой процесс пострадает при задержке, утечке, недоступности или невозможности восстановить версию.
Как записать критерии приёмки?
Соберите набор типичных, ошибочных и пограничных сценариев. Для каждого укажите вход, допустимый маршрут tools, ожидаемый результат, запрещённое действие и доказательство прохождения. Приёмка должна проверять весь trace, а не только красивый финальный ответ. Отдельно задайте порог критичных ошибок, при котором пилот останавливается.
Структуру eval-набора продолжает статья как оценить качество ИИ-агента.
Что должно войти в план пилота?
Добавьте этапы, владельцев, тестовую среду, выборку задач, базовую линию, бюджет, сроки пересмотра и решение после пилота. Результатом этапа может быть остановка или изменение архитектуры, а не только запуск. ТЗ должно позволять оценить объём и сравнить предложения исполнителей по одним границам.