Туториал OpenCodeReview 2026: установка AI Code Review CLI от Alibaba, Git Diff, скан, Claude/GPT

Почему «ещё один Review Skill» не чинит ревью

В 2026 году у большинства команд боль не в том, что «AI-ревью нет». Боль в том, что вход ревью приклеен к универсальному Agent. Вы говорите Claude Code «посмотри этот PR» — он читает часть файлов, другую пропускает, номера строк иногда сдвигаются, а в следующий раз чуть другой промпт даёт другой характер замечаний. Официальный README называет эти боли прямо: дыры в покрытии, плывущие позиции, Skill на чистом естественном языке почти не отладить.

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

Представьте типичный вторник. Утром кто-то просит агента «review this», днём другой человек копирует другой чеклист, вечером CI вообще молчит, потому что чат нельзя вызвать из workflow. На стендапе спорят не про конкретный null-deref, а про то, «почему вчера модель это видела, а сегодня нет». Это не каприз качества промпта. Это отсутствие контракта на входе: нет списка файлов, который можно воспроизвести, нет связки, которую можно проверить глазами, нет правила, которое живёт в репозитории, а не в голове того, кто сегодня дежурит у окна.

Ещё хуже, когда команда пытается лечить симптом новым Skill. Skill умеет напоминать «посмотри тесты» и «не забудь i18n». Он не умеет гарантировать, что message_en.properties и message_zh.properties попадут в один контекст, и не умеет после факта прибить номер строки внешним локализатором. Чем толще Skill, тем увереннее звучит чат — и тем труднее понять, какой слой солгал: модель, промпт или случайный набор открытых вкладок.

Асимметричный вывод: водораздел не в том, кто сильнее — Claude или GPT, а в том, является ли вход ревью «детерминированной инженерией + Agent» — выбор файлов, связки и сопоставление правил гарантирует инженерия, модель отвечает только за динамический сбор улик. Усиливать нужно вход (ocr review / ocr scan / CI), а не ставить ещё один более толстый Review Skill. Концептуальный разбор «что такое harness» — в статье Omnigent Agent Harness 2026: разбор; здесь только практика: как поставить OpenCodeReview, прогнать Git Diff и скан, подключить Claude и GPT.

Ещё одно наблюдение, которое редко попадает в обзоры: чат-ревью отлично выглядит на демо, потому что diff рядом с курсором и человек может ткнуть пальцем. Оно плохо масштабируется в ночной обзор, в self-hosted runner и в «оставь JSON, чтобы бот написал комментарий». Если ваша команда уже пишет «агент должен пройти PR и оставить воспроизводимые замечания», спор про стиль предложений в чате закончился. Нужен CLI, у которого вход — Git и путь, а не удачная формулировка.

Что такое OpenCodeReview: Git Diff и полный скан

Сначала классификация, потом команды. OpenCodeReview — не ещё одно чат-окно, а два способа открыть один и тот же цикл ревью. Измерения те же: вход, исполнение, контекст и целевая аудитория. Если запомнить только это, остальное — детали установки и счетов.

На сайте и в описании npm-пакета философия сформулирована прямо: детерминированная инженерия закрывает шаги, которые нельзя ошибить, — точно выбирает файлы, связывает родственные в одну пачку (например message_en.properties и message_zh.properties), сопоставляет правила по признакам файла, затем внешние модули локализации и рефлексии поправляют номера строк и формулировки. Agent делает только динамические решения и динамический сбор улик: читает целый файл, ищет по репозиторию, смотрит другие файлы той же правки. Официальный бенчмарк — 50 открытых репозиториев, 200 реальных PR, 10 языков с перекрёстной разметкой; относительно универсального Agent (включая Claude Code) заявляют выше Precision / F1, примерно 1/9 токенов и быстрее финиш, но ниже Recall. Это сознательный обмен точности на шум, а не провал из-за того, что что-то не поймали.

Практический смысл двух входов простой. Человек днём правит ветку и хочет понять, что именно изменилось, — вход review, корм — Git Diff. Через месяц тот же человек принимает каталог без осмысленной истории или хочет базовый список проблем до того, как команда начнёт резать инкремент, — вход scan, корм — целые файлы. Ошибка новичков — подсунуть пустой commit в review, «чтобы хоть что-то пробежало». Это не экономия. Это вы заставляете инженерный слой смотреть не тот вход.

