Мастер Claude · Блок 12. Качество и безопасность

Урок 88 из 93 · ~11 мин чтения

Проверка чужими глазами — /code-review и ultrareview

Урок пока закрыт

Курс проходится последовательно.

К текущему уроку

Почему это важно именно вам

У любой автономной работы есть слабое место: исполнитель сам оценивает, справился ли он. Модель, которая делала работу, склонна считать её выполненной — ровно как человек, проверяющий собственный текст.

Ответ на это — независимая проверка. Не «спроси Claude, всё ли хорошо» в том же разговоре, а отдельные агенты, которые не участвовали в работе и чья задача — найти в ней проблемы.

Для директора это знакомая конструкция: исполнитель и контролёр — разные люди. Здесь то же самое, только контролёров можно запустить хоть двадцать.

Что это такое

Три уровня проверки.

Локальная /code-review (алиас /review). Проверяет изменения, не выходя из вашей сессии: ищет ошибки, а заодно места, которые стоит упростить или переиспользовать. Работает фоновым агентом со своим контекстом, поэтому не засоряет разговор; флаг --fix сразу применяет находки, --comment выкладывает их комментариями в PR. Доступна всем.

Ultrareview/code-review ultra. Глубокая многоагентная проверка, выполняемая в облаке. Отличия от локальной:

Статус — research preview: возможность, цена и доступность могут поменяться. Требуется вход через claude.ai; недоступно при работе через сторонних провайдеров и в организациях с нулевым хранением данных. Если ultrareview недоступен, команда выполнит локальную проверку.

Code Review для репозиториев. Управляемый сервис для Team и Enterprise (тоже research preview, недоступен организациям с нулевым хранением данных): проверяет pull request'ы — при открытии, на каждый push или только по ручному запросу, как настроите. Замечания оставляет прямо на строках кода, а правила берёт из файла в репозитории, то есть проверяет по вашим стандартам. Оплачивается отдельно от лимитов плана, в среднем $15–25 за проверку, — поэтому выбор триггера это ещё и вопрос бюджета.

Почему многоагентная проверка честнее

Один проверяющий склонен подтвердить правдоподобную гипотезу. Когда каждую находку независимо перепроверяют другие агенты — и их задача именно опровергнуть, — до отчёта доходит меньше выдумок. Это тот же принцип, что закладывают в workflow из Дня 74, только упакованный в готовую команду.

Как работает на практике

Быстрая проверка в процессе

/code-review

Разумный ритуал: после того как Claude что-то сделал, но до того, как вы это применили. Занимает минуты, ловит очевидное.

Глубокая проверка перед важным

/code-review ultra

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

Когда ultrareview доступен, работает и короткий алиас /ultrareview. Перед запуском Claude Code показывает диалог: что именно проверяется, сколько осталось бесплатных прогонов и во сколько обойдётся этот — цену видно до, а не после. Для скриптов есть отдельная подкоманда claude ultrareview.

Работа идёт в облаке, вы продолжаете заниматься своим. Результаты приходят обратно в сессию.

Что это даёт вне программирования

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

Для документов, расчётов и решений это делается вручную тем же приёмом:

Ты — независимый проверяющий. Твоя задача — найти ошибки в этом расчёте:
проверь арифметику, сходимость с исходными данными, логику выводов.
Не соглашайся с автором: ищи, где он неправ. Если ошибок нет — скажи прямо.

Ключевые слова здесь — «не соглашайся с автором». Без этого проверка превращается в вежливое подтверждение.

Ещё сильнее — в новой сессии, где нет истории рассуждений: проверяющий не видит, как автор пришёл к выводу, и оценивает результат, а не логику его получения.

Частые ошибки

Просить проверку в том же разговоре у того же исполнителя. Он видел своё рассуждение и склонен его подтвердить.

Формулировать «проверь, всё ли хорошо». Такая постановка почти гарантирует ответ «да». Просите искать ошибки.

Запускать глубокую проверку на всём подряд. Она стоит денег и времени; её место — перед важными и необратимыми шагами.

Принимать находки без разбора. Проверка даёт список кандидатов. Решение — за вами; часть находок может оказаться неприменимой в вашем контексте.

Не фиксировать свои критерии. Проверка по общим представлениям находит общее. Ваши стандарты нужно записать — тогда и проверять будут по ним.

Когда нужно / когда нет

Стоит проверять:

Можно не проверять:

Связь с другими уроками

День 74 — workflow. Тот же принцип независимой проверки, но собираемый вручную под вашу задачу.

День 89 — плагины безопасности. Специализированная проверка на уязвимости.

День 63 — усилие. На проверке уровень — это размен: low и medium дают меньше находок, но самых достоверных; high и выше расширяют охват ценой ложных срабатываний. Поднимайте, когда пропустить проблему дороже, чем разобрать лишнюю.

Задание на сегодня

  1. Выполните /code-review на любых своих недавних изменениях.
  2. Если доступно — запустите /code-review ultra и сравните: что нашла глубокая проверка сверх локальной.
  3. Возьмите свой рабочий расчёт или документ и проверьте его отдельной сессией с ролью «независимый проверяющий, ищи ошибки».
  4. Сравните с тем, что сказал бы Claude в исходной сессии на вопрос «всё ли хорошо».
  5. Запишите свои критерии проверки, чтобы не формулировать их каждый раз заново, — и оформите как скилл.

Критерий «выполнено»: независимая проверка нашла хотя бы одно замечание, которого не дала проверка «в том же разговоре».

Резюме

Следующий урок откроется после отметки.