Промпты для бизнес-процессов на основе правил, а не примеров

Почему промпты, построенные на примерах, ломаются в реальной работе

Подход, где сначала показывают примеры, хорошо выглядит в демо. Кто-то вставляет аккуратный образец, модель копирует шаблон, и результат кажется умным. Но реальные бизнес-процессы гораздо менее аккуратны. В них есть ограничения, крайние случаи и шаги согласования, а примеры — плохое место для хранения такой логики.

Отполированный пример учит форме ответа, а не правилу, которое за ним стоит. Если компания разрешает возвраты до $100 без проверки, запрещает подарочные карты и отправляет все, что выше, в финансы, один удачный образец не объяснит эту политику достаточно ясно.

Сдвиги в формулировке тоже могут менять результат сильнее, чем ожидают команды. «Клиент попросил возврат из-за задержки» может дать один ответ. «Клиент расстроен и просит немедленный возврат» — другой. Политика та же. Формулировка изменилась. Для повторяемой работы это плохая основа.

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

Примеры также усложняют проверку. Финансы, операционный отдел и юристы могут посмотреть на таблицу правил или список условий. Но им сложно быстро понять несколько абзацев промпта и увидеть, какое именно предложение управляет лимитами бюджета, кто может одобрить исключения или когда модель должна отказать.

Простой рабочий сценарий показывает проблему. Допустим, сотрудник просит купить софт за $79 в месяц. Один пример может научить модель одобрять такую заявку. Но что, если сервис хранит данные клиентов, продлевается автоматически или дублирует уже оплаченный компанией продукт? Эти недостающие правила важнее примера.

Примеры все же полезны. Используйте их уже после того, как структура определена, в основном чтобы задать тон и формат. Не опирайтесь на них там, где бизнес-правила должны быть понятными, проверяемыми и обновляемыми.

Что собрать до того, как вы начнете писать промпт

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

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

Потом перечислите все входные данные, которые нужны модели для безопасного решения. Думайте полями, а не текстом. Вместо запроса «детали заявки» разбейте ее на точные части: сумма, отдел, причина, срок, поставщик, срок действия договора и входит ли расход в бюджет.

Одно пропущенное поле может сломать весь процесс. Если покупка софта требует проверки службы безопасности только тогда, когда в нем есть клиентские данные, то поле «обрабатывает клиентские данные: да или нет» должно быть обязательно. Без него модель начнет гадать.

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

То же самое касается блокирующих условий. Некоторые запросы останавливаются, потому что не хватает документа, неверен код бюджета или уже прошел дедлайн. Опишите такие условия простыми словами, чтобы промпт мог сказать «дальше нельзя» вместо того, чтобы толкать задачу вперед.

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

Хорошая стартовая база выглядит просто:

• текущий текст политики
• точные поля ввода
• согласующий для каждой ветки
• условия, которые останавливают процесс
• исключения, которые люди обрабатывают вручную

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

Превратите политику в поля, варианты и флаги

Промпты становятся безопаснее, когда правила перестают прятаться в абзацах и переходят в структуру входных данных. Формулировка важна, но структура важнее.

Сделайте каждое правило отдельным полем. Если менеджеры могут одобрять поездки до $1,000, а все, что выше, должно идти в финансы, не прячьте это правило в примечании. Храните amount, requester_role и approval_level как отдельные входы. Когда модель видит аккуратные части, она реже начинает додумывать.

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

Например, в процессе расходов поле request_type может принимать значения travel, software, training или other. status может быть draft, pending_manager, pending_finance, approved или rejected. requester_role может быть employee, manager или contractor. policy_exception может быть yes или no, а policy_source может указывать на конкретный набор правил, например travel_policy_v3.

Лимиты, роли и даты тоже держите в отдельных полях. Не запихивайте в одну фразу «менеджер может одобрить до 30 июня на сумму до $1,000» и не ждите, что модель каждый раз прочитает это одинаково. Разбейте на max_amount, approver_role, effective_date и end_date. Это выглядит скучно, но скучное решение — хорошее решение, когда речь идет о деньгах или комплаенсе.

Добавьте одно поле, которое указывает на исходную политику или набор правил. Это сильно упрощает проверки. Когда кто-то спрашивает, почему ИИ отправил запрос в финансы, вы можете отследить ответ через policy_source, а не спорить о формулировке промпта.

Комментарии по-прежнему нужны, но держите их в одном текстовом поле и больше нигде. Людям нужно место, чтобы объяснять необычные случаи, например: «у гостиницы рядом с площадкой конференции был только один доступный вариант». Все остальное должно оставаться структурированным.

