Автоматическое ревью кода в 2026 году: запустите его на каждом PR, не покупая лицензию

Автоматическое ревью кода — это CI-задача, которая отправляет ваш дифф языковой модели, публикует замечания на затронутых строках и помечает проверку статуса как неуспешную, если находит что-то серьёзное. Чтобы запустить это на каждом пул-реквесте без подписки на рабочее место, нужно развернуть собственный опенсорсный харнесс: скопируйте в репозиторий workflow примерно из пятнадцати строк, добавьте один API-ключ и платите только за токены, которые потребляет каждая проверка. Покупать места не нужно, потому что мест нет. Эталонная реализация, которую мы поддерживаем, — репозиторий Orca-Code-Review — публичный, под лицензией MIT, и с момента создания 25 июня 2026 года является кодом, стоящим за GitHub Action OrcaCode Review. Его стандартная схема маршрутизации по умолчанию назначает основной проход ревью на DeepSeek V4 Flash, а независимого судью верификации — на GLM-5.3; и то и другое вы можете изменить. В этой статье мы разберём, что именно выполняется при каждом пуше, что вы настраиваете, сколько это стоит в токенах и с какими сбоями вы столкнётесь на второй неделе.

Коротко. Каждый пуш получает одно ревью. Замечания размещаются инлайн на изменённых строках. Замечания P0 и P1 приводят к провалу проверки и блокируют merge; чистый прогон проходит. Вы можете повторно запросить ревью, оставив комментарий /orcacode-review. Workflow находится в вашем репозитории; логика ревью — в опубликованном action; выбор модели — в рецепте маршрутизации, который вы можете редактировать в своём рабочем пространстве. Ревьюер читает diff и файлы репозитория и никогда не выполняет код вашего PR. И честное предупреждение сразу: он ловит реальные баги, но всё равно пропускает те, что требуют человека, который знает, почему код устроен именно так.

• Один workflow + один секрет + оплата по токенам. Никакой лицензии за рабочее место на любом этапе.

• Харнес — с открытым исходным кодом. Копируйте его, форкайте его, проверяйте его, закрепите его на SHA коммита.

• Модель — это настройка, а не поставщик. Смените рецензента, отредактировав рецепт маршрутизации, а не переписывая YAML или изменяя действие.

• Слишком большие диффы ничего не стоят. Проверка размера выполняется до запуска модели.

• Он читает ваш код, но никогда не выполняет его. Именно это свойство безопасности делает pull_request_target безопасным для использования вообще.

Как на самом деле работает автоматическое рецензирование кода

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

Данное событие является триггером. Поставляемый рабочий процесс срабатывает на события pull request — opened, synchronize (новый push), ready_for_review (черновик становится готовым к ревью) — и на комментарий к PR. Поскольку он срабатывает на pull_request_target, определение рабочего процесса считывается из базовой ветки, поэтому рабочий процесс должен существовать в базовой ветке, прежде чем он сможет запуститься для PR. Одно ревью на каждый push; concurrency-блок отменяет предыдущий запуск, поэтому быстрая последовательность push'ей не ставит в очередь пять ревью устаревшего кода.

раннер — это GitHub Actions на ubuntu-latest. Заданию нужны три разрешения: чтение содержимого, запись в pull request (чтобы публиковать инлайновые комментарии) и запись в issues (чтобы публиковать сводку и удалять устаревшие комментарии).

Ревьюер — это языковая модель. Действие получает head PR, собирает diff и контекст репозитория, выбираемый движком, и отправляет это модели ревью. Результат — набор замечаний, каждое из которых отмечено уровнем серьёзности и привязано к файлу и строке. Действие публикует их в виде инлайновых комментариев к PR и записывает один сводный комментарий в маркерную область в верхней части описания PR, который заменяется на месте при каждом пуше.

Данный гейт — проверка статуса. GitHub не знает, что означает «review»; он знает только, проходит ли review-проверка. Вы делаете гейт реальным, пометив эту проверку как обязательную в защите веток. Это и есть весь механизм блокировки слияния — никаких вызовов admin API, никаких меток, только проваленная обязательная проверка.

