Kimi token optimize Prompten

Whitepaper: Token-Minimiertes Prompting mit Kimi für komplexe Softwareprojekte

Am Beispiel: “TaskFlow Pro” – Eine Cross-Platform-Auftragsmanagement-App mit integrierter Zahlungsabwicklung

1. Executive Summary

Dieses Whitepaper beschreibt eine systematische Methode, um mit Kimi (und vergleichbaren Large Language Models) komplexe Softwareprojekte – am konkreten Beispiel einer mobilen App für Auftragsmanagement – extrem effizient und kostengünstig zu entwickeln. Der Kern der Methode ist token-minimiertes Prompting: Ein architektonischer Ansatz, bei dem nicht jede Anforderung in einem einzigen, riesigen Prompt landet, sondern in einem modularen, hierarchischen Prozess verarbeitet wird.

Warum das wichtig ist: Jedes überflüssige Wort, jede unklare Anforderung und jede Rückfrage kostet Tokens, Zeit und Kontextfenster. Bei komplexen Projekten wie unserer Beispiel-App führt unstrukturiertes Prompting schnell zu Halluzinationen, Inkonsistenzen und einer exponentiell wachsenden Korrekturschleife.

2. Das Beispielprojekt: “TaskFlow Pro”

Um die Methode greifbar zu machen, entwickeln wir durchgehend eine App mit folgenden Anforderungen:

3. Warum Token-Minimierung der entscheidende Erfolgsfaktor ist

3.1 Das Kontextfenster-Problem

Kimi hat ein großes Kontextfenster, aber es ist nicht unendlich. Wenn Sie in einem einzigen Prompt versuchen, die gesamte App-Spezifikation, das UI-Design, die API-Struktur und den Zahlungsflow zu beschreiben, passiert Folgendes:

• Dilution: Wichtige Details gehen in der Masse unter
• Halluzination: Das Modell “erfindet” Details, um Lücken zu füllen
• Korrekturkaskade: Ein Fehler im Prompt führt zu 10 Fehlern im Output, die wiederum 10 Korrektur-Prompts erfordern

3.2 Die Kostenformel

Gesamtkosten = Σ(Initial-Prompt-Tokens) + Σ(Korrektur-Prompt-Tokens) + Σ(Rückfrage-Prompt-Tokens)

Ein modularer Ansatz reduziert alle drei Summanden drastisch.

4. Der Designprozess im Prompting-Kontext

Bevor ein einziger Code-Prompt geschrieben wird, muss ein Design-Prozess durchlaufen werden. Das ist nicht “overhead” – es ist die größte Token-Einsparung, die Sie je tätigen werden.

Phase 0: Design-Definition (Der wichtigste Prompt)

Falsch: “Programmiere mir eine App, wo Auftraggeber Aufgaben zuweisen können, mit Bildern und PayPal.”

Richtig: Ein strukturierter Design-Brief als separater Prompt.

ROLLE: Du bist ein Senior Product Designer und Tech Lead.
AUFGABE: Erstelle einen strukturierten Design-Brief für eine Cross-Platform-Auftragsmanagement-App.

KONTEXT:
- Zielgruppe: Handwerker, Reinigungskräfte, Kurierdienste
- Plattformen: iOS und Android
- Kern-Feature: Bidirektionaler Medien-Upload + Zahlungsabwicklung

OUTPUT-STRUKTUR:
1. User Personas (2 Stück, max. je 80 Wörter)
2. User Journey Map (3 Kern-Szenarien als Bullet-Points)
3. Feature-Matrix (MVP vs. Phase 2)
4. Technologie-Empfehlung mit Begründung
5. Risikoanalyse (Top 3)

Warum das der beste Weg ist: Sie definieren einmalig die Spielregeln. Jeder nachfolgende Prompt kann sich auf diesen Brief beziehen (“Gemäß Design-Brief Abschnitt 3…”), anstatt Kontext zu wiederholen. Das spart massiv Tokens über den gesamten Projektverlauf.

5. Die Architektur des Token-minimierten Prompting

