Месяц назад я опубликовал на Хабре статью про то, как сжал 39 агентов в 3 плагина — думал, что проще уже некуда. Полез на днях писать новый скилл process-logs для рабочего проекта — обработка логов ошибок из админки. Получилось 663 строки и 36 капс-блоков: «CRITICAL REQUIREMENTS», «YOU MUST FOLLOW THESE RULES. NO EXCEPTIONS», «ALWAYS run this FIRST», «MANDATORY», «NEVER ignore errors». Каждый второй раздел начинается с императива.

Логика была простая: чем подробнее опишу — тем меньше у модели шансов промахнуться.

И тут OpenAI выкатил гайд по промтингу GPT-5.5. Прямым текстом: вы делаете не так. Я полез проверять — действительно делаю не так. Самое неприятное — на Claude Opus 4.7, с которым я провожу по 12 часов в день, ровно та же история.

Эта статья — продолжение прошлой. Месяц назад упрощал стек. Теперь придётся упростить и промты внутри стека.

Что говорит OpenAI

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

Первый — про длину. Прямая цитата:

“Shorter, outcome-first prompts usually work better than process-heavy prompt stacks.”

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

Второй — про миграцию. OpenAI отдельно предупреждает: не переносите старые промты на новую модель.

“Avoid carrying over every instruction from an older prompt stack.”

Это особенно неприятно слышать тем, кто годами обрастал шаблонами. Я в их числе.

Третий — про императивы. ALWAYS/NEVER/MUST оставляем для true invariants. Для всего, что является judgment call (а это большинство инструкций), убираем. Что такое «true invariant»? Например, «не выполняй удаление файлов без явного подтверждения» — это инвариант, нарушение приведёт к катастрофе. А «всегда сначала проанализируй, потом пиши код» — это рекомендация. Модель должна сама решить, нужен ей анализ или задача очевидна. Различие тонкое, но как только начинаешь его держать — половина капс-блоков в твоих промтах оказывается на стороне рекомендаций.

Четвёртый — про стоп-условие. Минимум доказательств:

“Use the minimum evidence sufficient to answer correctly, cite it precisely, then stop.”

Stopping condition — это новое в гайде. Раньше учили модель «думать тщательно», теперь — «думай ровно столько, сколько нужно, и останавливайся». Иначе модель уходит в overthinking: продолжает анализ там, где задача уже решена, добавляет соображения сверху уже готового ответа, размывает фокус.

Пятый — про reasoning effort. OpenAI прямо пишет: это «last-mile knob», а не основной рычаг качества. Если результат плохой — не крутите effort вверх. Перепишите промт.

Ну ничего себе. Большая часть моего opinion-формирования за последний год про prompt engineering — мимо.

Главный диф: process-logs «до и после»

Покажу на реальном коде. У меня в одном из рабочих проектов живёт скилл process-logs — берёт ошибки из админки, классифицирует, создаёт задачи в трекере, фиксит, закрывает. Бизнес-задача рутинная, скилл в продакшене, версия 1.9.0.

Вот одна секция из него — называется «BUG FIXING PRINCIPLES»:

### 4. BUG FIXING PRINCIPLES

> **This is PRODUCTION. Every bug matters.**

**Fix fundamentally, not superficially:**
- Find and fix the ROOT CAUSE, not just symptoms
- If error happens in function X but cause is in function Y → fix Y
- Don't add workarounds/hacks that mask the problem
- Ask: "Why did this happen?" until you reach the actual cause

**Never ignore errors:**
- Every error indicates a real problem
- "Works most of the time" is NOT acceptable
- External service errors → add retry logic or graceful degradation
- Config warnings → fix config or make truly optional

**Propose improvements:**
- If you see code that could be better → create separate Beads task
- If fix reveals related issues → document them
- If pattern repeats → suggest refactoring to prevent future bugs

**Quality over speed:**
- Take time to understand the full context
- Test the fix mentally: "What else could break?"
- Check for similar patterns elsewhere in codebase
- One good fix > multiple quick patches

134 слова, четыре блока с буллетами, четырнадцать пунктов. Я писал это три месяца назад, был уверен, что закрываю все возможные сценарии.

Перечитываю сейчас по новым правилам OpenAI и вижу четыре проблемы.

Дублирование одной мысли. «Fix root cause», «not symptoms», «not workarounds», «not just patches» — четыре формулировки одного и того же. Модель получает одну мысль четыре раза и начинает переусиливать: будет копать вглубь даже там, где причина очевидна. Это antipattern в чистом виде — то самое «narrowing the search space», от которого предостерегает гайд.

Judgment под видом invariant. «Quality over speed» звучит здорово, но это рекомендация, а не инвариант. Иногда быстрый патч важнее идеального решения — продакшн горит, надо хоть как-то заткнуть до утра, а потом фундаментально починить. Я зашил императив там, где должен был дать модели контекст и право решать.

