Как написать документ об объёме ИИ-агента

Опубликовано в августе 2026 года.

TL;DR: Документ об объёме — это то, что превращает фразу «хочу ИИ-агента для своего бизнеса» в цифру, которую можно назвать клиенту, и которую клиент может подписать. В нём нужно шесть частей: триггер, входные данные, выходные данные, инструменты, к которым агент обращается, что явно исключено, и письменный список приёмочных тестов. Пишите его до того, как назвать цену за разработку, а не после. Я оцениваю его как фиксированный результат аудита за $500–$1,000, отдельно от разработки.

[Заметка оператора] Я управляю более чем 30 ИИ-агентами в продакшне — для консалтингового бренда и Pickleland, центра пиклбола в Пфлюгервилле, штат Техас, — и на основе этого опыта оценивал объём работ по созданию агентов для клиентов. Самая частая причина, по которой проект с агентом идёт наперекосяк, — не код. Дело в том, что никто не записал, что означает «готово», до того как выставлен счёт. Документ об объёме решает это за один присест. Это самый непритязательный результат, который я произвожу, — и тот, который спасает от наибольшего числа споров.

Содержание

Почему документ об объёме, а не письмо с предложением

Письмо с предложением описывает, что вы будете делать. Документ об объёме определяет, как выглядит «готово» — настолько конкретно, что вы и клиент можете независимо сверить это с готовым агентом и без разговора согласиться, прошёл он проверку или нет.

Это различие важно, потому что ценообразование ИИ-агента работает только тогда, когда плата за разработку привязана к чему-то фиксированному. Назовите фиксированную цену на неопределённый объём — и вы назвали цифру, которую физически не сможете выполнить: мысленная модель клиента о том, что такое «ИИ-агент для моего бизнеса», бесплатно расширяется до тех пор, пока вы не начнёте возражать, а возражать после получения депозита — куда более неприятный разговор, чем определить границу заранее.

Я пишу такой документ для каждого проекта, включая небольшие. Агент с одним рабочим процессом получает версию на полстраницы. Мультиагентная система получает полный документ. Формат не меняется — меняется только длина.

Шесть вещей, которые нужны документу об объёме

1. Триггер. Что запускает работу агента — отправка формы, время по расписанию, входящее письмо, вебхук от другого инструмента. Назовите точный триггер, а не категорию триггера. «Запускается при отправке формы лида» — это объём. «Обрабатывает входящих лидов» — нет.

2. Входные данные. Какие данные получает агент и откуда они приходят. Перечислите поля, а не только источник — «имя, email, размер компании и поле свободного текста из отправки Typeform», а не «данные формы».

3. Выходные данные. Что производит агент и куда это уходит. То же правило: назовите пункт назначения и формат. «Публикует черновик ответа в Slack-канале #leads для одобрения человеком» — это объём. «Отвечает лидам» — нет.

4. Инструменты и интеграции, к которым он обращается. Каждый API, база данных или платформа, которую вызывает агент. Здесь же нужно письменно зафиксировать всё, что вы явно не интегрируете, — клиент, который считает, что его CRM включена, потому что упомянул её один раз на звонке по знакомству, — самый частый источник расползания объёма, который я видел.

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

6. Список приёмочных тестов. Реальный перечень случаев, которые готовый агент обязан пройти до финального платежа. Не «работает хорошо» — конкретные, проверяемые случаи: «корректно классифицирует 9 из 10 примеров лидов из предоставленного набора данных», «успешно публикует пост в подключённом Slack-канале без ручного вмешательства», «обрабатывает некорректную отправку (отсутствует поле email), не падая». Это самый важный раздел документа, потому что именно на него обе стороны могут указать позже, не переспоря заново, что имелось в виду.

Шаблон

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

AGENT SCOPE DOCUMENT — [Client name] / [Project name]
Date: [date]

1. TRIGGER
   [What starts this agent running]

2. INPUTS
   [Exact data fields and their source]

3. OUTPUTS
   [What the agent produces, in what format, sent where]

4. TOOLS & INTEGRATIONS
   Included: [every API/platform/database touched]
   Explicitly excluded: [anything adjacent that is NOT built]

5. EXCLUSIONS
   [What this agent will not do, even if related]

6. ACCEPTANCE TESTS
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   ...

BUILD FEE: $[amount], due [payment terms]
MAINTENANCE RETAINER: $[amount]/month, starting [date]
CHANGE REQUESTS: priced separately, quoted before work starts

Signed: _______________  Date: _______

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

Как я провожу звонок, который производит этот документ

Я оцениваю саму сессию по определению объёма как фиксированный аудит за $500–$1,000, отдельно от платы за разработку — никогда не включая её туда, даже когда клиент продолжает работать со мной. Две причины: это не даёт этапу определения объёма превратиться в неоплаченную продажу, и заставляет клиента отнестись к звонку серьёзно, а не как к бесплатной консультации.

Сам звонок длится 30–45 минут и построен вокруг шести разделов выше, по порядку. Я не даю разговору уйти в сторону «что теоретически мог бы делать ИИ-агент для вашего бизнеса» — это другой, более дорогой разговор, и именно он производит документы, которые никто не может оценить. Сначала я спрашиваю про триггер, потому что клиент, который не может назвать, что запускает процесс, обычно ещё не имеет достаточно стабильного рабочего процесса для автоматизации, — и это стоит выяснить до того, как кто-либо из вас возьмёт на себя обязательства по проекту.

Отдаю промпту черновик, а не чистый лист

Я не пишу первый черновик документа вручную. Я беру заметки со звонка — часто это просто неопрятный абзац из пунктов — и вставляю это в Claude:

Here are my raw notes from a scoping call for an AI agent build. Turn them
into a scope document with exactly these six sections: Trigger, Inputs,
Outputs, Tools & Integrations, Exclusions, Acceptance Tests. For each
section, flag anything the notes don't specify clearly enough to build
against, rather than guessing or filling the gap yourself. The acceptance
tests need to be specific and checkable — reject vague criteria like
"works correctly" and either sharpen them into a concrete test case or
flag them for me to clarify with the client.

[paste raw notes]

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

Частые ошибки, которые я всё ещё вижу

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

Приёмочные тесты, описывающие поведение вместо результата. «Агент должен понимать тон клиента» — это поведение. «Черновик ответа агента утверждается без правок в 7 из 10 примеров» — это результат. Проверяемы только результаты.

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

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

Инструменты, которые я использую для этой работы

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

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

Airtable отслеживает, какие проекты находятся на этапе определения объёма, а какие подписаны или в разработке, — одна строка на клиента, чтобы документ об объёме никогда не оставался неподписанным неделями незамеченным.

FAQ

Какой длины должен быть документ об объёме?

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

Что если клиент хочет изменить объём после подписания?

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

Нужен ли документ об объёме для очень маленьких автоматизаций?

Да, просто короткий. Ценность не в длине — она в том, что письменный список приёмочных тестов есть до начала разработки, так что «готово» становится чек-листом, а не ощущением. У меня небольшие, неформально определённые проекты растягивались дольше, чем крупные, чётко определённые, именно по этой причине.

Кому принадлежит сам документ об объёме — это часть результата работы?

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

Следующие шаги: Мой курс AI Agents for Beginners охватывает создание агентов, которых описывает такой документ об объёме. Программа cowork — для операторов, которым нужна структурированная среда, чтобы практиковаться в определении объёма и разработке такой работы. Если вы хотите, чтобы документ об объёме написали за вас, запишитесь на 30-минутную сессию.