Ещё одна деталь, которую стоит зафиксировать до установки: OCR не обещает заменить продуктовое ревью архитектуры и не обещает править файлы за вас. Это вход ревью со сменным модельным бэкендом. Если вам нужен интерактивный diff в редакторе и живой диалог «давай перепишем этот модуль», это другой слой. Здесь речь о том, чтобы один и тот же набор файлов, связок и правил пережил смену Claude на GPT без переписывания чеклиста в чате.

OCR vs Claude Code / Copilot / человек

Если при выборе первым делом спрашивать «Claude сильнее или GPT?», реальная разница ускользает. Поставьте OpenCodeReview, универсальный Agent Skill, встроенное ревью IDE и человека в одну таблицу — по входу, исполнению, контексту и аудитории — и вывод почти сразу переворачивается. Жанр рейтингов моделей здесь не нужен. Нужен ответ: стоит ли вынимать ревью из чата.

Как слоить ключи в мультимодельном coding harness — в статье Установка Pi Coding Agent и мультимодели. Тот текст отвечает, как менять бэкенд, когда агент пишет код. Этот — как вынуть вход ревью из чата и сделать из него воспроизводимый CLI.

Есть соблазн «оставить Claude Code для правок, а OCR поставить рядом на всякий случай». Так можно, если вы честно делите задачи: интерактивный diff и переписывание модуля — в хост-агенте, воспроизводимое ревью — в ocr review. Плохо, когда оба инструмента комментируют одни и те же файлы без общих правил. Тогда Skill в чате и файл правил OCR расходятся, и вы снова спорите с двумя характерами моделей вместо одного контракта репозитория.

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

Как установить и подключить LLM

Предварительные условия

Официальное жёсткое требование — Git ≥ 2.41: генерация diff, поиск по коду и операции с репозиторием идут через Git. Сначала git --version; на старом дистрибутиве обновите Git, потом ставьте CLI. Node — не единственный путь установки, но npm в документации — путь по умолчанию. На облачном Mac имеет смысл сначала зафиксировать Git и PATH в образе, потом ставить глобальный пакет: иначе утром ocr есть в интерактивной сессии, а ночью в launchd его уже нет.

npm install -g @alibaba-group/open-code-review
ocr version
ocr --help
which ocr

После установки ocr должен быть в PATH. Если видите command not found, проверьте, попал ли глобальный bin npm в PATH. Не путайте «пакет встал» с «ревью уже работает»: без конфигурации LLM всё, кроме Delegation Mode, сразу падает. Это частая «поломка», на которую жалуются как на баг CLI. На самом деле не собран слой ключей. Проверка занимает минуту: ocr llm test должен пройти, иначе дальше нет смысла спорить про флаги Git.

Глобальный CLI — вход для человека и для скрипта на этой машине. Не ждите, что та же установка автоматически станет версией для CI. В Actions позже появится официальный action или отдельный бинарник на раннере. Человек обновляет глобальный пакет, когда удобно; CI живёт на версии, которую вы явно закрепили. Если смешать эти два ритма, получите «у меня локально другой каталог моделей, чем в workflow».

Другие способы установки

Для базового образа CI и безголовой среды есть скрипт установки (оборачивает бинарник из GitHub Release и проверяет его):

curl -fsSL https://raw.githubusercontent.com/alibaba/open-code-review/main/install.sh | sh
# OCR_INSTALL_DIR=/usr/local/bin（默认）
# OCR_VERSION=v1.2.3   # 可选：钉某个 release

Если Node ставить не хотите, тяните статический бинарник из GitHub Releases; если собрались править сам OCR — собирайте из исходников (Go ≥ 1.25 + Make). Платформенные детали смотрите в руководстве по установке: номера версий плывут, форма команд стабильнее, чем «имя модели на конкретный месяц».

Сначала модель, потом ревью

Конфигурация лежит в ~/.opencodereview/config.json. Интерактивный путь самый дешёвый по нервам: ocr config provider выбирает встроенного или своего поставщика, принимает ключ, выбирает модель и сам гоняет проверку связи; потом модель меняете через ocr config model. Скрипты и CI идут через неинтерактивный ocr config set.

ocr config provider    # 选 anthropic / openai / 自定义
ocr config model       # 为当前供应商选模型
ocr llm test           # 再测一次连通性
ocr llm providers      # 列出内置供应商

