Claude源码泄露:普通人视角看“System Prompt”(上)
本文从普通人视角解析Claude Code的系统提示词机制: 系统提示词由10个模块按固定顺序组装,分为静态(1-5步)和动态(6-10步)两部分 静态部分(角色定义/输出风格/系统规则等)由Anthropic硬编码,用户无法直接修改但需了解其存在 动态部分(环境/项目上下文等)自动生成,用户可通过CLAUDE.md等文件间接影响 普通用户应在理解系统架构的基础上,通过预设提示词、指令文件和对话策
Claude源码泄露已经快一个月了,为什么现在才来发文?因为我在花时间来研究我们作为普通人或者小白应该掌握的内容和方法。那些架构代码我们普通人根本看不懂,也没有能力和机会去参与这样一个产品。但是,作为普通人,我觉得最关键的是,我们要学会怎么用好它。所以,这篇文章,以普通人视角带你来了解一下Claude Code的System Prompt,你可以将它理解为Claude Code 的"内部工作手册"—它直接决定了这个工具怎么理解你的指令、怎么拆解你的任务、怎么回应你的需求。
1. Claude Code的System Prompt
1.1 系统提示词的组装流程(来自 rust/crates/runtime/src/prompt.rs)
Claude Code 的系统提示词由 SystemPromptBuilder 按以下顺序拼装:
1. Intro Section → 角色定义("You are an interactive agent...")
2. Output Style → 输出风格(如 "Concise")
3. System Section → 系统规则(工具权限、安全提醒等)
4. Doing Tasks Section → 任务执行准则(不乱改代码、不加冗余抽象等)
5. Actions Section → 操作安全准则(可逆性评估、高风险操作需授权)
6. ---- 动态分界线 ---- → SYSTEM_PROMPT_DYNAMIC_BOUNDARY
7. Environment Section → 环境上下文(模型名、工作目录、日期、操作系统)
8. Project Context → 项目上下文(Git status、Git diff 快照)
9. Instruction Files → CLAUDE.md 等指令文件内容
10. Runtime Config → 配置信息(权限模式、MCP 服务器等)
1.2 系统提示词的静态 Vs 动态(5+5 分层 + 三类角色)
1.2.1 系统“静态提示词”
组装流程的第 6 步 SYSTEM_PROMPT_DYNAMIC_BOUNDARY 是分水岭——线之上(步 1-5)可缓存、跨会话不变;线之下(步 6-10)每次按环境重新注入。两段的性质、控制权、用户实操方式完全不同。我将前5步静态提示词整理成表格作为补充:
| 流程步 | 在 Prompt 里的角色 | 普通用户实操 |
|---|---|---|
| 1. Intro(角色定义) | Claude 的内置身份 | 任务开头只需补充场景角色(“请扮演代码审查者 / 数据分析师”),不要试图覆盖内置身份(覆盖不掉,只会互相打架) |
| 2. Output Style(输出风格) | 输出格式偏好 | 跨会话不变的(中文、简洁、带注释)写进 CLAUDE.md;单次任务的格式要求("给 diff-代码/文档差异对照/“给表格”/“只给结论”)放对话里 |
| 3. System Section(系统规则) | 工具权限、安全提醒 | 用户无法改写,但要知道它存在——Claude 的"默认不破坏""警惕外部注入"等行为源自这里,不要在 Prompt 里要求它跳过("别管安全检查赶紧写"这类指令会被硬规则抵消) |
| 4. Doing Tasks(任务准则) | 紧扣 范围 / 禁投机抽象 / 失败先诊断… | 配合而非对抗:修复bug 别顺口加"顺便优化一下"(违反禁抽象规则,会被拒或误解);失败时贴完整 报错日志 让它诊断(对齐"失败先诊断");明确划范围(“只改 src/auth/”) |
| 5. Actions Section(操作安全) | 可逆性评估、高风险需授权 | 预先声明授权边界:“本次允许你删除 /tmp/ 下任意文件,其他目录一律先问我”——比事后反复打断确认高效;破坏性操作(rm -rf、git reset --hard)默认会先问,别嫌它繁琐 |
但是,需要注意的是,1~5步是代码里硬编码的常量 ,保持不变(跨会话、跨用户几乎一样),用户无法直接修改。
1.2.2 系统“动态提示词”
后面7~10(动态分界线之下)由系统自动注入,用户通过 CLAUDE.md / cwd / git 状态 / 权限模式 间接塑造。后面文章会介绍类似CLAUDE.md等指令文件怎么间接影响大模型的理解和执行。
同上,我先提供动态提示词概览表进行初步理解。
| 流程序号 | 控制手段 |
|---|---|
| 7. Environment(环境) | cwd / OS / 日期 / 模型名自动注入——Prompt 里不必重复"我在使用 Windows / 今天是 X 月X日",也别谎报(信息会冲突) |
| 8. Project Context | Git status / diff 自动注入——动手前先 commit 让 diff 聚焦当前任务;大堆无关 WIP 会稀释 AI 对"你现在在干什么"的判断 |
| 9. Instruction Files | 由 cwd 向上收集的 CLAUDE.md 等——最关键的个人红线放 CLAUDE.local.md(Recency 最强,注意力最高) |
| 10. Runtime Config | 权限模式 / MCP server——会话启动时通过 CLI 参数或 /permission 切换,不要在对话里要求 AI “给自己提升权限”(它改不了自己的运行时配置) |
1.2.3 系统动静态提示词对比
| 维度 | 静态部分(步 1-5) | 动态部分(步 6-10) |
|---|---|---|
| 来源 | Anthropic 硬编码在 prompt.rs |
按 cwd / git / runtime 自动注入 |
| 跨会话变化 | ❌ 不变(Claude Code 升级版本才改) | ✅ 每次会话都变 |
| 可缓存性 | ✅ 可缓存(Prompt Cache 命中率高,降成本) | ❌ 多变,缓存收益低 |
| 用户能否直接编辑 | ❌ 不能 | 部分能(通过 CLAUDE.md / 命令 / CLI 参数间接写入) |
| 用户操作策略 | 配合(不对抗硬规则) | 沉淀 / 塑造(通过 CLAUDE.md 等入口) |
| Prompt 内位置 | 开头(Primacy 效应) | 末尾(Recency 效应,更强) |
在使用大模型时,你会发现很多大模型可以做预设Preset,还有记忆功能memory。实际这是将“动态”或者“临时”信息持久化的一种操作。Preset 是"整段可切换的模板",Memory 是"持续累积的文件/会话",二者都并入 System Prompt静态部分,进行持久化沉淀。在system prompt组装流程上,可以看到Claude Code 把用户可写的 CLAUDE.md 放在动态部分的步 9——恰好位于 Prompt 末尾(Recency 注意力更强)。所以用户通过步 9 写入的规则,实际注意力 ≥ 1-5 的硬编码规则。这也是"用户无法改 1-5,但事实上能通过步 9 重塑大部分行为"的机制来源。
1.3 Claude Code 应用层的三类角色(补充理解)
同一个"System Prompt"在不同角色视角下含义不同。理清角色归属才能掌握"我能改什么,不能改什么"
| 角色 | 对 System Prompt 的控制能力 | 典型场景 |
|---|---|---|
| 原生 Claude API 调用者(开发者直调 API) | system 字段 + messages 数组完全自己写,无静态 / 动态分界 |
用 anthropic SDK 写聊天机器人 / 应用 |
| Claude Code 的开发者(Anthropic 团队) | 在 prompt.rs 硬编码 1-5,替所有 Claude Code 用户预设"通用 Agent 骨架" |
Anthropic 内部工程师 |
| Claude Code 的普通用户(你我) | ❌ 不能直接改 1-5;✅ 通过 CLAUDE.md / memory / /output-style / CLI 参数间接影响步 2、6-10;✅ User Message用户提示词(不在 10 步里,独立对话通道) |
在CLI/桌面客户端/网页版/手机app等用 claude 的所有人 |
所以,如果你通过API使用大模型,那么你可以原生构造“system prompt”,无动静态的区别。但是,作为 Claude Code 的普通用户或者其他任何大模型的普通用户,我们不需要"从零设计 System Prompt "——那是 Anthropic /其他模型公司的角色。我们是"在既定骨架之上做个性化扩展和对话"的人。比如,怎么设定指令文件CLAUDE.md,预设Preset提示词,构建Memory。识别这个边界,我们才可以更好在我们能够触及的层面去更好地理解和使用大模型。
系统提示词样例参考:
- 样例A:原生 Claude API 调用者的 System Prompt(开发者从零构造)
# 用 anthropic SDK 直调 API 时,system 字段完全可控、没有 Anthropic 预设的 1-5
client.messages.create(
model="claude-opus-4-7",
system="""You are a helpful assistant specialized in SQL query optimization.
Role:
- Analyze SQL queries for performance issues
- Suggest index strategies and query rewrites
- Explain reasoning behind each suggestion
Constraints:
- Never execute queries, only analyze
- Flag queries that might cause table locks
- Output format: issue -> cause -> fix -> alternative
Safety:
- Refuse to help with SQL injection payloads
- Warn if a query touches PII columns""",
messages=[{"role": "user", "content": "帮我优化这个 SQL: ..."}]
)
- 样例B-普通用户提示词:5件套—角色、技能、风格、标准、约束
#线上咖啡开店指南调研
角色:请扮演一位行业调研分析师,专注于新零售和咖啡赛道。
技能:你擅长市场趋势分析、竞品对比、线上渠道运营和数据可视化。
风格:输出内容要求结构清晰、逻辑严密,适合初创团队决策参考,语言简明、要点突出。
标准:调研内容需涵盖线上咖啡(咖啡豆/冲泡粉等)开店的主流平台选择、运营模式、成本结构、用户获取与留存策略,并结合2026年最新行业数据。
约束:只引用2024-2026年中国市场公开数据,避免主观臆断;如遇数据缺口需明确标注“暂无权威数据”。输出以分点总结+表格/图示辅助。
【示例提问】
请为我调研线上咖啡(咖啡豆成品/冲泡粉等)开店的主流平台、运营模式、成本结构和用户增长策略,要求结合2026年中国市场最新数据,输出结构化要点和可视化表格,适合初创团队决策参考
- 样例C-普通用户通过
CLAUDE.md间接写入 System Prompt 第9步
# CLAUDE.md(项目根目录,自动加载进 System Prompt 步 9)
## 项目技术栈
- Python 3.12 + SQLite + FastAPI
- 所有函数必须有类型注解
## 行为约定
- 回答使用中文
- 代码修改前先展示 diff 预览
- 数据库操作必须用参数化查询
## 安全红线
- 禁止在代码中硬编码任何密钥或 token
- 外部 API 响应必须做 schema 验证后再使用
2. 用户提示词的逻辑与实操(ANCHOR-USER-MESSAGE)
与 System Prompt(10 步组装)完全并行的另一条通道是 User Message(你在终端里输入的话),在 API 的 messages 数组里以 role: "user" 存在。它不在 10 步里,是独立的对话通道。
前面花了很长篇幅讲系统提示词,目的是让作为普通用户的我们了解整个系统提示词的架构,我们能做什么,不能做什么。现在我们来看下普通用户应该怎么强化自己能做的部分。
2.1 User Message 的 维度特征&实操建议
- 用户提示词的5个维度:
| 维度 | User Message 的特征 |
|---|---|
| 持久性 | 仅本轮 / 本会话(下次会话若不沉淀则丢失) |
| 写入方式 | 用户实时键入 |
| 在请求中的位置 | messages 数组末尾,System Prompt 之后 |
| 注意力强度 | 最强(Recency 极限,最靠近 AI的注意力越强) |
| 可重复性 | 每轮一条,累积为对话历史 |
- 用户提示词的实操建议
| 关注点 | 建议 |
|---|---|
| 明确目标 | 一次问一件事;目标模糊(“优化一下”)→ 换具体指标(“时间复杂度降到 O(n log n)”) |
| 给足上下文 | 贴完整错误 / 日志 / 相关文件片段;别指望 AI 读心,它只看到你发的内容 |
| 不重复系统已注入的信息 | cwd / OS / 日期 / git status 已自动注入——别再说"我在 Windows" |
| 识别临时 vs 永久 | 说过一次的偏好若下次还想要,立刻沉淀到 CLAUDE.md / memory;否则本轮说了就是一次性的 |
| 多轮配合 | 复杂任务拆多轮:先让 AI 列计划 → 确认 → 分步执行;别一条消息塞十个需求 |
| 纠偏用增量 | AI 跑偏时用增量纠偏(“第 3 步错了,应该用 X 而不是 Y”);别每次推翻重说,浪费上下文窗口 |
- 用户提示词示例模板(好 vs 差 对比)
| 场景 | ❌ 差的 User Message | ✅ 好的 User Message |
|---|---|---|
| Bug 修复 | “这个代码有 bug,帮我修一下” | “src/auth/login.py:42 的 verify_token 在 token 过期时抛 KeyError 而不是 TokenExpired,希望抛正确的自定义异常。完整 stack trace:...” |
| 功能开发 | “加一个导出功能” | “在 src/routes/reports.py 新增 GET /reports/{id}/export,支持 csv/xlsx 两格式,权限 report:read,>100MB 走异步导出;参考现有 _get_report 的实现风格” |
| 重构 | “优化一下代码结构” | “src/models/user.py 当前有 3 个循环依赖(见下图),请抽出 UserRepository 接口打破 user.py ↔ session.py 的循环。只改这两个文件,不要动 tests” |
| 解释代码 | “这段代码什么意思” | “请解释 rust/crates/runtime/src/prompt.rs:120-180 的 SystemPromptBuilder::build 方法——我关心它怎么决定哪些 section 进分界线之上、哪些之下” |
黄金判据:如果这条信息跨会话还会用到,它不该出现在 User Message 里——应该沉淀到 CLAUDE.md / memory / Preset。
User Message vs System Prompt 的根本区别:
- System Prompt = “我是谁 / 我该怎么表现”(身份与规则层)
- User Message = “我现在要做什么”(任务与请求层)
2.2 系统提示词 / 用户提示词 / 记忆 / 预设 —— 区别与联系
- 区别:4个横向维度
| 要素 | 持久性 | 写入方式 | 在 Prompt 中的位置 | 控制权归属 |
|---|---|---|---|---|
| System Prompt 硬编码段(步 1-5) | 跨会话永久 | Anthropic 源码写死 | Prompt 开头 | 开发者 |
Preset / 预设(如 /output-style、Custom GPTs) |
跨会话、可切换 | 用户从内置选项选 | 并入 System Prompt 某段(对应步 2) | 用户(选择层) |
Memory / 记忆(如 .claude/memory/*.md) |
跨会话持久 | AI 自动写 + 用户手写 / 删 | System Prompt 末尾段(步 9) | 用户 + AI 协作 |
| CLAUDE.md / 指令文件 | 跨会话持久 | 用户手写 Markdown | System Prompt 步 9 | 用户 |
| User Message / 用户提示词 | 仅本轮 | 用户实时键入 | messages 数组末尾 |
用户 |
| 对话历史 | 本会话(压缩后可能丢失) | 系统自动累积 | messages 数组 |
系统管理 |
- 联系(三个规律):
① 本质都是同一段 Prompt 的不同"写入通道"
不管叫 System / User / Memory / Preset,模型拿到的最终都是一整段拼接好的文本。差别只在"它们分别处于提示词的哪个部分(前面、中间还是后面)、是由谁写进去的(官方、用户还是AI自己)、以及它们能保存多久(一次对话、长期有效还是永久)"。Preset 和 Memory 不是独立的东西,而是 System Prompt 的可配置入口。
② 时间维度上是一条连续光谱(从短暂到持久):
对话历史(压缩即失) < User Message(本轮)
< Memory / CLAUDE.md(跨会话,用户可删改)
< Preset(跨会话,用户可切换)
< 硬编码 System Prompt(除非 Claude Code 升级版本否则不变)
③ "临时 → 持久"是单向沉淀:
本轮 User Message 里的偏好(临时)
↓ 识别出"值得永久化"
用户手写到 CLAUDE.md / AI 自动写到 memory 文件(持久化落盘)
↓ 下次会话从步 9 自动加载
并入 System Prompt,等价于永久生效
反向不成立——硬编码 System Prompt 不会退回成 User Message;Memory 不会"变回"一次性对话。持久化只能单向前进。
- 用户侧核心心法:
识别每条信息的"生命周期",放到匹配持久性的通道里——仅本轮对话使用放 User Message;跨会话需要用的放 CLAUDE.md / memory;多用户共享的放 Preset;全工具层面的规则是 Anthropic 的事。放错通道 = 要么丢失(该永久的却写到 User Message,每轮对话都要重复一遍)要么冗余(一次性的写到 CLAUDE.md 污染静态半段)。
- 三个约束
- 别重复 —— 系统已注入的(cwd、OS、git),别在 Prompt 里复述
- 别撒谎 —— 环境类信息会自动冲突,谎报反而让 AI 困惑
- 别对抗 —— 硬编码规则(步 1、3、4、5)不可改,配合才高效
本来打算一篇讲完System Prompt机制的,但是,我发现还有指令文件,注意力机制等内容。所以,临时决定拆成上下两篇。
今天的内容看起来很长,简单来讲就是,我们要理解模型公司Anthropic整个提示词组装流程–知己知彼,百战不殆。那么,作为API用户或者免费/订阅用户,我们在与AI/大模型交互过程中,我们通过拆解它的系统提示词设定机制,我们可以设计什么样的工作流,优化哪些节点以获得更好的结果(产出)。
Hey🌺我是一只肥罗,坚持做一些有意思的事情
🍻码字不易,路过的朋友麻烦点赞关注~
更多推荐



所有评论(0)