OpenCodeReview AI Code Review на практике: сколько багов, дыр и замечаний по качеству он находит в живом Git diff?

Сначала: что именно смотрит OpenCodeReview

Его часто путают с OpenCode (агент разработки за opencode serve). Другой продукт. OpenCodeReview — внутренний ИИ-ревьюер Alibaba, открытый как CLI: читает Git-изменения, выдаёт структурированные строчные комментарии, несёт правила (NPE, потоки, XSS, SQL-инъекции) и говорит с эндпоинтами OpenAI / Anthropic. Исходник: alibaba/open-code-review. Документация: open-codereview.ai.

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

У нас уже есть как выбрать 4 / 8 / 16 ГБ для self-hosted OpenCode — это счёт за память агента разработки. Здесь только ocr review: автопроверка Git diff, багов, уязвимостей и качества и сколько находок даёт живой проект.

Официальная формулировка — «десятки тысяч разработчиков, миллионы дефектов». Это история масштаба Alibaba, не обещание на ваш следующий PR. Вторая пара глаз перед мержем — да. Машина, которая подписывает прод, — ни README, ни этот прогон не подпишут.

Как он читает Git diff: три режима

Кто искал «автопроверка Git diff», хочет «что я изменил». CLI делит это на три взаимоисключающих режима — смешение даёт жёсткую ошибку. Флаги: CLI Reference.

Режим диапазона считает merge-base — ближе к человеческому ревью PR, чем сырой diff двух веток: поздние коммиты в main не заливают проверку. Официальный GitHub Action делает то же: merge-base, затем ocr review --from MERGE_BASE --to HEAD_SHA --format json и строчные комментарии в PR.

Четвёртый путь — ocr scan: целые файлы, без осмысленной Git-истории, когда наследуете каталог. Токены и шум растут. Для мержа начните с diff; scan наследия — потом.

Всегда сначала ocr review --preview. Только фильтр, без денег модели. Видно will_review против расширения / удаления / тестового пути. В нашем прогоне PR с картинками и lockfile потерял примерно половину «огромных на вид» файлов до LLM — правильно.

Пять минут: установка, модель, preview

По умолчанию — npm global. Есть install.sh и статичный бинарник с GitHub Releases. Нужен Git ≥ 2.41. Без настроенной модели ocr review не выдумает комментарии (кроме Delegation Mode на уже оплаченного агента разработки).

npm install -g @alibaba-group/open-code-review
ocr version
ocr config provider
ocr config model
ocr llm test

cd /path/to/your-repo
ocr review --preview
ocr review --from main --to HEAD --format json --audience agent

Конфиг в ~/.opencodereview/config.json. В CI — ocr config set или уже существующие ANTHROPIC_* / OCR_LLM_*. Язык комментариев: ocr config set language Russian (по умолчанию английский). .opencodereview/rule.json можно коммитить; ключи — нет.

npm-обёртка обновляется в фоне (~18 минут паузы). В CI зафиксируйте версию и OCR_NO_UPDATE=1. Сессии в ~/.opencodereview/sessions/. ocr viewer на localhost:5483 для повтора, не публичный сервис.

Не копируйте статью про RAM OpenCode. Тяжёлое — API LLM и параллельные git-подпроцессы; LSP не греется. По умолчанию --concurrency = 8. Крышка ноутбука посреди диапазона оставляет сессию на --resume. Машина, которая не спит, честнее, чем ставка на командировочный ультрабук.

Практика: три настоящих пакета изменений

Та же конфигурация (протокол, совместимый с OpenAI, средняя чат-модель, системные правила плюс проектные) на трёх пакетах в форме PR — не игрушка на десять строк. Каждый пакет: --preview, затем ocr review --from --to --format json. Метки: must-fix, should-fix, стиль, ложное. Один снимок; другая модель — другие числа. Смесь важнее заголовка.

Must-fix (7): три по безопасности, четыре дефекта. Безопасность: запросы из строк, неэкранированный HTML, внутренний текст ошибки клиенту. Дефекты: nil как объект, запись в map без блокировки, ошибки без %w. Это попадает в заявленный набор — NPE, потоки, XSS, SQL — не сочинение.

Should-fix (6): нет таймаутов, ретраи неидемпотентных вызовов, логи с почтой или телом. Человек должен поднять; пятничный вечер часто нет. Агент не устаёт.

Стиль (10) — самая большая корзина. Имена, ранний return, «вынеси функцию». Полезно и размывает сигнал. Без настройки к третьей неделе команда сворачивает всё ревью — та же патология шумных PR-ботов.

Ложные (4) были скучными в хорошем смысле: SQL из фикстуры как прод-инъекция; уже параметризованный запрос снова; переменная цикла до Go 1.22. Три из четырёх умирают, если после --preview исключить тесты. Сначала фильтр, потом модель.

Масштаб совпадает с официальным примером: диапазон часто выглядит как «9 файлов, десяток комментариев, около минуты, ~20k токенов». Наши три пакета — три отдельных диапазона, не один гига-PR. Diff файла, съедающий ~80% окна, отбрасывается до LLM — сгенерированные блобы и lockfile должны исчезнуть на preview, не в счёте.

Баги, безопасность, качество: что ловит

Разложить 27 комментариев по четырём словам заголовка ближе к тому, как вы будете пользоваться инструментом, чем одно «найдено проблем».

Агент читает весь файл, поэтому сильнее «только зелёные строки». Официальный пример map без блокировки типичен: в diff одна присваивание, ложе состояние уже выше. Diff-only боты пропускают; file_read тянет контекст. Это заявленный разрыв с ревьюерами PR, которые видят только патч — они быстрее и тише и слабее поперёк файлов.

Намеренные промахи: неверная формула скидки, поле валюты как USD, эндпоинт, который не должен открываться до одобрения. Ноль комментариев. У модели нет вашего глоссария. --background с описанием PR помогает. Требования человека это не заменяет.

Комментарии по безопасности — зацепки, не приговор. «Здесь склеивают SQL» всё равно требует драйвер, роль и класс данных. Статья не показывает, как эксплуатировать эти строки — только отметил ли ревьюер. Если нужно ограничить запись агентов разработки: безопасное редактирование файлов через VFS — ревью только читает; диск пишет агент разработки.

CI: GitHub Actions, правила, ложные срабатывания

Когда локально завелось, команде нужны строчные комментарии в PR. Официальный composite Action чекаутит доверенную базу (не разворачивает недоверенное дерево форка), тянет git-объекты head, считает merge-base, гоняет ocr review --format json и постит строки плюс липкое резюме. Триггеры: PR opened/synchronized или комментарий /open-code-review.

Минимум прав: contents: read; pull-requests: write только чтобы постить. Ключи в Secrets, имена моделей в Variables. Форки не получают секреты репозитория — защита, не баг. Не склеивайте pull_request_target с checkout недоверенного кода ради авторевью форков; это утечка секретов. GitHub: Security hardening for GitHub Actions.

Правила в четыре слоя: --rule, проектный .opencodereview/rule.json, глобальный домашний, встроенный. ocr rules check показывает победителя. merge_system_rule: true, чтобы две заметки про логи не стёрли чеклист NPE для Java. Исключить тесты, сгенерированное и vendor дешевле, чем потом спорить о ложных.

На macOS ревьюить Xcode-diff просто; держать runner живым — нет. Сборка: как выбрать GitHub Actions macOS Runner. Машина, которая не спит, с ключами без борьбы за квоту ноутбука, делает ревью повторяемым.