Марк Тьюрин
Промпты, которые работают: Как говорить с искусственным интеллектом на одном языке

Почему один запрос даёт три разных ответа

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

В 19:12 Марина Волкова открыла рабочий чат и набрала:

«Помоги подготовить запуск курса для руководителей проектов».

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

Марина пролистала ответ до конца.

«Слишком общее», — написала она.

Через минуту она скопировала тот же запрос в новый диалог. На этот раз ответ пошёл в другую сторону:

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

Тоже разумно. Но опять не то.

Марина повторила запрос в третий раз. Теперь ответ начинался так:

«Вот пример анонса курса для руководителей проектов:

“Как выстроить работу команды, не утонув в срочных задачах? На курсе вы научитесь планировать проекты, распределять ответственность и контролировать результат...”»

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

«Я задала один вопрос, — сказала она на следующий день Илье и Светлане. — Почему модель каждый раз решает, что мне нужно что-то другое?»

Илья, аналитик проекта, посмотрел на исходную формулировку.

«Ты задала одну тему».

«Я написала “подготовить запуск”. Это разве не действие?»

«Скорее намерение, но не задание».

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

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

Три ответа на один запрос

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

Поэтому каждый ответ по-своему достраивал недостающие элементы.

У первого варианта было одно исходное предположение: Марине нужно разработать последовательность продвижения. В качестве объекта работы модель выбрала предложение курса, аудиторию и каналы запуска. Скрытой аудиторией стали команда проекта и потенциальные участники, а ограничениями — общие рекомендации без сроков и бюджета. Результат выглядел как план из этапов и каналов; его успех можно было бы оценить по тому, насколько ясно описано привлечение участников.

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

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

У каждого варианта была своя логика. Первый полезен, если Марина не знает, как привлекать слушателей. Второй подходит, если программа ещё не собрана. Третий нужен, если курс готов, а странице не хватает текста.

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

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

Марина хотела получить план запуска. Для этого слово «запуск» нужно было превратить из темы в объект работы, а намерение — в проверяемый результат.

Тема, задача и критерий

Представьте, что руководитель говорит троим сотрудникам: «Подготовьте комнату к встрече».

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

Фраза «подготовьте комнату» обозначила направление, а не рабочее задание.

Тема отвечает на вопрос «о чём речь?». В случае Марины это запуск курса для руководителей проектов.

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

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

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

Светлана, редактор проекта, решила проверить это на простом примере. Она отправила модели запрос:

«Сделай текст живее».

Получила бы она один определённый результат? Нет. «Живее» может означать разные операции.

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

Светлана переформулировала запросы в зависимости от задачи.

«Перепиши описание курса для страницы регистрации. Сохрани факты, не добавляй новых обещаний, сократи текст до 900 знаков, обращайся к руководителю проекта на “вы”, замени абстрактные формулировки двумя конкретными примерами рабочих ситуаций».

Или:

«Отредактируй письмо участникам курса о переносе старта на 18 сентября. Сохрани дату и причину переноса, убери канцелярские обороты, сделай письмо спокойным и ясным, объём — до 700 знаков. В конце добавь один понятный шаг для получателя».

Или:

«Перепиши первый абзац статьи для публикации в сообществе проекта во “ВКонтакте”. Нужен один бытовой эпизод, затем вывод о планировании задач. Не используй слова “уникальный”, “эффективный” и “в современном мире”. Объём — 600–800 знаков».

Во всех трёх случаях работа связана с текстом, но действие, объект, условия и критерий различаются. Поэтому различается и результат.

Что модель угадывает вместо пользователя

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Такие слова можно оставлять, если рядом есть проверяемое уточнение.

«Короткое письмо» превращается в «до 700 знаков, три абзаца и один призыв к действию».

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

«Для новичков» — в «без предположения опыта работы с аналитическими отчётами; каждый термин объяснить при первом употреблении».

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

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

Домашний краш-тест

Через несколько дней Марина столкнулась с той же проблемой вне запуска курса. Она написала модели:

