Alibaba Open Code Review meldet keine Kommentare. Welche Dateien hat es geprüft?

5 min Lesezeit · 13. November 2026
Zuletzt geprüft 13. November 2026

Eine Rechnung, zwei Zahlungsversuche, zwei verschiedene Zahlungsschlüssel. Genau das erlaubte eine Änderung in unserem Go-Beispiel. Der zugehörige Test wurde im selben Pull Request angepasst. Alibaba Open Code Review wählte mit den Standardeinstellungen nur die Implementierung aus. Ausgerechnet im übersprungenen Test stand am deutlichsten, was bei einem zweiten Versuch passieren sollte.

Welche Dateien wählt Alibaba Open Code Review aus?

Ruf --preview für den Commit-Bereich deines Pull Requests auf. Die Vorschau listet die ausgewählten Änderungen auf und nennt für jede ausgeschlossene Datei den Grund. Dafür braucht sie weder ein Modell noch einen API-Schlüssel. Wir haben das am 13. November 2026 mit Version 1.13.8 geprüft. Alibabas Release v1.13.8

git diff --name-only main...HEAD
ocr review --from main --to HEAD --preview --format json

Beide Befehle vergleichen in unserem Beispiel dieselben Commits. Auf main bekamen der erste und der zweite Zahlungsversuch für die Rechnung inv-42 denselben Schlüssel. Der Branch lieferte dagegen inv-42-1 und inv-42-2. Der geänderte Test verlangte ausdrücklich unterschiedliche Werte. Erkennt der Zahlungsdienstleister Wiederholungen am Schlüssel, kann der erneute Versuch nach einem Timeout eine zweite Abbuchung auslösen. Der geänderte Test würde bestehen.

Dieselbe Änderung in zwei Vorschauen von Open Code Review v1.13.8
Geänderte Datei	Standardauswahl	Mit explizit einbezogenem Test
`billing/retry.go`	Ausgewählt	Ausgewählt
`billing/retry_test.go`	Ausgeschlossen (`default_path`)	Ausgewählt

Für die zweite Vorschau haben wir in der lokalen .opencodereview/rule.json genau einen Eintrag ergänzt. Die beiden Commits blieben gleich. Jetzt wählte die CLI beide Dateien aus. So kannst du einen einzelnen Test ins Review holen, ohne andere Standardfilter abzuschalten. Dateiauswahl und Reihenfolge der Regeln in v1.13.8

{"include":["billing/retry_test.go"]}

Mit unserem Shellskript für den Versuch mit zwei Dateien kannst du das selbst prüfen. Starte es mit Bash und einer lokal installierten CLI in Version 1.13.8. Das Skript legt ein eigenes Git-Repository an und prüft beide Vorschauen. Wir haben die Dateiauswahl gemessen. Ob das Modell den Fehler bei der Zahlungswiederholung erkennt, wäre ein eigener Versuch.

Was bedeutet eine leere Kommentarliste in der CI?

Prüfe zuerst status und warnings im endgültigen JSON-Bericht. Auch ein übersprungenes Review kann "comments": [] zurückgeben. Warnungen, die den Lauf nicht abbrechen, sind mit Exitcode 0 vereinbar. Gleiche den Bericht mit der Git-Dateiliste und der Vorschau für genau die Revision ab, die du mergen willst. CLI-Referenz für Status, Warnungen und Exitcodes

Für eine weitere Prüfung änderten wir auf einem Branch ausschließlich die ausgeschlossene Testdatei und starteten die CLI ohne Vorschau. Der Lauf endete mit Exitcode 0, status: skipped, comments: [] und null geprüften Dateien. Am lokalen Endpunkt ging keine Modellanfrage ein. Stehen im gespeicherten Bericht dagegen Hinweise, die auf GitHub fehlen, prüfe die Einstellungen und Logs für das Posten der Kommentare. Berichtsoptionen der GitHub Action