Чего не происходит: ничто не выполняет код PR. Движок только читает. Именно этот единственный инвариант делает привилегированный pull_request_target триггер безопасным для использования с платным API-ключом.

Открытый инструментарий является отличительной чертой.

Всё вышесказанное справедливо для многих инструментов. Но для большинства это не так: всё это можно проверить и развернуть самостоятельно — именно это даёт вам репозиторий Orca-Code-Review. Это публичный репозиторий GitHub под лицензией MIT (JavaScript, создан 25 июня 2026 года), который упаковывает ревью в переиспользуемый составной GitHub Action и установщик, и это тот же код, который размещённое приложение OrcaCode Review запускает.

Проведите десять минут в дереве, и вы сможете назвать каждый элемент, который касается вашего PR:

• action.yml — композитное действие примерно с пятнадцатью документированными входными параметрами. Названия моделей нигде в нём не захардкожены.

• workflows/orca-code-review.yml — пример workflow-потребителя, примерно пятнадцать строк, которые вы копируете в .github/workflows/.

• recipes/ — это DSL маршрутизации. Именно здесь на самом деле выбирается модель.

• rules/ — шкала критичности (P0–P3), обязательный формат вывода и директива о соглашениях, которая передаёт собственный документ соглашений проекта в проверку в качестве недоверенных справочных данных.

• scripts/ — фильтр точности (L1 плюс судья L2), защита от диффов, ворота слияния, отчет о запуске и счетчик токенов. Каждый — небольшой читаемый .mjs файл с тестами.

• skills/setup-orca-code-review — навык, который установщик встраивает в вашего кодинг-агента, охватывающий установку, перенастройку, устранение неполадок и удаление.

• .claude-plugin/ — что позволяет Claude Code устанавливать навык как самообновляющийся плагин.

Установка — это одна команда, которая объясняет вашему ИИ, что такое продукт, и на этом останавливается:

npx @orcarouter/code-review

CLI определяет, какие кодинг-агенты вы используете — каталог охватывает 36 платформ, от Claude Code, Cursor, Codex, OpenCode и Windsurf до GitHub Copilot, Gem​ini CLI, Amazon Q Developer, Cline, RooCode и других — устанавливает навык и передаёт управление. Затем вы обращаетесь к своему агенту на простом языке: “настройте OrcaCode Review в этом репозитории,” “блокируйте только P0,” “почему ревью не запустилось?” Навык берёт на себя весь жизненный цикл: он создаёт рабочий процесс, проводит вас по настройке API-ключа, устанавливает шлюз и задаёт только те вопросы, которые действительно должны решаться вами.

Claude Code может вместо этого установить навык как плагин, что позволяет поддерживать его в актуальном состоянии по мере перемещения репозитория:

Добавить плагин из маркетплейса: Continuum-AI-Corp/orca-code-review

/plugin install orca-code-review

Совсем нет агента? Тот же жизненный цикл — это просто подкоманды: init пишет workflow, reconfigure изменяет блокирующие правила и лимиты diff, doctor диагностирует ревью, которые не запускаются или не публикуются, uninstall удаляет его (сначала убрав обязательную проверку). Скилл — это входная дверь, но не единственная. Или настройте вручную: скопируйте workflow, добавьте один секрет с именем ORCAROUTER_API_KEY, и отметьте review как обязательную проверку.

В основе лежит движок — Open Code Review от Alibaba, привязанный к точной версии и распространяемый под лицензией Apache-2.0. OrcaCode определяет, как проводить ревью; OrcaRouter — какая модель будет его выполнять. Сравнение self-hosted и hosted — что на самом деле стоит «бесплатно», когда вы разворачиваете опенсорс-ревьюер у себя, — подробно разобрано в нашей статье о ревью открытого кода.

Что выполняется по порядку при каждом пуше

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

• Дифф-гард выполняется первым, ещё до того, как модель вообще приступит к работе. Если diff относительно merge-base превышает 512 КБ или затрагивает более 300 файлов, ревью пропускается и появляется уведомление. Значение по умолчанию: on-oversized-diff: fail, поэтому diff, раздутый сверх лимитов, не может пройти обязательный шлюз без ревью. Это также контроль расходов: слишком большой PR обходится в ноль токенов.