«Составь полезное меню на неделю, чтобы было быстро и недорого».

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

Марина уточнила:

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

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

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

Возвращаемся к запросу Марины

Светлана не стала переписывать запрос за Марину. Она начала с нескольких неудобных вопросов.

«Что именно должна сделать модель?»

«Составить план запуска».

«План для кого?»

«Для нашей команды: для меня, Ильи и тебя. Не для слушателей».

«С чем она должна работать?»

«Курс уже записан. Есть шесть модулей, страница регистрации и список из 1800 контактов, которые раньше интересовались обучением для руководителей. До старта четырнадцать дней. На продвижение есть 120 тысяч рублей. Использовать будем свои площадки, рассылку и сообщество проекта во “ВКонтакте”».

Илья добавил четвёртый вопрос:

«Как мы проверим, что план получился рабочим?»

Марина ответила не сразу.

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

Только после этого появился новый запрос:

«Составь четырнадцатидневный план запуска онлайн-курса для руководителей проектов. Курс уже записан: шесть модулей, готова страница регистрации, есть список из 1800 контактов, ранее интересовавшихся обучением для руководителей. До старта осталось 14 дней, бюджет на продвижение — 120 000 рублей. План предназначен для команды из руководителя проекта, аналитика и редактора. Используй собственные каналы проекта, рассылку и сообщество во “ВКонтакте”.

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

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

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

Эту минимальную конструкцию можно запомнить так:

«Сделай [действие] с [объектом] при [условиях] и выдай [проверяемый результат]».

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

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

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

Условия очерчивают рамку: кто читает, какие данные доступны, каковы срок, объём и бюджет, каким должен быть тон, что запрещено и по какому правилу выбирать вариант. Не нужно вписывать всю историю проекта. Достаточно назвать то, что меняет решение.

Проверяемый результат должен позволять открыть ответ и вынести суждение. В нём есть формат, количество, обязательные элементы или правило выбора. «Сделай полезно» не проверяется. «Дай пять вариантов заголовка длиной до 60 знаков и выбери один, объяснив выбор по критериям ясности и соответствия аудитории» — проверяется.

Типичные сбои

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

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

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

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

Пятый сбой — результат путают с целью. Цель проекта — набрать участников на курс. Результат работы модели — план, текст, сегментация аудитории или список экспериментов. Если попросить модель «набрать участников», она не сможет самостоятельно заменить все действия команды. Если попросить «составить план привлечения 50 заявок за 14 дней», работа становится конкретнее.

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

Короткая практика перед отправкой

Возьмите запрос: «Сделай полезный пост о нашем курсе».

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

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

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

«Напиши пост для сообщества проекта во “ВКонтакте” о наборе на онлайн-курс для руководителей проектов. Аудитория — руководители с опытом от одного года, которым сложно удерживать сроки и распределять задачи в команде. Используй только факты из описания курса, не обещай карьерного роста и конкретного увеличения дохода. Объём — 900–1100 знаков. Структура: рабочая ситуация в начале, три навыка, которые отрабатываются на курсе, дата старта и призыв перейти на страницу регистрации. Предложи два варианта заголовка».

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

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

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

Из желания — в рабочее задание

«К осени у нас должен быть хороший курс, который люди будут рекомендовать друг другу».

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

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

— И что вы хотите получить от меня? — спросила Светлана Орлова, редактор проекта.

— Помочь запустить курс.

— «Запустить» — это какое изменение должно произойти в ближайшие две недели?

Марина посмотрела на экран.

— Чтобы люди записались.

— А если после моего ответа у вас будет красивое описание курса, но так и не станет понятно, нужен ли он этой аудитории?

— Тогда такой ответ не поможет.

— Значит, сейчас вам нужен не «хороший курс» и не «красивый запуск». Вам нужно решить, есть ли основания проверять эту программу на реальных участниках и как провести такую проверку.

Марина кивнула, но через секунду добавила:

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

— Это уже четыре разные задачи, — сказала Светлана. — Они связаны, но не совпадают.

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

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

Длинный запрос автоматически становится понятным

