Agent 系统提示词编写完全指南：逆向工程 Claude 代码的实战经验

我反编译了 Claude Code 的系统提示词，深挖了 DeepAgents 的源码，然后从零手搓了一个自己的 AI Agent。市面上大多数的提示词教程，说白了都是玄学。

现在的 AI 圈正在经历一场集体错觉。

几乎所有的教程都在教你把写系统提示词（System Prompt）当成念咒语——仿佛只要找到那句正确的咒语，模型就会乖乖听话。"你是一个拥有 20 年经验的、极其优秀的资深工程师..." 听起来很耳熟吧？

过去几个月，我一直在开发 VibeCom —— 一个能进行深度市场调研并生成 VC 级别分析报告的 AI 创业顾问。在这个过程中，我逆向工程了 Claude Code 的系统提示词，翻阅了 DeepAgents 的中间件源码，还烧掉了多到我都不好意思承认的 API 额度。最大的教训是什么？人们认为系统提示词里最重要的那些东西，其实大多无关紧要。而真正重要的东西，却几乎没人讨论。

这篇文章是一份完整的实战指南——不是那种 5 分钟的泛泛而谈，而是我在动手前希望能有人告诉我的所有干货。去倒杯咖啡吧，我们慢慢聊。

1. 设计哲学：信任模型

"Agent（智能体）就是模型本身。不是框架，也不是提示词链（Prompt Chain）。" — shareAI-lab/learn-claude-code

这个理念彻底改变了我的认知。LLM 已经知道如何推理、计划和执行。你的系统提示词不是在教它如何思考——而是在为它搭建一个工作环境。

把它想象成招募一位资深工程师。你不会给他们一份包含 20 个步骤的死板清单来完成每个任务。你会告诉他们：我们是谁，边界在哪里，什么样的结果算优秀。然后，你只需要放权让他们去干。

你的系统提示词只有四个核心任务：

告诉它它是谁 —— 角色与身份
告诉它边界在哪 —— 安全约束
告诉它什么是优秀 —— 质量标准
给它配备工具 —— 能力与知识

就这些。其他的都是噪音。

脚手架思维 (The Harness Mindset)

Harness = Tools + Knowledge + Observation + Action Interfaces + Permissions

你的系统提示词就是这个脚手架（Harness）的操作手册。你不是在设计一条僵化的流水线——你是在设计一个能让模型自主发挥出最佳水平的环境。

不要把系统提示词写成流程图。模型自己会决定执行顺序。

2. 提示词结构与段落顺序

为什么这个顺序很重要

LLM 存在 U 型注意力曲线 —— 它们对提示词开头和结尾的注意力最集中，而在中间部分容易走神。这就是著名的"迷失在中间 (Lost in the Middle)"效应，已经被大量研究证实。

身份与安全放在顶部：模型首先建立角色和边界（首因效应）。
核心工作流放在中上部：这是你最重要的部分——Agent 如何开展工作。
工具定义在你的提示词之后由系统注入：Claude Code 的工具定义吃掉了大约 11,438 个 Token。这意味着你自定义的内容实际上比你想象的更靠前——这有助于模型遵循指令。
提醒放在底部：利用近因效应来强化关键规则。

3. 逐个模块拆解

3.1 身份 (Identity) —— 这个 Agent 是谁？

目标： 用 1-3 句话锚定模型的角色。

You are Claude Code, Anthropic's official CLI for Claude.
You are an interactive agent that helps users with software engineering tasks.

指南：

保持简明扼要 —— 最多 1-3 句话。
明确命名角色（帮助模型区分上下文）。
陈述核心职责（"帮助处理 X"），而不是模糊的"你是一个有用的助手"。
如果适用，提及 SDK/平台（"基于 Anthropic 的 Claude Agent SDK 构建"）。

反面模式：

"你是一个有用、无害且诚实的 AI 助手" —— 太过通用，没有角色锚点。
整整一段的背景故事和设定 —— 浪费 Token，模型不需要角色养成。

3.2 安全与约束 (Security & Safety) —— 绝对的边界

目标： 设定不可打破的行为约束。

IMPORTANT: Assist with defensive security tasks only.
Refuse to create, modify, or improve code that may be used maliciously.
IMPORTANT: You must NEVER generate or guess URLs for the user.

指南：

