Перейти к содержимому
Инструменты

Промпт как контракт: 7 полей, после которых нет переделок

Промпт как контракт: 7 полей, после которых нет переделок

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

Разница видна на простом сравнении. «Расскажи о безопасности Kubernetes» — и модель угадывает, что вам нужно. «Собери чеклист продакшен-готовности из 12 пунктов для команды платформы на EKS: identity, pod security, network policy, секреты, admission control, цепочка поставок, логирование, runtime-детект, бэкапы, патчинг, ревью доступов, реагирование на инциденты; для каждого пункта — контроль, зачем он нужен, какие доказательства собрать и критерий pass/fail; источники — актуальная документация AWS и Kubernetes; аудитория — senior DevOps» — и угадывать больше нечего.

Семь полей, которые закрывают 90% переделок

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

Deliverable — что именно должно существовать в конце: дифф, CSV со схемой, решенческая записка, runbook. Inputs — какие файлы, ссылки и решения считать авторитетными. Audience — кто это читает и что уже знает. Method — какой процесс и инструменты использовать: поиск, глубокое исследование, анализ данных, сравнительная рамка. Obligations — что обязательно, что запрещено, где границы задачи и что в неё не входит. Necessary evidence — источники, цитаты, тесты, расчёты, критерии приёмки. Done definition — при каких условиях задача закрыта.

Последнее поле самое недооценённое. В документации Codex прямым текстом советуют то же самое: «For narrower tasks, define what done looks like to keep the work focused» — определите, как выглядит готовность, иначе модель будет расширять задачу за вас. Формулировка «верни финальный результат в формате X, затем допущения, проверки и остаточные риски» экономит целый круг правок.

Шаблон, который можно скопировать

Префиксы имеет смысл держать на английском — так они компактнее и стабильнее срабатывают. Подставляйте своё в квадратных скобках.

DELIVERABLE
Create [specific artifact].

INPUTS
Use [files, facts, links, prior decisions]. Treat [source] as authoritative.

AUDIENCE
The audience is [role and knowledge level]. They need to [decision or action].

METHOD
Use [search, data analysis, coding tools]. Proceed without asking questions
unless a missing fact would materially change correctness.

OBLIGATIONS
Must include: [...] Must avoid: [...] Scope: [...] Tone: [...]

NECESSARY EVIDENCE
For time-sensitive facts, use current primary sources and cite each material claim.
Separate verified facts, assumptions, and recommendations.

DONE DEFINITION
Complete only when [acceptance criteria]. Return the output in [format],
followed by assumptions, checks, and remaining risks.

Обязательное отдельно от желаемого

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

HARD REQUIREMENTS
- Must use official sources.
- Must not expose secrets.
- Must preserve backward compatibility.

PREFERENCES
- Prefer concise headings.
- Prefer one table over several lists.
- Prefer low-cost approaches when quality is equivalent.

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

Права доступа — тоже часть промпта

Для агентных задач контракт обязан описывать не только результат, но и разрешённые действия. Иначе «почини тесты» однажды превратится в установку пакетов и force-push.

You may inspect all repository files and run read-only diagnostics.
You may edit files under src/ and tests/.
Ask before installing packages, using the network, modifying infrastructure,
changing secrets, deleting data, force-pushing, or deploying.

Это минимальная версия. Что ещё стоит закрывать, когда у агента есть доступ к браузеру, десктопу или корпоративным системам, разобрано отдельно в материале про права ИИ-агента в Work, Codex и Computer Use.

Пять антипаттернов, которые встречаются чаще всего

Расплывчатые превосходные степени. «Сделай на мировом уровне» — неизмеримый критерий. Переведите его в атрибуты: полное покрытие темы, ссылки на первичные источники, отсутствие фактических ошибок при проверке, протестированные команды, явно указанные ограничения.

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

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

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

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

Проходами, а не одним рывком

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

И последнее, самое практичное наблюдение. Когда результат не устраивает, первый рефлекс — поднять уровень рассуждений. В документации совет обратный: «Use the lowest reasoning effort that produces the result you need». Сначала уточните постановку задачи, и только потом добавляйте мощность — иначе вы платите за то, что модель дольше угадывает вашу цель. Как выбирать модель и уровень после того, как промпт стал контрактом, разобрано в статье про выбор между Sol, Terra и Luna.