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

Глава 1. Намерение как фундамент запроса: что вы реально хотите получить

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

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

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

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

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

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

Намерение полезно воспринимать как контракт. Контракт не обязательно юридический; это договор о том, что считается выполнением. Если вы не фиксируете критерии приемки, вы подписываете пустой лист и надеетесь, что исполнитель сам догадается, что вы имели в виду. Контракт намерения отвечает на два вопроса: «Что должно быть на выходе?» и «По каким признакам мы принимаем работу?». Внутри компании это экономит время на согласованиях и снижает риск конфликтов. В работе с подрядчиками это снижает расползание объёма. В работе с ИИ это снижает количество итераций, которые вы делаете не ради качества, а ради того, чтобы наконец совпасть в понимании задачи.

У контракта есть важная часть – границы. Нередко задача расползается не потому, что исполнитель ленив, а потому, что вы не сказали, что именно не входит. Вроде бы странно уточнять «что не делать», но границы экономят ресурсы лучше любых мотивационных речей. Границы бывают по содержанию (какие темы не трогать), по методам (какие инструменты не использовать), по стилю (какой тон недопустим), по объёму (сколько страниц или разделов), по времени (какой срок актуальности нужен), по риску (где недопустимы предположения). Чем выше цена ошибки, тем жёстче должны быть границы.

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

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

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

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

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

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

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

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

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

Чтобы намерение стало привычкой, нужен быстрый шаблон, который помещается в две строки и заставляет вас выбирать слова внимательно. Он может звучать так: «Хочу получить X, чтобы Y. Успех = Z». X – артефакт или результат, который можно увидеть и передать. Y – зачем это нужно, какое действие или решение вы сможете сделать. Z – критерий, по которому вы признаете, что ответ годится: формат, глубина, ограничения, уровень точности, применимость. Если вы научитесь прогонять через эти две строки даже короткие запросы, качество коммуникации резко вырастет, а количество уточнений и раздражения заметно снизится.

Короткий чек-лист вычитки намерения перед отправкой:

– На выходе будет конкретный артефакт или понятный результат.

– Понятно, для кого результат и где он будет использован.

– Названы критерии приемки и ограничения.

– Ясно, почему задача важна сейчас и что будет, если ошибиться.

– Я могу ответить, что сделаю по-другому после получения ответа.

Глава 2. Перевод намерения в задачу: формулировка, которая не разваливается

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

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

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

Превращение «хочу» в «сделай»: глагол действия + объект + критерий качества

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

Рабочая формула одной строки выглядит так:

Сделай [действие] с [объектом] так, чтобы [критерий качества / признак приемки].

Примеры формулировок как конструкций (их можно копировать и подставлять свой контекст):

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

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

– Собери план работ на месяц так, чтобы он включал приоритеты, зависимости и критерии готовности по каждой задаче.

Четыре обязательных элемента задачи: цель, контекст, ограничения, формат

Стабильная задача держится на четырёх опорах.

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

Контекст: где и при каких условиях выполняется задача. Контекст задаёт границы интерпретации. Без него исполнитель заполняет пустоты собственными предположениями.

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

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

Опасные слова без опоры: «лучше», «эффективнее», «топовый», «современный»

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

Список слов-ловушек и безопасная замена:

– «сделай лучше» → «уменьши количество шагов до результата», «сократи время на чтение», «сделай структуру понятнее по чек-листу»

– «эффективнее» → «с меньшими затратами времени», «с меньшим риском ошибок», «с большей повторяемостью результата»

– «современно» → «в соответствии с текущими паттернами интерфейсов/коммуникаций, без устаревших клише, с короткими формулировками и ясными призывами»

– «сильно» → «с ясной логикой, конкретными шагами, без общих фраз, с критериями приемки»

Как уточнять неопределенности без лишних вопросов: список допущений

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

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

– если данных нет, сделай разумные допущения и пометь их отдельным блоком «Допущения»;

– если допущение влияет на результат критически, вынеси это как вопрос.

Формат допущений, который удобно принимать:

Что предполагаю.

Почему предполагаю именно так.

Как это влияет на результат.

Что нужно уточнить, чтобы убрать предположение.

Лестница конкретики: от общего к частному, пока не появляется проверяемость

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

Пример лестницы как метода:

– «нужно улучшить страницу»

– «нужно улучшить страницу для роста записей»

– «нужно улучшить первый экран, чтобы человек быстрее понял ценность и увидел действие»

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

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