使用 IMPORTANT: 前缀 —— Claude 的指令层级训练会赋予它额外的权重。
使用绝对的语气词：NEVER（绝不）、MUST NOT（禁止）、Refuse to（拒绝）。
同时说明允许做什么和禁止做什么（双向约束更清晰）。
放在最顶部，不要埋在中间。
在结尾重复关键的安全规则 —— Claude Code 就是这么做的。

为什么要重复？ 首因效应（开头）+ 近因效应（结尾）= 双重强化。Claude Code 的安全声明在提示词的开头和结尾都有出现。这不是因为工程师健忘——而是因为他们深谙 U 型注意力曲线。

3.3 语气与风格 (Tone & Style) —— 控制输出

目标： 控制输出格式和语气。

## Tone and style

- Your responses should be short and concise.
- Only use emojis if the user explicitly requests it.
- Use Github-flavored markdown for formatting.
- NEVER create files unless absolutely necessary.

指南：

列出具体的行为，而不是模糊的"保持专业"。
每条规则都应该是可以用 True/False 测试的（"简短扼要" vs "尽量简短"）。
包含输出格式要求（Markdown？JSON？纯文本？）。
包含不要做什么 —— 很多风格问题其实是关于禁止某些行为。

Claude Code 的神来之笔 —— 专业的客观性：

Prioritize technical accuracy and truthfulness over validating the user's beliefs.
Focus on facts and problem-solving, providing direct, objective technical info
without any unnecessary superlatives, praise, or emotional validation.

这一段至关重要：它阻断了模型"讨好"用户的倾向。如果你的 Agent 需要给出客观的判断（代码审查、想法评估、架构决策），你绝对需要一个类似的条款。

3.4 核心工作流 (Core Workflow) —— 最重要的一环

目标： 教模型如何工作 —— 传授方法论，而不是死板的程序。

这是最难写好的一节，但写对了收益也最大。

核心原则：给原则，不给步骤。

告诉 LLM 优秀的输出是什么样的，以及为什么优秀——让它自己想办法怎么达到那个目标。避免规定精确的字段数量、步骤顺序或格式，除非输出是要给下游机器读取的。

Claude Code 的做法：

## Doing tasks

The user will primarily request software engineering tasks.
For these tasks the following steps are recommended:

- Use the TodoWrite tool to plan the task if required

注意 "recommended"（推荐）这个词——而不是"你必须严格遵循这些步骤"。仅仅是这一个词的选择，就给了模型适应变化的弹性空间。

一个好的工作流定义：

1. Understand first — read existing code before modifying it
2. Plan first — break complex tasks into steps before executing
3. Minimal changes — only change what's necessary, don't "refactor while you're in there"
4. Verify — confirm your changes work (run tests, lint, etc.)

每条规则都有一个隐含的"为什么"——模型能够理解背后的意图，并将其泛化到新的场景中。

反面模式：

死板的 20 步流程 —— 模型会机械地执行，遇到意外输入就会卡死。
"先做 A，再做 B，然后做 C" —— 那是提示词链 (Prompt Chain)，不是 Agent 提示词。
对 LLM 本来就擅长的事情过度指导 —— 纯属浪费 Token。

在开发 VibeCom 时，我在这上面吃过苦头。早期的版本有一个 10 步的调研工作流。即使第 3 步已经回答了用户的问题，模型还是会尽职尽责地把 10 步全跑完。当我改用原则驱动（"调研直到你有充分的证据，然后进行综合分析"）后，输出质量上去了，Token 成本也降下来了。

例外情况： 当输出是由下游机器消费时（Agent 间通信、API 响应格式），你确实应该定义严格的格式。原则是用来约束行为的；Schema（模式）是用来定义接口的。

3.5 工具使用策略 (Tool Usage Policy) —— 消除歧义

目标： 当多个工具都能做同一件事时，告诉模型该优先用哪个。

## Tool usage policy

- Use specialized tools instead of bash commands:
  - Read for reading files instead of cat/head/tail
  - Edit for editing instead of sed/awk
  - Grep for searching instead of grep/rg
- You can call multiple tools in a single response. If independent, call in parallel.
- Use the Task tool for file search to reduce context usage.

指南：

使用 "instead of"（而不是）来表达优先级（用 A 而不是 B）。
解释为什么要偏好某些工具（"提供更好的用户体验"、"减少上下文占用"）。
定义并行策略（独立的 → 并行，依赖的 → 串行）。
列出工具使用的安全约束（路径验证、权限检查）。

