Петли проверки в Claude Code: таблица бенча, чек-лист Stop hook и источники

TL;DR

Рекомендация самой Anthropic верна по духу: модель, у которой есть петля обратной связи, выдаёт работу лучше. Проблема в том, кто эту петлю запускает. В 116 прогонах встроенный /verify вернул PASS 24 раза из 24, включая правку, которая нарушала заявленное требование.
Модель, проверяющая собственную правку, делит с ней одно слепое пятно. Haiku 4.5 пропустил один и тот же случай с уникальным полем в 11 прогонах из 11, во всех конфигурациях с той же моделью, а его собственный /verify поставил галочку рядом с неверным случаем.
На Opus 5.5 /verify обошёлся в 2.5 раза дороже ($0.96 против $0.39) и не изменил ни одного результата. Обычный Opus справился в 12 прогонах из 12 и сам запустил набор тестов в 11 из них.
Проектный skill для модели необязателен: он сработал в 10 прогонах из 24, на Haiku в 0 из 6. Stop hook срабатывал в каждом прогоне, примерно за +20% к цене на Opus.
Проверка, которая сработала, пришла не от автора: тот же /verify, запущенный на Opus, вынес FAIL 3 раза из 3 на правку Haiku и назвал баг. Подключённый как Stop hook, он заставил Haiku починить баг 3 раза из 3, по $1.36 за задачу против $0.76, когда Opus пишет задачу сам.
Берите это: Stop hook для детерминированной части, верификатор, который не является автором, для части, требующей суждения, и никакого /verify на Opus для чётко поставленных задач.

Что говорят измерения

Утверждение Anthropic: "If Claude has that feedback loop, it will 2-3x the quality of the final result." s4 Блог превращает его в рабочий процесс внедрения из 5 шагов: выберите самую частую ручную проверку, попробуйте встроенный /verify, опишите процедуру простым языком как skill, сделайте её детерминированной, затем перенесите в CI. s1 Начиная с v2.1.215, "Claude no longer runs the /verify and /code-review skills on its own; invoke them with /verify or /code-review when you want them." s3

Отчёты из практики о том, что проверка заявлена, но не выполнена. Issue #96416: вердикт ревью с 19 замечаниями, из которых проверено 5, и всё равно выдано "accept as-is". s6 Issue #97039: заявление "held up" после частичных проверок, несмотря на загруженный чек-лист. s7 "build passes" и "production-ready" это разные планки, и каждый промах стоит 2-3 раундов повторных промптов. s8

Наш бенч проверял каждое "done" скрытыми приёмочными тестами, которых агент никогда не видел. 112 прогонов задач + 4 кросс-модельных прогона /verify = 116 прогонов, $66.29 в пересчёте на API. Ложных "done": 12 из 112, из них 11 у Haiku на T6 во всех конфигурациях от A до E и 1 у Sonnet на T6 в конфигурации со skill, где его собственные новые тесты падали, а skill так и не сработал. s1

Встроенный /verify написал Verdict: PASS в 24 прогонах из 24 на трёх моделях (23 разбираемых, 1 пасс без метки), включая сломанный T6 у Haiku. На Opus он стоил $0.96 против $0.39 без него (2.5x) и 125 s против 75 s; ни один результат он не изменил. s3

Проектный skill, написанный по 5-шаговому процессу, был вызван в 10 прогонах из 24: Opus 8/12, Sonnet 2/6, Haiku 0/6. Stop hook срабатывал в каждом прогоне, $0.47 против $0.39 на Opus (+20 %). s19

Слепое пятно это одно требование, T6 req 4: один update, который задаёт нескольким найденным документам одно и то же уникальное значение, должен выбросить DuplicateKeyError. Haiku пропустил его в 11 прогонах из 11, во всех конфигурациях (plain, /verify, skill, hook, tests first). Собственный /verify Haiku проверил "обновить один документ на email другого" и ни разу не попробовал один update, затрагивающий несколько документов. Правило "тесты сначала" не помогло: 3/3 всё равно пропускают req 4, а один ещё и сломал req 3. s1

