DotMDSo prüfst du eine KI-Spec:eine Checkliste, bevor der Agent baut.
Ein KI-Agent schreibt in einer Minute eine selbstsichere, saubere Spec. Das ist die Gefahr: Sie liest sich gut, auch wenn sie falsch ist. Diese Checkliste zeigt, worauf du achten solltest, bevor du den Agenten bauen lässt.
macOS 14 oder neuer. Lesen ist kostenlos; Bearbeiten und Reviews kaufst du einmalig.
Kurze Antwort
Prüfe eine von KI geschriebene Spec wie einen Pull Request: Sieh nach, ob sie das richtige Problem löst, und suche dann, was fehlt. Gehe Umfang und Nicht-Ziele, Randfälle, Daten und Migrationen, Tests und Rollback durch und kommentiere jede Stelle, die du geändert haben willst, bevor der Agent Code schreibt.
- [ ] Scope matches what I asked for
- [ ] Non-goals are listed
- [ ] Edge cases and errors are covered
- [ ] Data and migrations are explicit
- [ ] Tests prove each requirement
- [ ] There is a rollback·
Warum KI-Specs eine andere Art Review brauchen
Wer eine Spec von Hand entwirft, lässt meist dort Lücken, wo er unsicher ist. Ein Modell schreibt für alles flüssigen Text, auch für die Teile, die es geraten hat. Die üblichen Zeichen einer schwachen Spec, vage Formulierungen und offensichtliche Lücken, fehlen also, und die Probleme verstecken sich in selbstsicheren Sätzen. Prüfe auf das, wonach ein guter Autor gefragt hätte.
Die Checkliste
-
Umfang: Löst sie, was du verlangt hast?
Vergleiche den ersten Absatz mit deiner Anfrage. Achte darauf, ob ein anderes Problem gelöst wurde und ob Features dabei sind, die niemand wollte.
-
Nicht-Ziele: Was wird sie nicht tun?
Eine Spec ohne Nicht-Ziele hat keine Kante. Ergänze die Extras, die du nicht willst.
-
Annahmen: Was hat sie geraten?
Achte auf „vermutlich“, „wahrscheinlich“ und alles, was als Tatsache über Code oder Daten dasteht, die sie womöglich nicht gelesen hat. Bitte sie, die Dateien zu nennen.
-
Randfälle: Was passiert, wenn etwas schiefgeht?
Leere Eingabe, sehr große Eingabe, keine Berechtigung, kein Netz, zwei Nutzer gleichzeitig, dieselbe Aktion zweimal.
-
Daten: Was wird gespeichert, geändert oder gelöscht?
Felder, Formate, wer sie lesen darf und was mit bestehenden Datensätzen geschieht.
-
Migrationen: Wie ziehen die alten Daten um?
Eine Schemaänderung braucht eine Reihenfolge der Schritte, einen Plan für einen Abbruch auf halbem Weg und eine Möglichkeit, sie gefahrlos zweimal auszuführen.
-
Schnittstellen: Was ist sonst betroffen?
APIs, Bildschirme, Jobs, Code anderer Teams. Alles, was die Spec ändert, aber nicht auflistet, ist später eine Überraschung.
-
Sicherheit und Datenschutz: Wer darf was?
Neue Berechtigungen, neue Daten, die das System verlassen, Geheimnisse in Logs.
-
Tests: Woran erkennst du, dass es funktioniert?
Jede Anforderung sollte einer Prüfung entsprechen. Lässt sich eine Anforderung nicht testen, formuliere sie um.
-
Rollout und Rollback: Wie machst du es rückgängig?
Ein Flag, ein gestaffeltes Release, ein Weg zurück. „Wir korrigieren vorwärts“ ist kein Plan.
-
Offene Fragen: Wer entscheidet sie?
Eine ehrliche Spec listet auf, was sie nicht weiß. Gibt es keine, sei misstrauisch.
Ein Kommentar, der wirkt
Vages Feedback führt zu einer vagen Überarbeitung. Ein guter Review-Kommentar zeigt auf eine Stelle, sagt, was falsch ist und was du stattdessen willst:
> The export runs when the user taps Export.
Missing: what happens with a 2 GB file? Add a limit (R4) and an
error message, and say whether the export can be cancelled.Halte die Kommentare getrennt vom Spec-Text, damit die Datei sauber bleibt, und bündle sie: Lies die ganze Spec einmal, kommentiere dann, damit der Agent einmal überarbeitet statt zehnmal.
Die Review-Schleife
-
Zuerst von Anfang bis Ende lesen
Bevor du kommentierst, stelle sicher, dass du den ganzen Plan verstanden hast.
-
An den genauen Stellen kommentieren
Ein Problem pro Kommentar.
-
Den Agenten überarbeiten lassen
Er behebt jeden Kommentar und erzeugt eine neue Version.
-
Prüfen, was sich geändert hat, nicht das ganze Dokument
Lies die Unterschiede. Eine Korrektur kann etwas kaputt machen, das in Ordnung war.
-
Erst freigeben, wenn die Checkliste sauber ist
Dann lass ihn bauen, anhand der nummerierten Anforderungen.
Dieselbe Checkliste funktioniert, wenn ein Agent die Spec eines anderen prüft. Bitte den Reviewer, jeden Punkt mit einem Zitat aus der Spec zu beantworten.
So geht es in DotMD
All das erledigst du direkt auf der Seite. In DotMD markierst du die Stelle und schreibst einen Kommentar dazu; die Kommentare bleiben in DotMD, nicht in der Datei. Der Agent behebt sie und schickt das Dokument erneut, und beim Prüfen der Änderungen siehst du den alten Text rot und den neuen grün, sodass du sie einzeln übernehmen kannst. Die Einrichtung steht unter KI-Specs prüfen. Lesen ist kostenlos; für Reviews siehe Preise.
Häufige Fehler
- Den Stil prüfen statt die Substanz. Eine saubere Spec kann trotzdem falsch sein.
- Freigeben, weil sie lang ist. Länge ist keine Abdeckung.
- Nicht-Ziele und Rollback überspringen, die beiden Abschnitte, die Modelle am häufigsten dünn lassen.
- Den Code reparieren statt der Spec. Ist der Plan falsch, korrigiere ihn zuerst.
- Kein zweiter Blick. Prüfe nach der Überarbeitung des Agenten den Diff.
Fragen zum Prüfen von KI-Specs
Wie prüfe ich eine von KI geschriebene Spec?
Sieh nach, ob sie das richtige Problem löst, und suche dann, was fehlt: Nicht-Ziele, Randfälle, Daten und Migrationen, Tests und Rollback. Kommentiere jede Stelle und lass den Agenten überarbeiten, bevor er Code schreibt.
Was gehört in eine Checkliste für Spec-Reviews?
Umfang, Nicht-Ziele, Annahmen, Randfälle, Daten, Migrationen, Schnittstellen, Sicherheit, Tests, Rollout und Rollback sowie offene Fragen.
Kann ein KI-Agent die Spec eines anderen Agenten prüfen?
Ja. Gib dem Reviewer die Checkliste und bitte ihn, jeden Punkt mit einem Zitat aus der Spec zu beantworten. Du entscheidest weiterhin, was du übernimmst.
Warum nicht einfach den Code lesen?
Dann sind die Entscheidungen schon gefallen und teuer zu ändern. Eine falsche Annahme lässt sich in der Spec am billigsten korrigieren.