工具与提示词之间的关键关系：

工具定义通常是由系统注入的，你无法直接编辑。Claude Code 的工具定义大约有 11,438 个 Token。这意味着：

不要在系统提示词中重复工具定义里已经有的信息。
利用系统提示词进行战略性指导：什么时候使用哪个工具，为什么偏好某一个，以及优先级顺序。
工具定义的质量直接影响 Agent 的效能——如果你在构建自己的 Agent，花点时间写出优秀的工具描述。

3.6 领域知识 (Domain Knowledge) —— 按需加载，而非提前灌输

目标： 提供模型训练数据中可能缺乏的专业知识。

核心原则：渐进式披露，而不是知识大倾倒。

❌ Paste all 200 API endpoints into the system prompt → token explosion
✅ Give the model a tool to look things up → "Load knowledge when you need it"

这个策略在 Claude Code 的 Skills 系统和 DeepAgents 的 Progressive Disclosure（渐进式披露）中间件中都有体现。两者都是通过工具调用按需加载知识，而不是把所有东西都预先塞进去。

实现方式：

在系统提示词中放置指针："需要时使用 get_api_docs 工具检索文档"。
使用 CLAUDE.md / AGENTS.md 提供项目上下文 —— 在运行时加载，而不是硬编码。
使用 Skills / SKILL.md 进行能力发现 —— 模型看到可用技能的菜单，按需获取完整的规格说明。

3.7 环境信息 (Environment Info) —— 运行时上下文

目标： 让模型感知其执行环境。

<env>
Working directory: /Users/fengliu/Desktop/tfm/vibecom
Is directory a git repo: true
Platform: darwin
Today's date: 2026-03-21
</env>
You are powered by the model named Claude Opus 4.6.

指南：

动态生成，绝不硬编码。
包含：工作目录、操作系统平台、日期、模型名称、Git 状态。
使用结构化格式（XML 标签或代码块）以便于解析。
日期很重要 —— 模型需要知道"现在"是什么时候，才能判断信息的新鲜度。

3.8 提醒 (Reminders) —— 最后的强化

目标： 在提示词的最后重申最关键的规则。

Claude Code 在底部重复了它的安全约束和 TodoWrite 要求：

IMPORTANT: Assist with defensive security tasks only. [repeated]
IMPORTANT: Always use the TodoWrite tool to plan and track tasks. [repeated]

指南：

只重复 2-3 条最关键的规则 —— 不要把所有东西都复制一遍。
利用近因效应 —— 模型对近期内容的记忆更深刻。
最佳候选：安全约束、最常被违反的规则、核心工作流提醒。

4. Token 预算与上下文管理

预算分配参考

模块	推荐 Token 数	备注
身份与安全	200-500	简短但不可妥协
语气与风格	300-800	规则必须具体，但别啰嗦
核心工作流	500-2,000	最重要的部分，值得投入
工具使用策略	300-1,000	取决于工具数量
领域知识	0-1,000	首选按需加载
环境信息	100-300	动态生成
提醒	100-300	只重复最核心的
你的总计	1,500-6,000
工具定义（系统注入）	5,000-15,000	不受你控制

上下文衰减曲线

社区测试（Reddit 用户 u/CodeMonke_）绘制了真实世界中的指令遵循衰减情况：

< 80K tokens：提示词遵循度保持稳定
80K - 120K tokens：指令遵循开始衰减
> 120K tokens：显著衰减 —— 模型会"忘记"早期的指令
> 180K tokens：严重衰减

你拥有的 200K 上下文窗口 ≠ 200K 的有效上下文。 请据此做好规划。

缓解策略：

保持你的系统提示词精简（你控制的部分 < 6,000 tokens）。
使用摘要来压缩对话历史（DeepAgents 在约 80K 字符时触发）。
将关键规则放在提示词的两端（U 型注意力）。
在对话中途注入 <system-reminder> 标签（详见第 8 节）。

5. 写作原则

5.1 给原则，不给步骤

❌ "Step 1: Read the file. Step 2: Find the bug. Step 3: Fix it. Step 4: Run tests."
✅ "Always understand existing code before modifying it. Verify your changes work."

原则可以泛化。步骤只能被机械地遵循。当模型遇到你没有预料到的情况时，原则能指导它做出正确的决定。步骤做不到。

例外： 当输出由机器消费时（Agent 间通信、API 格式），请定义严格的 Schema。

