Zweck
Die technische Spezifikation ist geschrieben, der nächste Schritt ist das Schreiben von Code. Traditionell liest der Entwickler die technische Spezifikation, durchforstet den vorhandenen Code und schreibt Datei für Datei. Das Problem: Die technische Spezifikation enthält bereits das API-Design, DDLs, den Änderungsumfang und die Aufgabenzerlegung, aber der Entwickler muss diese Informationen trotzdem manuell in Code übersetzen – ein Prozess, der hochgradig repetitiv und fehleranfällig ist (falsche Parameternamen, inkonsistente API-Pfade, vergessene Änderungen in einem Dienst).
Dieser Skill liest die technische Spezifikation, die PRD, die Prototypen und die Coding-Knowledge-Base, und generiert/modifiziert Code-Dateien im Ziel-Repository gemäß der Aufgabenzerlegung in der technischen Spezifikation. Es wird kein "Gerüst" oder "Template-Code" generiert – sondern Implementierungscode mit vollständiger Geschäftslogik, der direkt für ein Code-Review eingereicht werden kann.
Die Kernfähigkeit liegt in der tiefgreifenden Nutzung von coding-knowledge: Durch Symbol-Indizes, Aufrufketten, DDLs und Codestandards in der Coding-Knowledge-Base ist der generierte Code in Bezug auf Namenskonventionen, Schichtenarchitektur und Fehlerbehandlung konsistent mit dem bestehenden Code des Projekts – er sieht aus, als wäre er von einem erfahrenen Teammitglied geschrieben, nicht von einem externen Dienstleister.
Eingaben
requirements/{Modulname}/tech-design.md(Haupteingabe, enthält API-Design, DDLs, Aufgabenzerlegung, Änderungsumfang)requirements/{Modulname}/prd-draft.md(Akzeptanzkriterien, Geschäftsregeln, Randbedingungen)requirements/{Modulname}/prototype/(Struktur der Frontend-Seiten als Referenz)coding-knowledge/(Kernreferenz – Codestil, Architekturmuster, Symbol-Indizes, Aufrufketten, DDL-Muster, Codestandards)- Pfad zum Ziel-Code-Repository (vom Benutzer angegeben oder aus dem Änderungsumfang der technischen Spezifikation extrahiert)
Arbeitsablauf
Phase 0: Eingaben lesen, Kontext aufbauen
0.1 Lese tech-design.md
Extrahiere folgende Informationen als autoritative Quelle für die anschließende Generierung:
- Änderungsauswirkungen (welche Repositories sind betroffen, welche Dateien müssen neu erstellt/geändert werden)
- API-Design (API-Liste, Anfrageparameter, Antwortstruktur, Fehlercodes)
- Datenbankänderungen (DDLs)
- Aufgabenzerlegung (T-01, T-02... mit Abhängigkeiten)
- Interaktions-Sequenzdiagramme (dienstübergreifende Aufrufbeziehungen)
- Beschreibung von Parametern für wiederverwendete Schnittstellen (Unterscheidung von Parametern und Verhalten)
0.2 Lese prd-draft.md
Extrahiere folgende Informationen, um die Vollständigkeit der Geschäftslogik sicherzustellen:
- Funktionsliste und Akzeptanzkriterien (stellt sicher, dass der generierte Code jeden Funktionspunkt abdeckt)
- Geschäftsregeln und Randbedingungen (stellt sicher, dass der Code entsprechende Validierungslogik enthält)
- Anforderungen an die Fehlerbehandlung (spezifische Fehlermeldungstexte)
0.3 Lese coding-knowledge intensiv (Kernschritt)
Dies ist der Hauptunterschied zwischen code-gen und gewöhnlicher KI-Codegenerierung. Es geht nicht darum, "es zu lesen, um einen groben Überblick zu bekommen", sondern schichtweise spezifische Codierungsmuster aus dem Code zu extrahieren.
Erste Schicht: Grundlegende Standards (Pflichtlektüre)
Lese die Dateien unter coding-knowledge/infra/ und extrahiere globale Codierungsbeschränkungen:
code-quality.md→ Namenskonventionen (CamelCase vs. Unterstriche, Präfix-/Suffix-Konventionen), Kommentarstil, Fehlerbehandlungsmuster, Logging-Standards- Andere Infrastrukturstandards → Art und Weise der Middleware-Nutzung (MQ-Produktion/Konsumtionsmodell, Cache-Betriebsart)
Zweite Schicht: Repository-Architektur (lesen pro betroffenem Repository)
Für jedes in tech-design aufgeführte Repository lese die Dateien unter coding-knowledge/repos/{repo}/:
architecture.md→ Paketstruktur und Schichtungskonventionen. Bestimmt, unter welchem Paket neue Dateien abgelegt werden, wie Klassen benannt werden. Achte besonders auf Beschreibungen wie "Dieser Dienst ist nicht zuständig für" – vermeide es, Logik in den Dienst zu schreiben, die nicht dorthin gehört.symbols.md→ Signaturindex vorhandener Klassen und Methoden. Dies ist der Einstiegspunkt für das "Stil-Lernen" – finde darin vorhandene Implementierungen desselben Typs (z. B. vorhandene Controller, Services). In Phase 1 wird dann der vollständige Quellcode dieser Dateien gelesen.database-schema.md→ Echte DDLs vorhandener Tabellen. Bei der Erstellung neuer Tabellen beziehe dich auf die Feldnamenskonvertierungsregeln (z. B.create_timevs.createdAt), Indexnamenskonventionen (z. B.idx_-Präfix), Zeichensatz- und Engine-Einstellungen.call-chains.md→ Tatsächlicher Code für dienstübergreifende Aufrufe. Wenn die technische Spezifikation dienstübergreifende Aufrufe betrifft, finde hier die im Projekt tatsächlich verwendete Aufrufmethode (Feign Client? RestTemplate? WebClient? gRPC Stub?) sowie die Schreibweise der Fehlerbehandlung und Timeout-Konfiguration.
Dritte Schicht: Geschäftsdomäne (bei Bedarf lesen)
Wenn die technische Spezifikation die Zusammenarbeit zwischen Diensten betrifft, lese coding-knowledge/business/domains/{domain}/:
cross-service.md→ Dienstübergreifende Aufrufbeziehungen und Datenflüsse
0.4 Stil-Lernen (entscheidender Schritt)
Lokalisiere aus symbols.md 2-3 vorhandene Implementierungsdateien desselben Typs und lese den vollständigen Quellcode mit einem Read-Tool. Ziel ist es, die Codierungsmuster des Projekts zu lernen, nicht nur die Signaturen anzusehen.
Konkret:
| Zu generierende Code-Schicht | Referenzobjekt aus symbols.md | Lernpunkte |
|---|---|---|
| Entity/Model | Vorhandene Entity-Klasse im selben Repository | Verwendung von Annotationen, Feldnamenskonvertierung, Basisklassenvererbung, Behandlung von Audit-Feldern |
| Mapper/Repository | Vorhandenes Mapper/Repository im selben Repository | MyBatis XML vs. Annotationen, Namensmuster für benutzerdefinierte Abfragemethoden, Paginierungsimplementierung |
| Service | Vorhandene Service-Klasse im selben Repository | Verwendung von Transaktionsannotationen, Art der Ausnahmebehandlung, Dependency-Injection-Stil (Konstruktor vs. @Autowired) |
| Controller | Vorhandene Controller-Klasse im selben Repository | Einheitliche Rückgabewertverpackung, Parameter-Validierungsannotationen, Berechtigungsannotationen, Swagger-Annotationsstil |
| Frontend-API-Schicht | Vorhandene API-Datei im selben Projekt | Axios-Kapselungsmethode, Request/Response-Interceptor, Fehlerbehandlung |
| Frontend-Seite | Vorhandene Listenseite/Formularseite im selben Projekt | Verwendung der Komponentenbibliothek, Statusverwaltungsmethode, Layout der Suchbedingungen |
Das Ergebnis des Stil-Lernens ist eine implizite "Codierungscheckliste" – sie muss nicht an den Benutzer ausgegeben werden, aber beim Generieren jeder Codezeile in Phase 2 befolgt werden. Zum Beispiel:
- "Die Controller in diesem Projekt verwenden alle
@RestController+@RequestMapping, nicht@Controller+@ResponseBody" - "Ausnahmen in der Service-Schicht werden einheitlich mit
throw new BusinessException(ErrorCode.XXX)geworfen, nicht durch Rückgabe von error codes" - "Alle Abfragemethoden heißen
listXxx/getXxx, nichtqueryXxx/findXxx"
Phase 1: Plan erstellen (Benutzerbestätigung einholen)
Vor dem Schreiben von Code muss dem Benutzer ein strukturierter Plan angezeigt und eine Bestätigung eingeholt werden.
Basierend auf den Analyseergebnissen von Phase 0 wird ein strukturierter Code-Generierungsplan ausgegeben:
## Code-Generierungsplan
### Referenz für Codestil
- Backend-Referenz: {Pfad zur referenzierten Controller/Service-Datei aus symbols.md}
- Frontend-Referenz: {Pfad zum referenzierten Komponentenpfad aus vorhandenen Seiten}
- Codestandards: {Wichtige Beschränkungen aus coding-knowledge/infra/code-quality.md}
### Backend ({Repository-Name})
| Nr. | Aktion | Dateipfad | Beschreibung | Entspricht Aufgabe |
|-----|--------|-----------|--------------|---------------------|
| 1 | Neu | {aus architecture.md abgeleiteter genauer Paketpfad}/XxxEntity.java | Neue Entity-Klasse | T-01 |
| 2 | Neu | {Paketpfad}/XxxMapper.java | Neues Mapper-Interface | T-01 |
| 3 | Ändern | {aus symbols.md abgeleiteter genauer Dateipfad}:L{Zeile} | Neue Methode createXxx() | T-02 |
| 4 | Neu | {Paketpfad}/XxxController.java | Neues CRUD-Interface | T-03 |
### Frontend ({Repository-Name})
| Nr. | Aktion | Dateipfad | Beschreibung | Entspricht Aufgabe |
|-----|--------|-----------|--------------|---------------------|
| 1 | Neu | src/api/xxx.js | API-Aufrufschicht | T-05 |
| 2 | Neu | src/pages/xxx/index.vue | Listenseite (Referenz: prototype/list.html) | T-05 |
| 3 | Neu | src/pages/xxx/form.vue | Neu-/Bearbeitungsformular | T-05 |
### Datenbank
- DDLs aus tech-design ausführen (Stilkonsistenz mit database-schema.md wurde bereits bestätigt)
### Hinweise
- {Vom Benutzer zu bestätigende Punkte}
Die Dateipfade im Plan müssen exakt sein – keine geratenen Pfade, sondern aus architecture.md (Paketstruktur) und symbols.md (vorhandene Dateipositionen) abgeleitet. Bei Änderungen an vorhandenen Dateien die Zeilennummer angeben.
Phase 2 beginnt erst nach Bestätigung durch den Benutzer.
Phase 2: Code generieren (abhängigkeitsbasiert)
Generierungsprinzip: Generiere von der untersten zur obersten Schicht gemäß der Abhängigkeitsbeziehung, um korrekte Referenzbeziehungen sicherzustellen. Jede Datei wird sofort nach der Generierung geschrieben.
Backend-Generierungsreihenfolge
In der Reihenfolge Entity → Mapper/Repository → Service → Controller → Konfiguration/Sonstiges:
1. Entity/Model-Schicht
- Generiere Entity-Klassen gemäß den DDLs der technischen Spezifikation
- Aus Phase 0.4 gelernte Muster: Feldannotationsmethode (JPA
@Columnoder MyBatis-Plus@TableField), Basisklassenvererbung (gibt esBaseEntity?), Behandlung von Audit-Feldern (createTime/updateTime), Logisches Löschen von Feldern - Referenz aus database-schema.md: Feldnamenskonvertierungsregeln (Datenbank
create_time→ JavacreateTime: Einige Projekte verwenden@TableField("create_time"), andere verlassen sich auf globale Konfiguration für automatische Konvertierung)
2. Mapper/Repository-Schicht
- Generiere Datenzugriffsschnittstellen basierend auf den Entities
- Aus Phase 0.4 gelernte Muster: MyBatis XML vs. Annotationen, Vererbung von
BaseMapper<T>, Namensregeln für benutzerdefinierte Abfragemethoden, Implementierung von Paginierung (PageHelper? MyBatis-Plus IPage?) - Enthält benutzerdefinierte Abfragemethoden aus der technischen Spezifikation
3. Service-Schicht
- Implementiere Geschäftslogik, entsprechend dem Verarbeitungsablauf für jede Schnittstelle in der technischen Spezifikation
- Aus Phase 0.4 gelernte Muster: Verwendung von Transaktionsannotationen (Gewohnheiten bei
@Transactional-Propagation), Art der Ausnahmebehandlung (benutzerdefinierte BusinessException? Einheitlicher ErrorCode-Enum?), Dependency-Injection-Stil (Konstruktor-Injektion vs.@Autowired), Protokollierungsgewohnheiten - Leite Validierungslogik aus PRD-Akzeptanzkriterien ab: Jedes Akzeptanzkriterium entspricht einem Validierungszweig
- Dienstübergreifende Aufrufe: Finde die tatsächlich verwendete Aufrufmethode aus call-chains.md und übernimm deren Codemuster (anstatt eine neue Aufrufmethode zu erfinden)
4. Controller-Schicht
- Schnittstellenpfade, Parameter und Antwortstruktur folgen strikt dem API-Design der technischen Spezifikation
- Aus Phase 0.4 gelernte Muster: Einheitliche Rückgabewert-Wrapper-Klasse (
Result<T>?ResponseEntity<T>?), Parameter-Validierungsannotationen (@Valid+ JSR 303 oder manuelle Validierung?), Berechtigungsannotationen (@PreAuthorize? Benutzerdefiniertes@Permission?), Swagger/OpenAPI-Annotationsstil - Fehlercodes verwenden die in der technischen Spezifikation definierten Geschäftsfehlercodes
5. Konfiguration/Sonstiges
- MQ Consumer/Producer (falls in der technischen Spezifikation erwähnt) – finde die Schreibweise des vorhandenen MQ-Codes aus call-chains.md
- Menü-/Berechtigungskonfigurationsdateien (falls erforderlich)
- Neue Konstanten-/Enum-Klassen
Frontend-Generierungsreihenfolge
In der Reihenfolge API-Aufrufschicht → Routenkonfiguration → Seitenkomponenten:
1. API-Aufrufschicht
- Generiere API-Methoden gemäß der API-Liste der technischen Spezifikation
- Aus Phase 0.4 gelernte Muster: Axios-Kapselungsmethode (einheitliche Request-Funktion? Jede API in einer eigenen Datei?), Request/Response-Interceptor-Verarbeitung
- Methoden- und Parameternamen entsprechen den API-Nummern der technischen Spezifikation
2. Routenkonfiguration
- Routenregistrierung für neue Seiten
- Referenziere die Organisationsweise vorhandener Routendateien
3. Seitenkomponenten
- Referenziere die Seitenstruktur aus prototype/: Die Reihenfolge der Tabellenspalten, das Layout der Suchbedingungen und die Fensterstruktur im Prototypen leiten direkt den Komponentencode
- Verwende die Komponentenbibliothek des tatsächlichen Technologie-Stacks des Projekts (aus coding-knowledge oder package.json: Element UI / Ant Design / Eigenentwicklung usw.)
- Tabellenspalten-Definitionen werden aus den API-Antwortfeldern der technischen Spezifikation abgeleitet
- Formularfelder und Validierungsregeln werden aus den API-Anfrageparametern der technischen Spezifikation abgeleitet
Generierungsablauf für jede Datei
- Wenn es sich um eine neue Datei handelt:
- Überprüfe, ob das Zielverzeichnis existiert (mit
ls) - Erstelle mit Write-Tool
- Überprüfe, ob das Zielverzeichnis existiert (mit
- Wenn es sich um eine Änderung einer vorhandenen Datei handelt:
- Lese zuerst den vollständigen Dateiinhalt mit Read
- Nimm genaue Änderungen mit Edit vor (ohne den umgebenden Code neu zu formatieren)
- Nach der Generierung sofort in das Dateisystem schreiben (nicht bis zum Ende ansammeln)
Phase 3: Bericht erstellen
Erstelle code-gen-report.md im Verzeichnis requirements/{Modulname}/:
---
title: "{Modulname} — Code-Generierungsbericht"
tech_design_version: "{Version der technischen Spezifikation}"
date: "{Erstellungsdatum}"
---
# {Modulname} — Code-Generierungsbericht
## 1. Generierungsübersicht
| Repository | Neue Dateien | Geänderte Dateien | Entspricht Aufgaben |
|------------|--------------|-------------------|---------------------|
| {Repository-Name} | {N} | {M} | T-01 ~ T-03 |
## 2. Referenz für Codestil
| Code-Schicht | Referenzierte vorhandene Datei | Wichtige gelernte Muster |
|--------------|--------------------------------|--------------------------|
| Controller | {Dateipfad} | Einheitliche Rückgabe Result<T>, Verwendung von @Valid |
| Service | {Dateipfad} | Konstruktor-Injektion, BusinessException-Behandlung |
| Entity | {Dateipfad} | Vererbung von BaseEntity, @TableField-Annotation |
## 3. Dateiliste
### {Repository-Name}
#### Neue Dateien
| Dateipfad | Beschreibung | Entspricht Aufgabe aus tech-design |
|-----------|--------------|-------------------------------------|
| src/.../XxxEntity.java | Neue Entity | T-01 |
#### Geänderte Dateien
| Dateipfad | Änderungsinhalt | Entspricht Aufgabe aus tech-design |
|-----------|-----------------|-------------------------------------|
| src/.../XxxService.java | Neue Methode createXxx() | T-02 |
## 4. Abdeckungsprüfung der Anforderungen
| PRD-Funktion | Schnittstellennummer | Code-Datei | Abdeckung der Akzeptanzkriterien |
|--------------|----------------------|------------|-----------------------------------|
| F-01 | API-01, API-02 | XxxController.java | Vollständig abgedeckt |
| F-02 | API-03 | XxxService.java | Teilweise abgedeckt (zu klärender Punkt Q-01 nicht implementiert) |
## 5. Nicht abgedeckte Punkte
{Aufgaben aus der technischen Spezifikation, die dieses Mal nicht generiert wurden, und Gründe}
## 6. Hinweise
{Vom Entwickler manuell zu erledigende Punkte, z. B.:}
- Neue Konfigurationseinträge, die im Konfigurationscenter hinzugefügt werden müssen
- Manuell auszuführende DDLs
- Manuell zu bestätigende Geschäftslogik
- In der coding-knowledge gefundene Inkonsistenzen mit der technischen Spezifikation
Phase 4: Zusammenfassung ausgeben
Informiere den Benutzer nach Abschluss der Generierung über:
- Speicherort des Code-Generierungsberichts
- Anzahl der neuen/geänderten Dateien (nach Repository aufgeschlüsselt)
- Abdeckung der entsprechenden Aufgaben aus der technischen Spezifikation
- Manuell zu erledigende Punkte
- Empfehlung, den generierten Code mit
/code-reviewzu überprüfen
Ausgabeverzeichnis
requirements/{Modulname}/
├── prd-draft.md ← PRD-Entwurf (Eingabe)
├── review/ ← prd-review-Ausgabe
├── prototype/ ← proto-gen-Ausgabe
├── tech-design.md ← tech-design-Ausgabe (Eingabe)
└── code-gen-report.md ← Ausgabe dieses Skills
Tatsächliche Code-Änderungen werden direkt in das Ziel-Repository-Verzeichnis geschrieben (nicht unter requirements/).
Beziehung zu anderen Skills
coding-knowledge-init ← Schritt 0: Projektlandkarte
generiert coding-knowledge/
↓ (Referenz)
project-import → knowledge-init → prd-draft → prd-review → proto-gen
↓
tech-design → code-gen → code-review
↑
coding-knowledge/
(tiefgreifende Nutzung)
- Voraussetzung: Die technische Spezifikation von
tech-designist die Haupteingabe; die Coding-Knowledge-Base voncoding-knowledge-initist die Kernreferenz - Nachfolgend: Die generierten Code-Änderungen werden von
code-reviewüberprüft - Beziehung zu tech-design: tech-design definiert "was zu tun ist" (API-Design, DDLs, Aufgabenzerlegung), code-gen führt aus "wie es zu tun ist" (generiert tatsächlichen Code). Die Schnittstellennummern (API-XX) und Aufgabennummern (T-XX) in tech-design sind die direkten Indizes für code-gen
- Beziehung zu coding-knowledge: coding-knowledge ist der "Codierungsmentor" für code-gen –
symbols.mdsagt dir, welche Klassen und Methoden im Projekt existieren und wo du Referenzen desselben Typs findestarchitecture.mdsagt dir, in welchem Paket neuer Code abgelegt werden soll und welcher Schichtung gefolgt werden solldatabase-schema.mdsagt dir, welcher Stil beim Erstellen von Tabellen verwendet wirdcall-chains.mdsagt dir, wie dienstübergreifende Aufrufe geschrieben werdeninfra/code-quality.mdsagt dir, welche Standards eingehalten werden müssen- Ohne coding-knowledge kann auch Code generiert werden, aber die Qualität sinkt von "von einem erfahrenen Teammitglied geschrieben" auf "von einem Praktikanten geschrieben"
Änderung vorhandener Dateien vs. neue Funktionalität
Die KI bestimmt automatisch anhand des Änderungsumfangs in der technischen Spezifikation, ob es sich bei jeder Datei um eine "Änderung vorhandenen Codes" oder eine "neue Datei" handelt, und wendet unterschiedliche Generierungsstrategien an.
Eiserne Regel beim Ändern vorhandenen Codes
Ändere nur, was geändert werden muss, rühre nicht an, was nicht geändert werden soll. Dies ist das häufigste und schwerwiegendste Problem bei der Änderung vorhandenen Codes – die KI versteht den vorhandenen Code und "optimiert nebenbei" die umgebende Logik um, was zu Regressionen führt.
Konkrete Anforderungen:
- Lese zuerst die vollständige vorhandene Datei mit Read, um den Kontext zu verstehen, bevor du handelst
- Verwende Edit für genaue Änderungen, nicht Write, um die gesamte Datei zu überschreiben
- Benenne vorhandene Variablen/Methoden nicht um, selbst wenn der Name schlecht erscheint – das ist eine andere Anforderung
- Passe das Format vorhandenen Codes nicht an (Einrückung, Leerzeilen, Import-Reihenfolge), es sei denn, es handelt sich um Code, der direkt an deinen neuen Code angrenzt
- "Optimiere" nicht die vorhandene Logik – wenn die technische Spezifikation besagt "Füge in der Methode createOrder eine neue Validierung hinzu", dann füge nur die Validierung hinzu und ändere keine andere Logik in createOrder
- Achte auf die Position beim Hinzufügen neuer Methoden: Füge Methoden an einer sinnvollen Position ein, gemäß der vorhandenen Methodenanordnungsgewohnheit des Projekts (z. B. CRUD-Reihenfolge, public vor private)
Entscheidungskriterien
| Signal | Entscheidung | Generierungsstrategie |
|---|---|---|
| tech-design markiert "Ändern: XxxService:L120" | Ändern vorhanden | Read → Edit genaue Änderung |
| tech-design markiert "Neu: {Paketpfad}/XxxController.java" | Neue Datei | Write vollständige Datei |
| tech-design markiert "Neue Methode createXxx()" | Neu in vorhandener Datei | Read → Edit an geeigneter Position einfügen |
Generierungsprinzipien
Stilkonsistenz hat höchste Priorität: Der generierte Code muss wie eine natürliche Erweiterung des vorhandenen Projektcodes aussehen. Die Vorgehensweise ist nicht "lies die Standards und folge dann dem Bauchgefühl", sondern:
- Finde vorhandene Implementierungsdateien desselben Typs aus symbols.md
- Lese den vollständigen Quellcode mit Read und extrahiere Codierungsmuster
- Der neue Code repliziert diese Muster strikt – dieselbe Kombination von Annotationen, dieselbe Methodenbenennung, dieselbe Fehlerbehandlung
Die technische Spezifikation ist die autoritative Quelle: Schnittstellenpfade, Parameternamen, Antwortstruktur und Fehlercodes richten sich nach der technischen Spezifikation, es wird nichts eigenmächtig hinzugefügt. Wenn die technische Spezifikation Probleme aufweist (z. B. unangemessene Parametertypen), wird dies im Abschnitt "Hinweise" des Berichts vermerkt, der Code jedoch weiterhin gemäß der technischen Spezifikation generiert.
coding-knowledge ist der Codierungsmentor: Bei der Frage "Wie soll ich das hier schreiben?" ist die erste Reaktion, in coding-knowledge nachzuschlagen, nicht auf Allgemeinwissen zu raten. Zum Beispiel:
- "Wie wird die Paginierung in diesem Projekt implementiert?" → Suche nach paginierungsbezogenen Methoden in symbols.md
- "Welche Methode wird für dienstübergreifende Aufrufe verwendet?" → Suche in call-chains.md
- "Wie werden Ausnahmen geworfen?" → Suche in code-quality.md und in der Referenz-Service-Implementierung
Vorhandenen Code nicht beschädigen: Beim Ändern vorhandener Dateien wird Code nur an den notwendigen Stellen hinzugefügt/geändert, ohne den umgebenden Code neu zu formatieren oder umzustrukturieren. Verwende das Edit-Tool für genaue Änderungen, nicht Write, um die gesamte Datei zu überschreiben.
Geschäftslogik muss vollständig sein: Es werden nicht nur Methodensignaturen und TODO-Kommentare generiert, sondern Code mit vollständiger Geschäftslogik. Validierungsregeln werden aus den PRD-Akzeptanzkriterien abgeleitet, Verarbeitungsabläufe aus den Sequenzdiagrammen der technischen Spezifikation.
In Batches generieren, sofort schreiben: Generiere Dateien nacheinander in der Reihenfolge von Phase 2 und schreibe jede Datei sofort nach der Generierung. Sammle nicht alles bis zum Ende, um es auf einmal auszugeben – falls zwischendurch ein Fehler auftritt, sind die bereits geschriebenen Dateien nicht betroffen.
Häufige Fallstricke
Stil-Lernen überspringen und sofort generieren: Ein neuer Controller wird generiert, ohne einen vorhandenen Controller im Projekt zu lesen, was zu einer völlig anderen Kombination von Annotationen und Rückgabewertverpackung führt. Das Stil-Lernen in Phase 0.4 darf nicht ausgelassen werden.
Nur symbols.md lesen, nicht den Quellcode: symbols.md enthält nur Signaturindizes, nicht die Codierungsmuster innerhalb der Methoden (wie Transaktionen verwendet werden, wie Ausnahmen geworfen werden, wie protokolliert wird). Es müssen 2-3 vollständige Quelldateien als Referenz gelesen werden.
Schnittstellenparameter inkonsistent mit tech-design: tech-design schreibt knowledgeType, der Code schreibt knowledge_type oder type. Die Parameternamen müssen strikt der technischen Spezifikation folgen.
Änderungsdateien übersehen: tech-design besagt, dass 3 Dateien geändert werden sollen, code-gen ändert nur 2. Die Planliste in Phase 1 muss den Änderungsumfang der technischen Spezifikation vollständig abdecken.
Frontend-Code ignoriert Prototypen: Die Seitenstruktur in prototype/ ist die visuelle Darstellung der PRD. Der Frontend-Code sollte sich am Layout und der Komponentenstruktur des Prototyps orientieren, nicht die Seite selbst neu entwerfen.
Nur Signaturen generieren, keine Implementierung: Der generierte Service-Methodenrumpf enthält nur // TODO: implement. Der Wert dieses Skills liegt darin, vollständige Geschäftslogik-Implementierungen zu generieren, nicht Platzhalter, die der Entwickler selbst ausfüllen muss.
Bei Änderung vorhandener Dateien "nebenbei" umstrukturieren: Beim Ändern vorhandener Methoden wird nur die erforderliche Logik hinzugefügt. Variablen werden nicht umbenannt, Codeformatierung nicht angepasst, umgebende Logik nicht optimiert. Diese "Verbesserungen" sind die Hauptquelle für Regressionen.
Bei Änderung vorhandener Dateien vorhandene Logik duplizieren: tech-design besagt "Füge einen neuen Validierungsschritt zum vorhandenen Ablauf hinzu", code-gen schreibt den gesamten Ablauf neu (einschließlich der bereits vorhandenen Logik). Es darf nur inkrementeller Code geschrieben werden, die vorhandene Logik bleibt unverändert.
Die "nicht zuständig"-Markierung in coding-knowledge ignorieren: In architecture.md steht "Dieser Dienst ist nicht zuständig für XXX", aber der generierte Code enthält diese Logik. Vor der Code-Generierung muss die Zuständigkeitsgrenze des Dienstes überprüft werden.
Inkonsistente Methode für dienstübergreifende Aufrufe: Der vorhandene Code des Projekts verwendet Feign Client, um andere Dienste aufzurufen, aber der generierte Code verwendet RestTemplate. Die tatsächliche Aufrufmethode muss aus call-chains.md oder Referenzcode gelernt werden.