Формулировка через артефакт: «дай файл/план/чек-лист/структуру»

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

Типовые артефакты для задач:

– план внедрения (шаги, последовательность, критерии готовности)

– чек-лист контроля качества (как проверить, что сделано)

– шаблон документа (структура + правила заполнения)

– структура страницы/материала (блоки, смысл каждого блока)

– список гипотез (с условиями проверки и метриками)

– скрипт коммуникации (фразы, логика, запреты)

Формулировка через действие пользователя: «я хочу скопировать и применить»

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

Конструкция:

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

Примеры:

– …так, чтобы я мог сразу передать это исполнителю без дополнительных пояснений.

– …так, чтобы я мог вставить это в регламент и обучить новичка за один созвон.

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

Формулировка через сценарий использования: «где, когда и кем будет применено»

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

Минимальный сценарий – три ответа:

Где будет использоваться результат.

Кто будет читать/использовать.

Что должно произойти после использования.

Формулировка через риск: «ошибки, которые нельзя допустить»

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

Как прописывать риск в задаче:

– недопустимо выдумывать факты и цифры;

– недопустимо обещать результат, который нельзя гарантировать;

– недопустимо использовать термины без расшифровки, если текст для широкой аудитории;

– недопустимо менять смысл исходного текста при редактировании.

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

Практический конфликт почти всегда один: вы хотите получить всё сразу. Задача становится устойчивой, когда приоритет назван прямо.

Шаблон приоритетов:

Главное: [1 приоритет].

Важно: [2–3 приоритета].

Допустимо пожертвовать: [что можно упростить].

Пример:

Главное: применимость и готовность к внедрению.

Важно: ясность для исполнителя, минимальное количество допущений.

Допустимо пожертвовать: художественность и длинные объяснения причин.

Запрос «в один проход» и запрос «итерациями»: когда что выбирать

Есть два режима постановки задач.

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

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

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

Уточнение аудитории: новичок, специалист, руководитель, смешанная

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

Как задавать аудиторию в задаче:

– пишем для человека без профессионального опыта, термины расшифровываем;

– пишем для специалиста, без учебных объяснений, больше деталей и условий;

– пишем для руководителя, коротко, с рисками и решениями;

– смешанная аудитория: сначала краткое резюме, затем подробности для исполнителя.

Уточнение уровня детализации: «с примерами и шагами» или «обзор»

Уровень детализации – это договор о плотности текста. Он определяет, что вы получите: обзорную картину или инструкцию.

Рабочая шкала:

– обзор: что это и как устроено;

– практический разбор: как сделать и какие ошибки;

– внедрение: пошаговый план, критерии готовности, контроль качества.

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

Уточнение локализации: Россия, русский язык, российские сервисы и реалии

Локализация – это часть контекста. Она влияет на инструменты, термины, привычки аудитории, юридические рамки, способы оплаты, платформы.

В задаче достаточно одной строки:

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

Уточнение времени: актуальность и что считать устаревшим

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

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

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

Минимальный блок:

Срок: …

Команда: …

Бюджет: …

Доступы/инструменты: …

Уточнение допустимого тона: формально, нейтрально, по делу

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

Пример формулировки:

Тон формальный и деловой, без разговорных подводок, без «воды», полными абзацами.

Уточнение ограничения по объему: коротко или полно

Иногда полезно задать объём как рамку. Слишком короткий ответ лишает деталей. Слишком длинный может мешать внедрению. Лучше задавать объём через назначение:

– «одна страница для руководителя»

– «инструкция для исполнителя»

– «документ, который можно положить в базу знаний»

Уточнение формата вывода: шаги, чек-листы, шаблоны, варианты

Формат – это способ сделать результат переносимым. Если вы хотите «пакет» для работы, просите структуру ответа.

Пример:

Выдай результат в формате:

краткое резюме;

пошаговый план;

чек-лист контроля;

список рисков и допущений;

шаблон формулировок.

Итоговая проверка задачи: «если это выполнить, намерение закрыто?»

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

Чек-лист проверки:

– Ясно, что нужно сделать, без разночтений.

– Ясно, в каком виде принести результат.

– Ясно, по каким критериям результат будет принят.

– Ясно, какие ограничения и запреты действуют.

– Ясно, кто будет использовать результат и что произойдёт дальше.

– Если это будет выполнено, намерение действительно закрывается.

Шаблон задачи, который можно копировать

Ниже – универсальная форма, которая делает задачу устойчивой. Её можно использовать как стандарт внутри команды.