Марина могла бы написать так:

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

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

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

Модель сама поймёт, что значит «хорошо»

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

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

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

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

Одной универсальной роли достаточно

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

Роль задаёт не статус, а угол зрения и способ работы.

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

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

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

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

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

Нужно сразу сообщить модели всё

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

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

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

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

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

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

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

Ограничения мешают хорошему результату

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

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

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

Хороший результат понятен сам по себе

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

Критерий качества превращает впечатление в проверку. Вместо «сделай полезно» можно сказать:

«В каждом выводе укажи, на каком факте он основан».

«Раздели подтверждённые наблюдения, интерпретации, гипотезы и пробелы в данных».

«Для каждого шага укажи срок, ожидаемый сигнал и риск».

«Не используй внешние цифры, которых нет во входных материалах».

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

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

Лестница конкретизации

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

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

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

Желание

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

Оно нужно как исходная точка, но ещё не является заданием.

Истинная цель

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

«Хочу хороший курс» может превратиться в несколько разных целей:

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

«Мне нужно собрать программу из шести модулей».

«Мне нужно набрать пятнадцать участников в первый поток».

«Мне нужно подготовить три варианта сообщения для приглашения».

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

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

Роль модели

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

Формула роли может быть короткой:

«Ты — аналитик, работающий с исследовательскими материалами».

«Ты — редактор делового текста для руководителей».

«Ты — консультант, который сравнивает варианты по срокам, ресурсам и рискам».

«Ты — критик проекта; твоя задача — найти неподтверждённые предположения и условия провала».

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

Входные данные

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

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

Ограничения

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

Запрос можно уточнить так:

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

«Нужен план на четырнадцать дней, а не стратегия на год».

«Объём — не более 1200 слов».

«Пиши ясным деловым языком, без рекламных обещаний».

«Не придумывай данные о рынке и не объявляй гипотезу фактом».

Критерии качества

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

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

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

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

Формат ответа

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

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

Короткая рабочая схема

Лестницу можно заполнить в черновике перед отправкой запроса. Не нужно писать ответы литературно.

Желание: чего я хочу в широком смысле.

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

Роль: какую операцию выполняет модель.

Входные данные: на каких фактах, текстах или наблюдениях она работает.

Ограничения: для кого, в каком объёме, каким тоном, к какому сроку и в каких пределах.

Критерии качества: что я проверю глазами.

Формат: в каком виде результат будет удобен для следующего действия.

Эта схема работает не только при запуске продукта.

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

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

В чате жильцов человек пишет: «Сделай объявление, чтобы все наконец начали сдавать деньги на ремонт». Истинная цель — получить нужное число ответов до пятницы, а не просто выразить раздражение. Роль модели — редактор сообщения. Входные данные — сумма, срок, способ передачи денег и контакт ответственного. Ограничения — до 500 знаков, без давления и публичного стыда. Критерий — адресат понимает, что сделать, сколько передать, кому и до какого числа.

В каждом случае текст запроса становится не просто длиннее. Он меняет предмет: от общего желания к конкретному изменению.

Как Марина собирала задание

Светлана вернулась к проекту курса и попросила Марину не начинать с формулировки программы.

— Какое ошибочное решение сейчас обойдётся нам дороже всего? — спросила она.

— Потратить месяц на запись курса, который никому не нужен.

— Значит, первая цель?

— Проверить востребованность.

— Среди кого?

— Среди людей, которые хотят расти в управлении.

Илья Соколов, аналитик проекта, поднял голову от ноутбука.

— Это пока описание намерения. Кто именно эти люди?

Марина помолчала.

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

— Теперь появилась проверяемая гипотеза об аудитории, — сказал Илья. — Но не выдавайте её за факт. Мы предполагаем, что именно эти трудности достаточно значимы для них.

На доске возникли четыре возможных направления работы:

Проверить спрос и понять, какая проблема наиболее острая.

Собрать программу курса из модулей и практических заданий.

Набрать первый пилотный поток.

Подготовить описание, приглашение и серию сообщений.

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

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