Слои ключей легко запутать, если относиться к ним как к «просто env». Практичное правило: ноутбук разработчика — интерактивный провайдер или переменные в shell profile; общая облачная машина — машинный config.json с закрытыми правами и без git; CI — Secrets репозитория, которые живут в процессе только на время job. Если три слоя пересечь без схемы, вы не поймёте, почему ночной job внезапно начал бить в личный ключ из домашнего каталога раннера.

Три режима ревью Git Diff на практике

Приёмка установки — это не ocr version. Приёмка — первый прогон в настоящем репозитории, из которого вышла хотя бы одна реплика с номером строки. Три входа закрывают локальные правки, сравнение веток и один конкретный commit.

cd your-project

# 工作区：暂存 + 未暂存 + 未跟踪
ocr review

# 分支：相对 merge-base 审 feature 相对 main 的变更
ocr review --from main --to feature-branch

# 单个 commit
ocr review --commit abc123

# 中断后续跑
ocr session list
ocr review --from main --to feature-branch --resume <session-id>

# 给宿主 Agent 或 CI 落盘
ocr review --format json --output result.json

Режим рабочей копии подходит сюжету «поправил, PR ещё не открыл, сначала поругай себя». Режим веток подходит CI: base — ветка по умолчанию, head — голова PR. Один commit подходит, чтобы переиграть проблемную посадку. Крупную правку режут на несколько bundle; каждый bundle — субагент с изолированным контекстом. Официально эта декомпозиция как раз держит огромный changeset, чтобы его не «забыли» посередине.

Если первый прогон отвечает no valid LLM endpoint configured, в цепочке конфигурации нет полной тройки (URL, token, model). По официальному FAQ: пишите ~/.opencodereview/config.json, либо экспортируйте OCR_LLM_URL / OCR_LLM_TOKEN / OCR_LLM_MODEL, либо переиспользуйте уже живые ANTHROPIC_* из Claude Code. OCR берёт первую полную тройку, а не последнюю: если файл конфигурации уже собран, переменные окружения игнорируются. Это ловушка для тех, кто «починил ключ в env», не заметив, что в config.json уже лежит старый endpoint.

Критерий приёмки на маленьком PR простой и жёсткий. Возьмите одну дыру с нулевым указателем, одну очевидную дыру в тестах и одну стилистическую мелочь. Прогон считается успешным, если первые две точки попали в нужные строки, а мелочь не раздулась в половину отчёта. Длина абзаца модели — не метрика. Если команда принимает «ревью прошло», потому что JSON не пустой, вы снова купили шум, только теперь в файле.

Сессии стоит относиться как к операционному объекту, а не к отладочной мелочи. Длинный прогон на ноутбуке оборвётся крышкой, сетью или лимитом токенов. ocr session list и --resume существуют именно для этого. Но resume не откатывает побочные эффекты на стороне CI: если вы уже опубликовали черновой комментарий в PR, повторный прогон нужно спланировать как идемпотентную запись, а не как «ну ещё раз». Это уже договор команды, не флаг CLI.

Как пользоваться полным сканом ocr scan

ocr review отвечает на вопрос «что изменилось в этой правке». ocr scan отвечает на вопрос «насколько этот каталог сейчас безопасен и понятен». Когда осмысленного diff нет — только что склонированный чужой репозиторий, базовая линия ревью с нуля, каталог почти без коммитов — не изобретайте пустой commit, чтобы обмануть review.

ocr scan                          # 扫描整个仓库
ocr scan --path internal/agent    # 目录或具体文件
ocr scan --resume <session-id>    # 中断后恢复

Скан дороже diff: токены и время считаются по «целому файлу», а не по «скольким строкам коснулись». По умолчанию сначала сканируйте поддерево, которое вы реально принимаете, а не весь vendor/ и не генерацию. Правила и фильтры путей — в официальных Review Rules; сначала исключите зависимости и артефакты, потом спорьте про модель.

Типичная ошибка внедрения — повесить ocr scan на каждый PR «на всякий случай». Вы получите повтор исторического шума, счёт как за аудит всего склада и команду, которая через две недели отключит пайплайн. Договор проще: один раз (или редко) скан строит базовый список; каждый PR смотрит только инкремент через review. Если после скана список не уехал в тикеты и не породил правила, вы просто сожгли токены ради отчёта, который никто не откроет.

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

Как подключить Claude и GPT и как читать результат

