OpenCodeReview Tutorial 2026: Alibabas AI-Code-Review-CLI installieren, Git Diff, Scan, Claude/GPT

Warum ein weiteres Review-Skill die Prüfung nicht löst

2026 leiden die meisten Teams nicht unter „zu wenig KI-Review“, sondern unter einem Review-Einstieg, der an einem allgemeinen Coding-Agenten klebt. Sie schreiben in Claude Code „review this PR“, das Modell liest einen Teil der Dateien, überspringt einen anderen, die Zeilennummern in den Kommentaren rutschen gelegentlich, und beim nächsten Prompt schwankt die Qualität erneut. Das offizielle README benennt genau diese Schmerzen: lückenhafte Abdeckung, Positionsdrift, schwer debugbare Skills, die nur aus natürlicher Sprache bestehen.

Die Ursache ist nicht ein zu dummes Modell. Eine rein sprachgetriebene Architektur legt dem Review-Prozess keine harten Constraints auf. Ob eine Datei in diesen Lauf gehört, ob verwandte Dateien zusammenbleiben müssen, welche Regel auf welche Dateiklasse fällt — das sind Schritte, die „einfach nicht falsch sein dürfen“. Trotzdem landen sie in derselben Chat-Session wie das Formulieren der Hinweise. Claude gegen GPT zu tauschen ändert nur die Art, wie Dateien übersehen werden. Der Kommentar klingt höflicher oder schärfer; die Lücke im Diff bleibt.

Wer das schon erlebt hat, kennt das Muster: Ein Skill mit drei Absätzen „sei gründlich, nenne Zeilen, ignoriere Style-Nits“ wirkt in der Demo stark. Im nächsten Sprint ändert jemand die Prompt-Datei, ein Junior öffnet nur die halbe PR, ein Modell-Update schreibt Zeilennummern als ungefähre Schätzung. Sie können das nicht in CI reproduzieren, weil der Einstieg ein Gespräch war und kein Befehl mit festem Eingang. Genau deshalb hilft „noch ein dickeres Review-Skill“ nicht — es verdoppelt die Hoffnung, nicht die Garantie.

Die asymmetrische Schlussfolgerung lautet: Die Trennlinie liegt nicht bei Claude oder GPT, sondern beim Review-Einstieg „deterministisches Engineering plus Agent“ — Dateiauswahl, Bündelung und Regelzuordnung sichert das Engineering, das Modell beschafft nur dynamisch Belege. Was Sie upgraden sollten, ist der Einstieg (ocr review / ocr scan / CI), nicht ein weiterer Review-Skill. Eine begriffliche Zerlegung, was ein Harness überhaupt ist, finden Sie unter Omnigent Agent Harness 2026 erklärt; dieser Text löst nur: OpenCodeReview installieren, Git Diff und Scan durchziehen, Claude und GPT anbinden.

Für DACH-Teams kommt ein organisatorisches Argument hinzu. Wenn Review-Qualität von der Tagesform eines Chatfensters abhängt, können Sie weder Gate-Policies noch Audit-Spuren sauber halten. Ein reproduzierbarer CLI-Einstieg macht aus „das Modell hat irgendetwas gesagt“ ein Artefakt: JSON mit Dateipfad, Zeile, Regel-ID. Ob Sie das später als Kommentar oder als hartes Gate nutzen, ist eine zweite Entscheidung. Zuerst brauchen Sie einen Einstieg, der dieselbe Diff-Menge morgen wieder findet.

Was OpenCodeReview ist: Git Diff und Vollscan

Erst klassifizieren, dann Befehle. OpenCodeReview ist kein weiteres Chatfenster, sondern zwei Öffnungen derselben Review-Schleife. Die Dimensionen bleiben Einstieg, Ausführung, Kontext und Zielgruppe. Wer das verwechselt, kauft sich entweder einen teuren Vollscan für jeden PR — oder versucht, eine Baseline ohne sinnvollen Diff mit ocr review zu erzwingen.

Website und npm-Paketbeschreibung formulieren die Philosophie klar: Deterministisches Engineering übernimmt die Schritte, die nicht falsch sein dürfen — Dateien präzise wählen, verwandte Dateien zu einem Bündel schnüren (etwa message_en.properties und message_zh.properties), Regeln nach Dateimerkmalen zuordnen, danach Zeilen und Inhalt über externe Lokalisierungs- und Reflexionsmodule korrigieren. Der Agent entscheidet dynamisch und beschafft Belege: volle Dateien lesen, im Repo suchen, andere Dateien derselben Änderung ansehen. Der offizielle Benchmark nutzt 50 Open-Source-Repos, 200 echte PRs und zehn Sprachen mit Kreuzannotation. Gegenüber allgemeinen Agenten (einschließlich Claude Code) werden höhere Precision und F1, etwa ein Neuntel der Tokens und schnellere Laufzeiten beansprucht — bei niedrigerem Recall. Das ist bewusst Präzision gegen Rauschen getauscht, kein Versagen, nur weil etwas nicht gemeldet wurde.

Lesen Sie diese Kennzahlen als Produktentscheidung, nicht als Modell-Werbung. Ein Chat-Agent, der „lieber einmal zu viel warnt“, erzeugt in CI Lärm, bis jemand den Job abschaltet. OpenCodeReview zielt auf Hinweise, die Sie einer Zeile zuordnen und in einem Ticket stehen lassen können. Wenn Ihr Team eher Brainstorming im Diff will, bleibt der allgemeine Agent die bessere Oberfläche. Wenn Sie Abdeckung und reproduzierbare Zeilen brauchen, ist der CLI-Einstieg die eigentliche Kaufentscheidung — das Modell dahinter ist austauschbar.

Praktisch heißt Bündelung: i18n-Paare, generierte und handgeschriebene Zwillinge, Test und Implementierung derselben Änderung sollen nicht in isolierten Mini-Kontexten landen. Das Engineering entscheidet, welche Dateien zusammen dem Sub-Agenten gehören. Das Modell darf innerhalb dieses Bündels Belege holen, aber nicht heimlich die halbe PR weglassen. Genau das unterscheidet „ein Agent hat irgendwelche Dateien geöffnet“ von „dieser Lauf hat denselben Eingang wie gestern“.

OCR vs. Claude Code / Copilot / Mensch

Wenn Sie bei der Auswahl zuerst fragen „ist Claude stärker oder GPT?“, verpassen Sie den echten Unterschied. Legen Sie OpenCodeReview, allgemeine Agent-Skills, IDE-integriertes Review und menschliche Prüfung auf dieselbe Tabelle — ausgerichtet nach Einstieg, Ausführung, Kontext und Zielgruppe. Dann sehen Sie, welches Werkzeug welche Arbeit tatsächlich übernimmt und wo Sie Steuern zahlen, ohne den Nutzen zu bekommen.

Wie Sie Schlüssel in einem Multi-Modell-Coding-Harness verlegen, steht unter Pi Coding Agent Installation und Multi-Modell. Jener Text beantwortet „wie wechsle ich das Backend zum Schreiben“; dieser beantwortet „wie ziehe ich den Review-Einstieg aus dem Chat in eine reproduzierbare CLI“. Die beiden Fragen zu vermischen ist der häufigste Beschaffungsfehler: Teams kaufen ein stärkeres Schreibmodell und wundern sich, warum PR-Kommentare weiter springen.

Menschliches Review ersetzen Sie mit OCR nicht. Architektur-Absicht, Produktkontext und die letzte Freigabe bleiben bei Menschen, die das System tragen. Was die CLI übernimmt, ist der Teil, der 2026 oft im Chat versickert: dieselbe Diff-Menge, dieselben Regeln, ein Artefakt, das CI und Ticket-Systeme fressen können. Copilot-Kommentare auf der PR-Seite sind bequem, wenn Sie bereits fest im GitHub-Ökosystem sitzen — skriptbar und vendor-unabhängig sind sie selten. Wählen Sie bewusst, welche Schicht Sie automatisieren und welche Sie weiter selbst lesen.

Installation und LLM-Konfiguration

Voraussetzungen

Die harte offizielle Anforderung ist Git ≥ 2.41: Diff-Erzeugung, Codesuche und Repo-Operationen laufen über Git. Prüfen Sie zuerst git --version und heben Sie ältere Distributionen an, bevor Sie die CLI installieren. Node ist nicht der einzige Installationsweg, npm ist aber der in der Dokumentation empfohlene Default. Auf einem frischen Cloud-Mac oder CI-Image scheitert der erste Lauf häufiger an einem zu alten System-Git als am npm-Paket.

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

Nach der Installation muss ocr in PATH liegen. Bei command not found prüfen Sie, ob das globale npm-Bin-Verzeichnis in PATH ist. „Erfolgreich installiert“ heißt nicht „kann schon reviewen“ — ohne LLM-Konfiguration schlägt der Lauf außerhalb des Delegation Mode direkt fehl. Das ist Absicht: Die CLI weigert sich, einen Review ohne vollständiges Backend zu simulieren.

Weitere Installationswege

CI-Basisimages und Headless-Umgebungen können das Installationsskript nutzen (packt das GitHub-Release-Binary und prüft es):

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

Wenn Sie kein Node wollen, holen Sie das statische Binary von GitHub Releases; wer OCR selbst ändern will, baut aus dem Quellcode (Go ≥ 1.25 plus Make). Plattformdetails stehen im Installationsleitfaden. Versionsnummern ändern sich; die Befehlsform ist stabiler als „der Modellname vom 18. September“. Pinning lohnt sich in CI: eine bekannte OCR_VERSION ist leichter zu debuggen als „was das Skript heute gezogen hat“.

Zuerst das Modell, dann das Review

Die Konfiguration liegt in ~/.opencodereview/config.json. Interaktiv ist am sparsamsten: ocr config provider wählt einen eingebauten oder eigenen Anbieter, nimmt den Schlüssel, wählt das Modell und testet die Verbindung; danach wechseln Sie mit ocr config model. Skripte und CI nutzen das nicht-interaktive ocr config set. Mischen Sie die beiden Wege nicht unnötig: Lokal einmal interaktiv, auf dem Runner nur noch deklarativ.

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

Der Connectivity-Test ist die eigentliche Installationsabnahme, nicht ocr version. Wenn ocr llm test scheitert, debuggen Sie URL, Token und Modell-ID — nicht Git-Flags und nicht die Diff-Größe. Viele „die CLI ist kaputt“-Tickets lösen sich in einem unvollständigen Triple auf: Datei hat URL und Modell, Token sitzt in einer anderen Shell, oder umgekehrt.

Für Teams mit Compliance-Vorgaben ist dieser Absatz die eigentliche Freigabegrenze. Ein Review-CLI, das Diffs an einen Endpunkt sendet, ist datentechnisch näher an einem gehosteten Coding-Agenten als an einem lokalen Linter. Nutzen Sie firmengeprüfte Gateways, Protokoll anthropic oder openai hinter dem Proxy, und halten Sie ~/.opencodereview auf dem CI-Host mit engen Rechten. Persönliche ChatGPT- oder Claude-Abos in die Pipeline zu legen ist bequem und in den meisten Orgs falsch.

Drei Git-Diff-Review-Modi in der Praxis

Die Installationsabnahme ist nicht ocr version, sondern der erste zeilennummerierte Hinweis in einem echten Repo. Drei Einstiege decken lokale Änderungen, Branch-Vergleich und einzelnen Commit ab. Laufen Sie das nicht in einem Spielzeug-Ordner ohne Git-Historie — sonst testen Sie nur, ob das Binary startet, nicht ob der Review-Einstieg greift.

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

Der Arbeitskopie-Modus eignet sich für „fertig geändert, PR noch nicht geöffnet, erst selbst gegenlesen“. Der Branch-Modus gehört in die CI: Base ist der Default-Branch, Head der PR-Kopf. Der Einzel-Commit eignet sich, um eine problematische Übergabe noch einmal abzuspielen. Große Änderungen werden in mehrere Bundles zerlegt; jedes Bundle ist ein Sub-Agent mit isoliertem Kontext. Offiziell dämpft diese Teilung das Übersehen in sehr großen Changesets. Wenn Ihre PR hundert Dateien berührt, ist das kein Grund, zurück in den Chat zu gehen — es ist der Fall, für den die Bündelung gebaut wurde.

Scheitert der erste Lauf mit no valid LLM endpoint configured, fehlt in der Kette das vollständige Triple (URL, token, model). Laut offizieller FAQ: ~/.opencodereview/config.json schreiben, oder OCR_LLM_URL / OCR_LLM_TOKEN / OCR_LLM_MODEL exportieren, oder vorhandene Claude-Code-ANTHROPIC_*-Variablen wiederverwenden. OCR nimmt das erste vollständige Triple, nicht das letzte — ist die Datei vollständig, werden Umgebungsvariablen ignoriert. Das überrascht in CI, wenn Secrets gesetzt sind, die Datei auf dem Runner aber schon ein unvollständiges, älteres Triple enthält.

JSON-Ausgabe ist der Haken für Host-Agenten und Gates. Menschen lesen den Terminal-Bericht; Pipelines brauchen --format json --output result.json. Speichern Sie das Artefakt neben den Logs, nicht nur in der Job-Zusammenfassung. Ein späteres „warum hat der Lauf das übersehen?“ lässt sich an Datei plus Session-ID klären, nicht an einem Screenshot aus dem Chat. --resume ist für lange Branch-Reviews gedacht, nicht als Ersatz für einen dauerhaft laufenden Host — unterbrochene Sessions auf einem schlafenden Laptop werden teuer und unübersichtlich.

ocr scan: Vollscan richtig einsetzen

ocr review beantwortet „was hat sich diesmal geändert“; ocr scan beantwortet „ist dieses Verzeichnis jetzt sicher / verständlich“. Fehlt ein sinnvoller Diff — frisch geklontes fremdes Repo, Baseline von null, Verzeichnis fast ohne Commits — fälschen Sie keinen leeren Commit, nur um review zu täuschen. Der falsche Einstieg erzeugt entweder leere Ergebnisse oder eine künstliche Diff-Geschichte, die niemand später nachvollzieht.

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

Scan ist teurer als Diff: Tokens und Zeit laufen über „ganze Dateien“, nicht über „geänderte Zeilen“. Standardmäßig scannen Sie zuerst den Teilbaum, den Sie wirklich übernehmen — nicht sofort vendor/ und generierte Artefakte im ganzen Repo. Regeln und Pfadfilter stehen in den offiziellen Review Rules; erst Abhängigkeiten und Build-Produkte ausschließen, dann über Modelle sprechen. Ein Scan, der node_modules und generierte Protobuf-Dateien mitnimmt, erzeugt eine Liste, die niemand triageen will — und das Team schaltet den Job ab, bevor die nützlichen Treffer ankommen.

Die saubere Arbeitsteilung ist Baseline versus Inkrement. Einmal ocr scan --path auf dem fremden Modul, Treffer in Tickets oder einem kurzen Audit-Dokument, danach nur noch ocr review auf PRs. Jeden Pull Request voll zu scannen wiederholt historischen Lärm und sprengt CI-Budgets. Wenn Sie nach drei Monaten das Gefühl haben, die Baseline sei veraltet, scannen Sie erneut denselben Pfad — nicht das ganze Monorepo „weil wir gerade Zeit haben“.

Unterbrechung und Fortsetzen gelten auch hier. Ein nächtlicher Scan auf einem zugeklappten Notebook ist die teuerste Art, --resume zu lernen. Legen Sie lange Scans auf einen Host, der nicht schläft, und behandeln Sie die Session-ID wie eine Job-ID: loggen, nicht in einem Slack-Thread verlieren. Der Scan ersetzt weder SAST-Tools mit festen Regelwerken noch ein menschliches Onboarding. Er liefert eine erste, zeilenbezogene Liste, mit der Sie das Gespräch über ein fremdes Verzeichnis beginnen können.

Claude und GPT anbinden und Ergebnisse lesen

Bei den eingebauten Anbietern geht anthropic an https://api.anthropic.com, Schlüsselvariable ANTHROPIC_API_KEY; openai an https://api.openai.com/v1, Schlüsselvariable OPENAI_API_KEY. Fehlt providers.*.api_key, fällt OCR auf die jeweilige Umgebungsvariable zurück. Existiert bereits eine Claude-Code-Umgebung, liest OCR auch ANTHROPIC_*. Das ist praktisch lokal und gefährlich in CI, wenn dieselbe Maschine interaktive Entwicklerschlüssel und Pipeline-Secrets mischt.

# 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"

Modell-IDs ändern sich mit dem Anbieterkatalog. In offiziellen Beispielen tauchten claude-opus-4-6 und gpt-4o auf; in der Produktion gelten die Optionen aus ocr config model, nicht der Snapshot eines Blogposts. Bei 401 / 403 zuerst das Protokoll prüfen: Anthropic spricht /v1/messages, OpenAI-kompatibel /v1/chat/completions; llm.protocol / use_anthropic müssen zur selben Familie gehören wie die URL. Ein OpenAI-kompatibles Gateway hinter einer Anthropic-URL ist der schnellste Weg zu undurchsichtigen Auth-Fehlern.

Dasselbe Repo, derselbe Diff: worauf Sie beim Backend-Wechsel achten

Ein Praxistest vergleicht nicht „wessen Sätze länger sind“. Fixieren Sie einen kleinen PR: ein Null-Risiko, ein fehlender Test, ein Stil-Nit. Laufen Sie Claude und GPT jeweils mit ocr review --from main --to HEAD --format json --output out.json und prüfen Sie drei Dinge: hat der relevante Defekt die richtige Zeile, wurde Stil-Rauschen gedrückt, passen Tokens und Wandzeit ins CI-Budget. Der offizielle Benchmark zielt auf hohe Präzision, wenig Rauschen, wenig Tokens. Ist GPT günstiger, meldet aber dreimal so viele Nits, schalten Menschen in der CI die ganze Pipeline ab. Dann haben Sie kein billigeres Modell gekauft, sondern das Review zerstört.

Lesen Sie JSON, nicht nur die Prosa. Zählen Sie Treffer nach Schwere, prüfen Sie, ob Zeilen im aktuellen HEAD existieren, und notieren Sie die Wandzeit. Ein Backend, das in drei Minuten drei haltbare Hinweise liefert, schlägt eines, das in zwölf Minuten eine Essay-Liste ohne Zeilenanker schreibt. Genau deshalb ist die Trennlinie der Einstieg: Dieselbe Dateiauswahl und dieselben Regeln, zwei Backends, eine vergleichbare Datei. Ohne diesen Rahmen vergleichen Sie Chat-Stile, nicht Review-Systeme.

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

Unterstützt werden auch GitLab CI, Gerrit und GitFlic. Schlüssel gehören in Repo-Secrets, nicht in die Workflow-Datei. Die Schichtung selbstgehosteter macOS-Runner und Cloud-Macs steht unter GitHub Actions macOS selbstgehosteter Runner und Cloud-Mac. Pinning der Action auf einen Tag statt @main ist in regulierten Umgebungen sinnvoller; das Beispiel oben folgt der offiziellen Minimalform, nicht einem Produktions-Härtungsleitfaden.

Ein zweites Backend lohnt sich erst, wenn der erste Schlüssel durch ocr llm test und einen echten Review gelaufen ist. Sonst verdoppeln Sie Betriebsfläche, ohne eine Baseline für Fehlalarme zu haben. Delegation Mode ist der dritte Weg, kein Ersatz für diese Reihenfolge: Host-Agent vorhanden, OCR trotzdem installiert, Dateiauswahl und Regeln bleiben bei OCR, Inferenz beim Host. Wer Delegation als „dann brauchen wir ocr nicht“ liest, landet wieder beim Chat-Einstieg.

Szenarien wählen

Die echte Frage ist nicht „soll ich OpenCodeReview installieren“, sondern die erste Constraint: Brauchen Sie reproduzierbares Diff-Review, ein Audit ohne Diff — oder nur mündliche Hinweise im Chatfenster? Alles andere (welches Modell, welches Gateway, welcher Runner) folgt dieser Entscheidung. Wenn Sie die Constraint nicht aufschreiben, kaufen Sie Werkzeuge nach Demo-Eindruck und wundern sich, warum niemand den Job anfasst.

Zwei Zeilen der Matrix werden oft ignoriert. Erstens: Wenn Editieren Ihre Hauptarbeit ist und niemand JSON in die CI legen will, ist OpenCodeReview optionale Steuer — bleiben Sie im Agenten, mit dem Sie schon schreiben. Zweitens: Wenn Reviews nachts oder nach dem Zuklappen sterben, ist das kein Modellproblem. Git, PATH und ~/.opencodereview sitzen auf dem Host, der den Prozess trägt. Beheben Sie den Host, bevor Sie den Anbieter wechseln.

Empfohlene Kombinationen

Werkzeuge dürfen sich überlagern. OpenCodeReview löst den reproduzierbaren Review-Einstieg; es stellt Ihnen weder einen Mac, der nicht zuklappt, noch zahlt es Ihre Claude- oder GPT-Rechnung. Die folgenden Stapel sind bewusst klein. Ein Stapel, den das Team nicht in einer Woche erklären kann, wird nicht zum Standard.

• Alltag allein: globales ocr plus ANTHROPIC_API_KEY oder OPENAI_API_KEY plus ocr review in der Arbeitskopie. Vor jedem PR einmal laufen lassen, Regeldateien ins Repo. Das ist der kleinste Stapel, der den Chat-Einstieg ersetzt, ohne CI anzufassen.
• PR / CI: ocr review --from base --to head --format json plus offizielle GitHub Action plus Secrets. Fehlerstrategie zuerst „kommentieren, nicht blockieren“; erst wenn die Fehlalarmquote stabil ist, hartes Gate. Wer am ersten Tag blockiert, erntet Workarounds statt Disziplin.
• Baseline-Audit: beim ersten Übernehmen ocr scan --path für die Problemliste, danach nur Inkremente per review. Kein Vollscan pro PR. Die Liste gehört in Tickets, nicht in einen endlos wachsenden Slack-Thread.
• Vorhandener Coding-Agent: lokal weiter mit Claude Code / Cursor schreiben, Review über ocr delegate oder ein von OCR verwaltetes Modell. Schreiben und Prüfen trennen, Schlüssel dürfen getrennt bleiben. So vermeiden Sie, dass derselbe Agent die Änderung schreibt und sie anschließend „für gut“ erklärt, ohne festen Dateieinstieg.
• Minimale Verifikation: nur CLI, nur ein Schlüssel, in einem kleinen Repo ocr review gegen Arbeitskopie-Änderungen. Vier Takte durchziehen (Installation → Zugang → ein Review → ein Scan), erst dann CI. Überspringen Sie keinen Takt, nur weil die Demo auf dem Laptop „schon irgendwie“ lief.

Was Sie nicht stapeln sollten: drei Anbieter, Delegation und Vollscan-pro-PR in Woche eins. Jede zusätzliche Fläche braucht jemanden, der Fehlalarme triageet. Lieber ein Einstieg, den das Team vertraut, als eine Matrix, die nur in der Architekturfolie existiert.

Häufige Fehlgriffe

• OCR als kostenlosen Klon von Claude Code lesen. Es nimmt dem Modell absichtlich Dateiauswahl und Zeilennummern weg. Sie wollen Review-Abdeckung, nicht ein weiteres Chatfenster, das Dateien ändert. Wer OCR „wie einen Agenten“ promptet, zahlt die CLI-Steuer und behält den Chat-Schmerz.
• Ohne LLM-Konfiguration „die Installation ist kaputt“ rufen. Außerhalb des Delegation Mode brauchen Sie ein vollständiges Endpunkt-Triple. Scheitert ocr llm test, fangen Sie nicht an, Git-Parameter zu drehen. Zuerst URL, Token, Modell — in dieser Reihenfolge.
• Scan als Ersatz für jedes PR-Review. Vollscans sind teuer und melden historischen Lärm erneut. Inkrement über review, Baseline über scan. Ein Team, das jeden Merge voll scannt, schaltet den Job ab, sobald die Rechnung sichtbar wird.
• Modell-IDs aus dem Blog fest in die Action schreiben. Kataloge ändern sich. model in der Action ist ein änderbarer Input; zuerst lokal mit ocr config model prüfen. Ein hart kodiertes gpt-4o von September 2026 ist kein Vertragsgegenstand.
• Persönliche Abo-Schlüssel in die CI committen. CI nutzt Repo-Secrets oder eine maschinenweite config.json mit engen Rechten. Firmencode gehört nicht an ungeprüfte Gateways. Ein geleakter privater Schlüssel ist teurer als ein Tag Verzögerung beim Secret-Setup.
• Ganzen-Repo-Scan auf einem Notebook, das in den Ruhezustand geht. Sessions kennen --resume, Wandzeit und Rechnung sehen trotzdem schlecht aus. Lange Scans gehören auf dauerhafte Knoten. Resume ist Wiederherstellung, kein Ersatz für einen Host, der durchläuft.

Ein siebter, stiller Fehler: Review-Regeln nur lokal halten. Wenn jede Entwicklerin eine andere Regeldatei hat, ist der CLI-Einstieg wieder ein Gespräch — nur ohne Chatfenster. Regeln versionieren, im Repo reviewen, in CI denselben Stand laden. Sonst vergleichen Sie nicht Backends, sondern private Vorlieben.

Umsetzungsschritte

1. Unverhandelbares aufschreiben: nur lokale Selbstprüfung, nur CI-Kommentare, oder beides; ob Woche eins schon Claude und GPT parallel braucht; ob CI zuerst kommentiert oder sofort blockiert. Ohne diesen Satz wird jede Demo zur Strategie.
2. CLI installieren und einmal leer laufen lassen: npm install -g @alibaba-group/open-code-review, ocr version, PATH und Git ≥ 2.41 bestätigen. Wenn Git zu alt ist, hier stoppen — nicht später im Diff-Schritt.
3. Nur einen Schlüssel anbinden: ocr config provider oder ocr config set, weiter erst nach bestandenem ocr llm test. Der zweite Anbieter wartet, bis der erste echte Hinweise mit Zeilen geliefert hat.
4. ocr review auf einem echten kleinen PR: Arbeitskopie oder --from/--to. Abnahme ist „Zeilen stimmen, relevante Treffer sind da“, nicht „der Kommentar ist länger“. Speichern Sie einmal JSON, auch lokal.
5. Einmal ocr scan --path nachziehen: nur den Teilbaum, den Sie übernehmen; die Arbeitsteilung Baseline versus Inkrement festhalten. Vendor und Artefakte vorher ausschließen, sonst ist die Liste wertlos.
6. Erst dann zweites Modell oder Delegation: denselben Diff mit Claude / GPT auf Fehlalarme und Kosten vergleichen; bei vorhandenem Host-Agenten ocr delegate testen. Schreiben Sie die drei Prüffragen (Zeile, Rauschen, Budget) auf, bevor jemand „uns gefällt der Ton besser“ zur Entscheidung macht.
7. Ausführungsumgebung wählen, dann CI: lokaler Versuch ist in Ordnung; Nacht-Scans und Gates gehören auf einen dauerhaften Cloud-Mac oder selbstgehosteten Runner, Logs anonymisieren, Schlüssel nicht in Artefakte. Pinning von Action und OCR_VERSION erst hier, nicht in Schritt zwei.

Wenn ein Schritt scheitert, gehen Sie nicht zwei Schritte weiter und „schauen später“. Ein grünes ocr version plus ein rotes ocr llm test ist kein Teilerfolg für CI — es ist ein unvollständiges Triple. Ein gelungener lokaler Review plus ein Scan über das ganze Monorepo in Nacht eins ist ebenfalls kein Erfolg, sondern der schnellste Weg zu einer abgeschalteten Pipeline.

FAQ

Wie hängen OpenCodeReview und Claude Code zusammen?

Claude Code ist Anthropics offizieller Coding-Workflow: Schreiben und mündliches Review können im selben Fenster bleiben. OpenCodeReview ist Alibabas Open-Source-Review-CLI; das Modell können Sie gegen Claude, GPT oder einen kompatiblen Endpunkt tauschen. Sie ersetzt nicht „offiziell tief Dateien editieren“. Sie ersetzt „Abdeckung und Zeilennummern hängen am Prompt“. Sie können beide nutzen: Claude Code schreibt, OCR prüft denselben Diff mit festem Dateieinstieg. Delegation Mode koppelt die Inferenz, nicht die Produktgrenzen.

Muss ich Claude und GPT gleichzeitig konfigurieren?

Nein. Ein Schlüssel reicht für die Installationsabnahme. Der Sinn eines zweiten Schlüssels: dieselbe Dateiauswahl und dieselben Regeln, Backend nach Kosten und Fehlalarmen tauschen. Ohne zweite Rechnung erzeugen Sie für einen „Vergleichstest“ nur Betriebsfläche. Richten Sie zuerst einen Anbieter so ein, dass ocr llm test und ein kleiner Review grün sind. Den Vergleich starten Sie mit identischem Diff und JSON-Ausgabe, nicht mit zwei Chats nebeneinander.

Können sich ocr review und ocr scan gegenseitig ersetzen?

Nicht als derselbe Befehl. Review frisst Git Diff und passt zu PRs sowie lokalen Änderungen; Scan frisst volle Dateien und passt zu Audits ohne Diff. Der falsche Einstieg bedeutet nicht, dass das Modell zu dumm ist — Sie haben der Engineering-Schicht die falsche Eingabe gegeben. Ein leerer Commit, nur um Scan zu vermeiden, erzeugt eine Lüge in der Historie. Ein Vollscan statt Branch-Review erzeugt Lärm und Kosten. Wählen Sie den Befehl nach der Frage, nicht nach Gewohnheit.

Läuft die Installation unter Windows und auf einem headless Cloud-Mac?

Ja. Das globale npm-Paket ist plattformübergreifend; das Installationsskript deckt darwin / linux auf amd64 und arm64 ab, unter Windows nutzen Sie Release-Binaries oder npm. Headless-Maschinen brauchen nicht-interaktives ocr config set und --format json, kein TUI. Auf einem Cloud-Mac sollten Sie zuerst Git, PATH und die Rechte von ~/.opencodereview festziehen — bevor der erste Nacht-Scan startet. Ein interaktives ocr config provider auf einem Runner ohne TTY ist Zeitverschwendung; schreiben Sie die Werte deklarativ in die Provisionierung.

Warum überhaupt ein Cloud-Mac? Reicht npm auf dem eigenen Laptop nicht?

Der Laptop reicht, um Befehle zu lernen. Er reicht nicht für nächtliche Vollscans, PR-Gates nach dem Zuklappen und CI, die dieselbe Umgebung wie Xcode und Signierung braucht. ocr hat das Modell entkoppelt; Git und Dateiwerkzeuge bleiben an die Maschine gebunden, auf der der Prozess läuft. Wenn Ihr Review-Job nach 20 Uhr stirbt, weil der Deckel zu ist, ist das kein Prompt-Problem. Ein dauerhafter macOS-Knoten hält Git ≥ 2.41, PATH und die Config-Rechte reproduzierbar — und lässt die Modellrechnung beim Anbieter, die Ausführung im Rack.

Fazit

Eine OpenCodeReview-Anleitung sieht oberflächlich nach npm, Umgebungsvariablen und ocr review / ocr scan aus. Was Sie wirklich einführen, ist eine Schichtung: deterministisches Engineering vom Modell trennen, Git-Diff-Einstieg vom Vollscan-Einstieg trennen, interaktive Config von CI-Config trennen. Was sich im September 2026 halten lässt: lokal ein Schlüssel, Review durchziehen, Regeln ins Repo, CI legt JSON über Secrets ab, Scan nur für die Baseline.

Die asymmetrische Schlussfolgerung bleibt: Die Trennlinie liegt nicht bei Claude oder GPT, sondern dabei, ob Sie den Review-Einstieg zur harten Constraint machen. Zuerst ein ocr review mit einem Schlüssel, dann Scan und ein zweites Modell; wenn Sie eine Ausführungsfläche brauchen, wandert der Prozess vom schlafenden Notebook auf einen Cloud-Mac. Was Sie upgraden, sind Einstieg, Zugang und Knoten — nicht noch ein Review-Skill.