Фреймворки написания промптов: как превратить запрос к ИИ в инженерное требование

Введение

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

Для ИТ-специалиста промпт - это не магия и креативный навык. Это короткая форма постановки задачи. Хороший промпт похож на компактное ТЗ: в нем есть цель, контекст, роль исполнителя, формат результата, ограничения и критерии проверки.

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

Почему обычные промпты ломаются

Большинство неудачных ответов ИИ появляются не потому, что модель «плохая». Часто проблема в том, что пользователь дал задачу на уровне намерения, а не на уровне требований. Например: «Напиши описание интеграции» - это не промпт, а направление мысли.

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

Официальные рекомендации OpenAI прямо советуют структурировать промпты с помощью Markdown-заголовков, списков и XML-тегов, чтобы разделять инструкции, примеры и контекст, а также использовать примеры ожидаемых входов и выходов при необходимости (OpenAI API Docs). Anthropic также рассматривает промптинг как итеративный процесс, где сначала задаются критерии успеха, а затем поведение промпта проверяется и улучшается через оценки и примеры (Claude API Docs).

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

Что такое фреймворк промпта

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

Важно понимать: фреймворк не является стандартом в смысле ГОСТа, BPMN или OpenAPI. Это рабочая мнемоника. Она нужна не для красоты аббревиатуры, а для дисциплины мышления.

В ИТ это привычный подход. Мы используем user story, чтобы не забыть роль, цель и ценность. Используем acceptance criteria, чтобы не спорить о готовности. Используем ADR, чтобы зафиксировать контекст, решение и последствия. Фреймворк промпта делает то же самое, только для взаимодействия с LLM.

Базовый минимум: Role, Task, Format

Самый простой и полезный фреймворк - RTF: Role, Task, Format. В популярном описании RTF состоит из трех элементов: роль, задача и формат ответа (The Prompt Warrior).

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

Шаблон RTF

Ты выступаешь в роли [роль].
Выполни задачу: [задача].
Верни результат в формате: [формат].

Пример для системного аналитика

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

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

CRAFT: когда нужен рабочий бриф

CRAFT обычно раскрывают как Context, Role, Action, Format, Target Audience. В таком виде фреймворк описывается как способ сделать промпт более ясным, релевантным и адаптированным под аудиторию (Geeky Gadgets).

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

Компоненты CRAFT

Пример для архитектора

Context:
Мы проектируем интеграцию между CRM и биллинговой системой. Обмен должен идти через REST API, часть операций асинхронная, есть требования к идемпотентности и трассировке.

Role:
Ты выступаешь в роли solution architect с опытом enterprise-интеграций.

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

Format:
Верни результат в виде таблицы сравнения и короткой рекомендации.

Target Audience:
Аудитория - руководитель разработки, системный аналитик и владелец продукта. Нужен практичный язык без избыточной академичности.

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

CO-STAR: когда важны стиль, тон и аудитория

CO-STAR раскладывает промпт на Context, Objective, Style, Tone, Audience, Response. В библиотечном руководстве West Point этот метод описывается как способ задать фон задачи, цель, стиль, тон, аудиторию и формат ответа (USMA Library).

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

Пример CO-STAR для бизнес-аналитика

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

Objective:
Подготовить текст объяснения, зачем нужна новая витрина и как она снизит ручной труд.

Style:
Деловой, понятный, без технического перегруза.

Tone:
Спокойный и уверенный. Не продавать, а объяснять.

Audience:
Руководители направлений продаж и операционные менеджеры.

Response:
Сформируй текст на 2500-3000 знаков с заголовком, коротким вводом, 3 смысловыми блоками и финальным выводом.

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

CLEAR: когда нужно улучшать не только промпт, но и мышление

CLEAR расшифровывается как Concise, Logical, Explicit, Adaptive, Reflective. Этот фреймворк связывают с доктором Leo Lo и его подходом к развитию информационной грамотности через промпт-инжиниринг (TAMU-CC Research Guides).

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

Как применять CLEAR

Для аналитика CLEAR особенно важен в связке с ревью результата. ИИ может выдать текст который приятно читать, но приятность чтения не равна корректности. Нужно спрашивать: «какие предположения ты сделал?», «каких данных не хватает?», «какие риски ты видишь?», «что нужно проверить у заказчика?».

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

