--- title: "Alibaba Open Code Review meldet keine Kommentare" canonical: https://wavect.io/de/blog/alibaba-open-code-review-no-comments/ language: de description: "Alibaba Open Code Review meldet keine Kommentare? Prüfe am Beispiel einer Zahlungswiederholung, welche Dateien der CLI auswählt und was vor dem Merge zählt." image: "https://wavect.io/img/blog/headers/header_alibaba-open-code-review-no-comments.png" author: ["Kevin Riedl"] published: "2026-11-13" updated: "2026-11-13" reviewed: "2026-11-13" --- # Alibaba Open Code Review meldet keine Kommentare. Welche Dateien hat es geprüft? [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 5 min Lesezeit · 13. November 2026 Zuletzt geprüft 13. November 2026 [**Weiter**](/de/blog/qa-for-ai-generated-code/) TL;DR Wenn Alibaba Open Code Review keine Kommentare meldet, prüfe den Status und die tatsächlich geprüften Dateien. In unserem Beispiel wählte Version 1.13.8 den Zahlungscode aus und übersprang den zugehörigen Test. Eine einzige Include-Regel nahm beide Dateien in die Prüfung auf. Ob eine Wiederholung nur eine Abbuchung auslöst, muss ein eigener Test zeigen. 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](https://github.com/alibaba/open-code-review/releases/tag/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. | 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](https://github.com/alibaba/open-code-review/blob/v1.13.8/pages/src/content/docs/en/review-rules.md) ``` {"include":["billing/retry_test.go"]} ``` Mit unserem [Shellskript für den Versuch mit zwei Dateien](/downloads/alibaba-open-code-review-preview.sh) 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](https://github.com/alibaba/open-code-review/blob/v1.13.8/pages/src/content/docs/en/cli-reference.md) 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](https://github.com/alibaba/open-code-review/blob/v1.13.8/examples/github_actions/README.md) | 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](https://github.com/alibaba/open-code-review/blob/v1.13.8/internal/session/manifest.go) ## 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](https://github.com/alibaba/open-code-review/blob/v1.13.8/README.md) 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](https://github.com/alibaba/open-code-review) ## 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](https://arxiv.org/html/2608.09290v2) | 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](/de/blog/qa-for-ai-generated-code/), beschreiben wir im QA-Leitfaden. Was vertiefte Reviews bei einem gehosteten Dienst kosten, zeigt unser [Vergleich der Review-Budgets von Greptile](/de/blog/greptile-base-plus-apex-review-budget/). ## 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/open-code-review@1.13.8` 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: [office@wavect.io](mailto:office@wavect.io) QA und Produktionsreife ## Weiterlesen Tests, Audits, Wartung und Härtung für verlässliche Produktionssoftware. [Hier starten**QA für KI-generierten Code**](/de/blog/qa-for-ai-generated-code/) - [LoRaWAN-Wasserzähler im Feldtest: Kommen Zählerstand und Leckalarm an?](/de/blog/lorawan-water-meter-field-acceptance-test/) - [Software von zwei Anbietern abnehmen: Welcher Nachweis reicht?](/de/blog/multi-vendor-software-acceptance-testing/) - [README ZIP Schadsoftware: Was deckt deine Freigabe ab?](/de/blog/readme-zip-malware-install-review/) - [KI-generierte Odoo-Module: Geschäftsregeln im Audit prüfen](/de/blog/ai-generated-odoo-module-audit/) - [Odoo-Migration abnehmen: Datensätze und Salden abgleichen](/de/blog/odoo-migration-acceptance-reconciliation/) [Nächster Artikel**LoRaWAN-Wasserzähler im Feldtest: Kommen Zählerstand und Leckalarm an?**](/de/blog/lorawan-water-meter-field-acceptance-test/) [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 5 min Lesezeit · 13. November 2026 Zuletzt geprüft 13. November 2026 [**Weiter**](/de/blog/qa-for-ai-generated-code/)