Цель: [что должно быть достигнуто, в чём измеряется успех]

Контекст: [где используется, что уже есть, что уже пробовали, что важно учесть]

Ограничения: [сроки, бюджет, инструменты, запреты, юридические рамки, стиль]

Аудитория: [кто читает/использует результат]

Формат результата: [какой артефакт нужен, структура ответа]

Критерии приемки: [что должно быть в результате обязательно, что недопустимо]

Допущения: [что можно предполагать при отсутствии данных, что вынести вопросами]

Следующий шаг: [что я сделаю после получения результата]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Запреты: что недопустимо.

Пример: «Не использовать “водяные” формулировки, не оставлять критерии в виде оценочных слов, не предлагать инструменты, недоступные в РФ».

Требования к достоверности/допущения: где можно предполагать, где нельзя.

Пример: «Если данных не хватает – делай допущения и помечай их. Не выдумывай факты и цифры».

Формат вывода: как структурировать ответ.

Пример: «Сначала краткая форма на 6 блоков, затем расширенная на 12 блоков, затем 3 примера “плохо/хорошо”, затем чек-лист вычитки».

Приоритеты: что важнее, если придётся выбирать.

Пример: «Главное – применимость и ясность для команды. Второе – краткость. Третье – полнота».

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

Пример: «Положу форму в базу знаний, проведу 30-мин обучение и начну требовать её во всех задачах».

Почему каждый блок важен и что ломается без него

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

Если нет контекста, исполнитель вынужден угадывать. У разных людей разные «по умолчанию». Кто-то даст теорию, кто-то даст список советов, кто-то уйдёт в детали. Контекст выравнивает понимание.

Если нет цели, будет трудно оценить качество. Исполнитель может сделать много полезного, но не попадёт в вашу задачу. Цель задаёт «куда бить».

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

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

Если нет критериев приемки, любой результат будет спорным. Вы будете говорить «не то», исполнитель – «но я же сделал». Критерии приемки убирают субъективность.

Как писать каждый блок так, чтобы он был коротким и точным

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

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

Цель. Формулируйте так, чтобы можно было проверить. Если метрика есть – называйте метрику и период. Если метрики нет – называйте критерий применения: «готово к внедрению», «готово к отправке клиенту», «можно передать исполнителю без дополнительного объяснения».

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

Запреты. Запреты нужны, чтобы защититься от типовых провалов. Обычно достаточно 3–5 запретов: не выдумывать факты, не менять смысл, не использовать недоступные инструменты, не давать общие советы без шагов, не писать разговорные подводки.

Формат. Заказывайте структуру ответа. Например: «Сначала краткое резюме, затем пошаговый план, затем чек-лист контроля, затем риски/допущения, затем шаблон для копипаста». Это резко повышает применимость.

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

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

Плохо: «Сделай текст для страницы услуги, чтобы был эффективный».

Почему плохо: нет аудитории, нет цели, нет ограничений, нет формата, слово «эффективный» не определено.

Хорошо: «Перепиши первый экран страницы услуги X для аудитории Y. Цель – увеличить клики по кнопке “Записаться” и снизить отказы на первом экране. Ограничения: нельзя обещать гарантированный результат, нельзя использовать медицинские утверждения без оговорок, стиль деловой, без жаргона. Формат: 3 варианта заголовка, 3 варианта подзаголовка, 5 буллетов преимуществ, 2 варианта CTA. Критерии приемки: текст понятен без терминов, один главный призыв, нет “воды”».

Плохо: «Сравни сервисы аналитики и выбери лучший».

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

Хорошо: «Сравни 3 варианта аналитики для сайта: A/B/C. Критерии: доступность в РФ, стоимость до N, простота внедрения без разработчика, достаточность для отслеживания лидов и событий. Выход: рекомендация одного варианта, почему он лучший по критериям, риски, план внедрения на 1 неделю, список событий, которые нужно настроить».

Плохо: «Сделай стратегию SEO».

Почему плохо: это не задача, а желание получить ощущение контроля.

Хорошо: «Собери проектный план SEO на 4 недели для сайта X. Контекст: ниша Y, регион Z, текущие проблемы: A/B/C. Ограничения: контент переписывать нельзя, бюджет на ссылки N, команда 1 SEO + 1 разработчик 10 часов/нед. Выход: список задач по неделям, приоритеты, зависимости, критерии готовности, метрики контроля».