5.2 对硬性约束使用绝对语气

强度	词汇	适用场景
绝对禁止	`NEVER`, `MUST NOT`	安全、不可逆操作
强烈要求	`ALWAYS`, `MUST`	核心工作流规则
推荐	`recommended`, `prefer`	允许例外的最佳实践
建议	`consider`, `you may`	可选的优化

Claude Code 示例：

NEVER update the git config —— 绝对禁止
ALWAYS prefer editing an existing file —— 强烈要求，但存在例外
The following steps are recommended —— 建议的工作流

5.3 用示例代替解释

## Code References

When referencing specific functions or pieces of code include
the pattern `file_path:line_number`.

<example>
user: Where are errors from the client handled?
assistant: Clients are marked as failed in the `connectToServer`
function in src/services/process.ts:712.
</example>

一个例子胜过百字解释：

模型从示例中学习模式的可靠性，远高于从抽象描述中学习。
使用 <example> 标签包裹，将其与规则区分开。
同时提供正向（"这样做"）和负向（"不要这样做"）的示例。
使用真实、具体的示例 —— 不要用 "foo/bar" 这种占位符。

5.4 双向约束

✅ "Use dedicated tools: Read for reading files, Edit for editing files."
✅ "Do NOT use bash for file operations (cat, head, tail, sed, awk)."

只说"做这个" → 模型不知道什么时候不该做。只说"别做这个" → 模型不知道替代方案是什么。双向约束 → 清晰且毫无歧义。

5.5 解释"为什么"，而不仅仅是"做什么"

❌ "Don't use git commit --amend."
✅ "Avoid git commit --amend. ONLY use --amend when either
   (1) user explicitly requested amend OR
   (2) adding edits from pre-commit hook.
   Reason: amending may overwrite others' commits."

解释为什么能让模型在边缘情况下做出正确的判断。Claude Code 的 Git 安全协议堪称教科书级别——每一条规则都暗示了其背后的基本原理。

5.6 结构胜于散文