Следом Светлана задала вопрос о роли модели.

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

— Наверное, предложить план запуска, — ответила Марина.

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

Они сравнили четыре варианта одного и того же исходного желания.

В роли консультанта модель получила бы такое задание:

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

Такой ответ помог бы выбрать способ проверки.

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

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

Такой ответ улучшил бы текст, но не доказал востребованность курса.

В роли аналитика задача звучала бы так:

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

Здесь модель должна была бы искать закономерности.

В роли критика запрос менялся ещё сильнее:

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

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

— Значит, один запрос не обязан заменять всю команду, — сказала Марина.

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

Теперь дошла очередь до входных данных. Марина сначала предложила написать: «У нас есть интерес аудитории». Илья остановил её.

— Откуда вы это знаете?

— Двенадцать интервью. Люди рассказывали, что им трудно управлять командой.

— Кто именно участвовал?

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

— Что показал опрос?

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

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

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

Входные данные для текущего запроса они собрали так.

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

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

Материалы — краткие заметки по двенадцати интервью, ответы двадцати семи участников опроса и три запроса о цене или дате старта. Все участники пришли из собственной базы Марины, поэтому выборка может быть смещённой.

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

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

Ограничения зафиксировали отдельно.

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

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

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

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

Объём — до 1200 слов, чтобы команда могла разобрать выводы на одной встрече.

Оставалось определить критерии качества. Илья предложил составить их до того, как модель даст ответ.

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

Каждый вывод связан с конкретным наблюдением из интервью или опроса.

Факты, интерпретации, гипотезы и неизвестные разделены.

Предложенные шаги идут в последовательности и укладываются в четырнадцать дней.

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

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

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

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

Собранный промпт

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

Роль:

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

Цель:

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

Контекст и входные данные:

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

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

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

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

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

Задача:

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

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

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

Ограничения:

Ответ предназначен для рабочей встречи команды. Пиши ясным деловым русским языком, без внешних статистических данных и общих маркетинговых обещаний. Объём — до 1200 слов. Не скрывай противоречия и не сглаживай отсутствие данных.

Критерии качества:

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

Каждый существенный вывод связан с указанным наблюдением.

Факты отделены от гипотез и интерпретаций.

План содержит последовательные шаги, сроки, показатели и риски.

В конце есть список из пяти вопросов, ответы на которые могут изменить решение о пилотном запуске.

Формат:

1. Краткий вывод для команды — не более семи предложений.

2. Возможные сегменты: проблема, подтверждающие наблюдения, степень уверенности.

3. Факты, интерпретации, гипотезы и пробелы в данных.

4. План проверки на четырнадцать дней.

5. Показатели и рабочие пороги.

6. Риски и способы их проверить.

7. Пять вопросов перед решением о запуске.

После этого Светлана попросила Марину прочитать запрос так, будто она впервые видит проект.

— Понятно ли, что модель должна сделать?

— Да. Она не должна писать программу или рекламу. Ей нужно разобрать наши материалы и предложить план проверки.

— Понятно ли, на каких данных она работает?

— Да. Названы источники, объём, содержание и ограничение выборки.

— Можно ли проверить результат глазами?

— Да. Я увижу сегменты, факты, гипотезы, сроки, показатели и риски.

— Понятно ли, чего модель не должна делать?

— Не разрабатывать весь запуск и не придумывать рыночные цифры.

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

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

Что делать, если задача пока неясна

Иногда человек не способен сразу выбрать истинную цель. Это не повод писать длинный промпт наугад. Можно поручить модели первый этап — помочь разложить желание на возможные задачи.

Например:

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

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

Есть и другой способ — разделить работу на два шага. Первый запрос выявляет неизвестные:

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

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

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

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

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

Контекст без свалки

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

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

Первый пакет занимает около 60 страниц. В нём есть выгрузка всех обращений за девять месяцев, отчёты отдела за разные периоды, несколько версий регламента, переписка руководителей, таблица с фамилиями операторов, примеры удачных ответов, жалобы клиентов, старый план мотивации и комментарии к документам. Материалы собраны в один длинный текст без дат, названий источников и разделения на обязательные правила и личные мнения.

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

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

