ideal

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"