Markdown 标题 (##, ###) —— 模型能识别层级结构。
无序列表优于段落 —— 每条规则都可以独立测试。
XML 标签用于特殊内容：<example>, <env>, <system-reminder>。
表格用于对比和映射。
绝不要倾倒非结构化的文本 —— 在指令遵循测试中，结构化的提示词表现始终优于自然语言散文。

6. 浪费 Token 的反面模式

伪装成 Agent 的提示词链

"First call tool A to get data.
Then call tool B with the result.
Then format the output as JSON.
Then save to file."

这不是 Agent 提示词——这是一个流水线脚本。模型会机械地执行，并丧失其自主规划能力。

解决方案： 告诉模型目标和约束。让它自己决定步骤。

奉承工程 (Flattery Engineering)

"You are an EXTREMELY TALENTED and INCREDIBLY EXPERIENCED
senior software engineer with 20 years of experience..."

赞美和最高级形容词并不会提高输出质量。模型没有自尊心需要你去满足。把这 15 个 Token 省下来写条真正的规则吧。

知识大倾倒

"Here is the complete API documentation for our 200 endpoints..."

这会吞噬你的上下文窗口，并加速上下文腐化。替换为按需加载：

"Use the get_api_docs tool to retrieve API documentation when needed."

重复工具描述

如果工具定义里已经写了"Read 工具用于从文件系统中读取文件"，就不要在系统提示词里再说一遍。只添加工具定义中没有涵盖的战略性指导——何时使用它，为什么偏好它，以及优先级顺序。

缺失失败处理机制

如果没有明确的指导，模型会在工具调用失败时陷入无限重试的死循环。请务必包含：

"If a tool call is denied, do not re-attempt the exact same call.
Think about why it was denied and adjust your approach."

无视上下文窗口衰减

200K 上下文窗口 ≠ 200K 的有效上下文。真实世界测试表明，衰减在 80K 时就开始了。你需要一个摘要策略。

7. 注入点与优先级

Claude Code 的三种自定义方法

方法	替换内容	注入位置	适用场景
Output Styles	"Tone and style" 和 "Doing tasks" 模块	就在工具定义之前	改变交互风格
--append-system-prompt	无（附加）	在 Output style 之后，工具定义之前	添加特定行为
--system-prompt	整个系统提示词	保留工具定义 + 一行身份声明	完全自定义（核弹选项）

如果你使用了多个：Output Style → Append Prompt → Tool Definitions

指令层级

Claude 专门针对指令层级进行了训练：

1. User's explicit instructions (CLAUDE.md, direct requests)  ← Highest priority
2. Custom system prompt additions                               ← High
3. Default system prompt                                        ← Medium
4. Tool definitions                                             ← Reference level

这意味着：

CLAUDE.md 的规则会覆盖默认的系统提示词行为。
用户的直接请求会覆盖一切。
你的自定义提示词会覆盖默认提示词。

动态注入机制

<system-reminder> —— 在对话中途注入到任何消息中，提醒模型关键规则。
CLAUDE.md / AGENTS.md —— 在运行时从文件加载，附加到系统提示词中。
Skills / SKILL.md —— 通过工具调用按需加载，零系统提示词占用。

8. 对话中途注入 —— 秘密武器

系统提示词只在消息数组的最开始出现一次。但 LLM 接受完整的消息数组（交替的用户/助手/工具消息）作为输入，你也可以将提示词注入到用户消息和工具结果中。 Claude Code 在生产环境中大量使用了这种技术。

为什么这是必要的

对抗上下文腐化。 随着对话变长，模型对系统提示词指令的遵循度会下降（在 80K+ Token 时很明显）。在对话中途注入提醒 = 利用近因效应刷新规则。

心智模型：

系统提示词 = 宪法（确立一次，具有长期权威）。
用户消息提醒 = 备忘录（定期发送，维持执行力度）。

消息数组中的三个注入点

Messages Array:
┌─────────────────────────────────────┐
│ System Prompt                       │ ← Appears once, primacy effect
│   (identity, safety, workflow...)   │
├─────────────────────────────────────┤
│ User Message 1                      │
│ Assistant Message 1                 │
│ User Message 2 + <system-reminder>  │ ← Mid-conversation injection
│ Assistant Message 2                 │
│ Tool Result + <system-reminder>     │ ← Can inject into tool results too
│ ...                                 │
│ User Message N + <system-reminder>  │ ← Latest message, strongest recency
└─────────────────────────────────────┘

位置	优势	劣势
系统提示词	首因效应，最先阅读	只出现一次，在长对话中容易被"遗忘"
用户消息注入	近因效应，定期刷新	每次注入都会消耗 Token
工具结果注入	最自然的注入点	只有在调用工具时才有效

Claude Code 实际上是如何使用它的

前提条件 —— 在系统提示词中声明标签：

Tool results and user messages may include <system-reminder> tags.
<system-reminder> tags contain useful information and reminders.
They are automatically added by the system, and bear no direct
relation to the specific tool results or user messages in which they appear.

这一步至关重要：它告诉模型这些标签是系统注入的，而不是用户的发言。

用法 1：行为提醒（定期刷新规则）

<system-reminder>
The task tools haven't been used recently. If you're working on tasks
that would benefit from tracking progress, consider using TaskCreate...
</system-reminder>

Claude Code 用这个来提醒模型使用 TodoWrite 进行规划——因为模型往往会"忘记"规划，直接开始写代码。

用法 2：模式切换（计划模式）

<system-reminder>
Plan mode is active. The user indicated that they do not want you to
execute yet -- you MUST NOT make any edits, run any non-readonly tools,
or otherwise make any changes to the system.
</system-reminder>

计划模式 (Plan mode) 并不是在系统提示词中实现的。它是注入到下一条用户消息中的一个标签。这让你可以在不修改系统提示词的情况下动态切换模式。非常巧妙。

用法 3：文件变更通知

<system-reminder>
Note: /path/to/file.ts was modified, either by the user or by a linter.
This change was intentional, so make sure to take it into account.
</system-reminder>

当外部进程（Linter、格式化工具、手动编辑）修改了文件时，系统通过提醒通知模型——防止它基于过时的文件内容做出决策。

用法 4：动态上下文（日期、项目规则）

<system-reminder>
Today's date is 2026-03-21.
Current branch: dev
claudeMd: [CLAUDE.md content injected here]
</system-reminder>

运行时上下文（日期、Git 状态、项目规则）是通过用户消息注入的，而不是硬编码在系统提示词中。

提醒的编写指南

用 XML 标签包裹 (<system-reminder>) —— 模型能区分系统注入和用户发言。
在系统提示词中预先声明标签 —— 否则模型可能会试图回复这个提醒。
不要在每条消息中都注入 —— 每次注入都要花 Token，只在需要时注入。
保持简短 —— 提醒不是第二个系统提示词，只需 1-2 条关键规则。
不要与系统提示词冲突 —— 提醒是补充和强化，不是覆盖。
用于动态切换 —— 计划模式、只读模式、功能开关 (Feature flags)。

何时使用系统提示词 vs 用户消息提醒

场景	系统提示词	用户消息提醒
角色定义	✅	❌
安全约束	✅ 首次声明	✅ 定期重复
工作流方法论	✅	❌
模式切换（计划模式）	❌	✅
文件变更通知	❌	✅
日期 / 环境信息	✅ 初始值	✅ 更新值
行为纠正	❌	✅
工具使用提醒	✅ 规则定义	✅ 执行提示

9. 提示词缓存 (Prompt Cache) —— 节省 90% 的重复 Token

Anthropic 的提示词缓存允许你缓存消息数组的静态前缀。当后续请求共享相同的前缀时，它们就会命中缓存——从而省钱并降低延迟。

对于 Agent 来说，这非常重要：在一次对话中，你每次调用 LLM 都在重复发送系统提示词 + 工具定义。

关键数据

指标	数值
缓存命中成本	正常价格的 10%（节省 90%）
缓存写入成本	正常价格的 125%（首次写入有 25% 溢价）
缓存存活时间	5 分钟（无请求则过期）
最小可缓存长度	1,024 Tokens（Claude 3.5+）
缓存粒度	前缀匹配 —— 从开头到标记的断点
最大断点数	4 个

这如何改变提示词设计

核心原则：静态内容在前，动态内容在后。

✅ Cache-friendly layout:
  System prompt (static)      ← Cache breakpoint 1
  Tool definitions (static)   ← Cache breakpoint 2
  CLAUDE.md / project rules   ← Cache breakpoint 3 (changes occasionally)
  Conversation history         ← Breakpoint 4 for rolling window

❌ Cache-destroying layout:
  System prompt
  DYNAMIC TIMESTAMP            ← Changes every request, everything after = cache miss
  Tool definitions
  Conversation history

没人警告过你的陷阱： 如果你在系统提示词中间放了一个动态的时间戳，那么它之后的所有内容都会缓存未命中。每一。次。请。求。都会这样。一个放错位置的时间戳，就会让你为成千上万的 Token 支付全价。

API 用法

const response = await anthropic.messages.create({
  model: "claude-sonnet-4-6",
  system: [
    {
      type: "text",
      text: "You are a startup advisor...",
      cache_control: { type: "ephemeral" }  // ← marks a cache breakpoint
    }
  ],
  messages: [...]
});

多断点策略

Breakpoint 1: System prompt           ← Almost never changes
Breakpoint 2: Tool definitions         ← Almost never changes
Breakpoint 3: Project rules / CLAUDE.md ← Changes occasionally
Breakpoint 4: First N history messages  ← Rolling window cache

即使对话历史发生变化，前 3 个断点依然能命中。一个 10 轮的对话大约能节省 40-60% 的输入 Token 成本。

设计建议

系统提示词中不要有高频动态值 —— 日期可以（每天变一次），精确的时间戳不行。
将动态上下文（Git 状态等）放在用户消息注入中 —— 不要放在系统提示词里，否则会破坏缓存。
保持工具定义稳定 —— 不要在运行时动态添加/移除工具。
对对话历史使用滚动窗口 —— 缓存前 N 条消息，只有最新的消息是缓存未命中。

10. 终极检查清单

写完系统提示词后，对照这份清单检查一下：

结构

身份声明是否在最顶部？
安全约束是否用 IMPORTANT 标记并在结尾重复？
是否用标题进行了清晰的模块划分？
示例是否用 <example> 标签包裹？

Token 预算

你控制的部分是否 < 6,000 Tokens？
是否没有重复工具定义中已有的信息？
领域知识是否按需加载，而不是预先灌输？
是否没有冗长的设定或角色背景故事？

规则质量

每条规则是否都可以用 True/False 测试？
硬性约束是否使用了绝对语气 (NEVER/MUST)？
软性建议是否使用了推荐语气 (recommended/prefer)？
关键规则是否解释了为什么，而不仅仅是做什么？
是否包含双向约束（做这个 + 别做那个）？

Agent 行为

是否给出了原则，而不是死板的按步操作流程？
是否处理了"工具调用被拒绝"的场景？
是否处理了"遇到障碍"的策略（不要暴力重试）？
是否有上下文管理策略（摘要阈值）？

不要做的清单

没有奉承或最高级形容词？
没有多余的"你是一个有用的 AI"声明？
没有写成提示词链 (Prompt Chain)？
没有过度工程（加了一堆没人要的功能）？

如果我今天重新开始

以下是我会严格执行的步骤：

在前 3 行写明身份 + 安全。 用两句话说明 Agent 是谁。用 NEVER/MUST 设定硬性约束。在结尾重复安全规则。
将核心工作流写成原则，而不是步骤。 最多 4-5 个要点。软规则用 "recommended" 和 "prefer"，硬规则用 "NEVER" 和 "MUST"。
为你自己写的部分预留 1,500-6,000 Tokens 的预算。 工具定义会额外增加 5,000-15,000 Tokens。如果你超过了 6K，你可能塞进了本该按需加载的知识。
结构化一切。 Markdown 标题、无序列表、用 XML 标签包裹示例。结构化的提示词永远胜过自然语言散文。
从第一天起就构建对话中途提醒机制。 在系统提示词中声明 <system-reminder>。为关键规则、模式切换和上下文更新注入提醒。
为缓存而设计。 静态内容在前，动态内容在后。绝不要把变化的值放在系统提示词主体中。

做完这一切最讽刺的是什么？最好的系统提示词其实都很短。Claude Code 的自定义指令（不包括工具定义）出奇地简洁。每一行都物尽其用。

我曾经以为提示词工程 (Prompt Engineering) 就是寻找巧妙的奇技淫巧。现在我认为它是一种克制——少说废话，精准表达，然后信任模型能搞定剩下的事。模型比你的提示词更聪明。你要设计的是环境，而不是行为。

参考资料

来源	核心洞察
Claude Code v2.0.14 System Prompt	完整的生产级 Agent 提示词结构参考
Reddit: Understanding Claude Code's 3 System Prompt Methods	Output Styles / --append / --system-prompt 深度解析，上下文腐化的真实数据
shareAI-lab/learn-claude-code	"模型即 Agent"哲学，脚手架工程 (Harness Engineering) 方法论
Anthropic Prompt Engineering Docs	官方提示词最佳实践
DeepAgents Framework	摘要中间件，技能渐进式披露

Agent 系统提示词编写完全指南：逆向工程 Claude 代码的实战经验

1. 设计哲学：信任模型

脚手架思维 (The Harness Mindset)

2. 提示词结构与段落顺序

推荐的布局结构（逆向工程自 Claude Code v2.0.14）

为什么这个顺序很重要

3. 逐个模块拆解

3.1 身份 (Identity) —— 这个 Agent 是谁？

3.2 安全与约束 (Security & Safety) —— 绝对的边界

3.3 语气与风格 (Tone & Style) —— 控制输出

3.4 核心工作流 (Core Workflow) —— 最重要的一环

3.5 工具使用策略 (Tool Usage Policy) —— 消除歧义

3.6 领域知识 (Domain Knowledge) —— 按需加载，而非提前灌输

3.7 环境信息 (Environment Info) —— 运行时上下文

3.8 提醒 (Reminders) —— 最后的强化

4. Token 预算与上下文管理

预算分配参考

上下文衰减曲线

5. 写作原则

5.1 给原则，不给步骤

5.2 对硬性约束使用绝对语气

5.3 用示例代替解释

5.4 双向约束

5.5 解释"为什么"，而不仅仅是"做什么"

5.6 结构胜于散文

6. 浪费 Token 的反面模式

伪装成 Agent 的提示词链

奉承工程 (Flattery Engineering)

知识大倾倒

重复工具描述

缺失失败处理机制

无视上下文窗口衰减

7. 注入点与优先级

Claude Code 的三种自定义方法

指令层级

动态注入机制

8. 对话中途注入 —— 秘密武器

为什么这是必要的

消息数组中的三个注入点

Claude Code 实际上是如何使用它的

提醒的编写指南

何时使用系统提示词 vs 用户消息提醒

9. 提示词缓存 (Prompt Cache) —— 节省 90% 的重复 Token

关键数据

这如何改变提示词设计

API 用法

多断点策略

设计建议

10. 终极检查清单

结构

Token 预算

规则质量

Agent 行为

不要做的清单

如果我今天重新开始

参考资料