TL;DR
Когда просишь AI починить сложную проблему, он почти всегда находит правильный файл и правильный симптом — но лечит не то место. Исследователи проанализировали 9374 попыток AI-агентов решить реальные баги и обнаружили: провалы происходят не потому, что задача сложная, а потому что агент атакует симптом вместо корня. 12 задач с однострочными патчами не решил ни один из 19 агентов — при том что люди оценили их как "15 минут работы".
Главная находка: длина ответа — ложный сигнал качества. Два агента делают по 36-37 шагов, один решает задачу, второй — нет. Разница не в количестве шагов, а в их порядке: успешный сначала понимает, потом правит, потом проверяет. Неуспешный сразу лезет редактировать, накапливает ошибки и не запускает тесты вообще.
Это превращается в конкретную технику для чата: принудительный workflow "понять → воспроизвести → найти корень → исправить → проверить" в промпте не даёт AI срезать углы и прыгать к "очевидному" решению.
Схема метода
ШАГ 1: ПОНЯТЬ → собрать контекст, описать что именно происходит
(один промпт, всё внутри)
ШАГ 2: ВОСПРОИЗВЕСТИ → механизм возникновения шаг за шагом
(AI объясняет цепочку событий, не решение)
ШАГ 3: РАЗДЕЛИТЬ → симптом (что видим) vs корень (откуда берётся)
(явный запрет атаковать симптом)
ШАГ 4: ИСПРАВИТЬ → точечное решение только для корневой причины
ШАГ 5: ПРОВЕРИТЬ → как это решение устраняет именно причину, не симптом
Все шаги выполняются в одном промпте — AI проходит их по порядку.
Пример применения
Задача: Ты ведёшь Telegram-канал с платной подпиской. Бот перестал принимать платежи через ЮKassa — пользователи жалуются, что кнопка "Оплатить" зависает. Команда разработчика говорит "всё работает на нашей стороне".
Промпт:
Помоги разобраться в проблеме. Не предлагай решение сразу — пройди шаги по порядку.
Проблема: в Telegram-боте перестала работать оплата через ЮKassa.
Пользователь нажимает кнопку "Оплатить" — бот зависает, платёж не проходит.
Разработчик говорит "у нас всё ок". ЮKassa говорит "смотрите у себя".
Проблема началась 3 дня назад.
ШАГ 1 — ПОНЯТЬ:
Задай мне 3-5 уточняющих вопроса, чтобы полностью собрать картину.
Не угадывай — спрашивай.
ШАГ 2 — ВОСПРОИЗВЕСТИ:
После моих ответов опиши механизм проблемы шаг за шагом:
что происходит от нажатия кнопки до зависания.
ШАГ 3 — РАЗДЕЛИТЬ:
Явно укажи:
- Симптом (что мы видим снаружи)
- Корневая причина (где именно ломается цепочка)
Не атакуй симптом.
ШАГ 4 — ИСПРАВИТЬ:
Предложи решение только для корневой причины.
ШАГ 5 — ПРОВЕРИТЬ:
Объясни, как это решение устраняет именно причину, а не маскирует симптом.
Результат: Модель сначала задаст вопросы — например, спросит что изменилось 3 дня назад, есть ли логи ошибок, какая версия библиотеки ЮKassa. После ответов явно пропишет цепочку: где именно рвётся передача токена или истекает webhook. В ШАГ 3 разделит "зависает кнопка" (симптом) и "Telegram не получает ответ от сервера за 30 секунд" (причина). Решение будет точечным — не "перепиши бота", а конкретное место в цепочке.
Почему это работает
AI склонен срезать углы. Когда видит знакомый паттерн — сразу генерирует "очевидное" решение. Это работает на простых задачах, но на сложных приводит к тому что исследователи назвали architectural reasoning gap — агент правит симптом там где видит его, а не там где проблема реально живёт. В примере с matplotlib агент нашёл правильный файл, понял баг с DPI — и всё равно исправил не то место, потому что прыгнул к первому подходящему решению.
Модель хорошо следует явным инструкциям о порядке. Если структура "сначала — потом — только потом" зашита в промпт, AI её держится. Это не "думать глубже" — это убрать возможность срезать угол.
Явное разделение симптома и корня — ключевой шаг. Без него AI автоматически работает на уровне симптома: видит зависание — лечит зависание. С явным ШАГом 3 модель вынуждена пройти на уровень глубже и найти откуда симптом вообще берётся.
Рычаги управления промптом: - Убери ШАГ 2 (воспроизведение) → быстрее, но теряешь цепочку причинно-следственных связей - В ШАГ 1 замени "задай вопросы" на "перечисли что тебе нужно знать" → AI даст список, потом ты отвечаешь разом - Добавь между ШАГ 3 и 4: "Предложи 2 гипотезы о корне, выбери более вероятную" → защита от уверенного неправильного вывода - Для технических задач добавь в ШАГ 4: "Укажи одно минимальное изменение" → блокирует тягу к крупным переписываниям
Шаблон промпта
Помоги разобраться в проблеме. Не предлагай решение сразу — пройди шаги по порядку.
Проблема: {описание проблемы — что происходит, когда началось,
кто что говорит}
ШАГ 1 — ПОНЯТЬ:
Задай мне 3-5 уточняющих вопроса, чтобы полностью собрать картину ситуации.
Не угадывай — спрашивай.
ШАГ 2 — ВОСПРОИЗВЕСТИ:
После моих ответов опиши механизм возникновения проблемы шаг за шагом:
что происходит от {начальная точка} до {конечный сбой}.
ШАГ 3 — РАЗДЕЛИТЬ:
Явно укажи:
- Симптом (что видим снаружи)
- Корневая причина (где именно ломается логика)
Предупреждение: не атакуй симптом.
ШАГ 4 — ИСПРАВИТЬ:
Предложи {конкретное действие / решение / изменение} только для корневой причины.
ШАГ 5 — ПРОВЕРИТЬ:
Объясни, как это решение устраняет именно причину, а не маскирует симптом.
Плейсхолдеры:
- {описание проблемы} — что происходит, факты, не интерпретации
- {начальная точка} — откуда начинается цепочка (нажатие кнопки, запуск процесса)
- {конечный сбой} — что видите в итоге (зависание, ошибка, неверный результат)
- {конкретное действие} — решение / план действий / изменение в тексте / причина провала
🚀 Быстрый старт — вставь в чат:
Вот шаблон для разбора проблем по корневой причине.
Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про начальную и конечную точки проблемы, контекст ситуации — потому что без этого не может правильно заполнить ШАГ 2 (воспроизведение цепочки). Она возьмёт структуру из шаблона и адаптирует под твою задачу.
Ограничения
⚠️ Простые задачи: Для очевидных вопросов ("какой тариф выгоднее") этот workflow избыточен — лишние шаги без пользы.
⚠️ Архитектурный потолок: Даже с правильным промптом AI не знает специфики твоей системы. Если проблема требует редких domain-знаний (как TeX math-mode или pickle-протокол Python), никакая структура не поможет — AI уверенно пойдёт в неверном направлении.
⚠️ Субъективные проблемы: Метод работает там где есть объективный "корень" — логика, процесс, цепочка событий. Для размытых задач ("почему контент не заходит") ШАГ 3 будет натянутым.
⚠️ Длина ответа: Пять шагов с вопросами — это длинный диалог. Если нужен быстрый ответ — оставь только ШАГ 3 и 4.
Как исследовали
Команда взяла публичные данные с лидерборда SWE-bench — 9374 записей того, как AI-агенты решали реальные баги из 12 open-source Python-проектов (Django, matplotlib, sympy). Каждый из 19 агентов пробовал все 500 задач, что позволило сравнивать одну и ту же задачу у разных агентов — устранив главную ловушку предыдущих исследований, где за "агент проваливается на длинных задачах" стояло "агент берётся за сложные задачи, которые и длиннее, и труднее".
Исследовательский ход с "простыми" незакрытыми задачами — настоящая находка. Они выбрали 12 задач с патчами в 2-8 строк, которые люди оценили как "15 минут работы", — и показали, что все 19 агентов проваливаются. Затем вручную прошли по траекториям лучших агентов и в 10 из 12 случаев нашли один и тот же паттерн: агент находит правильный файл, понимает симптом, но редактирует не тот архитектурный слой. В matplotlib-задаче агент починил слой отображения на экране, хотя проблема была в слое сериализации — функции __getstate__, которую Python вызывает при pickle. Агент нигде не "ошибся" в обычном смысле — он просто не понял, что симптом и причина живут в разных местах.
Адаптации и экстраполяции
1. Адаптация: Два конкурирующих объяснения корня
🔧 Добавь в ШАГ 3 запрос на две гипотезы → защита от ложной уверенности
ШАГ 3 — РАЗДЕЛИТЬ:
Предложи две конкурирующие гипотезы о корневой причине.
Для каждой укажи: что проверить, чтобы подтвердить или опровергнуть.
Выбери более вероятную и объясни почему.
Симулирует то, что исследование назвало "агент, который воспроизводит баг перед правкой" — снижает шанс уверенного неправильного ответа.
2. Экстраполяция: Применение для анализа провалов, не только технических проблем
Принцип "симптом vs корень" работает не только для кода. Пример — разбор почему упали продажи:
Проблема: в ноябре продажи онлайн-курса упали на 40% по сравнению с октябрём.
Рекламный бюджет тот же, охваты похожие.
ШАГ 1 — ПОНЯТЬ:
Задай 3-5 вопроса о воронке: трафик → лиды → продажи.
ШАГ 2 — ВОСПРОИЗВЕСТИ:
Опиши цепочку от перехода на сайт до решения не купить.
ШАГ 3 — РАЗДЕЛИТЬ:
Симптом: меньше продаж.
Корень: где именно ломается конверсия — трафик, лендинг, оффер, цена, доверие?
Предложи две гипотезы с разными корнями.
ШАГ 4 — ИСПРАВИТЬ:
Точечное действие для более вероятного корня.
ШАГ 5 — ПРОВЕРИТЬ:
Какую метрику смотреть, чтобы убедиться что это сработало?
Ресурсы
Beyond Resolution Rates: Behavioral Drivers of Coding Agent Success and Failure Tural Mehtiyev, Wesley Assunção — North Carolina State University, Raleigh, NC, USA Preprint, 2026
Датасет: SWE-bench Verified — swebench.com Фреймворки в исследовании: SWE-agent, OpenHands, AutoCodeRover, Trae, Skywork, CodeSweep, EPAM-AI, SAGE, Sonar