Среди встроенных поставщиков anthropic ходит на https://api.anthropic.com, ключ берёт из ANTHROPIC_API_KEY; openai ходит на https://api.openai.com/v1, ключ — OPENAI_API_KEY. Если providers.*.api_key не записан, откат идёт в соответствующую переменную. Если на машине уже живёт Claude Code, OCR подхватит и ANTHROPIC_*. Это удобно для ноутбука и опасно для общего раннера: чужой интерактивный ключ не должен стать ночным ключом CI по случайности.

# Claude
ocr config set provider anthropic
ocr config set model claude-opus-4-6
ocr config set providers.anthropic.api_key "$ANTHROPIC_API_KEY"
ocr llm test

# GPT（OpenAI）
ocr config set provider openai
ocr config set model gpt-4o
ocr config set providers.openai.api_key "$OPENAI_API_KEY"
ocr llm test

# 自定义 OpenAI 兼容网关
ocr config set provider my-gateway
ocr config set custom_providers.my-gateway.url https://gateway.internal.com/v1
ocr config set custom_providers.my-gateway.protocol openai
ocr config set custom_providers.my-gateway.model llama-3-70b
ocr config set custom_providers.my-gateway.api_key "$MY_API_KEY"

Идентификаторы моделей плывут вместе с каталогом поставщика. В официальных примерах мелькали claude-opus-4-6 и gpt-4o; в проде ориентируйтесь на то, что сейчас отдаёт ocr config model, и не вшивайте снимок из блога в workflow. На 401 / 403 сначала сверьте протокол: Anthropic идёт через /v1/messages, совместимый OpenAI — через /v1/chat/completions; llm.protocol / use_anthropic должны быть из того же семейства, что и URL. Неверная семья протокола выглядит как «ключ плохой», хотя ключ живой.

Один репозиторий, один diff: что смотреть при смене бэкенда

Практический прогон — не соревнование «у кого предложение длиннее». Зафиксируйте маленький PR: один риск нулевого указателя, одна очевидная дыра в тестах, одна стилистическая мелочь. Прогоните Claude и GPT командой ocr review --from main --to HEAD --format json --output out.json и смотрите три вещи: попали ли обязательные дефекты в нужные строки, удалось ли придавить стилистический шум, влезают ли токены и настенные часы в бюджет CI. Официальный бенчмарк смотрит в сторону высокой точности, низкого шума и малого числа токенов. Если GPT дешевле, но приносит втрое больше придирок, люди в CI выключат весь пайплайн — и вы вернётесь к чату, только злее.

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

- name: Open Code Review
  uses: alibaba/open-code-review@main
  with:
    provider: openai
    model: gpt-4o
    api-key: ${{ secrets.OPENAI_API_KEY }}

Есть также GitLab CI, Gerrit и GitFlic. Ключ кладите в Secrets репозитория, не в файл workflow. Как слоями резать self-hosted macOS runner и облачный Mac — в статье GitHub Actions macOS самостоятельный Runner и облачный Mac.

Политика падения в CI должна взрослеть отдельно от выбора модели. Первую неделю разумнее писать комментарий и не блокировать merge: вы измеряете шум, а не наказываете автора. Когда ложные срабатывания стабилизировались и правила лежат в репозитории, сигнал можно сделать жёстким засовом. Если начать с блокировки на сыром каталоге моделей, команда научится обходить job, а не читать JSON.

Как выбирать по сценарию

Спрашивать нужно не «ставить ли OpenCodeReview», а какой первый ограничитель. Нужно воспроизводимое ревью diff, аудит каталога без diff — или достаточно устного мнения в чате. Если честно ответить на этот вопрос, таблица ниже почти не оставляет места для спора про имя модели.

Если сомневаетесь между «оставить чат» и «переехать на OCR на этой неделе», задайте один вопрос: появится ли в ближайший месяц требование «повторно прогнать тот же PR и получить тот же набор файлов». Нет — оставайтесь в привычном окне. Да, и вы уже хотите JSON в CI — ставьте CLI, но не выкидывайте хост-агент в первый день. Неделя параллельной работы дешевле, чем большой взрыв «теперь всё через ocr».

Рекомендуемые комбинации

Инструменты можно складывать. OpenCodeReview закрывает задачу «воспроизводимый вход ревью»; он не даст вам Mac, который не засыпает, и не оплатит счета Claude или GPT.

