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

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

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

Например:

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

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

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

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

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

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

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

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

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

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

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

Первый пакет занимает около 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 года.

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

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

[ГИПОТЕЗА]

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

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

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

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

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

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

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

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