• Движок проверяет изменения. Один проход, пофайловая параллельность по умолчанию 24, с лимитом реального времени 20 минут на проход.

• Фильтр точности выполняет постобработку необработанных результатов. L1, детерминированный фильтр, сверяет каждый заявленный фрагмент существующего кода из результата с проверяемым коммитом и перемещает или отбрасывает несоответствия. L2, LLM-судья, группирует результаты по корневой причине и отбрасывает кластеры с низкой уверенностью. Оба уровня являются soft-fail: ошибка сохраняет результаты предыдущего этапа и никогда не прерывает проверку.

• Шлюз действует. Находки P0 и P1 не проходят проверку; сводка PR учитывает каждую находку, включая те, что замьючены в диффе.

• Счётчик выводит, сколько это стоило. Вход счётчика фиксирует учёт токенов по каждому вызову — prompt, completion, кэшированные токены и модель, которую выбрал маршрутизатор, — и выводит итоговую таблицу в журнал заданий.

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

Что вы на самом деле настраиваете

Есть три поверхности, и у них очень разный радиус поражения.

1. Файл рабочего процесса. Потребительский рабочий процесс намеренно минималистичен. Входные параметры, которые стоит менять, находятся в действии: block-on (какие уровни серьёзности приводят к провалу проверки — по умолчанию P0,P1), fix-first (какие уровни серьёзности прерывают полное ревью раньше времени), auto-review-authors (список разрешённых авторов для автоматического ревью), max-diff-kb и max-diff-files и on-oversized-diff (защита от слишком большого диффа), timeout-minutes, concurrency, meter и report. Для каждого есть документированное значение по умолчанию, так что новый рабочий процесс — это пять строк YAML плюс секрет.

2. Панель управления. С settings: true (по умолчанию), каждый запуск получает настройки конкретного репозитория из OrcaRouter → Apps → OrcaCode Review: модель, режим ревью, политика слияния, серьезность отчетов, тихий режим, исчерпывающее ревью, пользовательские критерии и ограничения. Установите settings: "false" и файл workflow имеет приоритет — никакое значение на панели управления не может его переопределить. Если вы никогда не открываете консоль, вы не теряете ни одной из возможностей; вы просто настраиваете все в YAML.

3. Рецепт маршрутизации — тот, который упускают из виду. Действие никогда не называет модель. Вместо этого оно внедряет необработанные факты в виде заголовков запроса — на каком уровне был записан запуск, обнаружил ли предыдущий проход P0/P1, и маркер линзы, когда запрос является судьёй L2 — а DSL-рецепт маршрутизатора рабочего пространства сопоставляет эти заголовки с конкретной моделью. Поставляемый рецепт по умолчанию назначает ревью на DeepSeek V4 Flash, а судью — на GLM-5.3, намеренно направляя их на разные модели. Изменение модели, которая ревьюит ваш код, — это правка этого рецепта в вашем собственном рабочем пространстве: без увеличения версии действия, без переписывания YAML, без повторного развертывания.

Контракт серьёзности — это две независимые настройки, а не одна. Политика слияния определяет, что блокирует слияние; отчётные серьёзности определяют, что отображается в диффе. Поставляемые по умолчанию значения: P0/P1 блокируют, P2/P3 пропускают. Серьёзность, которая блокирует, всегда публикуется, что бы ни говорила настройка отчёта — падающая проверка без каких-либо объяснений в диффе хуже, чем шумная. P0 означает эксплуатируемую уязвимость безопасности, потерю данных, сбой на обычном пути выполнения или сломанную сборку; P1 — реальную, но локальную ошибку; P2 — настоящий дефект, который срабатывает только при ненормальном предусловии; P3 — это стиль. Если вы колеблетесь между двумя уровнями, правила предписывают выбирать более низкий.

Сколько это стоит