Два пакета, одна задача

Разницу можно увидеть не в количестве знаков, а в том, как устроены материалы.

Цель. В бесформенном пакете она смешана с фоном и перепиской. В рабочем пакете сформулирована отдельным блоком.

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

Документы. В бесформенный пакет включены целиком и без приоритета. В рабочий — только релевантные выдержки с пояснением, зачем они нужны.

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

Гипотезы. В бесформенном пакете они нередко выданы за установленные причины. В рабочем обозначены как версии, которые ещё предстоит проверить.

Требования. В первом их приходится выискивать в конце файла. Во втором они перечислены отдельно и заданы как обязательные условия.

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

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

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

Полезный контекст отвечает хотя бы на один из пяти вопросов:

1. Какое решение нужно принять или какой результат получить?

2. Какие обстоятельства уже подтверждены?

3. На какие документы или данные можно опираться?

4. Как должен выглядеть приемлемый результат?

5. Какие ограничения нельзя нарушать?

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

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

Как распознать полезную информацию

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

Для быстрой проверки используйте четыре фильтра.

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

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

Третий фильтр — актуальность. Документ от 2021 года может быть полезен для изучения истории процесса, но не должен автоматически считаться действующим правилом. Укажите дату, редакцию и статус: действует, заменён, используется как справочный или требует проверки.

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

Сравним две формулировки.

Плохо: «В этом году поддержка стала работать на 30 процентов хуже».

Лучше: «Медианное время первого ответа выросло с 12 до 18 минут в период с января по март 2025 года. Расчёт выполнен по обращениям в рабочие дни, без ночных смен. Источник — отчёт руководителя поддержки от 5 апреля 2025 года».

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

Блок задачи

Задача должна стоять перед материалами, а не прятаться после них. Модель должна сначала увидеть, для какого решения собран пакет.

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

«Подготовь план сокращения медианного времени первого ответа службы поддержки с 18 до 10 минут для руководителя операционного отдела. Используй данные за январь—март 2025 года. Отдельно укажи подтверждённые причины, гипотезы и действия, которые можно проверить в течение четырёх недель».

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

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

Блок фактов

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

Пример:

[ФАКТ 1]

Медианное время первого ответа — 18 минут.

[ИСТОЧНИК]

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

[ОГРАНИЧЕНИЕ ФАКТА]

В расчёт включены обращения из формы на сайте и мобильного приложения; обращения с телефонной линии не включены.

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

Не смешивайте в одном абзаце факт и его объяснение.

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

Здесь слова «перегружены» и «поэтому» уже содержат интерпретацию.

Лучше:

[ФАКТ] 42 процента обращений поступают с 18:00 до 22:00.

[ФАКТ] В этот период медианное время первого ответа составляет 27 минут.

[ГИПОТЕЗА] Пиковая нагрузка может быть одной из причин задержки.

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

Блок исходных материалов

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

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

Пример:

[ИСТОЧНИК 1]

Действующий регламент обработки обращений, редакция от 12 февраля 2025 года.

[НУЖНЫЕ РАЗДЕЛЫ]

Порядок распределения обращений, норматив первого ответа, правила эскалации.

[ИСПОЛЬЗОВАНИЕ]

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

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

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

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

Блок примеров

Пример показывает, как что-то выглядит, но не доказывает, что так происходит всегда. Это одна из самых частых границ, которые теряются в длинном запросе.

Если вы передаёте модели три удачных ответа оператора, напишите, зачем они нужны:

[ПРИМЕР СТИЛЯ]

Используй как образец ясного и спокойного тона. Не копируй фактические обстоятельства и не считай этот ответ стандартом для всех обращений.

Если передаёте несколько клиентских сообщений, уточните их статус:

[ЦИТАТА]

Точный фрагмент сообщения клиента без исправления формулировок.

[НАЗНАЧЕНИЕ]

