TL;DR
ChatGPT и Claude работают хуже, когда промпт перегружен структурой: этапами, правилами, требованиями к формату и процессу одновременно. Исследователи называют это harness-complexity paradox — парадокс сложности инструкций. Чем подробнее инструкция для чат-модели, тем сильнее она «съезжает» в объяснения вместо чистого вывода.
Главная боль: просишь модель дать JSON или таблицу, добавляешь «для надёжности» шаги выполнения и критерии проверки — получаешь красивый рассказ о том, как она всё сделала, вместо самого результата. Модель не игнорирует задачу — она понимает её, но конкурирующие инструкции (объясни процесс + выдай формат) тянут в разные стороны, и побеждает проза.
Reasoning-модели (o1, Claude в режиме расширенного мышления) устроены иначе: им нужна больше структуры — чёткие критерии успеха сокращают не только ошибки, но и время ответа. Разные типы моделей требуют противоположных подходов.
Схема метода
Это не пошаговая техника, а диагностическая матрица — два измерения определяют правильный стиль промпта:
ТИП МОДЕЛИ × ТИП ЗАДАЧИ → СТИЛЬ ПРОМПТА
[Чат-модель] × [нужен чистый формат: JSON, таблица, список]
→ МИНИМАЛЬНЫЙ промпт: прямо скажи что нужно, без шагов и процесса
[Чат-модель] × [координация нескольких файлов / многошаговые операции]
→ УМЕРЕННЫЙ промпт: 3-4 шага, допустима структура
[Reasoning-модель] × [любая сложная задача]
→ СТРОГИЙ промпт: явные этапы + критерии успеха + что считается верным
[Слабая модель] × [любая задача]
→ УМЕРЕННЫЙ промпт: нужен список разрешённых действий, но не перегружай
Всё работает в одном промпте — запрос не делится на отдельные сообщения.
Пример применения
Задача: Ты — основатель небольшого SaaS-сервиса для малого бизнеса. Хочешь попросить ChatGPT (GPT-4o) проанализировать три конкурента и вернуть данные в виде таблицы: название, цена, ключевые фичи, слабое место.
❌ Промпт, который ломает результат:
Ты — эксперт по конкурентному анализу. Выполни следующие шаги:
Шаг 1. Изучи информацию о конкурентах ниже.
Шаг 2. Составь план анализа.
Шаг 3. Проанализируй каждого конкурента по критериям.
Шаг 4. Проверь полноту анализа.
Шаг 5. Сформируй финальный отчёт в виде таблицы.
Критерии: цена, ключевые фичи, слабое место.
Убедись, что анализ полный и обоснованный.
[данные о конкурентах]
✅ Промпт, который работает:
Вот данные о трёх конкурентах: [данные]
Верни таблицу в формате:
| Название | Цена | Ключевые фичи | Слабое место |
Только таблица, без пояснений.
Результат: Прямой промпт вернёт чистую таблицу без вводных, объяснений и «подведения итогов». Многошаговый промпт с высокой вероятностью вернёт тот же контент, обёрнутый в абзацы рассуждений — модель будет «отчитываться» о каждом шаге.
Почему это работает
Слабость чат-моделей: У них нет жёсткого «режима вывода» — они генерируют следующий токен, ориентируясь на весь предыдущий текст. Когда промпт длинный и процессный, паттерн генерации смещается в сторону объяснений. Инструкция «выполни шаг 2, затем шаг 3» активирует паттерн «рассказывать о действиях», а не «выдавать результат».
Сильная сторона чат-моделей: Они отлично понимают прямые, конкретные указания. «Верни JSON с полями X и Y — только JSON» — это однозначный сигнал. Нет конкуренции между «объясни процесс» и «дай формат».
Reasoning-модели работают иначе: Они проводят внутреннее «обдумывание» до генерации ответа. Чёткие критерии успеха дают этому внутреннему процессу ориентиры — модель знает, что считать завершённым. Без ориентиров она блуждает дольше и делает больше ошибок. Парадокс: строгая инструкция для o1 сокращает время ответа — модель тратит меньше внутренних итераций.
Рычаги управления:
| Что менять | Эффект |
|---|---|
| Убрать «шаги выполнения» | Меньше прозы, чище формат |
| Добавить «только результат, без объяснений» | Снижает «отчётность» |
| Для reasoning-модели: добавить «успешный результат выглядит так: [пример]» | Уменьшает время и ошибки |
| Перенести требования к формату в конец промпта отдельным блоком | Снижает конфликт инструкций |
Шаблон промпта
Для чат-модели (GPT-4o, Claude) + задачи с нужным форматом:
{контекст и данные}
Верни {нужный формат: таблицу / JSON / список} с полями: {поля}.
Только {формат}, без пояснений.
Для reasoning-модели (o1, Claude extended thinking) + сложная задача:
Задача: {задача}
Данные: {данные}
Этапы:
1. {этап 1}
2. {этап 2}
3. {этап 3}
Успешный результат: {конкретное описание что должно получиться}.
Формат вывода: {формат}.
Диагностический промпт — если не знаешь какой стиль выбрать:
Мне нужно {описание задачи}.
Я буду использовать {название модели}.
Какой стиль промпта даст лучший результат:
минимальный (прямой запрос), умеренный (3-4 шага) или строгий (этапы + критерии)?
Объясни коротко почему.
🚀 Быстрый старт — вставь в чат:
Помоги мне написать промпт под конкретную задачу.
Я использую [модель — GPT-4o / Claude / o1].
Мне нужно получить [что именно — JSON / таблицу / анализ / текст].
Задача: [твоя задача]
Вставь шаблон выше и адаптируй.
LLM спросит о типе нужного вывода и модели — потому что именно от этих двух факторов зависит правильный стиль промпта.
Ограничения
⚠️ Один представитель на тип модели: Каждый «класс» (чат, reasoning, слабая) представлен одной моделью. Нельзя уверенно сказать «все чат-модели» — это наблюдение по конкретным моделям.
⚠️ Только задачи с кодом и файлами: Бенчмарк — агентские задачи с изменением файлов в репозитории. Для чисто текстовых задач закономерности могут отличаться.
⚠️ Парадокс специфичен для формат-чувствительных задач: Структурное редактирование и «починка» работают хорошо при любой структуре промпта. Проблема — именно задачи с нужным форматом вывода (JSON, схема).
⚠️ Результаты предварительные: Авторы сами предупреждают — нужно минимум 3 повторения для статистической надёжности. Часть результатов — с одним прогоном.
Как исследовали
Идея была простой: взять 6 разных моделей — от топовых API-моделей до маленьких локальных — и прогнать каждую на одних и тех же 24 задачах, но с тремя версиями промпта: минимальной, средней и строгой. 432 прогона всего. Задачи — агентские: модели читали файлы в git-репозитории и вносили изменения. Верификатор просто смотрел на git diff — изменился ли нужный файл так, как надо. Никакого субъективного суждения.
Самый неожиданный результат — Gemma4 с 2 миллиардами параметров показала такую же стабильность как GPT-OSS-120B с 60-кратно большим количеством параметров. Это разрушает интуицию «больше параметров = лучше». Оказалось, что качество инструкционного тюнинга важнее размера — модель обучена следовать инструкциям, и это важнее чем просто «знать много».
Ещё один противоречивый результат: строгий промпт для reasoning-модели не только поднял точность, но и снизил задержку на 34%. Чёткие критерии буквально «укоротили» внутренние размышления модели.
Оригинал из исследования
Три уровня harness (промпта-обёртки):
Light: A two-line prompt: role statement plus the raw task instruction.
No format specification, no scope constraint, no verification procedure.
Balanced: Adds a four-step process template (plan, execute, check, respond)
and lists the allowed files. No schema or verification spec.
Strict: Adds six explicit stages (preflight / plan / execute / verify / recover / report),
an allowed-file list, explicit success criteria, a verification specification,
and instructions to express file changes using the <<>> marker.
Контекст: Это три версии одного и того же задания — минимальная, средняя, максимально структурированная. Разница только в обёртке вокруг задачи, не в самой задаче.
Адаптации и экстраполяции
💡 Диагностика по типу ошибки — что пошло не так:
Исследование даёт таксономию ошибок, которую можно применить напрямую. Если модель ошиблась — посмотри что именно:
| Ошибка | Что это значит | Что делать |
|---|---|---|
| Получил прозу вместо формата | Промпт конкурирует сам с собой | Убери шаги, оставь только формат |
| Модель изменила не тот файл / раздел | Промпт слишком лёгкий — нет ограничений | Добавь явный список допустимых действий |
| Правильная структура, неверные данные | Проблема понимания, не формата | Пересмотри задачу, не структуру промпта |
🔧 Техника: разделяй задачу и формат → лучше и то и другое
Одна находка из связанного исследования (Deng et al., 2025), которую авторы цитируют как объяснение парадокса: задача и требования к формату вывода конкурируют как частично противоречащие цели.
Попробуй разделить их в промпте:
Задача: {задача}
[Реши задачу]
---
Теперь оформи результат:
Формат: {нужный формат}
Поля: {поля}
Только формат, без пояснений.
Разделитель --- создаёт смысловую паузу между «думать» и «оформить». Это снижает конфликт между prose-режимом и format-режимом.
Ресурсы
- Статья: "It's Not the Capability: Harness Sensitivity Is Non-Monotone Across LLM Agent Tiers"
- Автор: Yong-eun Cho, KailosLab, Seoul, Republic of Korea — kevin@kailoslab.com
- Связанные работы: Sclar et al. (2024) — изменения форматирования промпта дают до 76 пунктов разницы; Deng et al. (2025) — разделение задачи и форматирования улучшает оба; Khan (2025) — более простые промпты обгоняют engineered для способных моделей