За токен, а не за место. Вы выбираете модель в OrcaRouter, оплата начисляется за потреблённые токены, и счётчик делает сумму за каждый запуск видимой вместо загадочной. Механика GitHub, метрируемое ревью кода Copilot с 1 июня 2026 года и то, как сторонние ревьюеры встраиваются в этот процесс, описаны в нашем руководстве по ревью кода в GitHub. Полное пофакторное сравнение стоимости — продукты с оплатой за место против продуктов с оплатой за токен, с проработанным примером — в нашем сравнении инструментов ИИ-ревью кода, а вопрос о том, сколько токенов стоит один проход ревью, когда ревьюер действительно исследует репозиторий (различие «бот против агента»), — в нашей статье об агентах ревью кода. Новое, что добавляет эта статья, — это форма счёта: она масштабируется с объёмом просматриваемого кода, а не с численностью команды, которая его проверяет.

Два ограничения расходов важны с первого дня. На публичном репозитории, pull_request_target обходит шлюз одобрения форков GitHub, а ключ ревью оплачивается из кошелька — незнакомец может открыть PR и запустить платные проверки. Установите бюджет кошелька с оповещениями на ключе и установите auto-review-authors на что-то вроде OWNER,MEMBER,COLLABORATOR,CONTRIBUTOR, чтобы неизвестные участники не получали автоматическое ревью. И, как уже отмечалось, дифф-гард означает, что очень большие PR не стоят ничего вообще.

Что ломается

Автоматическое рецензирование — это CI. Оно ломается, как CI, и режимы отказов в основном не по вине модели:

• Рабочий процесс никогда не запускается. Для pull_request_target рабочий процесс читается из базовой ветки — рабочий процесс, добавленный только в ветке PR, не запустится, пока не будет выполнено слияние. Также проверьте, что приложение включено, auto_review включено, PR не является черновиком (черновики пропускаются в режиме ready_for_review), и Actions включены в репозитории (в форках они изначально отключены).

• /orcacode-review ничего не делает. Триггер комментария требует, чтобы комментарий начинался с одного из четырёх вариантов написания — /orcacode-review, /orcacode review, @orcacode-review, @orcacode review — а комментатор должен быть OWNER, MEMBER или COLLABORATOR. Ведущий пробел нарушает совпадение. Команда внешнего контрибьютора намеренно молча игнорируется: команда запускает привилегированный workflow, содержащий платный ключ.

• Ошибка аутентификации. Секрет неправильно назван или отсутствует, ключ отозван или бюджет исчерпан, или рабочий процесс был переключен на pull_request (который не может читать секреты из форков).

• Проверка красная, с уведомлением “diff too large”. Это защита по размеру, сработавшая согласно настройкам. Разбейте PR, или поднимите лимиты, или укажите on-oversized-diff: pass — и помните: при обязательной проверке pass означает, что большой PR пройдёт через гейт без ревью.

• Проверка выполняется, но комментарии не появляются. Три причины, и все они безобидны или связаны с конфигурацией: чистый прогон публикует сводку вместо инлайн-комментариев; тихий режим подавляет P2 при публикации (хотя гейт и отчёт всё равно его учитывают); или фильтр точности отбросил находки: L1 отбрасывает находки, сниппет которых не соответствует коммиту, L2 отбрасывает кластеры с низкой уверенностью. Счётчики уровней серьёзности в журнале задания покажут, какая из причин.

О состоянии безопасности стоит сказать прямо, потому что именно оно обеспечивает безопасность всей архитектуры. Движок только читает diff и файлы репозитория; он никогда не выполняет код PR. У рецензента нет полномочий на слияние — замечания могут заблокировать слияние или добавить комментарий, но ни один путь в коде не позволяет результату работы модели одобрить или изменить репозиторий. Непомеченное замечание отказобезопасно: оно трактуется как блокирующее, а не как рекомендательное. И отчёт о запуске не содержит ни кода, ни текста замечаний. Двухуровневая настройка, которая ловит то, что пропускает одноразовая проверка, является темой нашей статьи о безопасности ИИ-ревью кода; описанная выше модель угроз задокументирована в SECURITY.md репозитория.

Когда автоматизированная проверка — не тот инструмент

Это неправильно чаще, чем признают поставщики инструментов. Пропустите это, когда:

