ИИ-проверка

Как устроена проверка

ИИ-проверка — это один запуск предустановленного конвейера pr_review для одного открытого pull request. Конвейер открывает пространство проверки этого PR, параллельно запускает агентов-ревьюеров, чтобы они прочитали diff в изолированной рабочей копии этого пространства, каждый из них фиксирует свои замечания как структурированные узлы проверки, ведущий агент сводит их в единый разбор, а финализатор вычисляет один вердикт: Ship, Hold или Block. Чего конвейер никогда не делает — так это не публикует: публикация в GitHub — отдельный, осознанный шаг, который делает человек.

Остальная часть страницы объясняет эти составные части и то, почему они устроены именно так.

Одно пространство проверки на каждый PR

Контекст проверки PR — это пространство обмена сообщениями — режим review, вид pr — связанное с pull request через связь пространства проверки. Оно создаётся идемпотентно: страница PR, конвейер проверки и чат-поверхности определяют единственное базовое пространство PR по одному и тому же пути в коде, поэтому шаблон, который проверяет PR, и человек, который его открывает, никогда не окажутся в двух разных комнатах, смотрящих на две разные рабочие копии.

В изолированном worktree пространства PR выгружен на его head ref. Одна комната означает и одну рабочую копию: все ревьюеры работают в одном и том же пространстве, а не каждый в своём клоне рабочего пространства.

Каждый ревьюер пишет в собственный именованный поток внутри этого единственного пространства, а замечания — это сообщения review_node, а не обычный текст. Итоговый сбор по всему пространству сделан намеренно: вердикт, вычисленный по замечаниям одной ветки, молча оказался бы вердиктом по одному ревьюеру.

Связь несёт лестницу статусов — requested → in progress → awaiting approval → completed — и именно она управляет доступностью кнопки Опубликовать на GitHub на вкладке «Ревью» PR.

Уровни проверки

Глубина проверки задаётся политикой рабочего пространства и имеет три уровня; они настраиваются в разделе Настройки → Рабочее пространство → Основные, на карточке Политика рабочего пространства:

Уровень	Какие ревьюеры запускаются	Что показывается
light	Только инженер	Только то, что действительно важно
balanced	Инженер, QA, архитектор (по умолчанию)	Обычный проход
thorough	Все пятеро, включая безопасность и производительность	Ничего не понижается

Уровень поворачивает две ручки сразу: какие ревьюеры запускаются — это обеспечивают шлюзы состояния runWhen в шаблоне конвейера, а не формулировки промпта (формулировки промпта можно проигнорировать, шлюз — нельзя), — и где отображаются замечания ниже порога. Ни одна из ручек никогда не удаляет замечание: уровень, который показывает меньше, фиксирует ровно столько же, а остальное группирует.

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

Узлы проверки: замечания как данные, а не текст

Замечание, зафиксированное через add_review_node, становится узлом проверки на PR — именно его отображает вкладка «Ревью», по нему вычисляется вердикт, и именно его «Опубликовать на GitHub» превращает во встроенный комментарий. Ревьюер, который возвращает только текст, даёт запуск конвейера, выглядящий успешным, и пустую поверхность проверки; именно фиксация — главное.

Каждый узел несёт:

Поле	Значения
Тип	bug, suggestion, recommendation, question, ticket
Приоритет	P0 (critical) → P3 (nit)
Тройка триажа	категория (security, stability, …), критичность, трудозатраты
Привязка	Путь к файлу, начало и конец строки
Данные для исправления	Предлагаемые строки замены, необязательный diff, необязательный промпт исправления
Уверенность	Оценка в диапазоне [0, 1]
Обоснование	Анализ, написанный до замечания

Две детали сделаны намеренно. Предложение GitHub в один клик доступно только тогда, когда ревьюер указал точные строки замены: выводить их из unified diff — значит тихо ошибаться, а коммит в один клик по неверному выводу хуже, чем полное отсутствие кнопки. А схема add_review_node ставит reasoning перед замечанием, поэтому модель, заполняющая объект в порядке схемы, сначала пишет анализ. Поле необязательно: его пропуск не отклоняет узел. Узел с некорректным payload исчезает, а не загрязняет проверку.

Консенсус ревьюеров

Узел проходит путь open → consensus-ready → resolved или dismissed. Средний шаг — сердце этой модели: замечание получает ход только тогда, когда его подтверждает другой ревьюер, и агент никогда не может подтвердить своё собственное замечание. Инструмент MCP publish_review_to_github и значение по умолчанию для RPC по-прежнему публикуют только замечания, подтверждённые другим ревьюером. Кнопка Опубликовать на GitHub на вкладке «Ревью» вместо этого отправляет все оставшиеся открытые замечания.

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

Когда ревьюеры расходятся — один файл и строка, приоритеты различаются на два уровня или больше, либо один называет это bug, а другой — suggestion, — расхождение выводится над списком замечаний. Именно там мнения ревьюеров расходятся, и суждение человека стоит дороже всего.

Отклонение замечания также записывает мягкий факт подавления в домен памяти, с низкой уверенностью: одно отклонение — это предпочтение, а не правило.

Когорты: вокруг чего группируется проверка