5.1 Das Prinzip der “Prompt-Hierarchie”

Stellen Sie sich das Projekt als Baumstruktur vor:

[Level 0] Projekt-Charter (1x)
    │
    ├── [Level 1] Design-Brief (1x)
    │       │
    │       ├── [Level 2] Architektur-Spezifikation (1x)
    │       │       │
    │       │       ├── [Level 3] Backend-API-Spezifikation (1x)
    │       │       │       └── [Level 4] Einzelne Endpunkte (n x modular)
    │       │       │
    │       │       ├── [Level 3] Datenbank-Schema (1x)
    │       │       │
    │       │       └── [Level 3] Frontend-Komponenten-Bibliothek (1x)
    │       │               └── [Level 4] Einzelne Screens (n x modular)
    │       │
    │       └── [Level 2] UI/UX-Design-System (1x)
    │               └── [Level 3] Einzelne Screen-Designs (n x modular)
    │
    └── [Level 1] Test-Strategie (1x)
            └── [Level 2] Einzelne Test-Suites (n x modular)

Regel: Ein Prompt behandelt immer genau einen Knoten. Nie zwei. Nie einen ganzen Ast.

5.2 Das “Referenz-Prinzip”

Anstatt Inhalte zu wiederholen, referenzieren Sie:

Gemäß Architektur-Spezifikation (Level 2):
- Auth: JWT-basiert, Refresh-Token-Rotation
- API-Format: RESTful JSON

Erstelle nun für den Endpunkt POST /tasks die detaillierte Spezifikation.

Token-Einsparung: Wiederholung kostet Tokens. Referenzierung kostet fast nichts.

6. Phase 1: Discovery & Requirements (Token-Effizienz: 40 % Einsparung)

6.1 Der Initial-Prompt: Projekt-Charter

ROLLE: Senior Product Manager & Solutions Architect
AUFGABE: Erstelle eine Projekt-Charter für eine Auftragsmanagement-App.

KONTEXT-REGELN (nur Stichworte, keine Erklärungen):
- Plattform: iOS + Android (Cross-Platform)
- Nutzerrollen: Auftraggeber (Aufgaben erstellen), Auftragnehmer (Aufgaben ausführen)
- Kern-Features: Aufgabenzuweisung, bidirektionaler Bild-Upload, Status-Tracking, Zahlung
- Zahlungsmethoden: PayPal, Wero, Kreditkarte (Stripe), Plugin-Architektur für weitere
- Compliance: DSGVO, PCI-DSS (für Zahlungen)

OUTPUT:
1. Scope-Definition (In-Scope / Out-of-Scope als Tabelle)
2. Annahmen & Abhängigkeiten (max. 5 Punkte)
3. Erfolgskriterien (3 messbare KPIs)
4. Risiko-Matrix (4 Felder: Hoch/Dringend, Hoch/Nicht dringend, etc.)

Warum Stichworte statt Fließtext? Kimi versteht semantische Zusammenhänge auch aus Stichworten. Fließtext kostet 3-4x mehr Tokens ohne Mehrwert.

6.2 Die Gefahr der Ungenauigkeit

Ungenauigkeit: “Bilder sollen hochgeladen werden können.”

Konsequenz: Kimi könnte annehmen:

• Bilder werden lokal gespeichert (falsch – Cloud-Speicher nötig)
• Keine Komprimierung (falsch – Mobile Datenkosten)
• Keine Validierung (falsch – Sicherheitsrisiko)

Rückfrage-Kosten: 1 ungenauer Satz → 3-5 Korrektur-Prompts à 500 Tokens = 2.000 Tokens verbrannt.

Präzise Alternative:

Bild-Upload-Spezifikation:
- Speicher: AWS S3 / Firebase Storage (temporäre Signed URLs)
- Komprimierung: Client-seitig max. 2MB, Server-seitig WebP-Konvertierung
- Validierung: MIME-Type (JPG/PNG/HEIC), Virenscan (ClamAV)
- Metadaten: EXIF-Stripping, Timestamp, Geolocation (optional, DSGVO-konform)