Как включать «страховку» от неполных данных: допущения и вопросы

Точный запрос не обязан содержать все данные. Но он обязан задавать правило, что делать, если данных нет. Есть два режима.

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

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

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

Как одним абзацем «закрыть» формат, критерии и приоритеты

Если вы не хотите писать длинно, используйте компактный блок, который сильно повышает точность:

«Сделай X для Y в контексте Z. Главное – A. Важно – B и C. Нельзя – D и E. Результат дай в формате: 1) … 2) … 3) … Критерии приемки: обязательно …, недопустимо …».

Эта формула занимает 5–8 строк, но закрывает почти всё, что нужно для качественного результата.

Универсальный шаблон для копипаста: короткий и расширенный

Короткий шаблон (подходит для большинства задач):

Задача:

Контекст:

Цель:

Ограничения/запреты:

Формат результата:

Критерии приемки:

Расширенный шаблон (для сложных задач):

Задача (заголовок):

Результат:

Контекст:

Проблема/симптомы:

Цель:

Аудитория:

Ограничения (срок/бюджет/ресурсы/инструменты):

Запреты (что недопустимо):

Достоверность/допущения/что уточнить:

Формат вывода (структура ответа):

Приоритеты:

Следующий шаг после результата:

Чек-лист вычитки запроса перед отправкой: 10 быстрых проверок

В заголовке есть глагол действия и объект.

Контекст содержит факты, а не эмоции.

Цель проверяемая: метрика или признак готовности.

Названа аудитория результата.

Ограничения указаны: срок/ресурсы/инструменты.

Запреты зафиксированы там, где есть риск ошибок.

Формат результата задан как артефакт или структура ответа.

Критерии приемки написаны в виде «обязательно/недопустимо».

Выбран режим неполных данных: вопросы или допущения.

Вы можете ответить: «что я сделаю после получения результата».

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

Глава 5. Декомпозиция: как дробить намерение на подзадачи без потери смысла

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

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

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

Один принцип, который решает половину проблем: «одна подзадача – один глагол»

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

Практическая форма подзадачи:

Действие (глагол) + объект + критерий готовности + входы/ограничения.

Пример:

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

Декомпозиция по этапам: исследование → решение → внедрение → контроль

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

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

Решение. Выбор подхода: варианты, критерии, риски, рекомендация. Выход – проект решения или план.

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

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

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

Декомпозиция по объектам: что именно мы меняем

Иногда этапы понятны, но всё равно хаос, потому что объект слишком широк. Тогда дробите по объектам.

Примеры объектов:

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

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

Декомпозиция по рискам: что может сорвать результат

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

Типовые риски:

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

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

Декомпозиция по данным: какие входы нужны, чтобы не гадать

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

Примеры подзадач по данным:

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

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

Декомпозиция по аудиториям: разные сегменты – разные ответы

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

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

Декомпозиция по каналам: где именно произойдёт эффект

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

Важно: декомпозиция по каналам не означает «делать всё сразу». Она означает видеть карту и выбрать приоритетный участок.

Обязательное и желательное: чтобы не перегрузить первый проход

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

Практический способ:

для каждой подзадачи помечайте статусом Must / Should.

Must – делаем обязательно.

Should – делаем, если остаётся ресурс.

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

Карта зависимостей: что без чего не делается

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

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

Точка входа: с чего начать, если всё сразу нельзя

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

даёт максимальную ясность для следующих шагов,

стоит дёшево по времени,

снижает риск,

создаёт первый полезный артефакт.

Часто точка входа – это уточнение намерения и критериев приемки, сбор входных данных или быстрая диагностика причин.

Типовая ошибка: дробить до микрошагов и потерять управляемость

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

Признаки слишком мелкой декомпозиции:

пункты похожи на клики мышкой, а не на управляемые действия,

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

любой пункт без контекста непонятен.

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

Типовая ошибка: не дробить и получить «водяной» ответ

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

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

Декомпозиция для ИИ: где генерация, где проверка, где расчёты

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

Типовые блоки:

генерация (создать варианты, структуру, текст),

аналитика (сравнить, выбрать, обосновать),

проверка (найти слабые места, противоречия),

расчёты (цифры, бюджеты, конверсии, сроки),

упаковка (шаблон, чек-лист, регламент).

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

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

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

Пример инкрементов:

Каркас решения (структура и порядок работ) – уже позволяет согласовать направление.

Минимальный внедряемый вариант – уже даёт действие завтра.

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.