Александр Костин – Промпт-менеджмент: как писать запросы к ИИ и получать предсказуемый ответ (страница 5)

Запрос на проверку: когда нужно не создать, а найти слабые места

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

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

Запрос на моделирование: когда нужны сценарии и последствия

Моделирование отвечает на вопросы «что будет, если». Выход – сценарии, развилки, ключевые предпосылки, риски и последствия, а также способы снизить неопределённость через сбор данных или пилот.

Ошибка режима – требовать от моделирования точного прогноза. Моделирование работает как инструмент решения: оно показывает, где риск, какие переменные важны, что стоит измерить, чтобы превратить неопределённость в управляемость.

Запрос на принятие решения: когда нужен выбор плюс план

Решение – это не сравнение и не мнение. Это рекомендация, привязанная к вашим приоритетам, с явными допущениями и планом внедрения. Выход решения – «что делаем», «почему», «какие риски», «как внедряем», «как проверяем».

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

Запрос на обучение: когда нужен навык, а не разовый ответ

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

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

Запрос на автоматизацию: когда нужна повторяемость, а не разовый успех

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

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

Запрос на коммуникацию: когда нужен текст, который выдержит внешний контакт

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

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

Один результат – много типов: почему одинаковые слова приводят к разным ответам

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

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

Смешанные запросы: как правильно разложить и собрать обратно

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

Правильная стратегия смешанного запроса – задать последовательность типов. Это можно делать прямо в тексте запроса, в одной строке: «Сначала диагностика причин, потом варианты решений, потом рекомендация, потом план внедрения и чек-лист контроля». Такое описание само по себе является управлением режимом.

Важно понимать: последовательность типов – это структура мышления. Если вы её не задаёте, она будет выбрана за вас. И почти всегда – не так, как вам нужно.

Как распознать, что тип выбран неверно: сигналы несоответствия

Есть набор характерных сигналов, по которым можно быстро понять: проблема не в качестве текста, а в неверном типе.

Первый сигнал – ощущение «много слов, нечего делать». Это значит, что вы хотели инструкцию, план или решение, а получили объяснение.

Второй сигнал – ощущение «шаги есть, но не про нас». Это значит, что вы хотели диагностику или проектирование под контекст, а получили универсальную инструкцию.

Третий сигнал – ощущение «варианты расписаны, но не сказано, что выбрать». Это значит, что вы хотели решение, а получили аналитику без приоритетов.

Четвёртый сигнал – ощущение «текст красивый, но опасный». Это значит, что вы хотели проверку или требования к достоверности, а получили генерацию без контроля фактов и рисков.

Пятый сигнал – ощущение «переделывать придётся всё». Это значит, что вы просили редактирование, когда нужна была переработка концепции, или просили «написать», когда нужно было сначала уточнить намерение и структуру.

Когда вы ловите такой сигнал, не пытайтесь «вытянуть» ответ правками стиля. Правка стиля не меняет тип. Нужно сменить режим.

Как переводить запрос из одного типа в другой за одну правку

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

Если вместо объяснения нужен план: добавьте «Выдай пошаговый план внедрения с критериями готовности каждого шага и минимальным набором входных данных».

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

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

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

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

Эти переключатели полезно хранить как стандартные фразы и использовать как операционные команды.

Типовая ошибка: просить «стратегию», когда нужен «первый шаг»

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

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

Типовая ошибка: просить «инструкцию», когда нужна «диагностика»

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

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

Запрос «один артефакт» и запрос «набор артефактов»: почему это разные режимы

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