Нет stopping condition. Когда фикс готов? По текущему промту — никогда. «Test the fix mentally: what else could break?» можно делать бесконечно. Модель не понимает, в какой точке остановиться, и в результате либо недокапывает (если устала от длинного промта), либо перекапывает (если решила следовать букве).

Императивы на judgment calls. «Never ignore errors» звучит правильно, но в реальной жизни часть ошибок именно надо игнорировать. В этом же скилле — отдельная таблица из 60 правил auto-mute: какие паттерны автоматически считать ожидаемым поведением и не разбирать. Промт сам себе противоречит: одна секция говорит «никогда не игнорируй», другая — «вот 60 паттернов, которые надо игнорировать».

Переписал по новым правилам OpenAI:

### Bug fix outcome

Goal: production stays clean. Each fix addresses the root cause,
not symptoms. A clean fix is one where you can answer "why did
this happen?" in one sentence — without saying "external timeout"
or "works most of the time".

Stopping criteria: similar pattern checked, fix is committed,
related issues documented as separate Beads tasks. Don't expand
scope into refactoring unless explicitly asked.

50 слов вместо 134. Одна мысль про root cause — один раз. Outcome (что значит «чисто») вместо процесса (как именно копать). Явный stopping criteria. Отдельная фраза про границы — «не расширяй скоуп», чтобы модель не уезжала в рефакторинг соседних модулей.

Я специально проверил на двух моделях. Дал каждой реальную ошибку из логов — getaddrinfo EAI_AGAIN во время деплоя — и оба варианта промта. Короткий выиграл на обеих: и Opus 4.7, и GPT-5.5 корректно классифицировали это как infrastructure (DNS-резолюция падает на момент рестарта подов), не пытались чинить application-код, не предлагали рефакторинг. Длинный вариант на обеих моделях привёл к тому, что они дополнительно полезли в код вокруг DNS-вызовов — искать, что там можно «улучшить».

Это не строгое измерение. Это один прогон. Но направление совпадает с тем, что говорит гайд.

Эксперимент в Stitch, который можно повторить за пять минут

Хочу, чтобы вы убедились сами, без слепой веры мне или OpenAI. Самый быстрый способ — Google Stitch. Это инструмент для генерации UI-экранов по описанию, у него свой движок, и реакция на формулировку промта там видна почти моментально.

Возьмите два промта на одну и ту же задачу.

Промт А — жёсткий и подробный (примерно так пишет одна модель, когда её просишь сгенерировать промт для другой):

Создай экран онбординга для AI-приложения. Используй карточки 16:9
с тенью box-shadow: 0 4px 12px rgba(0,0,0,0.08). Заголовок 32px,
подзаголовок 18px, отступы 24px, межблочные 16px. Цвета: primary
#2563EB, secondary #F1F5F9, текст #0F172A. Кнопка CTA в правом
нижнем углу, hover state с увеличением тени. Анимация slide-in
300ms ease-out. Иконки из Lucide, размер 24px, цвет primary.
Прогресс-индикатор сверху, 4 шага.

Промт Б — смысловой и короткий:

Экран онбординга для AI-приложения. Должен ощущаться лёгким,
дружелюбным, без бюрократии. Цель — чтобы новичок захотел
дойти до конца за 30 секунд.

Прогоните оба в Stitch на одной и той же задаче. Сравните, что получилось.

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

Кстати, это работает не только в Stitch и не только с дизайном. Есть отдельный антипаттерн, который я только сейчас осознал и хочу проговорить отдельно. Если попросить модель написать промт для другой модели — она напишет ровно тип А. Подробный, технический, с императивами. Потому что её саму так учили: чем точнее — тем лучше. И этот промт потом получает другая модель и работает по нему хуже, чем работала бы по короткому, написанному человеком.

Я сейчас целенаправленно перестаю генерировать промты через модели. Промт пишу руками. Модель — исполняет.

А что говорит Anthropic про Claude

Гайд OpenAI — про GPT-5.5. Я в Claude Code сижу больше времени, чем в чём-либо другом. Вопрос: применимо ли?

Полез смотреть, что говорит Anthropic. У них есть курс по prompt engineering и набор «real world prompting» ноутбуков. Тон — другой. Anthropic не говорит «выкиньте инструкции». Anthropic говорит: используйте структуру, оборачивайте данные в XML-теги (<patient_record>, <email>, <thinking>), отделяйте инструкции от контекста, кладите длинные документы в начало промта, инструкции — в конец.

Но если посмотреть их примеры хороших промтов — ALWAYS/NEVER там нет. Их «улучшенный промт» для медицинских саммари — это outcome-описание: «нужны такие-то поля в таком-то порядке, обёрнутые в XML-теги». Не процесс. Описание ожидаемого результата плюс структура.