7. Phase 2: Architektur & Tech-Stack (Token-Effizienz: 35 % Einsparung)

7.1 Der Architektur-Prompt

ROLLE: Software Architect
AUFGABE: Definiere den Tech-Stack für TaskFlow Pro basierend auf der Projekt-Charter.

BESCHRÄNKUNGEN:
- Cross-Platform: React Native (Begründung in 1 Satz)
- Backend: Node.js + Express oder Firebase (Vergleich in Tabelle)
- Datenbank: PostgreSQL (relationale Daten) + Redis (Sessions/Cache)
- Zahlungen: Stripe als Primary, PayPal SDK, Wero (Sofortüberweisung)
- Bilder: Firebase Storage mit Client-Komprimierung

OUTPUT-STRUKTUR:
1. Tech-Stack-Tabelle (Komponente | Technologie | Begründung)
2. High-Level-Architektur-Diagramm (als ASCII-Art oder Mermaid-Syntax)
3. Datenfluss: Bild-Upload (Sequenzdiagramm, 5 Schritte)
4. Datenfluss: Zahlungsabwicklung (Sequenzdiagramm, 7 Schritte)
5. Sicherheits-Layer (Auth, Encryption, Validation)

Warum Mermaid/ASCII-Art? Visuelle Strukturen sind token-effizienter als textuelle Beschreibungen. Ein Diagramm ersetzt 200 Wörter.

7.2 Modulare Architektur für Zahlungen

Falsch (monolithisch): “Integriere PayPal, Wero und Kreditkarte in einem Zahlungsmodul.”

Richtig (Plugin-Architektur):

Zahlungs-Adapter-Pattern:
- Interface: PaymentProvider { init(), createPayment(), verify(), refund() }
- Implementierungen: StripeProvider, PayPalProvider, WeroProvider
- Factory: PaymentFactory.getProvider(method)

Erstelle zunächst das Interface und die Factory.
Die konkreten Provider werden in separaten Prompts implementiert.

Warum? Sie können Stripe testen, während Kimi noch an PayPal arbeitet. Parallelisierung spart Zeit und Kontext.

8. Phase 3: UI/UX Design (Token-Effizienz: 50 % Einsparung)

8.1 Das Design-System zuerst

Niemals einzelne Screens designen, bevor das Design-System nicht steht.

ROLLE: UI/UX Designer
AUFGABE: Erstelle ein Design-System für TaskFlow Pro.

DESIGN-PRINZIPIEN:
- Mobile-First, Touch-Targets min. 44x44pt
- Dark-Mode-Support
- Barrierefreiheit: WCAG 2.1 AA

OUTPUT:
1. Farbpalette (Primary, Secondary, Semantic: Success/Warning/Error/Dark)
2. Typografie-Skala (6 Größen, Font: Inter oder System-Default)
3. Komponenten-Bibliothek (Buttons, Inputs, Cards, Avatars, Status-Badges)
4. Icon-Set (Outline-Stil, 24px Grid)
5. Layout-Raster (8px-Basis, Margin/Spacing-Token)

8.2 Screen-Designs mit Referenz

ROLLE: UI Designer
AUFGABE: Designe den "Aufgaben-Detail-Screen".

REFERENZ:
- Design-System: Primary #2563EB, Status-Badge-Komponente, Card-Komponente
- User Story: Auftraggeber sieht Aufgaben-Status, Bilder und Zahlungsstatus

ELEMENTE (in Reihenfolge):
1. Header: Aufgaben-Titel, Status-Badge (Offen/In Bearbeitung/Erledigt)
2. Medien-Sektion: Horizontales Scroll-Carousel mit Bildern (max. 6 Thumbnails)
3. Beschreibung: Expandable Text, max. 3 Zeilen gefaltet
4. Aktionen: "Aufgabe bearbeiten" (Primary), "Auftragnehmer kontaktieren" (Secondary)
5. Zahlungs-Widget: Betrag, Methode, Status (nur sichtbar für Auftraggeber wenn Status=Erledigt)