Проход вычислений проверки группирует изменённые файлы PR в когорты, производные от графа кода: изменённые файлы отображаются на затрагиваемые ими символы, символы — на связные компоненты, а когорты ранжируются по радиусу влияния. Когорта несёт рекомендуемый порядок чтения, диаграммы и выводы, а не является плоским списком файлов.

Это формируют два правила честности. Ключи когорт выводятся из содержимого и стабильны между отправками, поэтому замечания и прогресс проверки переживают rebase или force-push, а не становятся сиротами. А когда в репозитории нет индекса кода, группировка откатывается к обычным путям и сообщает об этом — этот откат никогда не имитирует семантическую уверенность.

Оси проверки и шлюзы

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

Ось	Вид	На чём основана
correctness, security	На основе токенов	Собственные замечания ревьюеров
testGap	На основе токенов	Замечания ревьюеров
visual, apiContract	Детерминированный	Вычисляется без расхода токенов
performance	Детерминированный	Только перечисление — ничего в продукте не вычисляет результат

Вердикт оси — pass, warn, fail, partial или unavailable — и только pass или warn открывает шлюз. Различие между fail, partial и unavailable принципиально: ось под шлюзом, которая не смогла завершиться или вообще не смогла запуститься, удерживает общий вердикт, а не пропускает его. Отсутствие доказательств никогда не превращается в зелёный шлюз.

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

Вердикт

Финализатор вычисляет вердикт по замечаниям со статусом open или consensus-ready:

• любое замечание P0 с уверенностью ≥ 0,7 → Block
• иначе любое P0 (с низкой уверенностью) или любое P1 → Hold
• иначе → Ship

Вердикт несёт агрегированную уверенность, производную от разброса уверенностей, которые его составили: согласие повышает её, расхождение понижает.

Сведение, которое делает ведущий (CEO) агент, — это редакторский проход, а не повторный перечень: написанная от руки вторая копия замечаний — это ровно то, что расходится с настоящей. Дублирующиеся замечания понижаются, а не повторяются: несколько ревьюеров намеренно нацелены на один diff с пересекающимися зонами ответственности, поэтому один и тот же дефект, дошедший до финализатора трижды, — это работающая система; публикация его трижды — это система, протекающая собственной архитектурой в почтовый ящик читателя. При повторной проверке замечания получают отпечатки и сравниваются с предыдущим раундом, поэтому на поверхность выходит именно разница.

Наконец подключаются оси, и они могут сделать вердикт только более строгим: ось под шлюзом с результатом fail принудительно даёт Block — замечания не могут её переголосовать, — а ось под шлюзом, которая не смогла завершиться, принудительно даёт как минимум Hold.

Публикация остаётся за вами

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

• Отправляется одно ревью GitHub. Замечания, уже разрешённые или отклонённые, пропускаются. Кнопка публикует все оставшиеся открытые замечания (selection: all_open). Инструмент MCP publish_review_to_github по умолчанию по-прежнему публикует только замечания, подтверждённые другим ревьюером (consensus).
• Замечания, привязанные к файлу и строке, становятся встроенными комментариями; всё остальное складывается в тело сводки, и каждое несёт подпись «— Control Center AI review», чтобы источник был однозначен.
• Привязки заново проверяются по текущему diff PR в момент публикации. Комментарий к коду, который уже переписан, — самое разрушительное для доверия, что может оставить ревьюер; если GitHub всё же отклоняет встроенную привязку, всё ревью отправляется заново, а каждое замечание складывается в тело, чтобы ничего не пропало молча.
• Вердикт Block отправляется как REQUEST_CHANGES; Hold — как COMMENT; Ship — как APPROVE при нажатии кнопки (approve_on_ship: true). Инструмент MCP оставляет Ship как COMMENT, если вы не передадите approve_on_ship.
• Ревью публикуется от имени приложения сервера. То, кто нажал «Опубликовать», записывается для ролевого шлюза и журнала аудита; это не автор в GitHub.

Публикация объявляет класс действий prPublish, поэтому точка контроля ограничений проводит её через шлюз, как любое изменяющее действие: по умолчанию она запрашивает подтверждение, а при отсутствии подключённого подтверждающего отказывает. См. Ограничения.

Что может делать ревьюер

Агенты-ревьюеры работают в режиме review: песочница только для чтения и подобранный список разрешённых инструментов, охватывающий замечания, комментарии, тикеты и рецензирование, — но без изменений. Ревьюер не может исправить код, который критикует; он может приложить предлагаемое исправление, которое применит человек. Сообщение об отказе этого режима говорит агенту, который всё же пытается действовать, завершить проверку и дать пользователю действовать по опубликованной сводке.

Связанные понятия

• Ограничения — движок политик, который управляет доступностью публикации
• Режимы — что режим review меняет для агента
• Конвейеры и автоматизация — движок, на котором работает проверка
• Жизненный цикл запуска агента — откуда берётся изолированный worktree

Связанные руководства

• Использовать ИИ-проверку — запустите проверку и опубликуйте её
• Запускать агентов-ревьюеров — выберите ревьюеров сами
• Вычисления проверки — когорты, оси и diff-ы