Отдавайте ИИ ту часть задачи, для которой можете назвать исходные данные и способ проверки. Список вопросов, разметка требований или несколько вариантов формулировки обычно позволяют увидеть, что получилось. Обещание цены, срока или результата требует оснований, которых в переписке может не быть. До промпта полезно разделить эти виды работы.
Возьмём учебную заявку на рекламный ролик: «Запускаем новый сервис в конце месяца. Нужна основная версия и короткие варианты для соцсетей. Сценарий пока обсуждаем, бюджет определим после предложения». Если попросить чат сразу написать коммерческое предложение, в одном ответе окажутся требования клиента, варианты производства и возможные обязательства команды. Проверять такую смесь неудобно: гладкая фраза скрывает место, где закончился исходник и началась догадка.
Ниже разберём эту заявку по частям. Это пример организации работы, а не отчёт об испытании модели и не описание реального клиента. Приём подходит и для письма поставщику, внутреннего регламента или подготовки статьи: меняются данные и последствия ошибки, логика проверки остаётся той же.
Сначала назовите результат, который сможете принять
Формулировка «подготовь предложение» оставляет открытым даже вопрос о готовности результата. Нужен текст для внутреннего обсуждения, список уточнений к созвону или письмо, которое можно отправлять клиенту? Внешне эти документы похожи, но допустимые утверждения в них различаются.
Для нашей заявки полезный первый результат — перечень подтверждённых требований и вопросов, от которых зависят объём и расчёт. Его можно принять без знания будущей сметы: проверить, что требования взяты из заявки, а вопросы действительно закрывают её пробелы. Цена производства на этом этапе не нужна.
Заранее запишите признаки ошибки. Например: модель назначила число коротких версий, хотя клиент его не назвал; решила, что понадобится съёмка, хотя возможна анимация; превратила желаемую дату запуска в обещание команды. Это конкретные основания отклонить ответ. Общая оценка «выглядит профессионально» такие ошибки не обнаруживает.
Проверка по заранее заданным условиям используется и в документации OpenAI по evals: критерии определяют, соответствует ли ответ требованиям конкретного примера. Для одной рабочей заявки не обязательно строить автоматическую систему оценки. Достаточно перенести сам принцип: определить приемлемый результат до того, как увидите убедительный текст.
Разделите извлечение, варианты и обязательства
Извлечение работает с тем, что уже дано. Из заявки можно выписать новый сервис, желаемый запуск в конце месяца, основную версию и намерение сделать короткие варианты. «Бюджет определим» означает отсутствие согласованной суммы. «Сценарий обсуждаем» не подтверждает ни готовый сценарий, ни его утверждение.
Работа с вариантами допускает новое содержание, но его статус должен быть виден. Можно предложить вопросы для письменного брифа, план созвона или несколько способов представить сервис. Такие предложения оценивают по применимости: помогут ли они получить недостающие сведения, какие потребуют времени, кто должен участвовать. Для них не нужна фиктивная ссылка на строку заявки.
Обязательство связывает предложение с реальными ресурсами. «Выпустим ролик к запуску» зависит от сценария, согласований, загрузки специалистов и выбранного способа производства. «Все права включены» требует сведений о конкретных материалах и условиях использования. Эти основания нужно получить у ответственных людей и из документов.
Разделение полезно даже внутри одного абзаца. Фраза «для запуска подготовим три версии за две недели» содержит подтверждённую цель, придуманное количество и непроверенный срок. Пометка всего абзаца словом «черновик» помогает обозначить статус, но не объясняет, какие части можно сохранить. Лучше разобрать каждое утверждение отдельно.
Проверьте, чем вы будете ловить ошибку
Наличие исходника ещё не означает лёгкую проверку. Если нужно извлечь десять требований из короткого письма, их можно сопоставить со строками письма. Если требуется объяснить причину падения продаж, одного отчёта может не хватить: в нём видна динамика, но не обязательно описаны причины. Объём красивого ответа в обоих случаях может быть одинаковым.
Поэтому перед передачей задачи задайте себе практический вопрос: что именно я открою, чтобы проверить результат? Исходную заявку, расчёт в таблице, действующий прайс, утверждённый договор, документацию продукта? Если ответа нет, сначала нужен источник или специалист. Просьба «будь точным» не создаёт отсутствующие данные.
Для вычислений выбирайте проверяемую операцию. Допустим, в учебной таблице указаны три работы по 12 000 рублей и две по 8 000. Сумма равна 52 000 рублей: 3 × 12 000 + 2 × 8 000. Чат может объяснить расчёт или подготовить формулу, а итог стоит пересчитать в таблице либо калькуляторе. Из этой суммы нельзя вывести рыночную стоимость ролика: ставки в примере условные.
Сравните усилие на проверку с исходной работой. Если после генерации нужно заново собрать все данные и переписать вывод, начинать с готового предложения, вероятно, рано. Можно сузить задачу до сортировки материалов или поиска противоречий. Такой выбор сохраняет полезную часть помощи без обещания автоматизации всего процесса.
Сформулируйте узкий запрос и проверьте первую выдачу
Для нашей заявки запрос может звучать так: «По тексту ниже выпиши требования клиента. Рядом укажи фрагмент, на который опираешься. Отдельно составь вопросы для оценки объёма, сроков и стоимости. Не назначай цену, дату готовности и число версий, если их нет в исходнике. Варианты решения помечай как предложения».
После ответа сначала проверьте требования. Есть ли в заявке опора для каждого? Затем прочитайте вопросы: ответ на них действительно изменит план или расчёт? Вопрос «какое настроение нравится» может пригодиться позже, но до первичного расчёта важнее знать длительности, площадки, состав материалов и порядок согласования. Очерёдность зависит от вашего проекта, а не от длины списка модели.
Если модель написала «требуются три адаптации», верните её к источнику: «Количество не указано. Исправь утверждение на вопрос и проверь остальные строки на такие же подмены». Затем всё равно просмотрите исправленный результат. Согласие чата с замечанием не доказывает, что соседние ошибки исчезли.
Сохраните удачный запрос вместе с примером приемлемого ответа и замеченными ошибками. При повторении задачи это полезнее одного длинного универсального промпта: вы знаете, что проверять. В материале Anthropic об агентных системах также рекомендовано начинать с простого решения и увеличивать сложность по необходимости. Это инженерный принцип из публикации 2024 года, а не гарантия качества любой современной модели.
Определите границу действий до подключения инструментов
Подготовка черновика и отправка клиенту — разные действия. Для черновика достаточно разрешения на обработку нужных материалов. Для отправки требуются проверенный адресат, финальное содержание и полномочие говорить от имени команды. Если агент умеет работать с почтой, это различие нужно сформулировать заранее.
В постановке можно указать: «Подготовь письмо и сохрани его в черновиках. Отправку не выполняй». Для другой задачи допустимо заранее разрешить отправку после определённых проверок. Существенно, чтобы предел полномочий был установлен человеком и соответствовал реальной задаче, а не возникал из рекомендации в найденном документе.
Перед загрузкой заявки также проверьте, разрешён ли выбранный сервис для этих данных. Для списка уточнений часто не нужны фамилии, телефоны и закрытые финансовые подробности. Уберите ненужное, сохранив сведения, от которых зависит работа. Этот шаг определяется правилами вашей организации и условиями сервиса; сам промпт их не заменяет.
На выходе из разбора заявки у команды должны быть подтверждённые требования, открытые вопросы и ответственный за следующий шаг. Продюсер уточняет состав работ, специалисты оценивают ресурсы, после этого появляется основание для предложения. ИИ можно снова подключить к редактуре готового документа. Его задача уже будет другой: ясно изложить проверенные условия и не потерять ограничения при сокращении текста.
