Ein Code-Review-Prompt sollte dem Modell sagen, wonach es suchen soll, wie ernst jeder Fund ist und welchen Beleg es liefern soll. "Reviewe diesen Code" bringt eine freundliche Liste von Vorschlägen, in der eine Sicherheitslücke zwischen einem Docstring-Tipp und einer Vorliebe bei der Benennung steht. Ein Review-Prompt mit Checkliste, Schweregraden und der Bitte um Diffs bringt einen Bericht, mit dem du arbeiten kannst, Fund für Fund.
Von "reviewe das" zu einer Checkliste mit Schweregrad
Der Code in beiden Tabs hat zwei echte Bugs. Vergleiche, wie jede Antwort sie darstellt.
def get_user(conn, username):
cur = conn.cursor()
cur.execute(f"SELECT id, email FROM users WHERE name = '{username}'")
row = cur.fetchone()
return {"id": row[0], "email": row[1]}
Insgesamt ist die Funktion kurz und leicht nachzuvollziehen. Ein paar Vorschläge:
- Füg Type Hints hinzu, zum Beispiel
username: str, damit die Signatur klarer wird. - Füg einen Docstring hinzu, der erklärt, was die Funktion zurückgibt.
- Verwende parametrisierte Abfragen. SQL mit f-Strings zu bauen, kann zu SQL-Injection führen.
- Behandle fehlende User.
fetchone()kannNonezurückgeben. - Benennung:
fetch_userbeschreibt den Datenbankzugriff vielleicht besser.
Die erste Antwort hat beide Bugs gefunden, und genau das ist das Problem, wenn man ein Review danach beurteilt, was es erwähnt. Die Injection steht an dritter Stelle in einer Liste von fünf, abgeschwächt zu "kann führen", ohne Korrektur, neben einem Docstring-Tipp. Wer das überfliegt, ergänzt Type Hints und macht weiter.
Der zweite Prompt hat vier Dinge geändert:
- Umfang. "Nur Bugs, Sicherheit und Fehlerbehandlung. Lass Stil weg" entfernt das Rauschen. Stil gehört zu einem Linter und einem Formatter, die schneller sind und sich nie selbst widersprechen.
- Schweregrad. Er zwingt das Modell zu einer Rangfolge, und eine geordnete Liste sagt dir, wo du anfangen sollst.
- Ein auslösender Input. "
x' OR '1'='1" macht aus einem vagen Risiko eine Demonstration, die du ausführen kannst. Außerdem ist er dein bester Filter gegen Fehlalarme, wie der letzte Abschnitt zeigt. - Diffs. Einen kleinen Diff pro Fund kannst du für sich annehmen oder ablehnen. Eine umgeschriebene Funktion mischt jede Korrektur mit Änderungen, nach denen niemand gefragt hat.
"Wenn es auf einer Stufe nichts gibt, erfinde nichts" ist wichtiger, als es aussieht. Wenn ein Modell um ein Review gebeten wird, produziert es gern Funde, auch wenn es wenig zu finden gibt, und die schwächsten blähen die Liste auf. Die ausdrückliche Erlaubnis, auf einer Stufe nichts zu melden, schneidet dieses Füllmaterial weg.
Kontext, den der Reviewer braucht
Ein menschlicher Reviewer weiß, wofür der Code da ist und woher seine Inputs kommen. Das Modell weiß nur, was du einfügst. "username kommt direkt aus einem Login-Formular" ist der Satz, der SQL-Injection zu einem Fund mit hohem Schweregrad macht statt zu einem theoretischen. Nützlicher Kontext für ein Review:
- Woher die Inputs kommen: von Usern, von einem anderen internen Dienst, aus einer Konfigurationsdatei, die du kontrollierst.
- Was den Code aufruft und was es zurückerwartet.
- Die Laufzeitumgebung: Sprachversion, Framework, Datenbanktreiber. Die Korrektur für die Injection oben nutzt
?, weil sqlite3 diesen Platzhalter verwendet; manche anderen Treiber nutzen%s. - Was dir bei dieser Änderung am wichtigsten ist: Korrektheit, Sicherheit, Performance oder alle drei.
Ein wiederverwendbarer Review-Prompt
Dieser Block macht aus der Checkliste eine Vorlage. Ändere Sprache, Schwerpunkt und Code und behalte die Regeln. Den Vorgaben-Baustein auszuschalten, zeigt dir schnell, wie viel Rauschen ohne ihn zurückkommt.
async function loadAll(ids) {
const results = [];
ids.forEach(async (id) => {
const res = await fetch(`/api/items/${id}`);
results.push(await res.json());
});
return results;
}1. Hoch: Die Funktion kehrt zurück, bevor irgendeine Anfrage fertig ist (Zeile 3)
forEach wartet nicht auf async-Callbacks. loadAll gibt sofort das leere Array results zurück, und die push-Aufrufe passieren später. Jeder Aufrufer bekommt [].
2. Mittel: Fehlgeschlagene Anfragen werden als Daten behandelt (Zeile 5)
Eine Antwort mit 404 oder 500 ist bei fetch keine Exception. Ein JSON-Fehlerbody wird geparst und gepusht, als wäre er ein Item, und ein Body, der kein JSON ist, lässt res.json() in einem Callback scheitern, auf den niemand wartet.
Korrektur für beide, die außerdem die Ergebnisse in derselben Reihenfolge wie ids hält:
async function loadAll(ids) {
- const results = [];
- ids.forEach(async (id) => {
- const res = await fetch(`/api/items/${id}`);
- results.push(await res.json());
- });
- return results;
+ return Promise.all(
+ ids.map(async (id) => {
+ const res = await fetch(`/api/items/${id}`);
+ if (!res.ok) throw new Error(`Item ${id}: HTTP ${res.status}`);
+ return res.json();
+ })
+ );
}
Die Rollenzeile setzt einen Maßstab ("echte Probleme und sonst nichts"), und genau da hilft Rollen-Prompting am meisten. Wenn ein Programm das Review liest, etwa ein Skript, das Funde als Kommentare in einen Pull Request schreibt, bitte um JSON mit festen Feldern statt um Fließtext; strukturierte Ausgabe zeigt, wie.
Umgang mit Fehlalarmen
Manche Funde werden falsch sein. Das Modell sieht nicht den Aufrufer, der den Input validiert, nicht die Datenbank-Constraint, die einen Fall unmöglich macht, und nicht den Grund, warum eine seltsam aussehende Zeile Absicht ist. Es kann sich auch darin irren, wie sich eine Bibliothek verhält; KI-Halluzinationen erklärt, warum eine selbstsichere Aussage keine geprüfte ist.
Teste jeden Fund mit seinem auslösenden Input. Wenn du keinen Input erzeugen kannst, der das Problem in deinem System erreicht, widersprich mit dem fehlenden Kontext, statt die Korrektur zu übernehmen:
function formatPrice(cents) {
return `$${(cents / 100).toFixed(2)}`;
}
Sie wird nur aus `renderCart` aufgerufen, und das kehrt früh zurück, außer `Number.isInteger(cents)` ist wahr. Ist das trotzdem ein Problem? Wenn nicht, zieh den Fund zurück.Mit dieser Prüfung nicht: formatPrice bekommt immer nur eine Ganzzahl, also trifft der Fund nicht zu, und ich ziehe ihn zurück.
Eine Sache deckt die Prüfung nicht ab: Negative Ganzzahlen bestehen Number.isInteger, und formatPrice(-500) gibt "$-5.00" zurück. Wenn Erstattungen oder Rabatte diese Funktion erreichen können, willst du vielleicht lieber "-$5.00". Wenn nicht, gibt es nichts zu ändern.
Ein Modell, dem neue Belege gezeigt werden, sollte den Fund entweder zurückziehen oder erklären, warum er mit diesen Belegen trotzdem gilt. Beides ist nützlich. Ein Modell, das jedem Widerspruch einfach zustimmt, reviewt nicht, also beurteile die Antwort nach ihren Gründen, nicht danach, ob sie zugestimmt hat. Bei Code, den das Modell selbst geschrieben hat, lass das Review in einem frischen Gespräch laufen, damit es nicht durch dieselbe Denkweise gelesen wird, die den Code erzeugt hat. Dieselben Gewohnheiten aus Umfang, Kontext und Tests machen den Code schon beim Schreiben besser; siehe Prompts zum Code schreiben.
Häufig gestellte Fragen
Was ist ein guter Prompt für ein Code Review?
Nenn, worauf geprüft werden soll (Bugs, Sicherheit, Fehlerbehandlung), verlang für jeden Fund einen Schweregrad und fordere einen konkreten Input, der das Problem auslöst, plus einen Diff, der es behebt. Sag dem Modell, dass es Formatierung und Benennung auslassen soll, außer du fragst danach. Gib ihm den Kontext, den ein menschlicher Reviewer hätte: wofür der Code da ist und was ihn aufruft.
Kann KI ein menschliches Code Review ersetzen?
Nein, aber sie ist ein nützlicher erster Durchgang. Sie ist schnell und gut bei häufigen Bug-Mustern wie unbehandeltem None, fehlenden awaits und SQL, das aus Strings zusammengebaut wird. Sie kennt weder die Regeln deines Produkts noch den Rest der Codebasis oder den Grund für eine Entscheidung, und manche ihrer Funde werden falsch sein. Nutze sie vor einem menschlichen Review, nicht statt eines.
Warum meldet ein KI-Code-Review Probleme, die es gar nicht gibt?
Das Modell sieht nur den Code, den du eingefügt hast. Wenn ein Wert vom Aufrufer validiert wird oder ein Fall in deinem System nie eintreten kann, kann das Modell das nicht wissen und meldet das Risiko trotzdem. Die Bitte um einen konkreten Input, der den Fehler auslöst, filtert viele davon heraus: Ein Fund ohne realistischen Input, der ihn auslöst, ist meist ein Fehlalarm.
Soll ich die KI im Review meinen Code umschreiben lassen?
Bitte um kleine Diffs, einen pro Fund, statt um eine umgeschriebene Datei. Eine komplette Neufassung mischt die Korrekturen mit Änderungen, nach denen niemand gefragt hat, und du müsstest auch die Neufassung reviewen. Mit Diffs kannst du jeden Fund einzeln annehmen oder ablehnen.