So würden wir mit einem Pull Request ohne Review-Kommentare umgehen
Ergebnis des Laufs	Nächster Schritt vor dem Merge
`skipped`	Prüfe die Vergleichsbasis und die Filter. Fehlt ein wichtiger Pfad, nimm ihn auf und starte das Review erneut. Alternativ kann jemand die Datei prüfen.
`partial`, `completed_with_warnings` oder `completed_with_errors`	Lies die Warnungen und prüfe die betroffenen Pfade. Hole fehlende Reviews nach oder verteile sie im Team. Verwertbare Hinweise aus den abgeschlossenen Teilen kannst du übernehmen.
`failed`, Abbruch oder fehlender Bericht	Für diese Revision fehlt ein verwertbares Review. Prüfe stderr und ob ein gespeicherter Bericht überhaupt aus diesem Lauf stammt.
`complete` oder `success`, alle erwarteten Dateien geprüft, keine Kommentare	Halte fest, dass der Reviewer zu diesen Dateien keine Auffälligkeiten gemeldet hat. Prüfe bei der Zahlungsänderung mit einem Timeout, ob nach dem zweiten Versuch nur eine Buchung vorliegt.

Enthält der Bericht ein Manifest, gleiche manifest.coverage.selected mit den Pfaden unter completed, reused, failed und waived ab. Prüfe bei waived, ob der Grund für das Auslassen ausreicht. Bewahre die IDs der beiden verglichenen Commits mit dem Ergebnis auf. Dateiabdeckung im Manifest von v1.13.8

Was macht der Reviewer nach der Dateiauswahl?

Alibabas Go-CLI wählt Dateien und passende Regeln aus, begrenzt den Lauf und ordnet Kommentare den geänderten Zeilen zu. Zusammengehörige Dateien lassen sich als Gruppe prüfen, mehrere Gruppen parallel. Der Agent kann ganze Dateien lesen, Aufrufer verfolgen und im Repository suchen, bevor er eine Auffälligkeit meldet. Selbst eine Datei, die als Prüfziel ausgeschlossen ist, kann er zum Verständnis heranziehen. Alibabas Dokumentation zu Architektur, Integration und Installation

Nach eigenen Angaben setzte Alibaba den internen Vorgänger zwei Jahre lang für Zehntausende Entwickler ein und identifizierte damit Millionen von Codefehlern. Das öffentliche Projekt steht unter Apache-2.0 und hat auf GitHub die Marke von 50.000 Sternen überschritten. Für dein Team dürfte eine andere Frage mehr zählen. Erkennt das Tool einen Fehler, der durch eure bisherigen Prüfungen gerutscht ist? Open Code Review auf GitHub

Welche Fehler fand Open Code Review im Vergleich zu Claude Code?

In Alibabas Benchmark mit 200 Pull Requests trafen die Kommentare von Open Code Review anteilig häufiger einen dokumentierten Fehler. Claude Code fand insgesamt mehr der bekannten Fehler. Für den Vergleich nutzten beide dasselbe Modell. Die Auswertung vom August umfasst 50 Repositorys, zehn Programmiersprachen und 1.505 annotierte Fehler. OpenCodeReview-Studie mit Versuchsaufbau und Tabelle 3

AACR-Bench mit Claude Opus 4.6, Ergebnisse der Autoren
Kennzahl	Open Code Review 1.3.1	Claude Code 2.1.169
Precision	33,90 %	7,23 %
Recall	20,00 %	28,90 %
F1	25,10 %	11,57 %
Token je Pull Request im Mittel	385.000	5.664.000

Open Code Review fand 301 der 1.505 dokumentierten Fehler, Claude Code fand 435. Höhere Precision macht den einzelnen Kommentar eher prüfenswert. Der niedrigere Recall spricht dafür, teure Fehler wie eine Doppelabbuchung weiterhin unabhängig zu testen. Wie zuverlässig die heutige CLI diese in deinem Produkt erkennt, lässt sich aus dem Benchmark nicht ablesen.

Was muss vor dem Merge der Zahlungsänderung geklärt sein?

