PACE-Bench: почему агент «закончил», а ТЗ не выполнено, и как проверять его работу чек-листом критериев

ШАГ 0 (отдельный запрос): ТЗ → список атомарных критериев
       (поведение, допустимые альтернативы, вес) → ЗАМОРОЗИТЬ
ШАГ 1: Жёсткие нарушения явных ограничений → Missing
       (если не доказано нарушение — не решать, передать дальше)
ШАГ 2: Для каждого критерия найти код + связи, 
       из-за которых поведение достижимо → пакет доказательств
ШАГ 3: По каждому критерию вердикт с цитатой:
       Covered / Partial / Missing (новых требований не добавлять)
ШАГ 4: Итог по правилу: Covered=1, Partial=0.5, Missing=0,
       взвешенное среднее. «Готово» = балл ≥ 95 И ни одного Missing

Шаги 1–4 можно уместить в один промпт. Шаг 0 лучше сделать отдельным запросом и проверить критерии глазами.

Задача: Вы руководите разработкой маркетплейса и просите Claude Code добавить программу лояльности вроде «Яндекс Плюса»: списание баллов при оплате заказа. Агент отчитался «готово». Проверять 1 200 строк диффа вручную нет времени, а просто спросить «всё ли сделано?» бесполезно.

Промпт:

Ты — строгий приёмщик работы. Проверь реализацию по ТЗ.

<ТЗ>
Программа лояльности «Баллы»:
1. При оформлении заказа пользователь может списать баллы, 1 балл = 1 ₽.
2. Списать можно не более 30% от суммы заказа.
3. Баллы списываются только после успешной оплаты.
4. При отмене заказа списанные баллы возвращаются.
5. В истории заказов отображается, сколько баллов списано.


<Критерии>
C1 (вес 3): расчёт скидки по курсу 1 балл = 1 ₽ при оформлении.
C2 (вес 3): лимит 30% от суммы заказа; превышение отклоняется или обрезается.
C3 (вес 3, неявный): списание происходит после подтверждения оплаты, а не при создании заказа.
C4 (вес 2): возврат баллов при отмене заказа.
C5 (вес 1): поле «списано баллов» видно в истории заказов.
C6 (вес 2, интеграция): новый обработчик/сервис зарегистрирован и вызывается из потока оформления заказа.
Допустимые альтернативы: любое имя методов и структура классов, если поведение то же.


<Дифф>
{вставить дифф или список изменённых файлов с кодом}


Правила:
1. Критерии менять и добавлять нельзя.
2. По каждому критерию найди в диффе код, который реализует поведение, и код, который делает его достижимым (вызов, регистрация, маршрут, конфигурация). Процитируй оба.
3. Наличие имени метода — не доказательство. Пустое тело, заглушка или код, который нигде не вызывается — это Partial или Missing.
4. Вердикт: Covered (поведение реализовано и достижимо), Partial (реализовано, но неполно или не подключено), Missing (нет или явно нарушено).
5. Если доказательств нет, пиши «не найдено», не додумывай.
6. Итог: Covered=1, Partial=0.5, Missing=0. Посчитай взвешенное среднее ×100. Работа принята, только если балл ≥ 95 и нет ни одного Missing.

Формат ответа: таблица «критерий — вердикт — цитата — чего не хватает», затем расчёт балла и вывод «принято / не принято».

Результат: Модель выдаст таблицу по шести критериям. В каждой строке будет вердикт и цитата кода. Если обработчик написан, но не вызывается из потока заказа, критерий C6 получит Partial или Missing, а не «ок». Затем идёт арифметика взвешенного балла и вывод «принято / не принято». Вы увидите конкретные дыры, а не общее «выглядит хорошо».

Слабость. Если попросить модель «оцени, выполнено ли ТЗ», она смотрит на диф целиком и поддаётся поверхностным совпадениям: имена методов, похожие названия классов. Пустая заглушка с правильным именем получает частичный кредит. Вердикт «на глаз» нестабилен и зависит от того, как подан материал. Без заранее зафиксированных критериев согласие с экспертами в исследовании упало до 70%.

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

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

Рычаги управления: - Веса критериев. Поднимай вес для бизнес-критичных условий (платежи, права доступа), снижай для косметики. - Порог «готово». Строже: 100 и ни одного Partial. Мягче: 90. - Список допустимых альтернатив. Чем подробнее, тем меньше ложных «не принято» из-за другой реализации. - Критерий интеграции. Добавляй отдельным пунктом для каждой новой сущности: «зарегистрирована и вызывается». Именно здесь агенты теряют больше всего. - Неявные критерии. Помечай их отдельно: именно они сложнее всего для агента, и им стоит уделять больше внимания.

Ты — строгий приёмщик работы. Проверь реализацию по ТЗ.

<ТЗ>
{текст_ТЗ}


<Критерии>
{id} (вес {1-3}, {явный/неявный/интеграция}): {одно проверяемое поведение}
...
Допустимые альтернативы: {что считать эквивалентной реализацией}


<Результат_работы>
{дифф_или_код_или_описание_изменений}


Правила:
1. Критерии менять и добавлять нельзя.
2. По каждому критерию найди и процитируй: (а) код, реализующий поведение; (б) код, делающий его достижимым (вызов, регистрация, маршрут, настройка).
3. Имя метода или файла — не доказательство. Пустое тело, заглушка, код без вызова = Partial или Missing.
4. Covered = реализовано и достижимо. Partial = реализовано неполно или не подключено. Missing = нет или явно нарушено.
5. Нет доказательств — пиши «не найдено».
6. Балл = взвешенное среднее (Covered=1, Partial=0.5, Missing=0) ×100.
   Принято, только если балл ≥ {порог} и нет ни одного Missing.