Та же правка Haiku, /verify запущен другой моделью: Sonnet сказал PASS (1/1), Opus сказал FAIL 3/3, и каждый раз называл один и тот же случай, один update, записывающий то же значение в несколько документов, по $0.39-$0.47 за проверку. Как Stop hook на Haiku (конфигурация F) верификатор на Opus добился исправления бага в 3 прогонах из 3; все три упёрлись в лимит 60 turn при исправлении, в среднем $1.36 за прогон T6 с учётом верификатора, против $0.76 у Opus, пишущего T6 в одиночку, с 0 ложных "done". s19

Измерения

Стенд: Claude Code 2.1.283 headless (claude -p), изолированный каталог конфигурации, один и тот же промпт на задачу, лимит 60 turn. Репозиторий: msiemens/tinydb @ 18d73a1 (Python, 226 тестов). Шесть запросов на фичи T1-T6, в каждом по 5 заявленных требований (T5: 6). Скрытые приёмочные тесты, по одному на каждое заявленное требование и никогда не показываемые агенту, оценивают каждый прогон; собственный набор тестов репозитория тоже запускается. Ложное "done" это прогон, завершившийся заявлением о готовности, пока скрытый тест или набор тестов репозитория падает.

Конфигурации: A plain (только запрос); B /verify (A, затем встроенный /verify вторым turn); C verify skill (проектный skill, который модель может вызвать сама, написанный по 5-шаговому процессу); D Stop hook (prove-it.py: блокирует остановку, пока набор тестов красный, и блокирует первую остановку, требуя по одной строке доказательства на каждое требование); E tests first (правило в CLAUDE.md: падающий тест на каждое требование до любого кода); F Opus verifier hook (claude -p /verify --model opus на правку, блокирует при вердикте не PASS, максимум 2 раунда).

модель	конфигурация	прогонов	ложных done	ср. цена	ср. turns	ср. время
Opus 5.5	A plain	12	0	$0.39	16.6	75 s
Opus 5.5	B /verify	12	0	$0.96	22.3	125 s
Opus 5.5	C skill	12	0	$0.43	19.5	80 s
Opus 5.5	D hook	12	0	$0.47	19.8	94 s
Opus 5.5	E tests first	2 (T6)	0	$0.64	18.5	129 s
Sonnet 5	A	7	0	$0.44	24.0	112 s
Sonnet 5	B	6	0	$1.18	36.3	210 s
Sonnet 5	C	7	1	$0.48	25.7	136 s
Sonnet 5	D	6	0	$0.53	27.0	157 s
Haiku 4.5	A	8	3	$0.34	35.4	172 s
Haiku 4.5	B	6	1	$0.68	43.3	217 s
Haiku 4.5	C	6	1	$0.26	28.2	124 s
Haiku 4.5	D	8	3	$0.37	38.9	179 s
Haiku 4.5	E	3 (T6)	3	$0.41	38.3	186 s
Haiku 4.5	F Opus verifier	3 (T6)	0	$1.36 с верификатором	61 (cap)	457 s
Sonnet 5	F	1 (T6)	0	$2.30 с верификатором	50	512 s

Ограничения: один репозиторий (небольшая, хорошо покрытая тестами библиотека на Python), шесть чётко поставленных запросов, от 1 до 3 повторов на ячейку, headless-прогоны. Скрытые тесты проверяют только то, что сказано в запросе.

Сделайте в понедельник

Напишите по одному приёмочному тесту на каждое заявленное требование сами, до того как прочтёте "done" от модели. Скрытые тесты бенча поймали то, что пропустили все проверки той же моделью.
Добавьте Stop hook, который запускает ваш набор тестов и возвращает решение block, пока он красный. Он срабатывает в каждом прогоне; skill нет.
Пусть первая остановка в задаче стоит по одной строке доказательства на каждое требование (паттерн prove-it.py): команда и её вывод, а не фраза.
Отдайте проверку, требующую суждения, модели, которая не писала правку: claude -p /verify --model opus на diff, блокировка при вердикте не PASS, максимум 2 раунда.
На Opus 5.5 при чётко поставленном запросе перестаньте по привычке набирать /verify. Он стоил 2.5x и ничего не изменил в 12 прогонах; оставьте его для области без тестов или для поиска давнего бага.
Если вы делегируете Haiku 4.5 ради цены, заложите в бюджет верификатор: $1.36 за задачу с hook на Opus против $0.76, когда Opus пишет сам.
Записывайте каждый повтор неудачного исправления в журнал и останавливайте цикл после повторения, чтобы блокирующий hook не жёг токены на одном и том же неверном патче.
Перечитайте свои требования на случай нескольких строк: "один update, затрагивающий несколько документов" это форма случая, который 11 прогонов Haiku из 11 так и не попробовали.