Это сходится с OpenAI в духе. Расходится в букве:

• OpenAI: outcome + constraints, минимум структуры, всё остальное модель решит сама.

• Anthropic: outcome + структура (XML-теги, чёткое разделение), модель решит сама внутри структуры.

В моём ежедневном опыте оба тезиса работают. Когда я переписывал свой агент code-reviewer (короткий, делегирует всё на skill) — поймал именно это: структура помогает, императивы вредят. Скилл был полностью на капс-инструкциях, переписал на outcome + XML-структуру (что входит, что выходит, какие критерии «хорошо»). Стало работать заметно лучше — и на Claude, и на GPT.

Самый честный ответ на вопрос «применимо ли»: да, применимо в духе. Принцип «не зажимайте модель в рамки» работает на обеих. Различие — в том, насколько структуру нужно эксплицитно прописать. На Claude чуть больше структуры (XML, разделители). На GPT-5.5 — чуть меньше, и больше доверия модели.

Нет, подождите, не «больше доверия» — это слишком расплывчато. Точнее: меньше попыток управлять процессом. На GPT-5.5 промт описывает «куда прийти и каких границ не пересекать». На Claude — «куда прийти, в какой структуре сложить ответ, и каких границ не пересекать».

И ещё одно наблюдение про передачу промтов между моделями. Если попросить Opus 4.7 написать промт для GPT-5.5 — Opus напишет очень структурированно, с разделами, XML-тегами, явными success criteria. Это избыточно для GPT-5.5, и GPT начинает вязнуть в структуре. Обратное тоже работает: GPT-5.5 пишет для Claude слишком сжато, без структуры, и Claude не понимает, где границы между context и task. Промты под конкретную модель пишу руками. Кросс-модельная генерация ломается.

Что меняю в orchestrator-kit прямо сейчас

Я в процессе. Не из позиции «всё уже переписал», а из позиции «увидел, начал чинить».

Что уже сделано: в скиллах для написания промтов добавил явное правило — не переусложняй промт. Когда я прошу модель сгенерировать новый скилл, она теперь не уходит в простыню инструкций, а старается описать через outcome.

Что в работе: переношу это в основные файлы памяти (CLAUDE.md, ~/.claude/CLAUDE.md). Это глобальный системный промт, он загружается в каждую сессию. Если модель там увидит «пиши outcome-промты, не процесс» — будет применять это ко всему, что генерирует.

Что в очереди: пройтись по самым жирным скиллам в моём kit. Текущий список:

• dzen-article — 758 строк, скилл для написания статей на Дзен

• process-logs — 663 строки (тот, на котором показывал диф)

• process-issues — 501 строка

• algorithmic-art — 404 строки

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

Где императивы оправданы

Чтобы не выглядело как евангелизм коротких промтов — отдельно про три категории, где императивы остаются.

Safety-критичные операции. У меня в kit есть агент dead-code-remover — удаляет неиспользуемый код. Там прямо написано: «CRITICAL SAFETY RULE: NEVER DELETE FILES AUTOMATICALLY. File removal requires MANUAL verification and is NEVER automated». Это true invariant. Удалить файл случайно — это не «качество немного просядет», это «потерянная работа без бэкапа». Императив здесь нужен, и я его не убираю.

Контракты и схемы. Если модель генерирует JSON-ответ для API, и схема жёстко задана — поле id всегда строка, status всегда из перечня — это не judgment, это технический контракт. Императив оправдан. Без него модель будет «творчески» интерпретировать схему, и через час вы получите 500-е на проде.

Детали, которые модель должна выполнить буквально. Например, имя файла миграции в формате YYYYMMDD_HHMMSS_description.sql — порядок применения определяется именно по таймстампу в начале, и любое отклонение сломает накат на новой среде. Это не «как лучше», это «должно быть так и не иначе, потому что миграционный фреймворк парсит имя». Императив — единственный надёжный способ.

Различие, которое я для себя вытянул: ALWAYS/NEVER — для invariants (нарушение приведёт к катастрофе или сломает контракт). Не для preferences (нам так больше нравится). Это, кстати, прямо соответствует тому, что пишет OpenAI: «Use rigid absolute rules for true invariants». Раньше я не отличал invariant от preference. Теперь буду.

Финал

Длинные промты с императивами на каждом шагу — это след времён, когда модели плохо держали контекст и нуждались в постоянных подсказках. Те модели ушли. Те промты — пора.

Не «выкидывайте всё подряд». А пересмотрите конкретно: где invariant, где preference, где outcome, где stopping condition. Я разбираю свои скиллы и агенты именно с этой рамкой. Будут результаты — напишу.

Канал, где я регулярно пишу про это: t.me/maslennikovigor. Прямой контакт: t.me/maslennikovig. Исходники моих инструментов: github.com/maslennikov-ig/template-bridge.