RISEN обычно описывают как Role, Instructions, Steps, End goal, Narrowing. В обзорах промпт-фреймворков RISEN предлагают использовать для более сложных задач, где нужно задать роль, инструкции, шаги выполнения, конечную цель и ограничения (The Prompt Warrior).

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

Пример RISEN для анализа требований

Role:
Ты опытный системный аналитик, который готовит требования для команды разработки.

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

Steps:
1. Выдели цели пользователя.
2. Найди функциональные требования.
3. Найди нефункциональные требования.
4. Сформулируй открытые вопросы.
5. Определи риски и противоречия.

End goal:
Получить основу для раздела требований в Confluence.

Narrowing:
Не используй общие фразы. Каждое требование должно быть проверяемым. Верни результат на русском языке в формате Markdown.

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

Как выбрать фреймворк под задачу

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

На практике фреймворки часто комбинируются. Например, можно взять CRAFT как основную структуру и добавить CLEAR как чек-лист проверки. Или использовать RISEN для сложной аналитической задачи, но внутри шага «Format» указать строгую таблицу.

Инженерный взгляд: промпт как требование

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

Хороший промпт задает критерии результата. Например: «Сформируй 10 требований, каждое в формате “Система должна…”, добавь критерий приемки и пометь требования, которые требуют уточнения у заказчика». Такой запрос уже можно проверить.

В корпоративной работе стоит относиться к промптам как к артефактам. Если команда регулярно использует ИИ для подготовки требований, ревью API или генерации тест-кейсов, промпты нужно версионировать, улучшать и проверять на примерах. OpenAI в своих рекомендациях отдельно выделяет переиспользуемые промпты, шаблоны с переменными и оценки поведения промптов при изменении моделей (OpenAI API Docs).

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

Типовые ошибки при написании промптов

Ошибка: просить результат без контекста

Запрос «напиши требования к личному кабинету» слишком широкий. Лучше указать тип системы, пользователей, ограничения, канал, интеграции и формат результата.

Ошибка: смешивать несколько задач в одну

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

Ошибка: не задавать формат

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

Ошибка: не ограничивать допущения

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

Ошибка: не проверять ответ

Первый ответ ИИ - это не финальная версия, а черновик. Anthropic подчеркивает важность критериев успеха и оценок, потому что не каждый сбой решается переписыванием промпта, а иногда требуется изменить модель, контекст или саму постановку задачи (Claude API Docs).

Чек-лист хорошего промпта

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

• Указана роль, из которой ИИ должен отвечать.
• Описан контекст задачи и исходные данные.
• Сформулирована конкретная цель.
• Задан формат результата.
• Определена аудитория или потребитель ответа.
• Указаны ограничения: объем, язык, стиль, глубина, запреты.
• Отдельно описано, что делать с неизвестными фактами.
• Есть критерии качества или приемки.
• Сложная задача разбита на шаги.
• Предусмотрен следующий уточняющий цикл.

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

Готовый универсальный шаблон

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

# Роль
Ты выступаешь в роли [роль и уровень экспертизы].

# Контекст
[Кратко опиши систему, процесс, предметную область, участников, ограничения и исходные данные.]

# Задача
Нужно [конкретное действие и ожидаемый результат].

# Шаги
1. [Первый шаг анализа]
2. [Второй шаг анализа]
3. [Третий шаг анализа]

# Формат результата
Верни результат в формате [таблица / Markdown / JSON / список / структура документа].
Структура ответа:
- [раздел 1]
- [раздел 2]
- [раздел 3]

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

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

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

Заключение

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

Для аналитика промпт - это интерфейс между мыслью и моделью. Чем яснее интерфейс, тем меньше неожиданных побочных эффектов. Мы же не проектируем API методом «пусть сервис сам поймет, что я имел в виду». С промптами логика такая же.

RTF помогает быстро задать роль, задачу и формат. CRAFT превращает запрос в рабочий бриф. CO-STAR управляет стилем, тоном и аудиторией. CLEAR помогает проверять качество промпта и ответа. RISEN полезен для сложных задач, где важны шаги, цель и ограничения.

Главная мысль простая: хороший промпт - это не длинный промпт. Хороший промпт - это управляемое требование. А фреймворк помогает сделать это требование понятным, проверяемым и пригодным для повторного использования.