Использовать ИИ-проверку

В этом руководстве показано, как поручить агентам-ревьюерам проверить pull request и как опубликовать результат в GitHub.

Запустить ИИ-проверку

Откройте PR и перейдите на вкладку «Обзор»
Откройте меню переполнения ⋯ в строке действий и выберите Спросить AI

Этот пункт появляется, только пока PR открыт — это действие до мержа. Та же кнопка предлагается как Спросить AI в пустом состоянии вкладки «Ревью», до появления какой-либо проверки.

Control Center запускает предустановленный конвейер pr_review и открывает вкладку «Ревью» этого PR, чтобы вы могли наблюдать за ним. Конвейер:

Открывает собственное пространство проверки PR, в изолированном worktree которого PR выгружен на его head
Запускает параллельно ревьюеров в соответствии с уровнем ревью рабочего пространства — по умолчанию троих (предустановленные агенты qa, architect и engineer, параллельно). Никакого определения языка или предметной области нет
Поручает ведущему агенту (CEO) свести их замечания в единый разбор
Финализирует: раскладывает замечания по корзинам консенсуса и вычисляет вердикт. Когда связь достигает awaiting approval, на вкладке «Ревью» появляется Опубликовать на GitHub

Насколько глубокой будет проверка, определяется уровнем ревью рабочего пространства — light (один ревьюер), balanced (трое, по умолчанию) или thorough (все пятеро, с добавлением специалистов по безопасности и производительности) — он задаётся в разделе Настройки → Рабочее пространство → Основные, на карточке Политика рабочего пространства. Более лёгкий уровень фиксирует ровно столько же замечаний; просто меньше из них показывается на первом плане.

Все ревьюеры пишут в единое пространство проверки PR — именно это делает их замечания сопоставимыми. О том, как все части складываются вместе, см. ИИ-проверка.

pr_review поставляется только с ручным триггером. Чтобы он срабатывал на каждый опубликованный PR, добавьте триггер сами — см. Запускать агентов-ревьюеров. Можно также запустить проверку прямо из GitHub, без триггера конвейера: упомяните бота сервера в PR или добавьте метку ai-review — см. Общаться с Control Center из GitHub PR.

Если всплывающее уведомление говорит, что проверка для этого pull request уже идёт, значит, она уже запущена; оставайтесь на вкладке «Ревью» или откройте Конвейеры, чтобы найти её.

Прочитать замечания

Ревьюеры фиксируют замечания как узлы проверки в пространстве проверки. Каждый узел несёт:

Поле	Описание
Тип	`bug`, `suggestion`, `recommendation`, `question` или `ticket`
Приоритет	P0 (critical) → P3 (nit)
Категория	`security`, `stability`, `data_integrity`, `correctness`, `performance` или `maintainability`
Файл и строка	Где привязано замечание
Исходный код	Код, к которому относится замечание
Предлагаемый код	Предлагаемое исправление
Уверенность	Насколько ревьюер уверен
Статус	`open` → `consensus-ready` → `resolved` или `dismissed`

Замечание достигает consensus-ready только тогда, когда его подтверждает другой ревьюер. Агент не может подтвердить собственное замечание, поэтому мнение одного ревьюера никогда не продвигается дальше само по себе.

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

Проверить панель расхождений

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

Прочитать вердикт

Когда ведущий агент завершает работу, он вычисляет вердикт:

Вердикт	Значение
Ship	Ничего блокирующего не найдено
Hold	Проблемы, которые стоит устранить до мержа
Block	Критические проблемы, которые необходимо исправить

Вердикт несёт агрегированную оценку уверенности и количество замечаний по каждому приоритету.

Затем в него встраиваются оси проверки, и они могут сделать его только более строгим. Ось под шлюзом, которая проваливается, принудительно даёт Block; ось под шлюзом, которая не смогла завершиться (partial) или вообще не смогла запуститься (unavailable), принудительно даёт как минимум Hold. Отсутствие доказательств никогда не открывает шлюз.

Опубликовать проверку в GitHub

Публикация — отдельный шаг, намеренно требующий подтверждения пользователя. Конвейер pr_review оставляет проверку в Control Center и не публикует ничего в GitHub.

На вкладке «Ревью» дождитесь появления Опубликовать на GitHub
Нажмите Опубликовать на GitHub

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

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

Другие встроенные конвейеры публикуют в GitHub напрямую: cross_review, pr_triage, ticket_to_pr и pre_merge_gate каждый завершается шагом комментария. Только pr_review придерживает свой результат для вас.

Запустить ревьюеров самостоятельно

Чтобы контролировать, какие роли проверяют PR и на какие файлы смотрит каждая из них, используйте инструмент MCP dispatch_reviewers в существующем пространстве проверки или добавьте узлы ревьюеров в конвейер. Оба пути вместе с точной сигнатурой инструмента описаны в разделе Запускать агентов-ревьюеров.