OUTPUT: React Native JSX mit Styled-Components, kommentarlos.

Warum “kommentarlos”? In Design-Prompts sind Kommentare oft Token-Overhead. Sie können einen separaten Prompt für Dokumentation schreiben.

8.3 Die Bild-Upload-UI: Ein Fallbeispiel für Präzision

Ungenau (führt zu Rückfragen): “Es soll möglich sein, Bilder hochzuladen und anzusehen.”

Was Kimi nicht weiß:

• Kamera-Integration oder nur Gallery-Picker?
• Multi-Select oder Einzelupload?
• Vorschau vor Upload?
• Upload-Progress-Anzeige?
• Offline-Queue wenn kein Netz?

Präzise Spezifikation:

Bild-Upload-Flow:
1. Trigger: Floating-Action-Button (Kamera-Icon)
2. Auswahl: ActionSheet (Kamera aufnehmen / Galerie wählen / Abbrechen)
3. Vorschau: Full-Screen-Modal mit Zoom, Cropping-Option 4:3
4. Upload: Progress-Bar (0-100%), Cancel-Button
5. Fehler: Retry-Option, lokale Speicherung bis erfolgreich
6. Anzeige: Grid-Layout 2 Spalten, Lazy-Loading, Pinch-to-Zoom

9. Phase 4: Entwicklung (Token-Effizienz: 60 % Einsparung)

9.1 Die “Atomic Prompt”-Methode

Jeder Prompt behandelt genau eine atomare Einheit:

Beispiel: Authentifizierung

ROLLE: Senior React Native Developer
AUFGABE: Implementiere den Auth-Context mit JWT-Refresh-Flow.

TECH-STACK:
- React Native, Context API, AsyncStorage
- Backend: REST-API, Endpunkte bekannt (siehe Architektur-Spezifikation)

ANFORDERUNGEN:
- Login: Email + Password, Response: {accessToken, refreshToken}
- Speicherung: AccessToken im Memory, RefreshToken in AsyncStorage (encrypted)
- Auto-Refresh: 5 Min vor Ablauf, Silent-Refresh im Hintergrund
- Logout: Clear Memory + AsyncStorage, API-Call /auth/logout

NICHT IN SCOPE:
- Biometrische Auth (Phase 2)
- Social Login (Phase 2)

OUTPUT: TypeScript-Code, vollständig typisiert, mit Error-Handling.

9.2 Die Zahlungsintegration: Modularer Ansatz

Prompt 1: Zahlungs-Interface

// Output: PaymentProvider.ts
interface PaymentProvider {
  initialize(config: ProviderConfig): Promise<void>;
  createPayment(amount: number, currency: string, metadata: object): Promise<PaymentIntent>;
  verifyPayment(paymentId: string): Promise<PaymentStatus>;
  refund(paymentId: string, amount?: number): Promise<RefundResult>;
}

Prompt 2: Stripe-Implementierung

Implementiere StripeProvider basierend auf PaymentProvider-Interface.
- Stripe React Native SDK
- PaymentSheet für Kreditkarten
- Webhook-Handling für async Bestätigung

Prompt 3: PayPal-Implementierung

Implementiere PayPalProvider basierend auf PaymentProvider-Interface.
- PayPal Checkout SDK
- Order-V2 API

Prompt 4: Wero-Implementierung

Implementiere WeroProvider basierend auf PaymentProvider-Interface.
- Wero Payment Initiation API
- QR-Code-Generierung für In-Store (falls relevant)

Prompt 5: PaymentFactory

Erstelle die PaymentFactory, die basierend auf der Zahlungsmethode 
den korrekten Provider instanziiert.

Token-Einsparung: Statt einem 3.000-Token-Prompt für alle Zahlungsmethoden haben Sie fünf 600-Token-Prompts. Bei Fehlern müssen Sie nur einen Prompt wiederholen, nicht alle.

9.3 Der Bild-Upload: Backend + Frontend getrennt

Backend-Prompt:

