前情提要
- 每一轮的上下文里，你亲手写的只占一小块；固定开销里最大的之一，是 Agent 自带的「员工手册」：系统提示词
- 第5节：系统提示词分成静态区（所有用户共享缓存）和动态区（每个会话不同）
- 第3节：工具说明也是提示词，比如 Bash 里就藏着一整套 git 提交流程
用了这么久 Claude Code，它的「员工手册」里到底写了什么？
这一节把 Claude Code 的系统提示词拆开读。读完你会发现：写 CLAUDE.md、写 Skill、写子代理，最好的老师就是这份系统提示词。 它是团队反复测试、用线上数据调过的，比网上任何「提示词技巧」都靠谱。
材料来自 CCB 源码 src/constants/prompts.ts。这是复原版本，CCB 改过一部分，下文会标出。
💡 系统提示词改得很频繁，下面引用的是 2026-10-11 查阅时的版本。看思路，别背原文。
一、静态区的六部分
静态区是所有用户共用的「员工手册」，一共六部分：
| 部分 | 讲什么 |
|---|---|
| 开头 | 你是谁：一个帮用户做软件工程任务的交互式 Agent；外加安全底线，比如不要编造网址 |
# System |
你所处的环境：输出会显示给用户；工具在权限系统下运行；<system-reminder> 是系统加的；工具结果里可能有提示注入；Hook 的反馈当作用户的话；对话会被自动压缩 |
# Doing tasks |
怎么干活 |
# Executing actions with care |
怎么对待有风险的操作 |
# Using your tools |
能用专用工具（Read、Edit、Glob、Grep）就别用 Bash 的 cat、sed、find、grep 代替 |
| 沟通风格 | 怎么跟人说话：简洁、少用格式、用户没要求就不用表情 |
动态区是会话相关的内容：环境信息（工作目录、平台、模型）、记忆、语言偏好、MCP 说明等。
六部分里，最值得细读的是 Doing tasks 和 Executing actions with care。
二、Doing tasks：针对老毛病的条目
这一部分是一串条目，几乎每一条都是针对 AI 编程的老毛病写的：
不要添加需求以外的功能、重构或「改进」。修一个 bug，不需要顺手把周围的代码也清理一遍。
不要为只用一次的操作创建工具函数或抽象……三行相似的代码，好过一个过早的抽象。
一般来说，没读过的代码，不要提出修改建议。
一个方法失败了，先诊断原因再换思路：读报错、检查假设、做有针对性的修复。不要盲目重复同样的操作，但也不要失败一次就放弃一个可行的方案。
把这几条和你见过的 AI 编程毛病对一下：
| 毛病 | 对应的条目 |
|---|---|
| 让它修个 bug，它把整个文件都「优化」了 | 不要添加需求以外的「改进」 |
| 写个小功能，冒出三层抽象 | 三行相似的代码好过一个过早的抽象 |
| 没看代码就开始改 | 没读过的代码不要提修改 |
| 报错了就换个写法重试，再报错再换 | 先诊断原因，别盲目重试 |
最后一条的写法值得注意：它同时堵住了两个方向的错误，既不要死磕，也不要轻易放弃。
Doing tasks 的每一条，都对着一个具体的老毛病。
三、配重：别矫枉过正
源码注释里还有一个有意思的发现。Doing tasks 里有几条被标成了「配重」（counterweight）：
| 注释里的名字 | 内容 |
|---|---|
| Thoroughness counterweight（彻底性配重） | 报告完成之前，先确认真的能用：跑测试、执行脚本、看输出。「最小复杂度」的意思是不镀金，不是不跑到终点 |
| Assertiveness counterweight（主见配重） | 发现用户的请求建立在误解上，或者看到旁边有个 bug，要说出来。你是协作者，不只是执行者 |
| False-claims mitigation（虚假完成缓解） | 如实报告结果：测试失败就说失败，没验证就说没验证；不要为了「全绿」去删测试、跳过检查 |
「配重」这个词很准确。前面说了「别过度设计」「别做需求以外的事」，模型就可能矫枉过正：变得敷衍、只会照做、不敢多说一句。
所以要在另一边加一块配重：
别过度设计 ⟷ 但也别偷工减料，要跑到终点
按需求做 ⟷ 但也要有主见，看到问题要说💡 CCB 的注释标明，这几条在原版里只对 Anthropic 内部员工（
USER_TYPE === 'ant'）生效，CCB 把它们打开给了所有人。从这个细节能看出，Anthropic 会先在内部试用新的提示词。
写一条约束，就想一想模型会不会往反方向走过头；会的话，加一块配重。
四、Executing actions with care：谨慎操作
这一部分是一整段话，核心是这两句：
仔细考虑每个操作的可逆性和影响范围……停下来确认一下的成本很低，而一个不想要的操作（丢失的工作、误发的消息、被删的分支）代价可能非常高。