Качество ответов ИИ падает, когда промпты скрывают продуктовые решения

Почему «используй здравый смысл» приводит к плохим ответам

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

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

Поэтому качество ответов ИИ падает даже тогда, когда команде, писавшей промпт, кажется, что все понятно. У людей есть молчаливые допущения. Они понимают, что значит «слишком длинно», «слишком неформально» или «достаточно безопасно». Модель — нет. Если не проговорить эти решения прямо, она начинает гадать.

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

Скрытые решения обычно прячутся в четырех местах:

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

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

Простой продуктовый пример хорошо это показывает. Представьте ассистента поддержки для SaaS-инструмента. В промпте сказано: «Используй здравый смысл и помоги пользователю быстро решить проблему». Один пользователь просит возврат денег после неудачной настройки. Должен ли ассистент извиниться, объяснить политику, предложить диагностику или сразу одобрить возврат? Каждый вариант может казаться разумным. Правильный ответ зависит от бизнес-правил, статуса аккаунта, окна возврата и того, сколько полномочий есть у ассистента.

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

Что команды часто оставляют невысказанным

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

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

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

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

Слова внутри продукта важнее, чем командам кажется. Если в вашем бизнесе есть выражения вроде «Fractional CTO», «technical due diligence» или «AI-augmented development», модель должна использовать именно их и избегать выдуманных ярлыков. Единый язык делает ответы понятнее и создает ощущение одного продукта, а не пяти разных голосов, сшитых вместе.

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

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

Такой простой набор правил каждый раз выигрывает у фразы «используй здравый смысл в промптах». Работа Олега со стартапами и клиентами Fractional CTO показывает, почему: как только команда записывает эти продуктовые решения, модель перестает гадать и начинает вести себя как часть бизнеса.

Как заметить расплывчатые инструкции в промпте

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

Начните с поиска фраз, которые звучат безобидно, но не несут правила. Вот частые примеры:

• «используй здравый смысл»
• «будь полезным»
• «обрабатывай крайние случаи»
• «делай уместно»
• «отвечай нормально»

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

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

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

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

Хороший промпт обычно разделяет это так:

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

Если вы работаете со стартап-командой, такая проверка экономит время. Олег часто работает над AI-first workflows, где одна расплывчатая строка может потом обернуться часами исправлений. Настройка модели не исправит промпт, который по-прежнему просит ее угадывать.

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

Замените догадки правилами предметной области

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

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

Каждому правилу нужен один пример, который должен пройти проверку. Пусть он будет скучным и конкретным. Если пользователь говорит: «Я зарегистрировался вчера и один раз открыл приложение. Могу я получить возврат?», ответ должен соответствовать правилу: «Да. Ваш аккаунт находится в пределах 14 дней, а использование низкое, поэтому я могу предложить полный возврат».

Затем проверьте то же правило на сложном запросе, который все еще часто встречается. Попробуйте что-то вроде: «Я пользовался приложением две недели, экспортировал все данные и теперь хочу вернуть деньги». Именно на таких кейсах расплывчатые промпты ломаются. Хорошее правило не дает модели гадать и отправляет случай на ручную проверку.

Пишите правила в одном и том же формате каждый раз:

• Если [условие], сделай [действие].
• Если [исключение], сделай [другое действие].
• Если правило не покрывает случай, эскалируй.

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

Простой продуктовый пример

Представьте бот поддержки для SaaS-продукта. Клиент пишет на 31-й день и просит возврат. Промпт говорит боту следовать политике возврата, но еще добавляет одну расплывчатую фразу: «используй здравый смысл», если случай выглядит справедливым.

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

До правила

В одном запуске бот одобряет возврат, потому что клиент звучит честно и говорит, что забыл отменить подписку. В другом — отказывает, потому что 31-й день выходит за пределы 30-дневного окна. В третьем — начинает задавать странные вопросы про активность аккаунта или данные устройства, которые вообще не относятся к возврату.

Все три ответа на секунду могут звучать разумно. В этом и проблема. Команда не может понять, следовал ли бот политике или просто импровизировал.

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

После правила

Теперь замените размытое указание небольшим набором правил:

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

Это меняет задачу бота. Он больше не решает, что значит «справедливо». Он проверяет факты по порядку, а затем выполняет разрешенное действие.

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

Теперь команда может проверять каждый ответ по одному стандарту. Лид поддержки может прочитать ответ и задать простые вопросы: проверил ли бот дату? Проверил ли он тариф? Эскалировал ли он случай, когда правило требовало эскалации?

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

Ошибки, из-за которых промпты сложнее выполнять

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

Частая ошибка — смешивать голос бренда с правилами принятия решений. «Звучи спокойно и бодро» — это замечание о стиле. «Запрашивай номер заказа перед обсуждением возврата» — это правило. Когда они стоят в одном абзаце, модель может принять жесткое правило за мягкий совет. Разделите голос в одном месте, правила продукта — в другом, и пусть правило всегда имеет приоритет.

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

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

Нестабильный промпт можно быстро заметить по нескольким признакам:

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

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

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

Быстрая проверка перед следующим тестом

Перед тем как тратить время на настройку, проведите короткий аудит промпта. Пять минут сейчас могут сэкономить часы потом. Большинство провалов в качестве ответов ИИ появляются из-за правил, которые автору кажутся понятными, а всем остальным — нет.

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

Используйте этот чек-лист перед следующим раундом тестирования:

• Убедитесь, что у каждого правила есть триггер и действие. «Если пользователь спрашивает цену, сначала запроси регион» — это рабочий вариант. «Будь умным в вопросах цены» — нет.
• Решите, что модель должна делать, когда данных не хватает. Ей задавать один уточняющий вопрос, использовать значение по умолчанию, отказывать или передавать случай человеку?
• Добавьте хотя бы одно правило отказа или эскалации. Это особенно важно, когда модель получает юридические, медицинские, финансовые или зависящие от аккаунта запросы.
• Назначьте каждому правилу одного владельца. Один человек должен утверждать формулировку, обновлять ее и решать, когда она меняется.
• Проверьте, не конфликтуют ли два правила. Если конфликт есть, пропишите, какое из них главнее.

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

Небольшой продуктовый пример это хорошо показывает. Представьте бота поддержки для SaaS-инструмента. Пользователь пишет: «Мой экспорт снова не удался». Если в промпте не сказано, что означает «снова», каким логам может доверять бот и когда он обязан передать случай в поддержку, модель начнет импровизировать. Лучшее правило звучит просто: «Если статус экспорта неизвестен, запроси ID задания. Если задание дважды завершилось ошибкой за 24 часа, эскалируй в поддержку. Не предлагай решение без записи в логах».

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

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

Что делать дальше вашей команде

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

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

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

Что делать дальше

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

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

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

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

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