Александр Костин – Промпт-менеджмент: как писать запросы к ИИ и получать предсказуемый ответ (страница 6)
Набор артефактов особенно важен в командной работе. Один текст не обеспечивает внедрение. Пакет обеспечивает переносимость: вы можете передать результат исполнителю, можете проверить, можете повторить, можете встроить в регламент.
Как выбрать тип запроса быстро: короткая диагностическая таблица в голове
Есть три вопроса, которые позволяют почти мгновенно выбрать тип.
Первый: мне нужно понять или сделать. Если понять – информационный или обучающий. Если сделать – инструктивный, проектный, коммуникационный, генеративный.
Второй: причина известна или неизвестна. Если неизвестна – диагностический. Если известна – инструкция или проектирование.
Третий: мне нужен выбор из вариантов или один конкретный путь. Если выбор – аналитика. Если путь – решение или план.
Эта тройка вопросов снимает большую часть неопределённости и резко повышает точность постановки.
Связка «поиск + запрос»: почему тип важен даже при сборе информации
Даже когда вы ищете информацию, тип запроса определяет, что вы ищете. Если вы ищете «объяснение», вы будете потреблять обзоры. Если вы ищете «инструкцию», вы будете искать руководства и регламенты. Если вы ищете «проверку», вы будете искать критические разборы, списки ошибок, разборы кейсов и методологии оценки.
Если тип не определён, вы утонете в источниках. Поэтому сначала режим, потом поиск. И уже после – сбор материалов.
Переход от типов запросов к управлению процессом: тип как инструмент руководителя
На уровне руководителя тип запроса становится управленческим рычагом. Он задаёт, что именно вы хотите получить от команды: объяснение, план, риск-реестр, матрицу решений, протокол внедрения, регламент. Когда вы формулируете запросы типами, вы перестаёте получать «мнения» и начинаете получать управляемые артефакты.
Это меняет качество исполнения. Команда понимает, что от неё требуется. Снижается количество согласований. Уменьшаются конфликты ожиданий. Повышается скорость принятия решений. А главное – становится проще контролировать качество, потому что у каждого типа есть свои критерии приемки.
Итоговое правило главы простое: прежде чем формулировать запрос, выберите тип результата. Не тему. Не «о чём поговорить». А режим работы ответа. Если режим совпал с ожиданием, даже средний по качеству ответ даст пользу. Если режим выбран неверно, даже идеально написанный текст будет «не то», потому что он решал другую задачу.
Глава 4. Структура точного запроса: универсальная «форма» для любой задачи
Точный запрос – это не «красиво сформулированная просьба», а рабочий документ, который задаёт: что должно быть сделано, в каких условиях, в каких границах, каким должен быть результат, и по каким признакам вы принимаете работу. Если эта структура отсутствует, вы получаете ответ, который может быть умным, но не пригодным. Если структура есть, вы получаете управляемый результат даже при неполных данных, потому что исполнитель понимает рамки и формат.
Универсальная форма запроса нужна не для бюрократии. Она нужна, чтобы экономить время на итерациях, снижать риск промаха и быстрее получать применимые артефакты. Важно понимать: форма – это не «побольше текста». Форма – это правильные элементы, которые удерживают смысл. Иногда достаточно 6–10 строк, если они содержательные. Иногда нужен развёрнутый бриф, если задача сложная и цена ошибки высокая.
Ниже – универсальная структура, которую можно использовать для людей, команды, подрядчиков и ИИ. Она одинакова в логике, меняется только глубина каждого блока.
Минимальная форма точного запроса: 6 блоков, которые закрывают 80% задач
Первый блок – заголовок задачи в одной строке. Он должен быть конкретным, с глаголом и объектом. Не «Помоги с маркетингом», а «Составь план A/B теста первого экрана лендинга услуги X». Заголовок нужен, чтобы фиксировать смысл и не давать задаче расползаться в процессе.
Второй блок – контекст. Где это происходит, что уже сделано, что не сработало, какие ограничения среды. Контекст – это не «история проекта», а факты, без которых невозможно выбрать правильный подход. Если контекста нет, исполнитель вынужден выдумывать «средний» сценарий.
Третий блок – цель. Чего вы хотите добиться на выходе. Цель должна быть проверяемой: либо метрикой, либо чётким признаком готовности. «Сделай хорошо» – не цель. «Сделай так, чтобы я мог отдать это исполнителю без дополнительных пояснений» – цель. «Сделай так, чтобы снизить количество отказов на шаге оплаты» – цель.
Четвёртый блок – ограничения и запреты. Срок, бюджет, инструменты, юридические рамки, стиль, недопустимые решения. Ограничения превращают задачу из «идеальной в вакууме» в «реальную и внедряемую». Запреты особенно важны, если есть риск фантазий, риск юридической ошибки или риск непригодных инструментов.
Пятый блок – формат результата. Что именно вы хотите получить: план, чек-лист, регламент, шаблон, текст, сценарий, набор вариантов. Формат – это упаковка результата для использования. Если формат не задан, вы почти гарантированно получите «объяснение» вместо «инструмента».
Шестой блок – критерии приемки. Это признаки, по которым вы скажете «да, это то». Критерии приемки могут быть простыми: «в ответе должны быть шаги, сроки, риски, первый шаг на завтра». Но они должны быть. Без критериев приемки любые обсуждения качества превращаются в субъективный спор.
Расширенная форма: 12 блоков, когда нужна высокая точность и применимость
Если задача важная, сложная или с высокой ценой ошибки, используйте расширенную форму. Она не обязательно длиннее, она просто содержит больше «замков», которые удерживают смысл.
Заголовок задачи (одна строка). Глагол + объект + ожидаемый эффект или назначение.
Пример: «Собери структуру точного запроса для внедрения регламента обработки лидов в агентстве».
Результат в одном предложении: что должно оказаться у вас в руках.
Пример: «На выходе нужен документ, который можно передать команде как единый стандарт».
Контекст: факты о ситуации.
Пример: «Команда 10 человек, задачи идут через чат, часто теряется ответственность, сроки срываются из-за расплывчатых постановок».
Проблема/симптомы: что сейчас не работает и как это проявляется.
Пример: «Появляются правки “не то”, по 3–4 итерации, нет ясных критериев “готово”».
Цель: что должно измениться.
Пример: «Сократить число итераций до 1–2 и повысить процент задач, которые принимаются с первого раза».
Аудитория результата: кто будет читать/использовать.
Пример: «Руководитель (контроль), тимлид (постановка), исполнители (выполнение)».
Ограничения: сроки, бюджет, ресурсы, инструменты, доступы.
Пример: «Внедрение без новых платных инструментов, всё на существующих процессах, срок – 2 недели».
Запреты: что недопустимо.
Пример: «Не использовать “водяные” формулировки, не оставлять критерии в виде оценочных слов, не предлагать инструменты, недоступные в РФ».
Требования к достоверности/допущения: где можно предполагать, где нельзя.
Пример: «Если данных не хватает – делай допущения и помечай их. Не выдумывай факты и цифры».
Формат вывода: как структурировать ответ.
Пример: «Сначала краткая форма на 6 блоков, затем расширенная на 12 блоков, затем 3 примера “плохо/хорошо”, затем чек-лист вычитки».
Приоритеты: что важнее, если придётся выбирать.
Пример: «Главное – применимость и ясность для команды. Второе – краткость. Третье – полнота».
Следующий шаг: что вы сделаете после получения результата.
Пример: «Положу форму в базу знаний, проведу 30-мин обучение и начну требовать её во всех задачах».
Почему каждый блок важен и что ломается без него
Если нет заголовка, задача расползается. Люди начинают обсуждать смежные темы, добавлять пожелания, менять фокус. Заголовок фиксирует «о чём именно работа».
Если нет контекста, исполнитель вынужден угадывать. У разных людей разные «по умолчанию». Кто-то даст теорию, кто-то даст список советов, кто-то уйдёт в детали. Контекст выравнивает понимание.
Если нет цели, будет трудно оценить качество. Исполнитель может сделать много полезного, но не попадёт в вашу задачу. Цель задаёт «куда бить».
Если нет ограничений, ответ окажется непригодным. Самая частая боль: решение хорошее, но его нельзя внедрить из-за бюджета, сроков, инструментов или юридических рамок.
Если нет формата результата, вы получаете «рассуждение» вместо артефакта. Особенно в работе с ИИ: по умолчанию он охотно объясняет, но не всегда «упаковывает» в инструмент.
Если нет критериев приемки, любой результат будет спорным. Вы будете говорить «не то», исполнитель – «но я же сделал». Критерии приемки убирают субъективность.
Как писать каждый блок так, чтобы он был коротким и точным
Заголовок. Используйте глаголы действия: «составь», «собери», «перепиши», «проанализируй», «сравни», «проверь», «спроектируй», «подготовь», «настрой». Избегайте «помоги», «разберись», «сделай нормально». Они не задают действие.
Контекст. Пишите фактами: что за продукт, кто аудитория, где используется, какой этап, что уже пробовали, что не получилось. Контекст должен отвечать на вопрос «в каких условиях это будет применено». 5–10 строк обычно достаточно.
Цель. Формулируйте так, чтобы можно было проверить. Если метрика есть – называйте метрику и период. Если метрики нет – называйте критерий применения: «готово к внедрению», «готово к отправке клиенту», «можно передать исполнителю без дополнительного объяснения».