从 Claude code 泄漏的源码,挖出优秀提示词工程的秘密

昨天 Claude Code 源码泄漏，可谓是程序员的狂欢节。 这里也和大家一起学习一下它的提示词工程。

Claude Code 的提示词，不是靠”文案技巧”，而是靠系统级设计——工具纪律、风险确认、优先级裁决、缓存边界、特性开关，全部写进了提示词工程里。

这篇文章基于泄漏源码中的函数、规则与注释，和大家一起来拆解 Claude Code 提示词工程的 8 个关键设计。

01 它不是一段长 Prompt，而是模块化策略编排

在很多产品里，系统提示词是一段固定文本。

但在 Claude Code 中，提示词明显是”代码化 + 组件化”的。

从 src/constants/prompts.ts 可以看到，核心提示词按职责拆分为多个 section 生成函数，例如：

• getSimpleSystemSection()：系统级行为约束 • getSimpleDoingTasksSection()：任务执行风格与工程纪律 • getUsingYourToolsSection()：工具调用规范 • getActionsSection()：高风险动作确认机制 • getSessionSpecificGuidanceSection()：会话态动态补充

这意味着它不是”写好一段话”，而是“构建可组合策略”。

工程价值很直接：可维护、可灰度、可局部迭代、可观察行为变化。

02 Prompt 与工具体系是”硬耦合”，不是”建议耦合”

Claude Code 的核心差异之一，是它把”工具使用纪律”写成系统规则，而不是交给模型自由发挥。

在 getUsingYourToolsSection() 里能看到明确约束：

• 不要在有专用工具时使用 Bash • 读文件用 Read 工具，不用 cat/head/tail/sed • 编辑文件用 Edit 工具，不用 sed/awk • 创建文件用 Write 工具，不用 heredoc/echo 重定向 • 多个独立调用应并行，不要串行浪费轮次

这类规则不是修辞，它直接影响执行路径。

本质上，Claude Code 在做“模型行为治理”：

• 可审计：用户看得懂你做了什么• 可复盘：错误链路可定位• 可控风险：避免 Shell 黑盒式操作

03 它把”真实性报告”写进系统，专治”没跑却说跑了”

AI coding 最常见问题之一：

“嘴上 all tests pass，实际上根本没跑或已经报错。”

Claude Code 对这类问题有显式约束。

在 getSimpleDoingTasksSection() 的条件分支里，存在非常严格的报告规则（例如不得把失败说成成功、未验证要明确声明等）。

这说明一个关键点：它不是靠”模型自觉”，而是把“诚实报告”工程化成系统约束。

对团队协作来说，这比”多写点礼貌话术”重要得多。因为交付质量首先取决于”状态是否真实”。

04 它对高风险动作设置”默认确认”，而非盲目自动化

许多 Agent 强调”自动执行”，但忽略了协作成本。

Claude Code 的处理更稳：对不可逆、影响共享环境的动作，默认先确认。

getActionsSection() 中明确列出典型风险操作：

• 删除类：删文件、删分支、rm -rf• 难回滚类：force push、git reset --hard• 外部可见类：发消息、改 PR、改共享基础设施

工程上，这是一条非常成熟的原则：可逆动作自动化，不可逆动作确认化。

它降低的不是”执行速度”，而是”事故概率”。

05 它有静态/动态边界，Prompt 直接服务缓存与性能

很多人理解 Prompt 只关注”让模型更懂”。

但 Claude Code 连缓存边界都写进了提示词工程。

在 prompts.ts 中定义了动态边界常量：

• SYSTEM_PROMPT_DYNAMIC_BOUNDARY

并通过注释明确：边界前可做跨会话缓存，边界后为用户/会话相关动态内容。同时还提示了相关缓存逻辑位置（如 API 侧 prompt block 构建代码）。

这件事非常”基础设施化”：Prompt 不再只是语义输入，也是性能系统的一部分。

06 最终生效 Prompt 有明确优先级链，行为可解释

多层指令并存时，最怕”互相覆盖却不可解释”。

Claude Code 用显式裁决链解决这个问题。

在 src/utils/systemPrompt.ts 的 buildEffectiveSystemPrompt() 中，可以归纳出优先级路径（简化表达）：

1. override 2. coordinator 3. agent（某些模式下 append 而非 replace） 4. custom 5. default 6. append

这意味着当行为变化时，你可以追溯”是哪一层生效了”。从工程角度看，这是可调试性的基础。

07 Feature Flags 直接驱动 Prompt 分叉，提示词进入”可运营时代”

在 prompts.ts 中可见大量 feature(...) 触发逻辑分支，例如实验性技能搜索、proactive/kairos 模式等。

这代表 Prompt 已经进入产品实验体系：

• 可灰度 • 可 AB • 可回滚 • 可按模式差异化策略

换句话说，它不是”静态提示词仓库”，而是“可运营的行为配置层”。

08 Claude Code 与普通聊天 Prompt 的本质差异

很多”Prompt 教程”关注：

• 角色设定 • 语气要求 • 输出格式

这些当然有价值，但在 Claude Code 这类 coding agent 场景里不够。

因为真正决定效果的，是以下四层是否打通：

1. 任务层：模型知道该做什么

2. 工具层：模型知道怎么做，并且按规则做

3. 风险层：模型知道哪些动作要刹车

4. 基础设施层：缓存、分段、特性开关支撑长期演进

Claude Code 的强点，正是在这四层协同。

结论：Prompt Engineering 的下一阶段

如果一句话总结：

Claude Code 的 Prompt Engineering，本质不是语言优化，而是执行系统设计。

它把提示词从”文案问题”升级为”工程问题”——有模块、有优先级、有安全策略、有性能边界、有实验机制。这也正是它和多数通用聊天 Prompt 的根本分水岭。

📚 信息来源

1. Claude Code 源码分析

https://github.com/phodal/claude-code-sourcemap

 免责声明：本文基于公开源码分析撰写，仅代表作者观点，不构成投资建议。