Claude Code Systemprompt-Montage und Struktur enthüllt

System-Prompt-Erstellungsprozess

Der System-Prompt wird in einer festen Reihenfolge in src/constants/prompts.ts über getSystemPrompt() zusammengestellt. Die Struktur folgt: zuerst statischer Inhalt, dann ein dynamischer Grenzmarker, gefolgt von einem sitzungs-/benutzerspezifischen Suffix.

return [
  // Statischer Inhalt (cachebar)
  getSimpleIntroSection(),
  getSimpleSystemSection(),
  getSimpleDoingTasksSection(),
  getActionsSection(),
  getUsingYourToolsSection(),
  getSimpleToneAndStyleSection(),
  getOutputEfficiencySection(),
  // Cache-Grenze
  SYSTEM_PROMPT_DYNAMIC_BOUNDARY,
  // Dynamischer/Sitzungsinhalt
  getSessionSpecificGuidanceSection(),
  loadMemoryPrompt(),
  getAntModelOverrideSection(),
  computeSimpleEnvInfo(),
  getLanguageSection(),
  getOutputStyleSection(),
  getMcpInstructionsSection(),
  getScratchpadInstructions(),
  getFunctionResultClearingSection(),
  SUMMARIZE_TOOL_RESULTS_SECTION,
]

Identitäts-Präfix-Varianten

Drei Identitätsvarianten sind in src/constants/system.ts definiert:

• Standard-Interaktivmodus: "Du bist Claude Code, die offizielle CLI von Anthropic für Claude."
• Agent-SDK-Voreinstellung (nicht-interaktiv + System-Prompt anhängen): "Du bist Claude Code, die offizielle CLI von Anthropic für Claude, die innerhalb des Claude Agent SDK läuft."
• Agent-SDK ohne Anhängen (nicht-interaktiv): "Du bist ein Claude-Agent, basierend auf Anthropics Claude Agent SDK."

Der Auswahlpfad ist vereinfacht als: Vertex API → Standard | Nicht-interaktiv + anhängen → SDK-Voreinstellung | Nicht-interaktiv → SDK | sonst → Standard.

Attribution/Abrechnungs-Header

Beobachtetes Format: x-anthropic-billing-header: cc_version={version}.{fingerprint}; cc_entrypoint={entrypoint}; [cch=00000;] [cc_workload={type};]

Hinweise: cch=00000 scheint ein Client-Auth-Platzhalter zu sein, der später vom HTTP-Stack überschrieben wird. cc_workload={type} scheint als Routing-/Planungshinweis zu dienen (z.B. cron-ähnliche Workloads).

Prompt-Abschnittsdetails

Der Einführungsabschnitt von getSimpleIntroSection() lautet: "Du bist ein interaktiver Agent, der Benutzern bei Softwareentwicklungsaufgaben hilft. Verwende die folgenden Anweisungen und die dir verfügbaren Werkzeuge, um dem Benutzer zu assistieren."

Der Systemregeln-Abschnitt (getSimpleSystemSection()) enthält hohe Betonung auf: nur Unterstützung in autorisierten/defensiven Sicherheitskontexten; Ablehnung destruktiver/bösartiger Nutzungsmuster; keine Halluzination von URLs (es sei denn, klar sicher/programmierbezogen); Behandlung von Systemerinnerungen und Hook-Feedback als strukturierte Steuersignale; Achten auf Prompt-Injection in Werkzeugausgaben; und automatische Kontextkompression bei wachsender Historie.

Aufgabenausführungsrichtlinien (getSimpleDoingTasksSection()) enthalten Kernanweisungen: tatsächliche Entwicklungsarbeit in Dateien durchführen, nicht nur abstrakte Antworten geben; Code lesen vor Änderungen; unnötige neue Dateien vermeiden; spekulative Refactorings oder Over-Engineering vermeiden; sicheren Code priorisieren; Fehler diagnostizieren vor Ansatzwechsel; und Ergebnisse ehrlich überprüfen (nicht behaupten, dass Prüfungen bestanden wurden, wenn sie es nicht taten). Es gibt auch einen zusätzlichen Anweisungssatz für interne Benutzer, der verstärkt: Kollaborationsmentalität, minimale Kommentare und wahrheitsgemäße Verifikationsberichterstattung.

Sichere Ausführungsrichtlinien (getActionsSection()) rahmen Aktionen nach Umkehrbarkeit + Auswirkungsradius. Leitmuster: lokale/umkehrbare Aktionen: normalerweise fortfahren; destruktive, geteilte Zustände oder schwer umkehrbare Aktionen: zuerst bestätigen; frühere einmalige Genehmigung impliziert keine pauschale zukünftige Genehmigung; unerwarteten Zustand untersuchen vor Löschen/Überschreiben; Sicherheitsvorkehrungen nicht umgehen (z.B. --no-verify-Abkürzungen vermeiden). Beispiele, die Bestätigung erfordern, umfassen Force-Pushes.