Промт-инжиниринг по-взрослому: как писать запросы к OpenAI и Anthropic так, чтобы модели действительно работали
Сильный промт — не волшебная фраза, а поставленная задача. Правила OpenAI и Anthropic: сначала результат, инструкции отдельно от данных.
Введение
За последние два года вокруг промт-инжиниринга накопилось много мифов. Кто-то до сих пор ищет «волшебные слова», кто-то собирает наборы хитрых формулировок, а кто-то вообще считает, что с новыми моделями промты больше не нужны. И то и другое — крайности.
Если свести рекомендации OpenAI и Anthropic к одной честной мысли, она звучит так: сильный промт — это не магическая фраза, а качественно поставленная задача. Хороший запрос не заставляет модель догадываться, что именно вы имели в виду. Он задаёт цель, контекст, ограничения, формат, критерии качества и правила поведения в неоднозначных местах.
Именно в этом состоит зрелый промт-инжиниринг. Не в словесных трюках, а в дисциплине мышления. Модель работает лучше не потому, что её «убедили», а потому, что ей дали внятный контракт на результат.
В рекомендациях OpenAI акцент делается на ясности инструкций, порядке блоков, конкретике, примерах, управлении форматом ответа и различии между prompting для обычных GPT-моделей и reasoning-моделей. Anthropic дополняет это более развитым взглядом на XML-структуру, длинный контекст, tool use, thinking-режимы, агентные системы, самопроверку и долгие автономные задачи. Вместе эти подходы складываются в единую рабочую систему.
Ниже — подробный практический лонгрид: основные правила, архитектура сильного промта, алгоритмы по типам задач, антипаттерны, диагностика ошибок и набор шаблонов, которые можно адаптировать под реальные задачи.
1. Что такое сильный промт на практике
Слабый промт обычно выглядит нормально только на первый взгляд. Он может быть коротким, вежливым и даже звучать «разумно», но внутри него почти всегда не хватает критически важных вещей. Модель не понимает, какой результат считать хорошим, где заканчивается контекст и начинается инструкция, можно ли делать предположения, насколько жёстко соблюдать формат, нужно ли объяснять ход работы или сразу давать финальный результат.
Сильный промт, наоборот, снимает неопределённость. Он работает как хорошее техническое задание для сильного исполнителя: задаёт цель, рамки, ожидаемый тип результата, ограничения и критерии приёмки.
Проще всего запомнить это через формулу:
сильный промт = роль + цель + контекст + входные данные + ограничения + формат ответа + примеры + проверка качества.
Не в каждом запросе нужны все элементы в равной степени, но именно из них строится основа почти любой хорошей постановки задачи.
2. Главные правила промт-инжиниринга
Сначала формулируется не текст запроса, а результат
Главная ошибка новичков — начинать с фразы, а не с outcome. Перед тем как писать промт, полезно ответить себе на несколько вопросов: что именно должно получиться на выходе, по каким критериям я пойму, что результат хороший, какие ограничения обязательны и что недопустимо.
Запрос «напиши хороший текст про продуктовый подход» слишком слабый не потому, что он короткий, а потому, что в нём не определено почти ничего. Кто аудитория? Какой тезис? Какой объём? Какой стиль? Нужна статья, тезисы, пост, речь, заметка для канала, презентационный текст? Можно ли использовать списки? Нужны ли примеры?
Прежде чем писать запрос, нужно ответить на четыре вопроса:
- Что именно должно получиться на выходе?
- Как я пойму, что результат хороший?
- Какие ограничения обязательны?
- Что недопустимо?
Например, плохая постановка:
Напиши хороший текст про продуктовый подход.
Хорошая постановка:
Напиши статью на 6–8 абзацев для аудитории фаундеров и продактов. Объясни, почему в эпоху AI скорость сборки продукта перестала быть преимуществом сама по себе. Покажи, что ключевой вопрос — не «что мы можем собрать», а «за какую проблему клиент готов платить». Стиль — умный, ясный, без канцелярита. Без списков, кроме одного короткого блока из 3 вопросов. Без ссылок.
Во втором варианте модель понимает:
— тему;
— аудиторию;
— тезис;
— длину;
— стиль;
— структуру;
— запреты.
Сильная версия такого запроса уже похожа на задачу: написать статью для фаундеров и продактов на 6–8 абзацев, показать, почему в эпоху AI скорость сборки продукта перестала быть самостоятельным преимуществом, объяснить, что ключевой вопрос — не что можно собрать, а за какую проблему клиент готов платить, выдержать ясный живой стиль без канцелярита и без ссылок. Здесь модель уже не гадает, а работает.
Инструкции нужно отделять от данных
И OpenAI, и Anthropic прямо указывают, что модель лучше справляется, когда промт структурирован. Самая частая проблема — смешивание команды и материала в один неразмеченный блок. В таком виде модель начинает хуже различать, что является инструкцией, а что — данными для анализа.
Поэтому промт должен быть разложен по блокам. Самые удобные варианты:
— Markdown-заголовки;
— XML-теги;
— явные секции вроде Инструкция, Контекст, Вход, Формат ответа.
Пример в Markdown:
# Задача
Сделай аналитическое резюме документа.
# Контекст
Текст ниже — это стенограмма интервью.
# Требования
- Исправь явные речевые ошибки
- Не меняй смысл
- Раздели реплики двух спикеров корректно
# Формат ответа
1. Короткое summary
2. Полная вычитанная версия интервью
# Входные данные
"""
...
"""Поэтому промт почти всегда выигрывает от явной структуры. Это может быть Markdown с секциями «Задача», «Контекст», «Требования», «Формат ответа», а может быть XML с тегами <role>, <task>, <context>, <input>, <constraints>. Anthropic особенно последовательно продвигает XML как способ убирать неоднозначность в сложных промтах.
Нельзя писать расплывчато
Слова вроде «нормально», «красиво», «не слишком длинно», «профессионально», «сделай как эксперт» выглядят как инструкции, но на самом деле почти ничего не задают. Модель не знает, что именно вы вкладываете в эти формулировки.
Промты ломаются на словах вроде:
— «нормально»;
— «красиво»;
— «не слишком длинно»;
— «коротко, но подробно»;
— «сделай как профессионал».
Модель не знает, что именно ты вкладываешь в эти слова. Их нужно переводить в операционные требования.
Вместо:
Сделай коротко.
Лучше:
Ответ — 5 пунктов, каждый по 1–2 предложения.
Вместо:
Напиши живо и экспертно.
Лучше:
Стиль — уверенный, ясный, без канцелярита, без маркетинговой воды. Предложения средней длины. Допускается живая разговорная интонация, но без фамильярности.
Любую абстракцию нужно переводить в рабочие критерии. Не «сделай коротко», а «дай 5 пунктов по 1–2 предложения». Не «напиши живо и экспертно», а «стиль уверенный и ясный, без канцелярита и маркетинговой воды, предложения средней длины, допустима живая разговорная интонация без фамильярности».
Формат ответа задаётся как контракт
Если формат важен, его нельзя описывать расплывчато. Не надо просить «в формате JSON примерно вот так». Нужно задавать формат как контракт.
Плохо:
Верни JSON.
Лучше:
{
"topic": "string",
"key_points": ["string"],
"risks": ["string"],
"conclusion": "string"
}Ещё лучше — добавить правила:
— никаких дополнительных полей;
— никаких комментариев вне JSON;
— если данных не хватает, вернуть пустой массив или поле null;
— не придумывать значения.
Этот принцип одинаково работает и для текстов. «Напиши кратко» хуже, чем «дай ответ в трёх абзацах: проблема, вывод, рекомендация». Чем легче потом проверить соответствие результата формату, тем стабильнее работает промт.
Примеры — один из самых мощных рычагов
OpenAI рекомендует идти по понятной лестнице: сначала zero-shot, потом few-shot, и только если этого недостаточно — думать о более системной настройке. Anthropic тоже делает сильный акцент на few-shot, особенно когда задача неоднозначна или когда важны точная структура, тон и тип мышления.
- Сначала пробуем zero-shot.
- Если качество нестабильно — добавляем few-shot.
- Если задача повторяется массово и регулярно — думаем про более системную настройку или fine-tuning.
Хорошие примеры должны быть:
— релевантными;
— разнообразными;
— показывающими именно нужный паттерн;
— отделёнными от инструкций.
Их задача — не просто показать желаемый ответ, а зафиксировать паттерн, который модель должна воспроизвести.
Лучше говорить, что делать, чем только что не делать
Один из самых полезных выводов из материалов: негативные запреты работают слабее, чем позитивные инструкции.
Плохо:
Не пиши сухо. Не используй списки. Не делай канцелярит. Не повторяй вопрос.
Лучше:
Пиши плавными абзацами. Стиль — живой, журналистский, уверенный. Начинай сразу с сути, без повторения вопроса. Списки используй только если они действительно улучшают читаемость.
Запреты нужны, но они не должны быть единственным способом управления моделью.
1.7. Хороший промт учитывает режим модели
Это очень важный момент.
Разные модели и режимы требуют разного типа управления.
Для обычных GPT-моделей полезно явно описывать шаги, формат, структуру и правила.
Для reasoning-моделей лучше работают:
— чёткая цель;
— ограничения;
— явный output contract;
— критерии «что считается выполненным».
Но не надо слишком детально расписывать внутреннее мышление модели. Современные reasoning-модели часто лучше справляются, когда им задают рамку, а не насильно прописывают каждую мыслительную операцию.
1.8. Параметры не заменяют хороший промт
Температура, max tokens, reasoning effort и прочие настройки — это вторичный слой.
Правильный порядок такой:
- Сначала хороший промт.
- Потом примеры.
- Потом правила проверки.
- Потом уже настройка параметров.
Для фактических задач, извлечения и truthful QA обычно нужен низкий temperature.
Для более творческих задач допустим более высокий.
Но плохой промт нельзя «спасти» только температурой.
3. Архитектура сильного промта
На практике почти любой сильный промт можно разложить на восемь блоков.
1. Роль
Роль задаёт модель поведения. Она не обязана быть длинной, но часто помогает сузить режим работы. «Ты — редактор интервью», «Ты — исследователь-аналитик», «Ты — инженер, который сначала изучает код, а потом меняет его» — это не украшения, а способ сместить модель в нужный режим.
2. Цель
Здесь важно описать не просто действие, а ожидаемый результат. Не «проанализируй документ», а «собери аналитическое резюме, выдели ключевые тезисы, спорные места и практические выводы».
3. Контекст
Контекст отвечает на вопрос: что модели важно знать до начала работы. Кто аудитория? Как используется результат? Какие есть предпосылки? Почему задача вообще ставится? Anthropic отдельно подчёркивает, что контекст и мотивация поведения могут заметно улучшать качество ответа.
4. Входные данные
Это сам материал: текст, таблица, транскрипция, код, документы, список ссылок, пользовательский ввод. Он должен быть отделён от инструкций.
5. Ограничения
Сюда входят стиль, длина, допустимая свобода модели, запрет на домысливание, правила поведения при нехватке данных, необходимость источников, ограничения на списки, ссылки, канцелярит, предположения и так далее.
6. Формат ответа
Ответ должен быть задан так, чтобы его можно было проверить. Даже если это свободный текст, полезно определить желаемую структуру: например, «сначала короткое summary, потом разбор, затем рекомендации».
7. Примеры
Нужны не всегда, но особенно полезны при форматировании, извлечении, трансформации текста, классификации и стилевых задачах.
8. Проверка качества
Это критически важный слой, который часто забывают. Модели полезно явно сказать: перед завершением проверь, что все части задачи покрыты, формат соблюдён, противоречий нет, неподтверждённые факты не добавлены. Anthropic особенно подчёркивает пользу self-check, а GPT-5 guidance для кодовых и агентных сценариев делает верификацию вообще обязательной дисциплиной.
Вот базовый каркас, который можно использовать как универсальную заготовку:
<role>
Ты — [роль].
</role>
<objective>
Нужно получить [точный результат].
Успех считается достигнутым, если:
1. ...
2. ...
3. ...
</objective>
<context>
Вот важный контекст:
...
</context>
<input>
Вот входные данные:
...
</input>
<constraints>
- Соблюдай стиль: ...
- Длина: ...
- Не домысливай неподтверждённые факты.
- Если данных недостаточно, явно отметь неопределённость.
</constraints>
<output_format>
Верни результат в формате:
...
</output_format>
<examples>
<example>
<input>...</input>
<output>...</output>
</example>
</examples>
<verification>
Перед финальным ответом проверь:
- все ли части задачи покрыты;
- соблюдён ли формат;
- нет ли противоречий;
- не добавлено ли ничего неподтверждённого.
</verification>4. Базовый алгоритм проектирования промта
Хороший промт почти всегда собирается по одной и той же логике.
Сначала определяется тип задачи. Пока непонятно, это генерация, извлечение, редактирование, анализ, ресёрч, код или агентная работа с инструментами, качественно поставить запрос трудно.
Потом определяется, что считается успехом. Нужно буквально выписать критерии: покрыты ли все части задачи, допустимы ли гипотезы, нужен ли строгий формат, нужны ли источники, можно ли проверять результат автоматически.
Следующий шаг — определить степень свободы модели. Должна ли она просто отвечать, предлагать варианты, сама искать данные, действовать автономно, запрашивать подтверждение перед рискованными действиями? Эта часть особенно важна для tool use и агентных режимов.
Дальше промт раскладывается на блоки: роль, задача, контекст, ограничения, формат, проверка. Если задача сложная, добавляются примеры, citation rules, research mode, dependency checks, completeness contract, tool policy.
Затем убирается двусмысленность. Лучший проверочный вопрос здесь очень простой: если дать этот промт человеку без дополнительного контекста, поймёт ли он, что именно нужно сделать?
После этого промт тестируется не на одном кейсе, а на нескольких: нормальном, сложном, граничном, кейсе с нехваткой данных и кейсе с конфликтующими источниками. И только потом начинается настоящая доработка.
Главный принцип исправления: чинить нужно не «красоту формулировки», а слабое место в контракте. Если модель ошибается, причина обычно одна из пяти: не хватает контекста, не определён формат, нет примеров, не задано поведение при неопределённости или отсутствует финальная проверка.
5. Алгоритмы по типам задач
Генерация текста
Для текстов важнее всего правильно задать аудиторию, цель и главный тезис. Если не указать, кто читатель и какого эффекта вы хотите, модель почти неизбежно скатится в усреднённый текст «для всех». Хороший генеративный промт задаёт роль автора, аудиторию, цель текста, ключевую мысль, тон, стиль, ограничения по длине и правила структуры.
Базовый шаблон:
Ты — сильный редактор и автор.
Задача: напиши текст на тему [тема].
Аудитория: [кто читает].
Цель: [какой эффект должен быть].
Главный тезис: [что нужно донести].
Требования:
- стиль: ...
- тон: ...
- длина: ...
- структура: ...
- допускается / не допускается: ...
Ответ дай сразу в финальном виде, без пояснений о процессе.Извлечение фактов и классификация
Здесь креативность должна быть минимальной, а структура — максимально строгой. Нужны явный запрет на домысливание, точная схема ответа и понятное поведение, если нужных данных нет.
<task>Извлеки сущности из текста.</task>
<constraints>
- Извлекай только то, что прямо есть в тексте.
- Ничего не додумывай.
- Если сущность отсутствует, верни пустой массив.
</constraints>
<output_format>
{
"companies": [],
"people": [],
"topics": [],
"themes": []
}
</output_format>
<input>
...
</input>Анализ длинных документов
Anthropic отдельно подчёркивает несколько сильных практик для long-context задач: длинные документы лучше размещать выше в промте, сам запрос — ближе к концу; несколько документов нужно размечать отдельно и сопровождать метаданными; перед синтезом вывода полезно сначала просить модель извлечь релевантные цитаты или факты.
Это особенно важно для интервью, транскрипций, судебных материалов, больших отчётов, презентаций, исследований и совокупности документов по одной теме.
<documents>
<document index="1">
<source>Интервью 1</source>
<document_content>...</document_content>
</document>
<document index="2">
<source>Интервью 2</source>
<document_content>...</document_content>
</document>
</documents>
<task>
Сначала выдели все места, где можно надёжно определить говорящего.
Потом собери цельную вычитанную версию.
Если уверенности недостаточно, пометь это явно.
</task>Research и deep research
Для ресёрча почти всегда слабо работает общий запрос «изучи тему и расскажи». Сильнее — явный исследовательский режим. Модель должна разбить тему на под-вопросы, исследовать каждый отдельно, проверять конфликты фактов, повторять поиск при пустом результате и чётко отделять подтверждённые факты от выводов.
<research_mode>
- Разбей тему на 3–6 под-вопросов.
- Исследуй каждый отдельно.
- Если результаты пустые или слишком узкие, попробуй 1–2 альтернативные стратегии.
- Завершай исследование только когда дополнительный поиск вряд ли изменит вывод.
</research_mode>
<citation_rules>
- Ссылайся только на реально найденные источники.
- Не придумывай ссылки и цитаты.
- Привязывай источник к конкретному тезису.
</citation_rules>
<grounding_rules>
- Не делай утверждений без опоры на данные.
- Если источники конфликтуют, покажи конфликт явно.
- Если это вывод, а не прямой факт, пометь это.
</grounding_rules>Код и coding agents
Здесь рекомендации OpenAI и Anthropic особенно сходятся: сначала понять задачу и окружение, не менять код до изучения нужного места, после изменений обязательно проверять результат, учитывать hidden tests и edge cases, не завершать задачу на ощущении «вроде работает».
<role>
Ты — инженер-программист, который работает аккуратно и тщательно проверяет изменения.
</role>
<workflow>
1. Сначала пойми задачу и кодовую базу.
2. Не редактируй файлы, пока не понял место и смысл изменения.
3. После изменений проверь код тестами или прямым запуском.
4. Не завершай задачу, пока не убедился, что решение корректно.
</workflow>
<verification>
- Проверяй не только видимые кейсы, но и edge cases.
- Не считай изменение успешным только потому, что патч применился.
- Если что-то не удалось проверить, честно укажи это.
</verification>OpenAI дополнительно отмечает приём с leading words: для Python может помочь начало import, для SQL — SELECT. Это небольшой, но иногда полезный способ мягко подтолкнуть модель к нужному формату генерации.
Агентные сценарии и tool use
Когда у модели есть доступ к инструментам, нужно задавать не только задачу, но и политику действий. Когда использовать инструмент, когда продолжать без него, когда обязательно проверять результат, что считать рискованным действием, в каких случаях спрашивать подтверждение у пользователя.
<tool_policy>
- Используй инструменты, если они заметно улучшают корректность, полноту или grounding.
- Не останавливайся рано, если дополнительный tool call может существенно усилить результат.
- Если tool вернул пустой или подозрительно узкий результат, попробуй альтернативный путь.
</tool_policy>
<dependency_checks>
- Перед действием проверь, нужны ли предварительные шаги поиска, чтения или извлечения данных.
- Не пропускай prerequisite-этапы только потому, что финальное действие кажется очевидным.
</dependency_checks>
<safety>
- Если следующее действие необратимо или влияет на внешние системы, сначала запроси подтверждение.
</safety>6. Что особенно важно для современных reasoning-моделей
У современных reasoning-моделей есть важная особенность: им часто не нужно вручную прописывать каждый мыслительный шаг. OpenAI прямо различает prompting для GPT-моделей и для reasoning-моделей. Anthropic тоже подчёркивает, что избыточно жёсткий пошаговый контроль может даже мешать.
Для reasoning-модели сильнее работает не ручной CoT-театр, а ясная рамка: цель, ограничения, формат, критерии качества и требование финальной проверки. Формулировка вроде «реши задачу внимательно; перед финальным ответом проверь соответствие всем условиям» обычно полезнее, чем попытка вручную расписать мыслительный процесс до мелочей.
Для маленьких моделей, наоборот, чаще нужны более жёсткие и явные инструкции: важные правила в начале, конкретный порядок шагов, закрытый формат, описание edge cases и хотя бы один хороший пример.
7. Антипаттерны, которые ломают промты
Первый и самый частый антипаттерн — «сделай хорошо». Это не инструкция, а надежда. Модель не знает, что в вашем контексте означает «хорошо».
Второй — смешивание задачи и входных данных в одну кашу. Когда промт неразмечен, модель чаще теряет структуру и роль отдельных частей.
Третий — отсутствие формата ответа. Тогда каждый запуск может выдавать разную упаковку, и результат становится нестабильным.
Четвёртый — отсутствие правила поведения при нехватке данных. В такой ситуации модель либо начинает галлюцинировать, либо уходит в бесконечные уточнения.
Пятый — отсутствие критерия завершения, особенно в агентных задачах. Модель может закончить слишком рано или, наоборот, бесконечно продолжать работу без явной точки остановки.
Шестой — избыток запретов без позитивной рамки. Негативные ограничения полезны, но без явного описания желаемого поведения они работают хуже.
Седьмой — переусложнение без необходимости. Сильный промт не обязан быть длинным. Он должен быть достаточным. Начинать лучше с минимальной структуры, которая проходит реальные кейсы, и только потом наращивать сложность.
8. Диагностика: почему промт работает плохо
Если результат слабый, задавай себе вопросы по порядку.
Модель вообще поняла задачу?
Признаки, что нет:
— отвечает не на тот вопрос;
— уходит в общие слова;
— путает режим работы.
Лечение:
— переписать цель;
— упростить формулировку;
— отделить инструкцию от контекста.
Ей хватило контекста?
Признаки:
— домысливает;
— путает участников, даты, роли;
— делает красивые, но слабые выводы.
Лечение:
— добавить релевантные данные;
— убрать шум;
— разметить источники.
Был ли формат задан жёстко?
Признаки:
— плавающая структура;
— невозможно автоматически парсить;
— каждый запуск упакован по-разному.
Лечение:
— задать schema;
— добавить пример;
— прямо написать «верни только этот формат».
Понятно ли модели, что делать при нехватке данных?
Признаки:
— галлюцинации;
— лишние уточнения;
— остановка на полпути.
Лечение:
— добавить missing-context behavior;
— явно разрешить осторожные предположения только если они помечены;
— для retrievable-контекста — направить к tools.
Есть ли встроенная проверка?
Признаки:
— формально хороший, но неполный ответ;
— пропущенные подпункты;
— нарушения формата.
Лечение:
— добавить verification loop;
— добавить completeness contract.
9. Набор готовых шаблонов
Универсальный шаблон
<role>
Ты — [роль].
</role>
<task>
Сделай [точная задача].
</task>
<context>
Вот важный контекст:
...
</context>
<constraints>
- Не домысливай факты.
- Соблюдай стиль: ...
- Длина: ...
- Структура: ...
</constraints>
<output_format>
Верни ответ в виде:
...
</output_format>
<verification>
Перед финальным ответом проверь полноту, корректность и соответствие формату.
</verification>Шаблон для анализа нескольких документов
<documents>
<document index="1">
<source>Документ 1</source>
<document_content>...</document_content>
</document>
<document index="2">
<source>Документ 2</source>
<document_content>...</document_content>
</document>
</documents>
<task>
1. Сначала выдели релевантные факты по теме.
2. Потом сравни документы.
3. Затем собери единый вывод.
4. Если данные конфликтуют, покажи конфликт явно.
</task>
<output_format>
1. Факты
2. Расхождения
3. Итоговый вывод
4. Неопределённости
</output_format>Шаблон для deep research
<role>
Ты — исследователь-аналитик.
</role>
<research_mode>
- Разбей тему на 3–6 под-вопросов.
- Исследуй каждый отдельно.
- Если поиск пустой или слишком узкий, попробуй альтернативные стратегии.
- Остановись только когда новый поиск вряд ли изменит вывод.
</research_mode>
<citation_rules>
- Ссылайся только на реальные источники.
- Не придумывай ссылки и цитаты.
- Привязывай источник к конкретному тезису.
</citation_rules>
<grounding_rules>
- Не делай утверждений без опоры на данные.
- Если это вывод, а не прямой факт, пометь это.
</grounding_rules>
<output_format>
1. Краткий ответ
2. Ключевые выводы
3. Спорные места
4. Источники по тезисам
</output_format>Шаблон для статьи
Ты — сильный редактор и автор long-form текстов.
Задача: напиши статью на тему [тема].
Аудитория: [аудитория].
Цель: [цель текста].
Главный тезис: [тезис].
Требования:
- стиль: умный, ясный, живой;
- без канцелярита;
- без повторов;
- структура логическая, с плавными переходами;
- объём: [объём];
- списки только если реально нужны.
Сразу дай финальный текст.Шаблон для Telegram-поста
Напиши пост для Telegram.
Тема: [тема]
Аудитория: [кто читает]
Цель: [что должен сделать читатель]
Требования:
- сильный заголовок;
- короткое и цепкое вступление;
- ясное раскрытие сути;
- тон: живой, уверенный, читаемый;
- без воды;
- длина: [примерно];
- финал: [CTA или нужная концовка].Шаблон для восстановления интервью из транскрипции
<role>
Ты — редактор интервью и аналитик расшифровок.
</role>
<task>
Из сырой транскрипции собери цельное интервью.
</task>
<context>
Есть два спикера: [кто именно].
Могут быть ошибки распознавания и путаница в репликах.
</context>
<constraints>
- Не меняй смысл.
- Исправляй только явные ошибки речи и OCR/ASR.
- Разделяй реплики максимально точно.
- Если уверенность низкая, помечай это явно.
</constraints>
<output_format>
1. Краткое summary
2. Цельное интервью
3. Неясные места
</output_format>10. Финальный чеклист перед запуском
Перед тем как считать промт готовым, полезно проверить его по короткому списку.
Понятно ли, что именно нужно сделать? Понятно ли, какой результат считается хорошим? Отделены ли инструкции от входных данных? Есть ли явный формат ответа? Определено ли поведение при нехватке данных? Нужны ли примеры? Нужна ли самопроверка? Если используются инструменты, задано ли, когда действовать, а когда спрашивать подтверждение? Если задача исследовательская, есть ли grounding и citation rules? Если контекст длинный, размечены ли документы?
Если хотя бы на несколько из этих вопросов ответ отрицательный, промт почти наверняка можно усилить.
Заключение
Главный вывод из рекомендаций OpenAI и Anthropic очень прагматичный. Сильный промт — это не магия и не коллекция секретных формулировок. Это способ превратить смутное человеческое намерение в чёткую рабочую задачу для модели.
Когда промт построен хорошо, модель получает не просто «тему», а понятный режим работы. Она знает, что нужно сделать, для кого, в каком формате, с какими ограничениями, как вести себя при неопределённости и как проверить себя перед финальным ответом.
Именно поэтому зрелый промт-инжиниринг — это, по сути, архитектура постановки задачи. Чем лучше вы умеете формулировать цель, задавать контекст, ограничивать свободу там, где она опасна, и оставлять её там, где она полезна, тем сильнее становятся результаты.
В одной фразе это можно свести к простой формуле:
не проси модель «сделать красиво» — строй для неё ясный контракт на результат.
Промт — только часть того, что видит модель. Всё остальное, что попадает в неё до ответа, — это контекст, и им тоже нужно управлять.