• Личная ежедневная связка: глобальный ocr + ANTHROPIC_API_KEY или OPENAI_API_KEY + ocr review по рабочей копии. Перед PR прогоните один раз; файл правил положите в репозиторий.
• Связка PR / CI: ocr review --from base --to head --format json + официальный GitHub Action + Secrets. Политика падения сначала «комментарий, не блок»; когда шум стабилизируется — жёсткий засов.
• Связка базового аудита: при первой приёмке ocr scan --path строит список проблем, дальше на инкремент только review. Не сканируйте весь репозиторий на каждый PR.
• Связка с уже живым Coding Agent: локально по-прежнему пишете в Claude Code / Cursor, ревью идёт через ocr delegate или через модель, которой управляет сам OCR. Писать и ревьюить можно разными ключами.
• Минимальная проверка: только CLI, только один ключ, в маленьком репозитории ocr review на правках рабочей копии. Четыре такта (установка → учётные данные → один review → один scan) — и только потом CI.

Типичная рабочая неделя после минимальной проверки выглядит так. Понедельник: один ключ и рабочая копия, правите привычные файлы. Среда: тот же diff через --from/--to, сверяете строки, а не длину абзацев. Пятница: JSON в Actions на постоянно включённом узле. Если пятница ломается, причина почти всегда PATH, тройка endpoint или секрет — не «модель глупая».

Мультиагентный класс или толстый планёр — не домашняя территория OCR. Здесь один цикл «выбрать файлы — связать — сопоставить правила — собрать улики». Если команда уже держит внутренний шлюз к моделям, OCR всё равно может остаться слоем ревью: шлюз отдаёт ключ, CLI крутит Git и правила. Не пытайтесь заменить этим циклом архитектора и не пытайтесь заменить им IDE.

Частые заблуждения

• Считать OCR бесплатным клоном Claude Code. Выбор файлов и номера строк сюда сознательно забрали у модели. Вам нужно покрытие ревью, а не ещё одно чат-окно, которое умеет править файлы.
• Без LLM винить «установку сломали». Кроме Delegation Mode нужна полная тройка endpoint. Пока ocr llm test не проходит, не начинайте крутить параметры Git.
• Подменять каждый PR-ревью сканом. Полный скан дорогой и заново поднимает исторический шум. Инкремент — review, база — scan.
• Вшить идентификатор модели из блога в Action. Каталог плывёт. model в Action — изменяемый вход; сначала проверьте его локально через ocr config model.
• Положить личный подписочный ключ в CI. CI берёт Secrets репозитория или машинный config.json с зажатыми правами. Корпоративный код не направляйте на неаудированный шлюз.
• Гонять полный скан репозитория на ноутбуке, который засыпает. Сессию можно --resume, но настенные часы и счёт будут выглядеть плохо. Длинный скан — на постоянно включённый узел.

Отдельно стоит миф «раз модель сменная, безопасность решена». Сменный бэкенд только уменьшает зависимость от одного вендора. Он не заменяет аудит того, куда уезжает diff, ротацию ключей и принцип наименьших прав. Если раннер один на всю компанию и на нём лежат и личный ключ разработчика, и прод-секрет без изоляции job, вы собрали единую точку отказа аккуратнее, чем чат, но не безопаснее.

Второй миф — «JSON на диске уже и есть качество». Файл лишь делает результат наблюдаемым. Если никто не смотрит ложные срабатывания и не возвращает их в правила репозитория, вы построили дорогой генератор комментариев. Правило, которое нельзя найти в git, снова превращается в Skill в чьей-то голове.

Шаги внедрения

1. Запишите то, чем нельзя поступиться: нужно только локальное саморевью, только комментарий в CI или оба входа; обязательны ли Claude и GPT на первой неделе; CI сначала комментирует или сразу блокирует.
2. Поставьте CLI и сделайте холостой прогон: npm install -g @alibaba-group/open-code-review, ocr version, проверьте PATH и Git ≥ 2.41.
3. Подключите только один ключ: ocr config provider или ocr config set, дальше только после зелёного ocr llm test.
4. Прогоните ocr review на настоящем маленьком PR: рабочая копия или --from/--to. Критерий приёмки — «строки попали, обязательное поймали», а не «замечание длиннее».
5. Добавьте один ocr scan --path: сканируйте только поддерево, которое принимаете; зафиксируйте разделение труда: база против инкремента.
6. Потом решайте про второго поставщика или Delegation: на том же diff смените Claude / GPT и сравните ложные срабатывания и цену; если хост-агент уже жив, попробуйте ocr delegate.
7. Выберите среду исполнения и только потом входите в CI: локально — чтобы выучить команды; ночной скан и засов — на постоянно включённый облачный Mac или self-hosted runner, логи без секретов, ключи не в артефактах.