ROLLE: Backend Developer (Node.js)
AUFGABE: REST-Endpunkt POST /upload/presigned-url

LOGIK:
1. Validiere JWT
2. Generiere Signed-URL für S3 (Gültigkeit: 15 Min)
3. Speichere Metadaten in DB (userId, taskId, filename, mimeType, status='pending')
4. Return: {uploadUrl, fileId, expiresAt}

SCHEMA (PostgreSQL):
files: id(UUID), task_id(FK), user_id(FK), filename, s3_key, mime_type, size_bytes, status, created_at

Frontend-Prompt:

ROLLE: React Native Developer
AUFGABE: Upload-Service mit Presigned-URL

FLOW:
1. Bild auswählen (react-native-image-picker)
2. Client-seitige Komprimierung (react-native-image-resizer, max 2MB)
3. POST /upload/presigned-url → erhalte Signed-URL
4. PUT direkt zu S3 mit Progress-Tracking (axios onUploadProgress)
5. PATCH /files/:id/confirm nach erfolgreichem Upload
6. Optimistische UI-Update: Thumbnail sofort anzeigen (lokal), nach Upload ersetzen

FEHLERBEHANDLUNG:
- Netzwerkfehler: Retry 3x, dann Queue in AsyncStorage
- S3-Fehler: Neuer Presigned-URL-Request

10. Phase 5: Testing & QA (Token-Effizienz: 45 % Einsparung)

10.1 Test-Strategie als separater Prompt

ROLLE: QA Engineer
AUFGABE: Erstelle eine Test-Strategie für TaskFlow Pro.

TEST-EBENEN:
1. Unit Tests: Jest, React Native Testing Library
2. Integration Tests: MSW (Mock Service Worker) für API-Calls
3. E2E Tests: Detox (iOS + Android)

TEST-FÄLLE FÜR BILD-UPLOAD:
- TC-UP-001: Erfolgreicher Upload (JPEG, 1MB)
- TC-UP-002: Übergroße Datei (JPEG, 10MB → muss komprimiert werden)
- TC-UP-003: Ungültiger Dateityp (PDF → Error)
- TC-UP-004: Netzwerkabbruch nach 50% → Retry
- TC-UP-005: Offline-Upload → Queue & Sync

TEST-FÄLLE FÜR ZAHLUNGEN:
- TC-PAY-001: Stripe Kreditkarte erfolgreich
- TC-PAY-002: Stripe 3D-Secure erforderlich
- TC-PAY-003: PayPal Abbuchung
- TC-PAY-004: Wero Überweisung
- TC-PAY-005: Unzureichendes Guthaben → Error-Handling

10.2 Automatisierte Test-Generierung

ROLLE: Test Engineer
AUFGABE: Generiere Unit Tests für den PaymentFactory.

INPUT (Code aus vorherigem Prompt):
[PaymentFactory-Code einfügen]

OUTPUT:
- Jest-Test für jede Zahlungsmethode
- Mock für StripeProvider, PayPalProvider, WeroProvider
- Edge Case: Unbekannte Zahlungsmethode → Error

11. Phase 6: Deployment & Store-Veröffentlichung

11.1 CI/CD-Pipeline

ROLLE: DevOps Engineer
AUFGABE: GitHub Actions Workflow für React Native CI/CD.

TRIGGER: Push auf main, Pull Requests

JOBS:
1. Lint & Type Check: ESLint, Prettier, tsc --noEmit
2. Unit Tests: Jest mit Coverage-Threshold (80%)
3. Build iOS: Fastlane match + gym
4. Build Android: Fastlane gradle assembleRelease
5. Deploy Staging: Firebase App Distribution
6. Deploy Production: App Store Connect + Google Play Console (nur bei Tag)

SECRETS MANAGEMENT:
- Stripe API Keys (Test vs. Live)
- PayPal Client ID / Secret
- S3 Bucket Credentials
- Firebase Config

11.2 Store-Assets

ROLLE: App Store Optimization Specialist
AUFGABE: Erstelle Store-Assets für TaskFlow Pro.