Klär mit der für Zahlungen zuständigen Person, was nach einem Timeout passieren soll. Die erste Abbuchung kann erfolgreich gewesen sein, obwohl ihre Bestätigung nie ankam. Ein weiterer Versuch für dieselbe Rechnung sollte dann genau eine Abbuchung im Buchungsjournal hinterlassen. Spiele den Fall durch und zähle die Buchungen. Der geänderte Unit-Test belegt lediglich, dass der Code zwei unterschiedliche Zeichenfolgen liefert.

Wenn du den Reviewer einführen willst, nimm einen bereits behobenen Fehler bei Zahlungswiederholungen und eine ähnliche, fehlerfreie Änderung. Zeig dem Reviewer die damalige Korrektur nicht. Halte fest, welche Dateien er geprüft hat, und lass jemanden die Hinweise anhand des Codes beurteilen. Wie du KI-generierten Code vor dem Release testest, beschreiben wir im QA-Leitfaden. Was vertiefte Reviews bei einem gehosteten Dienst kosten, zeigt unser Vergleich der Review-Budgets von Greptile.

Häufige Fragen zur Open-Code-Review-CLI

Wie installiere ich die Version aus dem Beispiel?

Mit Git ab 2.41 kannst du npm install -g @alibaba-group/[email protected] ausführen und die Version mit ocr version kontrollieren. Das Beispielskript benötigt neben der lokalen OCR-Binärdatei Bash, Git und jq. Die Vorschau funktioniert bereits, bevor du ein Modell konfigurierst.

Wie prüfe ich nur einen Commit?

Übergib ocr review mit --commit die SHA des Commits. Für einen ganzen Pull Request gibst du die beiden lokal verfügbaren Revisionen mit --from und --to an. Der Vergleich beginnt am gemeinsamen Vorfahren und erfasst die seitdem auf dem Branch eingeführten Änderungen.

Was tun, wenn ein Pull Request nur Tests ändert?

Lass dir den Commit-Bereich mit der Vorschau anzeigen und prüfe die Ausschlussgründe. Legt ein geänderter Test eine Geschäftsregel fest, nimm seinen Pfad in die Include-Konfiguration auf oder lass ihn von jemandem prüfen. Auch eine reine Teständerung kann bestimmen, welches Verhalten beim nächsten Release durchgeht.

Kann ich ein Verzeichnis ohne Git-Diff prüfen?

Mit ocr scan --path billing prüfst du die vollständigen Dateien im Verzeichnis billing. Das eignet sich für bestehenden Code. Bei einem Pull Request ist dessen Commit-Bereich die bessere Wahl, weil du das Ergebnis später genau dieser Änderung zuordnen kannst.

Kann Open Code Review das Modell meines Coding-Agenten verwenden?

Bei einem regulären CLI-Review nutzt OCR den eingestellten Anbieter und das konfigurierte Modell, etwa Anthropic oder einen OpenAI-kompatiblen Endpunkt. Im Delegationsmodus stellt der aufrufende Coding-Agent sein Modell und die Zugangsdaten bereit. Notiere den Modus, wenn du zwei Läufe vergleichst.

Unabhängigkeit und Marken: Wavect veröffentlicht diese Seite und ist selbst Anbieter, wir haben also ein wirtschaftliches Interesse daran. Mit den hier genannten anderen Unternehmen sind wir weder verbunden noch von ihnen beauftragt oder empfohlen, und alle Firmennamen, Marken und Warenzeichen Dritter gehören ihren jeweiligen Inhabern. Aussagen über andere Anbieter stammen aus öffentlich zugänglichen Quellen, vor allem aus deren eigenen veröffentlichten Seiten, mit Stand des auf dieser Seite genannten Prüfdatums, und können sich seither geändert haben. Bitte prüfe sie vor einer Entscheidung selbst. Diese Seite wurde nach bestem Wissen und Gewissen erstellt, mit dem Ziel, möglichst objektiv zu bleiben. Wenn dir etwas falsch oder unfair erscheint, schreib uns und wir korrigieren es: [email protected]