Ja. Das ist die richtige Frage. Die eigentliche Kunst ist **nicht** “einen guten Prompt schreiben”. Die eigentliche Kunst ist, **Task, Harness und Modell getrennt zu denken**. Viele machen stillschweigend diesen Fehler: * sie schreiben **einen** Prompt, * werfen ihn in irgendein Harness, * wechseln das Modell, * und wundern sich, warum sich das Verhalten stark ändert. Aber ein starker AI Engineer denkt in **drei Ebenen**: ## 1. Die drei Ebenen, die du auseinanderhalten musst ### Ebene A: Task Spec Das ist die **objektive Arbeitsbeschreibung**. Unabhängig von Modell und Harness. Beispiel hier: * lange PDF * modularer Führungsleitfaden * semantisches Chunking * Subagents parallel * lokale Summaries * Cross-checks * Konsolidierung * finale Markdown-Datei * Shell-Skript für PDF Das ist der Teil, der **stabil** bleibt. ### Ebene B: Harness Prompting Das ist die Anpassung an die **Laufzeitumgebung**: * Kann das Harness gut parallelisieren? * Hat es echte Subagents oder nur sequentielle Tool-Loops? * Kann es Dateien robust schreiben? * Ist es eher chatty oder eher execution-first? * Muss man Schreibzugriffe koordinieren? * Ist es terminal-first, cloud sandbox, IDE-native? Das ist **nicht** primär Modellprompting. Das ist **Betriebssystem-/Orchestrierungs-Prompting**. ### Ebene C: Model Prompting Das ist die Anpassung an das **kognitive Profil des Modells**: * Wie gut inferiert es fehlende Schritte? * Wie stark halluziniert es elegante Übergänge? * Wie viel Struktur muss man explizit vorgeben? * Wie stark muss man Anti-Slop-Regeln setzen? * Wie gut hält es lokale vs. globale Trennung? * Wie gut kann es sich selbst verifizieren? Das ist der Teil, der sich zwischen **Minimax**, **GPT-5.4** und **Opus 4.6** wirklich ändert. --- # 2. Was ist ein guter mentaler Frame? Denk nicht: > “Wie promptet man Modell X?” Denk lieber: > “Welche Fehler macht dieses Modell in diesem Harness auf diesem Task?” Das ist viel näher an echter AI-Engineering-Arbeit. Denn Prompting ist im Kern: **Fehlerprävention durch Spezifikation.** --- # 3. Was sich beim Harness ändert ## A. OpenCode So wie du es beschreibst, nutzt du OpenCode als eher **ausführungsorientiertes Coding-Harness**, mit Möglichkeit, Arbeit in mehrere Subagents auszulagern und parallel laufen zu lassen. Das heißt: * du musst **Agent-Rollen sehr hart trennen** * du musst **Artefakte** definieren * du musst **Schreibkonflikte verhindern** * du musst sagen, **wer was lesen darf** * du musst sagen, **wer global synthetisieren darf und wer nicht** OpenCode-Prompts sollten deshalb oft sein: * stark workflow-orientiert * datei- und artefaktzentriert * explizit parallelisierbar * mit klarer Ownership pro Agent OpenCode ist also eher: **“Agentenbetriebssystem prompten”** als **“schönen Text prompten”**. ## B. Codex mit GPT-5.4 OpenAI beschreibt Codex als Coding-Agent für Softwareentwicklung; es kann lokal oder in der Cloud arbeiten, und Codex ist explizit auf Software-Tasks, Codeverständnis und Delegation ausgelegt. OpenAI empfiehlt für die meisten Codex-Aufgaben mit `gpt-5.4` zu starten. ([OpenAI Entwickler][1]) Für Codex ist der richtige Prompt meist: * **weniger micromanaged** * etwas mehr **outcome-oriented** * trotzdem mit **klaren Deliverables** * plus **Verification Loop** Warum? Weil GPT-5.4 stark in agentischen, coding-lastigen und professionellen Workflows ist und OpenAI für GPT-5.4 explizit Dinge wie Verifikationsschleifen, Structured Outputs und saubere Tool-Preambles empfiehlt. ([OpenAI Entwickler][2]) Mit Codex musst du also weniger sagen: * “bitte denke auch an Schritt 7b” und mehr: * “das sind die Deliverables, das sind die Qualitätsgates, das ist die erlaubte Arbeitsweise, das ist der Verifikationsrahmen”. Codex/GPT-5.4 ist oft stärker, wenn du ihm: * Zielzustand, * Constraints, * Prüfkriterien, * Artefaktstruktur klar gibst, aber nicht jede Mikroentscheidung erdrückst. ## C. Claude Code mit Opus 4.6 Hier spreche ich jetzt bewusst als Engineering-Inferenz, nicht als zitierte Produktspezifikation: Ein Claude-Code-artiges Terminalharness wirkt typischerweise am besten, wenn du ihm: * **grobe Richtung** * **starke Prinzipien** * **wenige, aber harte Qualitätsregeln** * **klare Arbeitsphasen** * **Review-/Plan-Disziplin** gibst. Warum? Weil solche Modelle in terminalnahen Coding-Setups oft sehr gut sind in: * Codebase lesen * Plan bilden * große semantische Bögen halten * brauchbare Refactors und Synthesen formulieren Aber sie neigen eher dazu, * zu viel global zu denken, * zu früh zu synthetisieren, * Dinge elegant zu glätten, * und lokale Grounding-Grenzen zu überschreiten. Für Opus-artige Modelle ist daher oft wichtig: * **weniger Prozessbürokratie als bei schwächeren Modellen** * aber **starke epistemische Regeln** * also: “erfinde nichts, markiere Unsicherheit, halte lokale und globale Ebenen getrennt”. --- # 4. Was sich beim Modell ändert Jetzt zum Kern. ## Minimax M2.7 Aus deinem Experimentbild heraus würde ich Minimax so behandeln: **Stärken** * schnell * produktiv * kann gute Makrostruktur simulieren * kann erstaunlich starke zusammenhängende Texte bauen **Risiken** * wirkt überzeugender als es geerdet ist * füllt Lücken mit plausibler Prosa * macht aggressive narrative Glättung * braucht härtere lokale Begrenzung * braucht stärkere Fact-Check-Schicht Deshalb muss der Prompt für Minimax: * **expliziter** * **enger** * **rollenstärker** * **anti-hallucination-lastiger** * **stärker datei- und formatgesteuert** sein. Mit Minimax promptest du mehr wie: > “Hier ist das Geländer. Hier sind die Wände. Hier darfst du laufen. Hier nicht.” ## GPT-5.4 OpenAI beschreibt GPT-5.4 als stark für agentische, coding-lastige und professionelle Workflows; die offiziellen Prompt-Guides betonen Verifikationsschleifen, Structured Outputs und Tool-Persistence, und OpenAI sagt, dass `gpt-5.4` in Codex für die meisten Aufgaben der sinnvolle Startpunkt ist. ([OpenAI Entwickler][2]) Was heißt das praktisch? GPT-5.4 braucht oft: * **klaren Endzustand** * **klare Prüfkriterien** * **saubere Phasen** * **weniger redundante Wiederholung** * **weniger defensive Überinstruktion** Es verträgt eher: * “hier ist der Job, hier sind die Artefakte, hier sind die Qualitätsgates, arbeite sauber” als * 200 Zeilen Micromanagement. Wenn du GPT-5.4 wie ein kleines Modell behandelst, schadest du oft: * es wird schwerfällig, * formalistisch, * manchmal unnötig rigid, * und verbringt zu viel Energie mit dem Befolgen des Metaprozesses statt mit dem Kernproblem. Mit GPT-5.4 promptest du mehr wie: > “Hier ist die Mission, hier ist der Qualitätsrahmen, zeig mir robuste Execution.” ## Opus 4.6 Für Opus-artige große reasoning/stylistic Modelle würde ich sagen: Sie profitieren oft von: * **Prinzipien** * **Review-Disziplin** * **hochrangiger Zieldefinition** * **epistemischen Grenzen** * **klaren Stop-Regeln** Sie brauchen nicht unbedingt jeden Formatcontainer ausbuchstabiert, aber sie brauchen sehr wohl: * “nicht ausschmücken” * “nicht psychologisieren” * “keine historischen Schlüsse ohne Deckung” * “keine globale Synthese vor lokaler Extraktion” Mit Opus promptest du oft mehr wie: > “Arbeite wie ein guter Senior Analyst mit starker Selbstdisziplin.” --- # 5. Das Entscheidende: derselbe Task, drei verschiedene Prompt-Stile Jetzt wird es konkret. --- ## Prompt-Stil für Codex + GPT-5.4 Hier würde ich **Outcome-first + Verification-first** prompten. ### Charakter * klar * knapp * professionell * deliverable-orientiert * mit Qualitätsgates * nicht zu überfrachtet ### Beispiel ```text Task: Summarize the uploaded Heidelberg Castle guide into a source-faithful Markdown document that can later be rendered into a ~15-page PDF. Context: This is not a linear book. It is a modular guide for castle tours with four top-level modules: 1. History 2. Architecture 3. Personalities 4. Cultural history Required workflow: 1. Read the document structure and create a semantic chunk plan. 2. Summarize each chunk locally before attempting any global synthesis. 3. Run verification passes for chronology, person/title consistency, and architecture/building attribution. 4. Merge the verified local summaries into a single coherent Markdown summary. 5. Create a shell script that renders the Markdown to PDF. Deliverables: - work/document_map.md - work/chunk_plan.md - work/local_summaries/*.md - work/checks/chronology.md - work/checks/persons.md - work/checks/architecture.md - output/summary_15_pages.md - output/render_pdf.sh Quality bar: - Source-faithful - No invented facts - No decorative filler - Preserve uncertainty where the source is ambiguous - Prioritize “key facts” sections from the source - Final summary should reflect the source’s didactic structure, not flatten it into generic prose Before finalizing: - verify dates - verify ruler/person mappings - verify building-to-builder mappings - remove claims that are plausible but not clearly grounded in the source ``` ### Warum so? Weil GPT-5.4 stark genug ist, den Workflow zu tragen, wenn du ihm gibst: * Ziel * Arbeitsweise * Prüfkriterien * Artefakte. Du musst es nicht so stark “einsargen” wie Minimax. --- ## Prompt-Stil für Claude Code + Opus 4.6 Hier würde ich **Plan-first + Principle-first** prompten. ### Charakter * etwas semantischer * etwas analytischer * mehr Betonung auf Denkdisziplin * weniger auf starre Formatbürokratie * aber mit starken epistemischen Regeln ### Beispiel ```text You are producing a source-faithful analytical summary of a long Heidelberg Castle guide. This source is modular, not linear. Treat it as a structured teaching document, not as a conventional narrative book. Its top-level modules are history, architecture, personalities, and cultural history. Working method: - First map the document structure. - Then produce local summaries for semantically coherent sections. - Do not jump to global synthesis early. - After local extraction, perform explicit review passes: - chronology - person/title consistency - building/builder attribution - source faithfulness - Only then write the final consolidated summary. Important rules: - Do not invent transitions or historical motives. - Do not turn plausible inferences into assertions. - Do not smooth over ambiguities. - Respect the source’s didactic emphasis, especially explicit key facts. - Keep architecture, political history, and reception history distinct until the consolidation phase. Outputs: - a document map - a chunk plan - local section summaries - review notes - a final ~15-page Markdown summary - a shell script to render it to PDF Write densely and clearly. Prefer precision over flourish. ``` ### Warum so? Weil Opus-artige Modelle oft stark sind, wenn du ihnen: * semantische Disziplin, * epistemische Strenge, * Review-Phasen, * und klare High-Level-Prinzipien gibst. --- ## Prompt-Stil für OpenCode + Minimax M2.7 Hier würde ich **Workflow-first + Guardrail-first + Subagent-first** prompten. ### Charakter * explizit * streng modular * harte Agententrennung * formale Outputs * Anti-Halluzinationsblock * Anti-Slop-Block * Parallelitätsregeln ### Beispiel ```text You are running a multi-agent workflow. Goal: Create a source-faithful 15-page Markdown summary of the Heidelberg Castle guide and a shell script to render it to PDF. This is a modular guide, not a linear book. Primary modules: 1. History 2. Architecture 3. Personalities 4. Cultural history Agent roles: - Orchestrator - Structure agent - Local content agents - Chronology check agent - Person/dynasty check agent - Architecture check agent - Merge agent - Editor agent - Build agent Hard rules: - Local content agents may only use their assigned chunk. - No agent may write to another agent’s file. - Only merge/editor agents may create global synthesis. - Any uncertain claim must be marked as uncertain. - Any claim not clearly grounded in the source must be removed from the final summary. Required outputs: - work/00_document_map.md - work/01_chunk_plan.md - work/02_local_summaries/chunk_*.md - work/03_cross_checks/*.md - work/04_global_outline.md - output/summary_15_pages.md - output/render_pdf.sh Anti-hallucination rules: - no invented dates - no invented motives - no unsupported architectural labels - no elegant filler - no generic culture-language - no importing facts across chunks during local summarization Parallel execution: - run local content agents in parallel on independent semantic chunks - run cross-check agents in parallel after all local summaries exist - avoid shared write targets ``` ### Warum so? Weil Minimax sonst mit hoher Wahrscheinlichkeit: * zu früh global synthetisiert, * zu viel selbst ergänzt, * und dann sehr überzeugend falsch wird. --- # 6. Also: Wie muss der Prompt aussehen für welches Harness? Hier ist die Faustregel: ## Für Harnesses mit starker Agent-Orchestrierung Prompt muss enthalten: * Rollen * Artefakte * Zuständigkeiten * Abhängigkeiten * Parallelitätsregeln * Merge-/Check-Phasen ## Für Harnesses mit starkem Modell und guter Tool-Disziplin Prompt muss enthalten: * Ziel * Constraints * Deliverables * Verification gates * Stoppregeln ## Für terminalnahe, planstarke Harnesses Prompt muss enthalten: * Zielbild * epistemische Leitplanken * Plan- und Review-Disziplin * wenige harte Qualitätsregeln * keine unnötige Prozessverstopfung --- # 7. Also: Wie muss der Prompt aussehen für welches Modell? Noch kürzer: ## Schwächer / glatter / riskanter schreibende Modelle Mehr: * Struktur * Format * Regelhaftigkeit * Cross-checking * harte Lokalität * starke Negativregeln ## Stärkere reasoning-heavy Modelle Mehr: * Zielklarheit * Qualitätsgates * epistemische Regeln * weniger Mikromanagement * mehr Verantwortung beim Modell --- # 8. Woher weiß man das? Das ist die Kernfrage. Nicht durch Magie. Nicht durch “Prompting ist Kunst”. Sondern durch **Eval-getriebene Modellierung**. Du weißt es aus vier Quellen: ## 1. Offizielle Dokumentation Für GPT-5.4 und Codex ist das direkt nützlich: OpenAI dokumentiert, dass Codex ein Coding-Agent ist, für die meisten Codex-Aufgaben `gpt-5.4` der Startpunkt ist und GPT-5.4 gut mit Verifikationsschleifen, strukturierten Outputs und Tool-orientierten Arbeitsweisen harmoniert. ([OpenAI Entwickler][1]) Das ist dein **Prior**. ## 2. Harness-Verhalten beobachten Du siehst in echten Läufen: * wann das Modell zu früh synthetisiert * wann es lokale Grenzen missachtet * wann es Tool-Calls vergisst * wann es in langen Tasks entgleist * wann es zu chatty oder zu knapp wird Das ist dein **Runtime-Profil**. ## 3. Fehlerkataloge bauen Für jedes Modell/Harness-Paar solltest du fast wie in einem Labor notieren: * typische Halluzinationen * typische Strukturfehler * typische Tempo-/Kostenmuster * typische Missverständnisse * typische Stärken Dann promptest du nicht mehr abstrakt, sondern gezielt gegen Fehler. ## 4. Kleine kontrollierte Evals Das ist der wichtigste Punkt. Du machst nicht “große Gefühle”, sondern kleine Benchmarks: * 5 ähnliche PDFs * gleiche Task Spec * drei Promptvarianten * drei Modelle * Score auf: * Faithfulness * Coverage * Dedup * Coherence * Hallucination rate * Time * Cost Dann siehst du: * welches Modell mehr Freiheit verträgt * welches Modell mehr Geländer braucht * welches Harness welche Promptform am besten umsetzt --- # 9. Woher weiß *ich*, wie ich den Prompt schreiben muss? Nicht sicher im absoluten Sinn. Sondern durch eine Mischung aus: * allgemeiner Agent-/Prompt-Engineering-Heuristik, * beobachteten Fehlermustern, * Dokumenttyp-Erkennung, * und Anpassung an das wahrscheinliche Stärken-/Schwächenprofil von Modell + Harness. Also nicht: > “Ich kenne den perfekten Prompt.” Sondern: > “Ich versuche, die wahrscheinlichsten Failure Modes dieses Setups im Voraus zu neutralisieren.” Das ist der professionelle Frame. --- # 10. Was ein AI Engineer daraus machen sollte Wenn du das ernsthaft können willst, dann bau dir diese Arbeitsweise: ## Immer drei Artefakte trennen 1. **task_spec.md** 2. **harness_policy.md** 3. **model_adapter.md** Dann kombinierst du sie je nach Lauf. Beispiel: ### task_spec.md * PDF zusammenfassen * semantische Chunks * lokale Summaries * globale Konsolidierung * Markdown + PDF script ### harness_policy_opencode.md * Subagents * Parallelität * Dateibesitz * Merge-Phase * Check-Phase ### model_adapter_minimax.md * stärker explizit * Anti-Halluzination * harte Formatdisziplin ### model_adapter_gpt54.md * outcome-first * verification-first * weniger Micromanagement ### model_adapter_opus46.md * principle-first * review-first * epistemische Strenge Dann hast du echte **Prompt-Architektur**, nicht nur einzelne Texte. --- # 11. Meine verdichtete Theorie in einem Satz **Der richtige Prompt ist nicht nur eine Eigenschaft des Modells, sondern die Schnittstelle zwischen Taskstruktur, Harnessmechanik und Fehlertyp des Modells.** Das ist der Übergang von “gut prompten” zu **AI Engineering**. --- # 12. Mein praktischer Rat für dich Wenn du in diese Richtung willst, dann fang an, für jede Agent-Aufgabe systematisch zu dokumentieren: * Dokumenttyp * Task Spec * Harness * Modell * Promptversion * Fehlerbilder * Kosten * Dauer * Ergebnisqualität * nächste Hypothese Dann baust du dir dein eigenes internes **Prompt- und Harness-Wissenssystem**. Genau daraus entsteht später dein echter Vorteil gegenüber Leuten, die nur “ein bisschen mit Modellen rumspielen”. Wenn du willst, mache ich dir als Nächstes daraus ein **konkretes AI-Engineer-Template-Set**: * `task_spec.md` * `harness_policy_opencode.md` * `harness_policy_codex.md` * `harness_policy_claudecode.md` * `model_adapter_minimax.md` * `model_adapter_gpt54.md` * `model_adapter_opus46.md` * plus eine kleine Eval-Rubric. [1]: https://developers.openai.com/codex/?utm_source=chatgpt.com "Codex" [2]: https://developers.openai.com/api/docs/models/gpt-5.4?utm_source=chatgpt.com "GPT-5.4 Model | OpenAI API"