Формат: таблица «критерий — вердикт — цитата — чего не хватает», затем расчёт и вывод.

Что подставлять: {текст_ТЗ} — исходное ТЗ без правок. {id} — C1, C2… Критерии пишите по одному поведению на строку. {порог} — 95 по умолчанию. Результат работы — то, что сделал агент.

🚀 Быстрый старт — вставь в чат:

Вот шаблон приёмки работы агента по ТЗ. Мой случай: {опиши задачу и что сделал агент}.
Сначала разбей моё ТЗ на атомарные критерии (одно поведение на критерий), 
отметь неявные требования и пункты интеграции, предложи веса. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит, что в ТЗ сказано явно, а что подразумевается, и какие части системы должны быть связаны с новой функцией. Это нужно, потому что качество проверки целиком зависит от критериев. Модель возьмёт структуру из шаблона и соберёт критерии под вашу задачу.

⚠️ Исследован бенчмарк, а не готовый приём: авторы проверяли судью с поиском по графу вызовов и фиксированными правилами. В обычном чате вы получите упрощённую версию. Её точность в этой статье не измерялась.

⚠️ Заглушки всё ещё проходят частично: даже полный пайплайн дал небольшой частичный кредит коду с правильными именами и пустыми телами. Поэтому правило про пустые тела нужно писать явно и просматривать Partial глазами.

⚠️ Критерии нужно проверять руками: в исследовании их проверяли доменные эксперты. Если модель сама разобьёт ТЗ плохо, судья честно проверит неправильный список.

⚠️ Выводы про то, что прописать в инструкции агенту, не проверены напрямую: статья показывает, где агенты ломаются: интеграция, недоделанность, отсутствие проверки после правки. Но проверенного лечения инструкциями в доступной части текста нет. Это гипотеза, её надо пробовать.

⚠️ Связь «сигнал → провал» — совпадение, а не доказанная причина: отсутствие проверки после правки часто идёт рядом с недоделками, но авторы сами пишут, что это не доказывает причину.

⚠️ Узкий материал: задачи из одной корпоративной среды (Java и TypeScript, игры, акции, маркетплейс). Для других стеков закономерности вероятны, но не доказаны.

⚠️ Текст статьи обрезан: разделы про статические знания в промптах и про улучшение оболочки агента здесь не видны. Выводы по ним опираются только на краткое резюме.

Команда Alibaba (Taobao и Tmall) взяла 43 реальные задачи из рабочей разработки. В каждой был живой репозиторий, диалог с пользователем и принятый патч. Из этого собрали единое ТЗ и разбили его на 750 атомарных критериев, которые проверили доменные эксперты. Медианная задача: около 1 500 изменённых строк в 15 файлах.

Дальше прогнали 11 конфигураций «модель + оболочка агента». Восемь моделей работали в одной оболочке, две пары ещё и в собственных. Для оценки использовали трёхслойного судью: жёсткие проверки, поиск связей по графу вызовов, смысловой вердикт с цитатой.

Судью проверяли так: три аннотатора вручную пересмотрели все 750 вердиктов. Согласие составило 95,2%. Обычный судья без структуры дал около 77%. Без критериев-контракта согласие падало до 70%, без агрегации по правилу — до 76%. Эталонные патчи получили около 98 из 100, а пустые и чужие патчи — ноль. Так показали, что судья не ведётся на поверхностные совпадения.

Удивило: лучшая модель полностью закрыла лишь 6 из 43 задач, хотя средний балл был около 78. Высокий средний балл скрывает недоделанные функции. Сложность задачи зависела от доли неявных требований: баллы падали с 75 до 57 по мере роста этой доли. А объём ТЗ и число файлов почти не влияли.

Ещё один вывод: сам агент при трёх запусках на одной задаче даёт заметно разные результаты. Оценка судьи при повторах стабильнее примерно в 3,7 раза. Один удачный запуск мало что говорит о надёжности.

🔧 Техника: добавить «определение готовности» в файл инструкций агента → закрыть самые частые провалы

Это не метод статьи, а гипотеза из её диагностики: основные потери идут от недоделок, неподключённых компонентов и отсутствия проверки после последней правки. Для CLAUDE.md или AGENTS.md:

## Определение «готово»
Перед тем как написать «готово», по каждому пункту ТЗ:
1. Покажи, где реализовано поведение (файл, функция).
2. Покажи, где оно подключено: вызов, регистрация, маршрут, конфиг.
3. Убедись, что нет пустых тел, заглушек и TODO.
4. Явно перечисли неявные требования, которые ты вывел из смысла ТЗ.
5. После ПОСЛЕДНЕЙ правки запусти проверку (тесты или сборку) и приведи результат.
Если что-то не сделано — напиши «не сделано», а не «готово».

🔧 Техника: вынести неявные требования до начала работы → снизить главный фактор сложности

Перед задачей агенту: «Выпиши все требования, которые в ТЗ не сказаны прямо, но вытекают из смысла. Дай мне подтвердить список». Сложность задач росла именно с долей неявного, и человек проверит такой список дешевле, чем переписывание кода.

Комбинация: сначала запрос с неявными требованиями, потом их критерии в судью из шаблона, потом «определение готово» в инструкциях агента. Получается петля от ТЗ до приёмки.

• Работа: When Coding Agents Outpace Review: Evaluating PRD-Driven Development in Mature Enterprise Repositories (PACE-Bench)
• Код: https://github.com/TianqiLiu1/PACE-Bench
• Авторы: Tianqi Liu, Yandong Guan, Songze Li, Wenkai Wang, Gang Yu, Chengfei Lv
• Организации: Zhejiang University; Alibaba Taobao & Tmall Group
• Связанные работы: OpenHands (оболочка агента), Agent-as-a-Judge (Zhuge et al., 2025), SWE-bench, DevEval, FeatureBench