Промпт-менеджмент: как писать запросы к ИИ и получать предсказуемый ответ

Глава 3. Типы запросов и почему «не тот тип» ломает результат

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

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

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

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

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

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

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

Инструктивный запрос: когда нужен маршрут, а не философия

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

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

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

Диагностический запрос: когда важнее понять причины, чем действовать

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

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

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

Проектный запрос: когда нужно собрать решение под ограничения

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

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

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

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

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

Генеративный запрос: когда вы создаёте материал, а не оцениваете истину

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Второй: причина известна или неизвестна. Если неизвестна – диагностический. Если известна – инструкция или проектирование.

Третий: мне нужен выбор из вариантов или один конкретный путь. Если выбор – аналитика. Если путь – решение или план.

Эта тройка вопросов снимает большую часть неопределённости и резко повышает точность постановки.

Связка «поиск + запрос»: почему тип важен даже при сборе информации

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

Если тип не определён, вы утонете в источниках. Поэтому сначала режим, потом поиск. И уже после – сбор материалов.

Переход от типов запросов к управлению процессом: тип как инструмент руководителя

На уровне руководителя тип запроса становится управленческим рычагом. Он задаёт, что именно вы хотите получить от команды: объяснение, план, риск-реестр, матрицу решений, протокол внедрения, регламент. Когда вы формулируете запросы типами, вы перестаёте получать «мнения» и начинаете получать управляемые артефакты.

Это меняет качество исполнения. Команда понимает, что от неё требуется. Снижается количество согласований. Уменьшаются конфликты ожиданий. Повышается скорость принятия решений. А главное – становится проще контролировать качество, потому что у каждого типа есть свои критерии приемки.

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

Глава 4. Структура точного запроса: универсальная «форма» для любой задачи

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

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

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

Минимальная форма точного запроса: 6 блоков, которые закрывают 80% задач

Первый блок – заголовок задачи в одной строке. Он должен быть конкретным, с глаголом и объектом. Не «Помоги с маркетингом», а «Составь план A/B теста первого экрана лендинга услуги X». Заголовок нужен, чтобы фиксировать смысл и не давать задаче расползаться в процессе.

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

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

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

Пятый блок – формат результата. Что именно вы хотите получить: план, чек-лист, регламент, шаблон, текст, сценарий, набор вариантов. Формат – это упаковка результата для использования. Если формат не задан, вы почти гарантированно получите «объяснение» вместо «инструмента».

Шестой блок – критерии приемки. Это признаки, по которым вы скажете «да, это то». Критерии приемки могут быть простыми: «в ответе должны быть шаги, сроки, риски, первый шаг на завтра». Но они должны быть. Без критериев приемки любые обсуждения качества превращаются в субъективный спор.

Расширенная форма: 12 блоков, когда нужна высокая точность и применимость

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

Заголовок задачи (одна строка). Глагол + объект + ожидаемый эффект или назначение.

Пример: «Собери структуру точного запроса для внедрения регламента обработки лидов в агентстве».

Результат в одном предложении: что должно оказаться у вас в руках.

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

Контекст: факты о ситуации.

Пример: «Команда 10 человек, задачи идут через чат, часто теряется ответственность, сроки срываются из-за расплывчатых постановок».

Проблема/симптомы: что сейчас не работает и как это проявляется.

Пример: «Появляются правки “не то”, по 3–4 итерации, нет ясных критериев “готово”».

Цель: что должно измениться.

Пример: «Сократить число итераций до 1–2 и повысить процент задач, которые принимаются с первого раза».

Аудитория результата: кто будет читать/использовать.

Пример: «Руководитель (контроль), тимлид (постановка), исполнители (выполнение)».

Ограничения: сроки, бюджет, ресурсы, инструменты, доступы.

Пример: «Внедрение без новых платных инструментов, всё на существующих процессах, срок – 2 недели».