Почему ChatGPT и Claude отвечают «нормально», но бесполезно

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

Формально не придерёшься. Практически — такое письмо можно отправить любому клиенту, в любой компании и по любому поводу. С вашим клиентом оно не сработает.

Тогда вы добавляете в промпт ещё пару слов: «сделай убедительнее», «напиши как опытный sales-менеджер», «будь настойчивее». Ответ меняется — но полезнее не становится. Всё тот же выглаженный текст, в котором не за что зацепиться.

После этого обычно выбирают один из двух путей. Одни решают, что ChatGPT и Claude годятся разве что для написания черновиков и досужих развлечений. Другие начинают искать некий «правильный промпт»: покупают книгу с заголовком вроде «580 промптов для ChatGPT», сохраняют пост «50 запросов, которые заменят маркетолога», тащат в закладки GitHub-репозиторий с тысячей шаблонов или подписываются на Telegram-канал, где каждое утро публикуют очередной «промпт, о котором вам больше нигде не расскажут».

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

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

Почему ответы получаются размытыми и бесполезными

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

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

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

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

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

У сильного промпта четыре слоя:

• Контекст — что происходит на самом деле
• Метаконтекст — через какую оптику смотреть на ситуацию
• Интенция — зачем нужен результат и что он должен изменить
• Формат — как модели подойти к задаче, прежде чем выдавать ответ

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

Разберём на одном примере.

Контекст: что происходит на самом деле

Самая частая ошибка — считать существенные детали «и так понятными».

Представьте, что вам говорят: «Нужно разгрузить автомобиль». Работа понятная. Через минуту уточняют: это не легковая машина, а грузовик. Затем: грузовик забит бетонными блоками. Затем: он застрял в болоте. И наконец: болото находится на Луне.

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

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

Было:

Напиши ответ клиенту, который отказался от сделки.

Стало:

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

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

Без этого она напишет ответ для усреднённого клиента, который отказался от усреднённой сделки. Вам же нужен ответ для конкретного человека в конкретной ситуации.

Что спросить себя: какой факт я знаю, но не написал, потому что он кажется очевидным? Часто именно там лежит половина решения.

Метаконтекст: через какую оптику смотреть

Контекст отвечает на вопрос «что случилось». Метаконтекст — на вопрос «через какую рамку это интерпретировать».

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

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

С отказавшимся клиентом происходит то же самое:

• Роль: «Посмотри на ситуацию как руководитель отдела продаж в B2B SaaS» — фокус на следующем шаге, риске потери сделки и тактике переговоров
• Модель: «Проанализируй ситуацию через воронку продаж» — фокус на этапе, где клиент выпал из процесса, и на проблемах демо или оффера
• Методология: «Используй принципы переговоров Фишера и Юри» — фокус на интересах сторон, а не на позиции «у вас дорого»
• Точка зрения клиента: «Посмотри на ситуацию глазами клиента» — фокус на том, почему прежние аргументы не сработали
• Экономическая оптика: «Оцени ситуацию с точки зрения совокупной стоимости владения и экономики внедрения» — разговор о цене лицензии превращается в разговор о затратах, потерях и окупаемости

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

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

Что спросить себя: чья экспертиза, какая теория или какая точка зрения сделает ответ действительно полезнее?

Интенция: чтобы что

Теперь самый неудобный вопрос: зачем вам вообще нужен этот ответ?

Не «что требуется сделать», а «что должно измениться после результата». Это и есть интенция.

С одним и тем же отказавшимся клиентом можно решать разные задачи:

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

Факты остаются теми же. Но меняются цель, логика ответа, тон и критерии качества.

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

Что спросить себя: «Чтобы что мне этот ответ?» А затем ещё раз: «Чтобы что мне это?» Второй вопрос часто отделяет формальный запрос от реальной потребности.

Например, «нужно письмо клиенту» может оказаться задачей «понять, можно ли ещё спасти сделку». А «нужно ревью кода» — задачей «не пропустить риски перед релизом». Исходный артефакт один, но задачи разные.