Не перескакивайте через третий шаг. Команды часто ставят сразу два ключа, Action и полный скан — и потом не могут сказать, какой слой сломался. Один ключ и один воспроизводимый ocr review отсекают половину тикетов ещё до разговора про модели. Если третий шаг падает, чините тройку endpoint, а не пишите новый Skill.

FAQ

Как связаны OpenCodeReview и Claude Code?

Claude Code — официальный coding workflow Anthropic: писать код и устно ревьюить можно в одном окне. OpenCodeReview — открытый CLI ревью от Alibaba: модель можно сменить на Claude, GPT или совместимый endpoint. Он не заменяет «глубокую официальную правку файлов». Он заменяет сюжет «покрытие ревью и номера строк целиком держатся на промпте».

Обязательно ли сразу настраивать и Claude, и GPT?

Нет. Одного ключа достаточно, чтобы пройти приёмку установки. Смысл второго ключа: один и тот же выбор файлов и одни правила, а бэкенд меняется под цену и уровень шума. Пока второго счёта нет, не расширяйте эксплуатацию ради слова «сравнение».

Можно ли подменять ocr review и ocr scan друг другом?

Нельзя считать их одной командой. Review ест Git Diff и подходит PR и локальным правкам; scan ест целые файлы и подходит аудиту без diff. Неверный вход — это не «модель недостаточно умна». Это вы заставили инженерный слой смотреть не тот корм.

Можно ли ставить на Windows и на безголовый облачный Mac?

Да. Глобальный npm-пакет кроссплатформенный; скрипт установки покрывает darwin / linux на amd64 и arm64, на Windows берите бинарник из Release или npm. На безголовой машине используйте неинтерактивный ocr config set и --format json, не рассчитывайте на TUI. На облачном Mac сначала зафиксируйте Git, PATH и права ~/.opencodereview.

Зачем тогда облачный Mac, если npm ставится и локально?

Локальной машины хватает, чтобы выучить команды. Её не хватает для ночного полного скана, для засова PR после того, как крышка закрылась, и для CI, который делит среду с Xcode и подписью. ocr отвязал модель, но Git и файловые инструменты по-прежнему живут на той машине, где крутится процесс.

Что делать, если строки в JSON всё же не совпали с файлом?

Сначала проверьте, что смотрите тот же commit и тот же путь, а не «почти ту же» рабочую копию с лишним незакоммиченным хвостом. Затем смотрите, не уехал ли файл после прогона: OCR прибивает строки инженерным слоем, но он не может удержать номер, если вы уже переписали файл под ним. Если расхождение повторяется на чистом diff, это уже тикет к правилам и к локализатору, а не повод возвращаться к чату как к источнику истины.

Итог

Туториал OpenCodeReview на поверхности — это npm, переменные окружения и пара команд ocr review / ocr scan. По-настоящему внедрить нужно слоёный договор: детерминированную инженерию отделить от модели, вход Git Diff — от полного скана, интерактивную конфигурацию — от конфигурации CI. Устойчивая практика на сентябрь 2026 года выглядит так: на своей машине один ключ и живой review, правила в репозитории, в CI Secrets и JSON на диске, scan — только для базы.

Асимметричный вывод держится: водораздел не в том, кто сильнее — Claude или GPT, а в том, умеете ли вы сделать вход ревью жёстким ограничением. Сначала доведите до конца один ocr review на одном ключе, потом добавьте scan и второго поставщика; когда понадобится поверхность исполнения, перенесите процесс с засыпающего ноутбука на облачный Mac. Усиливать нужно вход, учётные данные и узел — а не ставить ещё один Review Skill.

Если после этой статьи останется только одно действие на сегодня, пусть это будет не «сравнить две модели в чате». Поставьте CLI, соберите тройку endpoint, прогоните маленький PR и посмотрите, попали ли две обязательные дыры в нужные строки. Если да — у вас появился вход, который можно повторить. Если нет — чините конфигурацию и правила, а не ищите более красноречивую модель.