Используй для классификации типов жалоб и подбора нейтральных формулировок. Одна цитата не подтверждает распространённость проблемы.

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

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

Блок гипотез

Гипотеза — это правдоподобное объяснение или версия, которую ещё нужно проверить. В пакетах исходных данных гипотезы полезны: они показывают, какие направления уже рассматриваются. Проблема возникает, когда гипотеза маскируется под факт.

Пишите так:

[ГИПОТЕЗА 1]

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

[ЧЕМ ПРОВЕРИТЬ]

Сравнить медианное время ответа для обращений, требующих одного действия, и обращений, требующих передачи в другой отдел.

[СТАТУС]

Не подтверждена.

В таком виде гипотеза становится объектом анализа. Модель может предложить способ проверки и не будет строить весь план на предположении.

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

Блок требований и ограничений

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

Пример:

[ТРЕБОВАНИЯ К РЕЗУЛЬТАТУ]

Подготовь план на четыре недели.

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

Раздели действия на те, которые не требуют бюджета, и те, которые требуют согласования.

Не называй причиной то, что обозначено только как гипотеза.

Объём — до двух страниц.

Ограничения могут касаться и содержания:

[ОГРАНИЧЕНИЯ]

Не использовать персональные данные сотрудников.

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

Не ссылаться на старую редакцию регламента как на действующую.

Не включать в итоговый документ внутренние цены подрядчиков.

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

Сигналы информационной свалки

Сигнал 1. Все материалы склеены в один сплошной текст

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

Что делать: разделить материалы по источникам и назначить каждому метку. Даже простые заголовки «Факт», «Цитата», «Регламент», «Пример», «Гипотеза» значительно снижают неоднозначность.

Сигнал 2. В пакете есть все документы за несколько лет

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

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

Сигнал 3. Числа не имеют единиц измерения

«Рост на 30 процентов», «120 обращений», «срок — два дня» — неполные сведения. Неясно, что именно измерялось, за какой период и с чем сравнивалось.

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

Сигнал 4. Вывод уже встроен в описание факта

Фраза «клиенты уходят из-за высокой цены» может быть выводом из двух жалоб, а не доказанным результатом исследования.

Что делать: разделять наблюдение и объяснение. В блоке фактов оставить данные, а в блоке гипотез — возможную причину. Если есть исследование, указать его метод и размер выборки.

Сигнал 5. Пример выглядит как обязательное правило

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

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

Сигнал 6. Противоречивые цифры повторяются в разных файлах

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

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

Сигнал 7. Требование появляется после всех материалов

К этому моменту модель уже может сформировать направление ответа, не учитывая ограничение.

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

Сигнал 8. В пакет попали сведения, которые не нужны для решения

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

Что делать: удалить идентификаторы до передачи материала. Сохранить только признаки, которые могут изменить вывод.

Единая маркировка материалов

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

[ФАКТ] Подтверждённое утверждение с источником, датой или способом проверки.

[ЦИТАТА] Дословный фрагмент документа, письма, обращения или интервью.

[ПРИМЕР] Иллюстрация желаемого результата, формулировки, стиля или ситуации.

[ГИПОТЕЗА] Версия, объяснение или предположение, которое требуется проверить.

[ТРЕБОВАНИЕ] Обязательное условие к процессу или итоговому результату.

[КОНФИДЕНЦИАЛЬНО] Фрагмент, который нельзя передавать без необходимости; предпочтительно удалить или заменить обобщённым описанием.

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

Небольшой пример разметки:

[ФАКТ]

В марте 2025 года 38 процентов обращений были переданы из поддержки в отдел доставки.

[ИСТОЧНИК]

Выгрузка журнала передачи обращений, период с 1 по 31 марта 2025 года.

[ОГРАНИЧЕНИЕ]

В журнале не фиксируется причина передачи.

[ГИПОТЕЗА]

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

[ЧЕМ ПРОВЕРИТЬ]

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

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

Когда данных недостаточно

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

Чтобы этого не произошло, добавьте к запросу предварительный аудит:

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