Именно этот шаг многие команды пропускают. Сначала они настраивают промпт, а потом удивляются, почему ответы меняются. Обычно проблема не в самой модели. Проблема в том, что входные данные слишком грязные.

Добавьте исключения и маршруты согласования

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

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

Обычному рабочему процессу обычно нужны поля вроде exception_type, approval_required, approver_role, override_allowed и exception_reason. Эти поля показывают модели, когда остановиться, когда попросить человека проверить запрос и когда правило можно временно изменить.

Сделайте точки согласования жесткими условиями, а не мягкими намеками. Требуйте согласование, если сумма выше лимита, если запрос нарушает правило, если кто-то просит обход, или если данные в документах не совпадают. Как только появляется одно из этих условий, модель должна переключиться с режима «решить» на режим «подготовить к проверке».

Будьте точны в вопросе полномочий. Руководитель команды может одобрить небольшое бюджетное исключение. Финансы могут согласовать изменение налога. Юристы могут закрыть вопрос с контрактом. Если это не прописать, промпт начнет считать все согласования равными, а именно так маленькие ошибки превращаются в рискованные.

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

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

Напишите промпт после того, как структура уже есть

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

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

После этого обращайтесь к именам полей ровно так, как они названы в форме или полезной нагрузке. Используйте request_type, amount, country, policy_match и manager_approval. Не подменяйте их сюжетными примерами вроде «сотрудник летит в Берлин на встречу с клиентом». Истории звучат естественно, но они же провоцируют догадки.

Порядок тоже важен. Скажите модели, что делать сначала, затем и в конце:

• Сначала проверь, что все обязательные поля заполнены.
• Затем применяй бизнес-правила по порядку.
• Потом реши, подходит ли запрос для автоодобрения, отклонения или ручной проверки.
• В конце верни ответ только в требуемом формате.

Такой порядок убирает много плохих ответов. Если какого-то поля не хватает или два правила противоречат друг другу, скажите об этом прямо в промпте: остановись, не угадывай и попроси человека проверить запрос. Многие рискованные ответы появляются тогда, когда модель пытается помочь, хотя должна была сделать паузу.

Формат вывода нужно зафиксировать. Выберите один формат и придерживайтесь его всегда, обычно это небольшой JSON-объект или таблица с фиксированными столбцами. Возвращайте поля вроде status, reason, needs_human_review и missing_fields. Если разрешить модели отвечать свободным текстом, она начнет расплываться. Одни ответы будут аккуратными. Другие спрячут решение в абзаце.

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

Простой пример: согласование командировочных расходов

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

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

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

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

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

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

Ошибки, из-за которых выходит неверный или рискованный результат

Многие плохие промпты для рабочих процессов начинаются с образца письма. Команда вставляет два-три сообщения, добавляет «следуй нашей политике» и надеется, что модель поймет логику. Обычно это не работает. Образцы писем скрывают настоящие правила, особенно неудобные части вроде исключений, недостающих чеков, разделенных согласований или лимитов, которые изменились в прошлом квартале.

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

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

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

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

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

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

Короткая проверка перед запуском

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

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

Используйте короткий чек-лист:

• Проверьте трассируемость. Каждое решение, метка и комментарий должны соответствовать правилу или полю.
• Проверьте исключения. Особые случаи должны иметь свои поля, а не одну общую текстовую заметку.
• Проверьте поведение при недостающих данных. Модель должна остановиться, попросить недостающее или вернуть фиксированное состояние ошибки.
• Проверьте повторяемость. Дайте один и тот же случай двум проверяющим и сравните результаты.
• Проверьте формат. Ответ всегда должен быть одной и той же формы.

Исключения заслуживают особого внимания, потому что именно они часто ломают в целом хороший дизайн промпта. Если расход выходит за бюджет, но уже был предварительно одобрен, или покупка обычно требует проверки финансов, но подпадает под правило экстренного случая, для таких ситуаций нужны отдельные входные данные. Размытая пометка вроде «особый случай» обычно недостаточна.

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

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

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

Следующие шаги для вашей команды

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

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

Достаточно короткого плана работы:

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

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

Сделайте первую версию маленькой. Десять хороших тестовых случаев лучше пятидесяти расплывчатых. Если заявка больше $5,000 требует согласования в финансах, проверьте $4,999, $5,000, $5,001 и запрос без указанной суммы. Такие граничные случаи часто показывают больше, чем длинный промпт.

Если вам нужна внешняя оценка, Oleg Sotnikov на oleg.is помогает стартапам и небольшим компаниям превращать запутанные технические процессы в практичные рабочие процессы с поддержкой ИИ. Это особенно полезно, когда политика понятна людям в голове, но ее трудно превратить в согласования, исключения и автоматизацию, которой команда может доверять.