• Проблема в контексте, а не в объёме. Если ревью идут медленно, потому что ревьюеры должны понимать, почему код был написан именно так, то LLM, читающий дифф, приносит мало пользы. У него нет памяти о прошлой ветке обсуждения и никакого понимания истории системы.

• Дифф в основном состоит из сгенерированного или вендорного кода. Автоматически отформатированный вывод, скаффолд-файлы, снимки зависимостей. Его ревью сжигает токены и создаёт шум, и именно здесь директива о соглашениях помогает меньше всего — код не соответствует стилю проекта намеренно.

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

• Никто не читает выводы. Ревью, на которое никто не реагирует, — это рабочий процесс, который проваливается, но навсегда остаётся зелёным. Это самый распространённый тихий отказ, и никакой фильтр точности его не исправит.

• Ревью должно запускать код. Если вам нужен набор тестов для PR, LLM-ревью — не тот инструмент. Оно читает; оно не выполняет. Сканирование безопасности, которому нужно собрать и запустить артефакт, должно быть вынесено в отдельную, тщательно ограниченную задачу — помните, рабочий процесс ревью ни в коем случае нельзя расширять для запуска кода, управляемого PR.

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

Ложные срабатывания, и что фильтрация по точности исправляет и не исправляет.

Обвинение против каждого ИИ-рецензента заключается в том, что он кричит «волки». Харнесс атакует это на двух уровнях, и полезно точно понимать, какой уровень исправляет какой сбой.

Данный детерминированный слой (L1) устраняет призрачную находку: движок иногда указывает на код, которого нет — фрагмент, который сместился, или находка, скопированная на соседний файл. L1 сверяет фрагмент существующего кода для каждой находки с фактическим проверяемым коммитом и перемещает или отбрасывает несоответствия. Это исправляет класс ложных срабатываний вида «этой строки вообще не существует», который является механическим и проверяемым.

Слой судьи (L2) устраняет дубликат и неподтвержденное утверждение: LLM-судья группирует находки по первопричине и отбрасывает группы, чья уверенность ниже порога судьи (по умолчанию 0.5). Это исправляет «один и тот же баг, сообщенный тремя способами» и спекулятивную находку.

Что не исправляет ни один из слоёв, стоит сказать вслух. Неверное, но уверенное замечание проходит проверку судьёй: судья — это LLM, а LLM, который звучит уверенно, — это не то же самое, что истинное замечание. Судья, работающий на той же модели, что и рецензент, соглашается сам с собой, и проверка становится инертной, продолжая сообщать об успехе; именно поэтому в поставляемом рецепте судья направляется на другую модель, нежели рецензент. А шкала серьёзности намеренно консервативна — «когда сомневаешься между двумя уровнями, выбирай нижний» — что означает, что реальная, но условная ошибка с большей вероятностью попадёт в категорию консультативного P2, чем блокирующего P1. Это правильная калибровка для инструмента, который не должен блокировать всё, но это калибровка: она разменивает пропущенные блокеры на меньшее число ложных срабатываний. Сводка PR всегда учитывает каждое замечание, так что приглушённые P2 по-прежнему можно прочитать. Если такой компромисс не подходит вашей команде, шкала и порог судьи — это настройки, а не тикет в поддержку.

Суть

Для команды, которая уже живёт в GitHub Actions, инструментарий с открытым исходным кодом — это самый дешёвый способ получать автоматическое ревью кода на каждом PR: один файл workflow, один секрет, счёт за токены, который масштабируется в зависимости от объёма проверяемого кода, и выбор модели, который принадлежит вам. Покупайте продукт с оплатой за рабочее место, когда вам нужны нулевые операции и поставщик, которому можно позвонить, — не потому что ревью становится лучше, а потому что вы покупаете чужую проблему вместо того, чтобы решать свою. И прежде чем всё это настраивать, спросите себя, будет ли ревью вообще читаться. Инструментарий может сделать ревью автоматическим. Он не может заставить кого-то его прочитать.

Хотите того же ревьюера, не запуская его самостоятельно?OrcaCode Review запускает этот же самый харнесс в виде размещённого GitHub-приложения — тот же открытый рецепт, та же оплата за токены, без платы за места.