iOS App Store:
- Screenshots: 6.7" (iPhone 15 Pro Max), 6.1" (iPhone 15), 5.5" (iPhone SE)
- Text: Titel (30 Zeichen), Untertitel (30 Zeichen), Beschreibung (4000 Zeichen)

Google Play:
- Feature Graphic (1024x500)
- Screenshots: 16:9 und 9:16
- Kurze Beschreibung (80 Zeichen), Lange Beschreibung (4000 Zeichen)

KEYWORDS (für ASO):
Auftragsmanagement, Handwerker-App, Zahlung per App, Aufgaben-Tracking

12. Anti-Patterns: Was Sie vermeiden müssen

12.1 Der “Alles-in-einem”-Prompt

❌ FALSCH:
"Erstelle mir eine komplette App mit Login, Aufgaben, Bildern und Zahlungen.
Nutze React Native, Firebase und Stripe. Die App soll schön aussehen und
schnell sein. Achte auf Sicherheit. Danke!"

PROBLEME:
- Keine definierte Ausgabe-Struktur → unstrukturierter Output
- Keine Technologie-Versionen → veraltete SDKs
- "Schön aussehen" ist nicht messbar → subjektive Ergebnisse
- "Schnell sein" ohne Metriken → nicht überprüfbar
- Keine Fehlerbehandlung definiert → Lücken im Code

Kosten: Dieser Prompt erzeugt 2.000 Tokens Output, von denen 60 % unbrauchbar sind. Dann folgen 5 Korrektur-Prompts à 1.000 Tokens. Gesamt: 7.000 Tokens für etwas, das modular in 2.500 Tokens lösbar wäre.

12.2 Der “Kontext-vergessende” Prompt-Kette

❌ FALSCH:
Prompt 1: "Erstelle ein Login-System."
Prompt 2: "Füge jetzt Bild-Upload hinzu." (ohne Bezug auf Auth)
Prompt 3: "Integriere Zahlungen." (ohne Bezug auf vorherige Prompts)

PROBLEM: Kimi hat keinen gemeinsamen Kontext über die Prompts hinweg.
Jeder Prompt startet bei Null. Inkonsistenzen sind garantiert.

Lösung: Ein Master-Dokument (Projekt-Charter), auf das jeder Prompt referenziert.

12.3 Der “implizite Annahme”-Prompt

❌ FALSCH:
"Der Auftragnehmer soll die Aufgabe als erledigt markieren können."

WAS KIMI NICHT WEISS:
- Braucht es eine Bestätigung durch den Auftraggeber?
- Was passiert mit offenen Zahlungen?
- Sollen Bilder Pflicht sein vor Markierung?
- Gibt es eine Stornierungsfrist?

Konsequenz: Kimi implementiert den einfachsten Fall. Sie müssen 3x nachbessern.

13. Ungenauigkeiten und ihre Eskalationskosten

Faustregel: Jede unpräzise Anforderung multipliziert sich mit Faktor 3-5 in der Token-Anzahl.

14. Das ultimative Prompt-Template

Speichern Sie dies als wiederverwendbare Vorlage:

=== PROJEKT-KONTEXT ===
Projekt: [Name]
Phase: [Discovery/Design/Arch/Dev/Test/Deploy]
Referenz: [Link zu vorherigem Output oder Abschnitt]

=== ROLLE ===
[Spezifische Rolle, z.B. Senior React Native Developer]

=== AUFGABE ===
[Konkrete, atomare Aufgabe]

=== INPUT / KONTEXT ===
[Relevante Code-Snippets, Schemas, Designs aus vorherigen Prompts]

=== ANFORDERUNGEN (MUST) ===
- [Messbare Anforderung 1]
- [Messbare Anforderung 2]

=== EINSCHRÄNKUNGEN (MUST NOT) ===
- [Was explizit ausgeschlossen ist]

=== OUTPUT-FORMAT ===
[Code / Diagramm / Tabelle / Text]

=== VALIDIERUNG ===
[Wie das Ergebnis geprüft werden soll]