Копнуть глубже

5-шаговый процесс и лестница зрелости, от ручной проверки до CI-гейта: верхние ступени (CI и PR-гейты) это место, где должна жить детерминированная часть, когда ваш hook заработает локально. s1
Семантика Stop hook: решение block с причиной возвращает turn модели; прочтите контракт exit code и JSON, прежде чем писать свой гейт. s19
Groundtruth, Stop hook, который не даёт закончить turn, пока проверки не пройдут: детерминированная версия идеи, которую можно читать как эталонную реализацию. s5
regressionledger, сторона стоимости: hook, не дающий циклу повторять то же неудачное исправление; этого не хватало нашему Stop hook, когда прогоны упирались в лимит 60 turn. s10

Sources

Building verification loops in Claude Code with skills, блог Anthropic. Зачем читать: 5-шаговый процесс и лестница, на которых построена конфигурация со skill в бенче.
Building verification loops in Claude Code, официальный канал Claude. Зачем читать: три минуты о том, что /verify делает при первом запуске, прежде чем решать, оставлять ли его.
Claude Code CHANGELOG, GitHub. Зачем читать: в v2.1.215 /verify стал вызываться только пользователем, что меняет то, как часто он запускается у вас.
Boris Cherny: give Claude a way to verify its work, X. Зачем читать: утверждение про "2-3x the quality" в точной формулировке.
Groundtruth, GitHub. Зачем читать: рабочий гейт на Stop hook, который можно взять за основу вместо написания своего с нуля.
Issue #96416, GitHub. Зачем читать: датированная запись вердикта ревью, где проверено 5 замечаний из 19, а принято всё равно.
Issue #97039, GitHub. Зачем читать: тот же сбой двумя днями позже с загруженным чек-листом, так что чек-лист не решение.
AI coding agents can verify some of their work now, dev.to. Зачем читать: самая ясная формулировка разрыва между "build passes" и "production-ready".
Saguaro, GitHub. Зачем читать: спор о ревью внутри петли против ревью на уровне PR, с контраргументом в комментариях.
regressionledger, GitHub. Зачем читать: проблема стоимости повторов, которую создаёт блокирующий hook, и один способ её ограничить.
SPICE simulation to oscilloscope to verification with Claude Code, личный блог. Зачем читать: петля проверки, где эталоном служит физический прибор.
Hooks reference, code.claude.com. Зачем читать: контракт решения block, который должен соблюдать ваш Stop hook.

FAQ

Ловит ли встроенный /verify баги?

В этом бенче нет. Он вернул PASS в 24 прогонах из 24 на Opus 5.5, Sonnet 5 и Haiku 4.5, включая правку Haiku, нарушавшую заявленное требование. Единственной полезной находкой стал давний баг в upstream, не связанный с правкой.

Почему более сильный верификатор помогает более слабому автору?

Собственная проверка Haiku тестировала случай, о котором он уже подумал. Opus, получив ту же правку и тот же /verify, попробовал один update, затрагивающий несколько документов, и вынес FAIL 3 раза из 3. Sonnet сказал PASS. Верификатор должен увидеть случай, которого не увидел автор.

Что дешевле: проверять Haiku с помощью Opus или писать на Opus?

Писать на Opus. Hook с верификатором Opus на Haiku в среднем стоил $1.36 за прогон T6 и каждый раз упирался в лимит 60 turn; Opus, пишущий T6 в одиночку, в среднем $0.76 и 0 ложных "done".