Месяц назад я опубликовал на Хабре статью про то, как сжал 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 outcomeGoal: production stays clean. Each fix addresses the root cause,not symptoms. A clean fix is one where you can answer "why didthis 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 expandscope 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-in300ms 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.
ссылка на оригинал статьи https://habr.com/ru/articles/1031498/