15. Praxisbeispiel: Kompletter Prompt-Flow für TaskFlow Pro

Schritt 1: Projekt-Charter (1 Prompt, ~800 Tokens)

→ Output: Scope, Annahmen, Risiken

Schritt 2: Design-Brief (1 Prompt, ~600 Tokens, referenziert Charter)

→ Output: Personas, User Journeys, Feature-Matrix

Schritt 3: Architektur (1 Prompt, ~700 Tokens, referenziert Brief)

→ Output: Tech-Stack, Diagramme, Datenflüsse

Schritt 4: Design-System (1 Prompt, ~500 Tokens, referenziert Brief)

→ Output: Farben, Typografie, Komponenten

Schritt 5: Datenbank-Schema (1 Prompt, ~600 Tokens, referenziert Architektur)

→ Output: SQL-DDL, Beziehungen, Indizes

Schritt 6: Auth-Modul (1 Prompt, ~700 Tokens)

→ Output: Login, JWT, Refresh

Schritt 7: Aufgaben-API (1 Prompt, ~800 Tokens)

→ Output: CRUD-Endpunkte, Validierung

Schritt 8: Bild-Upload-Backend (1 Prompt, ~700 Tokens)

→ Output: Presigned-URLs, S3-Integration

Schritt 9: Bild-Upload-Frontend (1 Prompt, ~800 Tokens)

→ Output: React Native Komponenten, Komprimierung

Schritt 10: Zahlungs-Interface (1 Prompt, ~400 Tokens)

→ Output: TypeScript-Interface

Schritt 11-13: Zahlungs-Provider (3 Prompts, je ~600 Tokens)

→ Output: Stripe, PayPal, Wero Implementierungen

Schritt 14: PaymentFactory (1 Prompt, ~300 Tokens)

→ Output: Factory-Pattern

Schritt 15: UI Screens (5 Prompts, je ~500 Tokens)

→ Output: Login, Dashboard, Aufgaben-Liste, Aufgaben-Detail, Zahlungs-Screen

Schritt 16: Test-Suite (1 Prompt, ~700 Tokens)

→ Output: Jest-Tests, E2E-Szenarien

Schritt 17: CI/CD (1 Prompt, ~600 Tokens)

→ Output: GitHub Actions, Fastlane

Schritt 18: Store-Assets (1 Prompt, ~500 Tokens)

→ Output: Screenshots, Beschreibungen, Keywords

Gesamt: 18 Prompts, ca. 12.000 Tokens Input + Output

Vergleich Monolithischer Ansatz: Ein einziger Prompt mit allen Anforderungen würde 4.000 Tokens Input erzeugen, aber 8.000 Tokens unbrauchbaren oder inkonsistenten Output. Mit Korrekturschleifen: 20.000+ Tokens.

Einsparung: 40-50 %

16. Fazit: Die vier Säulen token-minimierten Promptings

Säule 1: Hierarchie

Arbeiten Sie nie auf mehr als einer Abstraktionsebene gleichzeitig. Charter → Design → Architektur → Modul → Funktion.

Säule 2: Referenzierung

Wiederholen Sie nie, was bereits definiert wurde. Verweisen Sie auf Dokumente, Abschnitte, vorherige Outputs.

Säule 3: Atomisierung

Jeder Prompt behandelt genau eine Entscheidung, eine Funktion, einen Screen. Nicht mehr.

Säule 4: Präzision

Jede Anforderung muss messbar, validierbar und kontextfrei verständlich sein. Keine adjektivischen Beschreibungen (“schön”, “schnell”, “benutzerfreundlich”), sondern konkrete Spezifikationen.

Anhang A: Quick-Reference Card

Anhang B: Glossar

Ende des Whitepapers

Dieses Dokument ist als lebendes Dokument gedacht. Passen Sie die Templates an Ihren spezifischen Workflow an, behalten Sie aber die vier Säulen bei. Die Investition in strukturiertes Prompting zahlt sich bereits beim zweiten Projekt exponentiell aus.