Формат: как оформить ответ

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

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

Несколько полезных конструкций:

• Несколько стратегий: «Предложи три стратегии ответа. Для каждой укажи преимущества, риски и условия, при которых она уместна»
• Premortem: «Представь, что этот ответ окончательно сорвал сделку. Почему это произошло? Перепиши письмо так, чтобы снизить эти риски»
• Адвокат дьявола: «Сформулируй сильнейшую позицию клиента против нашего предложения. Затем подготовь ответ, который не игнорирует эти возражения»
• Самокритика: «Подготовь черновик, затем оцени его глазами скептичного клиента и перепиши с учётом слабых мест»
• Сценарии: «Дай вариант для случая, если клиент готов к разговору; если уже выбрал конкурента; и если цена — только прикрытие для другого возражения»
• Несколько тональностей: «Подготовь жёсткую, нейтральную и мягкую версии. Кратко поясни, в какой ситуации выбрать каждую»

В этом и состоит значительная часть «изощрённых техник» из платных библиотек промптов. Их ценность не в экзотических названиях. Они не дают модели остановиться на первом гладком тексте.

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

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

Что спросить себя: мне нужен готовый текст с первого раза или сначала нужны варианты, риски и критерии выбора?

Один запрос, четыре слоя

Вернёмся к исходной формулировке.

Запрос А:

Напиши ответ клиенту, который отказался от сделки.

Теперь — версия, в которой закрыты все четыре слоя.

Запрос Б:

Мы продаём B2B SaaS для автоматизации ручного процесса у клиентов среднего бизнеса. После демо клиент отказался от сделки, сославшись на цену. Три месяца назад ему уже предложили скидку 15%, поэтому дополнительную скидку сейчас не рассматриваем. По косвенным признакам клиент сравнивает нас с конкурентом. На демо команда клиента не увидела достаточно убедительной экономической выгоды от внедрения, хотя ручной процесс занимает несколько сотрудников и приводит к ошибкам.Посмотри на ситуацию одновременно как руководитель отдела продаж в B2B SaaS и как консультант по принципиальным переговорам. Отдельно оцени ситуацию глазами клиента: какие риски, сомнения или ожидания могут скрываться за формулировкой «слишком дорого»?Наша цель — вернуть клиента к предметному разговору без дополнительной скидки. Нужно сместить обсуждение с цены лицензии на стоимость текущего ручного процесса, риски бездействия и измеримый эффект от внедрения. При этом нельзя давить, спорить с возражением клиента или звучать как шаблонный продавец.Сначала предложи три стратегии следующего контакта. Для каждой укажи логику, риски, признаки того, что она уместна, и пример первого шага. Затем выбери оптимальную стратегию при имеющихся данных и объясни выбор.После этого подготовь короткое письмо клиенту: спокойное, уважительное, без канцелярита и агрессивного продавливания. Письмо должно приглашать к следующему разговору и содержать один конкретный вопрос, который поможет выяснить истинную причину отказа.В конце перечисли, каких данных не хватает для следующей итерации и как они могут изменить выбранную стратегию.

Разница между А и Б — не в количестве слов как таковом. Во втором запросе модель понимает, что происходит, через какую оптику рассматривать ситуацию, к какому результату прийти и каким путём работать.

Никакой магии. Просто задача перестала быть недосказанной.

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

Как уточнить свой промпт с помощью нейросети

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

Поэтому я собрал системный промпт-усилитель. Он берёт сырой запрос и превращает размытое «хочу вот это» в внятно поставленную задачу.

Он не выдаёт себя за оракула и не делает вид, будто с первого сообщения знает вашу ситуацию лучше вас. Вместо этого он строит гипотезы: где в запросе, вероятно, не хватает контекста, оптики, цели или способа работы с задачей. Затем предлагает усиленные версии промпта, задаёт уточняющие вопросы и даёт варианты ответов.

Дальше можно действовать как удобно:

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

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

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

А вот и сам системный промпт: