alibaba/open-code-review v1.11.0: Hybrides Code-Review-CLI mit zeilengenauen Befunden
Alibaba Open Code Review kombiniert deterministische Prüfungen mit einem Sprachmodell-Agenten, um Ergebnisse auf Zeilenebene für Probleme wie Nullzugriff, Parallelitätsfehler, XSS und SQL-Injection zu liefern.
Auf einen Blick
- Was ist das?
- Ein in Go geschriebenes Kommandozeilenwerkzeug, das deterministische Dateiauswahl mit einem LLM-Agenten verbindet. Was das README zu ocr review, ocr scan, dem Delegationsmodus und AACR-Bench hergibt, und wo Recall und Modellzwang Grenzen setzen.
- Für wen ist es gedacht?
- Geeignet ist Open Code Review für Teams, die zeilenbezogene Befunde in eine CI-Kette einhängen wollen und bereits einen Modell-Endpunkt betreiben. Weniger geeignet ist es für Vorhaben, bei denen vollständige Erfassung zählt, weil der selbst berichtete Recall unter dem allgemeiner Agenten liegt, und für Quellcode, der das eigene Netz nicht verlassen darf.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Was alibaba/open-code-review unter v1.11.0 tatsächlich prüft
Open Code Review ist ein Kommandozeilenwerkzeug für KI-gestützte Code-Reviews. Nach Angaben des README entstand es als interner KI-Review-Assistent der Alibaba Group, der über zwei Jahre Zehntausende Entwickler bediente und Millionen von Codedefekten fand, bevor er als Open-Source-Projekt ausgegründet wurde. Die Metadaten weisen Go als Hauptsprache aus, die Lizenz ist Apache-2.0, der Standardbranch heißt main. Bei der Materialsammlung standen 21568 Sterne, 1591 Forks und 145 offene Issues in den Metadaten, das letzte Release v1.11.0 datiert auf den 28. August 2026, unmittelbar nach v1.10.2 und v1.10.1.
Die Projektbeschreibung nennt konkrete Fehlerklassen: Nullzugriff, Parallelitätsfehler, XSS und SQL-Injection. Damit ist das Werkzeug auf Befunde ausgelegt, die sich an einer bestimmten Codezeile festmachen lassen, weniger auf Architekturkritik. Diese Eingrenzung erklärt auch den Aufbau der Pipeline.
Das README liegt in fünf Sprachen vor, neben Englisch in Chinesisch, Japanisch, Koreanisch und Russisch. Eine deutsche Fassung existiert nicht, und die weiterführende Dokumentation einschließlich CLI-Referenz, Prüfregeln, MCP-Server und CI-Integration liegt auf open-codereview.ai.
Vom Git-Diff zum zeilengenauen Kommentar: der Ablauf hinter ocr review
Der Ablauf beginnt beim Diff. Open Code Review liest die Änderungen, schickt die betroffenen Dateien über einen Agenten mit Werkzeugnutzung an ein konfigurierbares Sprachmodell und erzeugt strukturierte Kommentare mit Zeilenbezug. Der Agent darf dafür vollständige Dateiinhalte lesen, die Codebasis durchsuchen und andere geänderte Dateien als Kontext heranziehen. Das README grenzt das ausdrücklich von einem oberflächlichen Diff-Feedback ab.
Welche Werkzeuge der Agent im Einzelnen aufrufen kann, zählt das README nicht auf. Es beschreibt nur die Herleitung des Werkzeugsatzes: Er wurde aus der Analyse von Aufrufspuren in großen Produktionsdaten destilliert, mit Blick auf Aufrufhäufigkeiten, Wiederholungsraten je Werkzeug und die Wirkung zusätzlicher Werkzeuge auf die gesamte Aufrufkette.
Voraussetzung ist Git ab Version 2.41. Das Werkzeug nutzt Git für Diff-Erzeugung, Codesuche und Repository-Operationen. Wie es sich mit älteren Git-Versionen verhält, wird im README nicht behandelt.
Deterministische Dateiauswahl und das Bündeln von message_en.properties
Der Kern des Entwurfs ist eine Aufgabenteilung. Für Schritte, die nicht schiefgehen dürfen, soll nach README-Angaben Ingenieurslogik und nicht das Sprachmodell die Korrektheit garantieren. Das betrifft mehrere Stellen. Die Dateiauswahl legt fest, welche Dateien geprüft und welche herausgefiltert werden. Das Bündeln fasst Zusammengehöriges zu einer Prüfeinheit zusammen, als Beispiel nennt das README die Paarung von message_en.properties mit message_zh.properties.
Jedes Bündel läuft als Sub-Agent mit isoliertem Kontext. Das README beschreibt das als Teile-und-Herrsche-Strategie, die auch bei sehr großen Änderungssätzen stabil bleibt und parallele Prüfung erlaubt. Dazu kommt die Regelzuordnung: Prüfregeln werden an die Merkmale der einzelnen Datei gebunden, über eine Template-Engine statt über sprachlich formulierte Hinweise. Das soll die Aufmerksamkeit des Modells bündeln und Informationsrauschen an der Quelle vermeiden.
Der im README genannte Vorteil dieser Trennung ist Vorhersagbarkeit. Eine rein sprachlich gesteuerte Prüfung reagiert empfindlich auf kleine Prompt-Änderungen, eine regelgebundene weniger.
Positionierungs- und Reflexionsmodule gegen Positionsdrift
Als Ausgangsproblem beschreibt das README drei Beobachtungen zu allgemeinen Agenten mit Review-Skills. Erstens unvollständige Abdeckung: Bei größeren Änderungssätzen würden Teile übersprungen. Zweitens Positionsdrift: Gemeldete Befunde passten nicht zur tatsächlichen Codeposition, Zeilen- oder Dateiangaben wichen ab. Drittens schwankende Qualität, weil sprachlich formulierte Skills schwer zu debuggen seien.
Dagegen setzt Open Code Review zwei getrennte Module, die das README als extern bezeichnet: eines für die Positionierung von Kommentaren, eines für deren Reflexion. Sie sollen Positionsgenauigkeit und inhaltliche Genauigkeit getrennt voneinander verbessern. Der Ansatz ist nachvollziehbar, eine Messgröße für die erreichte Trefferquote nach Position nennt das README aber nicht.
Für Anwender folgt daraus eine Trennung: Ein zeilengenauer Kommentar ist ein eigenes Ergebnis, das unabhängig von der Frage entsteht, ob der Befund selbst zutrifft. Wer das Werkzeug in eine CI einbindet, sollte falsche Positionen und falsche Befunde getrennt zählen, sonst verdeckt eine Fehlerart die andere.
Installation über npm und Konfiguration mit ocr config provider
Die Installation läuft über npm:
npm install -g @alibaba-group/open-code-review
Danach steht der Befehl ocr global zur Verfügung. Das README verweist für drei weitere Wege auf die Installationsdokumentation: ein Installationsskript, ein Binärpaket von der Releaseseite und der Bau aus dem Quellcode. Welche Architekturen das Binärpaket abdeckt, steht im README nicht.
Vor dem ersten Review ist ein Modell zu konfigurieren, sofern nicht der Delegationsmodus genutzt wird. Dafür nennt das README zwei Befehle:
ocr config provider
ocr config model
Die interaktive Oberfläche führt laut README durch Provider-Auswahl, API-Schlüssel, Modellwahl und einen Verbindungstest. Konfigurationsdatei und Schlüsselnamen werden nicht genannt. Wer Konfiguration versionieren will, findet die Angaben in der Konfigurationsdokumentation auf open-codereview.ai.
ocr review, ocr scan und ocr delegate im Vergleich
Für den eigentlichen Review nennt die Dokumentation mehrere Wege. ocr review prüft Änderungen der Arbeitskopie. Für Bereichsvergleiche dienen die Optionen --from und --to zwischen zwei Referenzen, für einen einzelnen Commit --commit. Mit --resume und einer Sitzungs-ID lässt sich ein unterbrochener Review fortsetzen, was bei großen Änderungssätzen und zeitweiligen Modellfehlern nützlich ist.
ocr scan verlässt die Diff-Logik und prüft ganze Dateien, Repositorys oder bestimmte Pfade. Das README empfiehlt das für die Auditierung unbekannter Codebasen und für Verzeichnisse ohne aussagekräftigen Diff. Dort ist der Prüfumfang größer, entsprechend höher fällt der Tokenverbrauch aus, den das README aber nicht beziffert.
Daneben steht der Delegationsmodus mit ocr delegate preview und ocr delegate rule. Dort führt ein Codierungsagent das Review aus, während Open Code Review Dateiauswahl und Regelauflösung übernimmt. Nach README-Angaben ist dafür kein eigener OCR-API-Schlüssel nötig. Als Integrationen nennt das Material Claude Code, Codex, Cursor und OpenCode. Wie sich die Delegation qualitativ vom direkten ocr review unterscheidet, bleibt offen.
AACR-Bench: 200 Pull Requests gegen Claude Code, selbst berichtet
Der im README enthaltene Benchmark heißt AACR-Bench und ist als Datensatz auf Hugging Face unter Alibaba-Aone/aacr-bench veröffentlicht. Aufgebaut wurde er laut README aus 50 verbreiteten Open-Source-Repositorys, 200 echten Pull-Requests und 10 Programmiersprachen, gegengeprüft von mehr als 80 leitenden Entwicklern mit 1505 annotierten Referenzbefunden.
Im Vergleich mit einem allgemeinen Agenten, namentlich Claude Code, und demselben zugrunde liegenden Modell berichtet das README deutlich höhere Präzision sowie einen höheren F1-Wert, bei etwa einem Neuntel der Tokens und kürzerer Laufzeit. Die Recall liegt niedriger, und das README stellt das als bewusste Gewichtung zugunsten von Präzision dar: weniger Fehlalarm zum Nachprüfen statt maximaler Trefferzahl. Als Messgrößen führt die Tabelle F1, Precision, Recall, Avg Time und Avg Token auf.
Diese Werte sind selbst berichtet und nicht unabhängig nachgerechnet. Rohzahlen zu den einzelnen Metriken stehen nicht im README, auch die Bewertungsreihenfolge bleibt offen. Wer den Vergleich nachvollziehen will, kann über den Datensatz auf Hugging Face die Grundlage selbst auswerten.
Grenzen von Open Code Review: Recall, Modellzwang, Git 2.41
Die auffälligste Grenze ist der niedrigere Recall. Ein Review, das bewusst weniger meldet, lässt Defekte durch. Ein sauberer ocr review ist deshalb kein Freibrief, die menschliche Prüfung bleibt nötig. Das README formuliert das nicht, es folgt aber aus der eigenen Beschreibung des Kompromisses.
Zweitens braucht das Werkzeug einen Modell-Endpunkt und damit einen API-Schlüssel. Das README nennt keine Anbieter und keine Preise, auch nicht, ob eine lokale Modelllaufzeit unterstützt wird. Für Projekte, deren Quellcode das Haus nicht verlassen darf, ist das vorab zu klären; dazu enthält das README keine Aussage. Eine Telemetrie ist im Dokumentationsverzeichnis verlinkt, vom README aber nicht beschrieben.
Drittens hängt die Installation an npm und an Git ab 2.41. Projekte ohne Node-Toolchain müssen die Installationsdokumentation prüfen. Als Alternative bleibt der Weg, den das README selbst als Ausgangspunkt nennt: ein allgemeiner Agent wie Claude Code mit Review-Skills. Der Unterschied liegt im Zuschnitt. Der allgemeine Agent ist breiter einsetzbar und kann auch Architekturfragen behandeln, zeigt aber die im README beschriebene Positionsdrift. Open Code Review verlangt einen eigenen Schritt in der Toolchain und ein Modell-Endpunkt, liefert dafür zeilenbezogene Befunde und nach eigenen Angaben einen geringeren Tokenverbrauch.
Redaktionelles Fazit
Geeignet ist Open Code Review für Teams, die zeilenbezogene Befunde in eine CI-Kette einhängen wollen und bereits einen Modell-Endpunkt betreiben. Weniger geeignet ist es für Vorhaben, bei denen vollständige Erfassung zählt, weil der selbst berichtete Recall unter dem allgemeiner Agenten liegt, und für Quellcode, der das eigene Netz nicht verlassen darf. Vor der Einführung gehört geklärt, ob Git mindestens 2.41 vorliegt, wie ocr config provider mit dem bevorzugten Anbieter zusammenspielt und ob die Befunde von ocr review im eigenen Repository zeilengenau landen.
Community-Notizen