Claude源码泄露:普通人视角看“System Prompt”——指令性文件(下)

上一篇文章Claude源码泄露：普通人视角看“System Prompt”(上）讲到了，作为普通用户，我们无法变更1~5层级的静态系统提示词部分，因为这是模型公司的硬编码。

但是，如果我们需要进行持久性记忆存储，跨会话记忆信息沉淀，我们可以从7-10的动态提示词部分入手，其中指令性文件CLUADE.md，.claude/CLAUDE.md是我们可以利用的机制之一，还有memory机制，以及Preset机制。这些都是我们可以利用起来的，本质上就是“临时会话”到“持久化记忆”的沉淀，也是“动态可变”到“静态稳定”的迁移。

今天，这篇文章主要探讨“动态提示词”第9步，“指令性文件 ”，了解它的加载顺序，cwd锚点机制，指令文件位置和模型注意力的关系，普通用户如何在不同注意力层级的文件写入适配相应执行强度的提示词，通过提升沟通的效率，降低无效、高成本的中间（沟通/token)损耗，获得更高性价比的沟通、执行结果（投入产出比）。

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.1 什么是指令性文件

根据Anthropic官方文档https://code.claude.com/docs,Claude Code，指令性文件Instruction Files，主要是 CLAUDE.md 文件——这些 Markdown 文件为你的项目、团队或组织向 Claude 提供持久性指令。它们会在每次会话开始时加载。主要包含：./CLAUDE.md，claude/CLAUDE.md，.rules/.md，skills//SKILL.md,commands/*.md，agents/.md,CLAUDE.local.md等文件。为此，我做了一个汇总表：

Instruction Files in Claude Code：

File文件	Scope作用域	Purpose用途
CLAUDE.md	Project & Global（项目&全局）	Main instructions loaded every session; includes memory rules每次会话都会加载的主要规则；包含内存规则
rules/.md	Project & Global*	Topic-scoped instructions, optionally path-gated 主题作用域指令，可选路径门控
skills//SKILL.md*	Project & Global（项目&全局）	Reusable prompts invoked with /name or auto-invoked 通过 /name 调用或自动调用的可复用提示
commands/*.md	Project & Global （项目&全局）	Single-file prompts using the same mechanism as skills 单行提示采用与技能相同的机制
agents/.md	Project & Global（项目&全局）	Subagent definitions with their own prompt and tools 具有独立提示词和工具的子代理定义
CLAUDE.local.md*	Project only（仅项目）	Your private preferences for the project (not committed)*您对该项目的个人偏好（不提交Git）

完整路径-官方权威清单（2026-04 当前）：

路径	官方规范	作用域	纳入 Git
/Library/Application Support/ClaudeCode/CLAUDE.md 等	✅ Managed policy	组织级，IT 部署	—
~/.claude/CLAUDE.md	✅ User	个人全局（跨项目）	否
./CLAUDE.md	✅ Project	团队共享	是
./.claude/CLAUDE.md	✅ Project（等价）	团队共享	是
./CLAUDE.local.md	✅ Local	个人项目级	否（.gitignore）
./.claude/rules/*.md	✅ 子规则	可按路径作用域	通常是
./.claude/instructions.md	❌ 非当前规范	（可能为旧版遗留）	—

具体的加载顺序与注意力强度见 1.3.5 和 2.1。

1.2 指令性文件的内容规则以及示例

这些文件都是纯 Markdown，里面写的是给 Claude 的自然语言指令/规则，会被注入到 System Prompt 中直接影响 AI 的行为。

1.2.1 四类项目级指令文件的分工

文件	写什么	谁能看到	是否进 Git	同目录内加载顺序
CLAUDE.md	项目级规则：技术栈约定、代码风格、测试要求、架构约束	团队所有人 + Claude	是（团队共享）	第1个
.claude/CLAUDE.md	与 CLAUDE.md 等价的合法替代位置；把 Claude 相关文件集中到 .claude/ 目录时使用	团队所有人 + Claude	是（团队共享）	与 CLAUDE.md 等价
CLAUDE.local.md	最关键的个人指令：本地路径、个人偏好、当前任务红线（同目录内最后加载，Recency Effect 最强）	只有你 + Claude	否（默认 .gitignore）	第2个（最后）
~/.claude/CLAUDE.md	跨项目的永久个人偏好（如“回答用中文”、“必须加注释”）	只有你 + Claude	否	最靠前（全局层）

策略建议： 同目录内 CLAUDE.local.md 排在 CLAUDE.md 之后加载（注意力最强），比如绝不能被忽略的个人偏好（如“回答用中文”、“必须加注释”）这种规则应该写入CLAUDE.local.md。跨项目的永久个人偏好应写入 ~/.claude/CLAUDE.md。

CLAUDE.md vs .claude/CLAUDE.md，官方文档 https://code.claude.com/docs/en/memory 原文：Project instructions: ./CLAUDE.md or ./.claude/CLAUDE.md —— A project CLAUDE.md can be stored in either ./CLAUDE.md or ./.claude/CLAUDE.md. 两者等价，任选其一（或同时存在）。.claude/CLAUDE.md 是合法且推荐的位置之一，常用于把 Claude 相关文件集中到 .claude/ 目录。

操作指南：

在项目根目录创建CLAUDE.md，写入项目约定（技术栈、代码风格、测试要求等）
在CLAUDE.local.md写入个人偏好（不进 Git）
嵌套子目录可以有自己的CLAUDE.md，实现分模块指令CLAUDE.md
指令内容要精炼，单文件上限 4,000 字符、总预算 12,000 字符，超出会[truncated]

1.2.2 指令性文件内容示例

示例1——CLAUDE.md

# 项目约定- 技术栈：Python 3.12 + SQLite + Next.js 前端- 所有 Python 代码必须有类型注解- 数据库操作必须使用参数化查询，禁止字符串拼接 SQL- 测试用 pytest，每个新函数必须有对应测试- 提交信息格式：feat/fix/docs: 简短描述# 代码风格- 缩进 4 空格- 函数不超过 30 行- 变量名用 snake_case

示例2——.claude/CLAUDE.md（子模块/目录级补充规则，加载顺序第3，注意力中等）：

# API 模块约定- 本目录为 API 模块，所有接口函数必须返回标准 JSON 格式- 错误处理统一使用自定义异常类，禁止裸 except- 数据库查询必须走 ORM 层（SQLAlchemy / Prisma），不直接写原生 SQL- 新增 API 端点必须同步更新 OpenAPI 文档# 目录专属约定- 文件命名：`_router.py`（如 `user_router.py`）- 每个 router 文件只处理一个资源的 CRUD

示例3——CLAUDE.local.md（同目录内最后加载，注意力最强；最关键的个人红线放这里）：

# 最高优先级个人指令## 必须遵守的个人偏好- **所有回答必须使用中文**- **生成代码时必须加上注释解释每一步逻辑**- 修改文件前必须先展示 diff 预览，等我确认后再执行## 当前任务关键约束- 当前正在重构用户认证模块，所有改动必须限定在 `src/auth/` 目录内- 不要触碰 `src/database/migrations/` 下的任何文件- 每次代码修改后自动运行 `pytest tests/auth/` 验证## 安全红线- 绝对不能在代码中硬编码 API Key、密码、token- 所有用户输入必须做参数化处理，禁止字符串拼接进 SQL/Shell 命令- 生成的代码不能包含 `eval()`、`exec()` 或 `os.system()`

本质：这些文件就是你写给 Claude 的“工作手册”，Claude 每次对话都会先读取它们。

1.3 指令文件是怎么被发现的

Claude Code 在会话启动时，会从 cwd（Current Working Directory，当前工作目录）向上收集路径链，然后从根向下按顺序加载所有命中的指令文件。核心要点：向上收集路径链、从根向下读取、追加拼接（不是覆盖）。

1.3.1 cwd 工作机制——如何收集工作目录路径

第一步，拆路径

：把 cwd 的绝对路径从根（第一层）到 cwd（锚点位置）拆成若干层目录

第二步，逐层探文件

：对路径链上每一层（不是只有 cwd 那一层！），尝试读这三种候选：CLAUDE.md、.claude/CLAUDE.md、CLAUDE.local.md。存在就命中，不存在就跳过。

第三步，从根向下拼接

：按 根 → … → cwd 的顺序把命中的内容依次追加进 System Prompt（越靠近 cwd 越靠后，Recency 更强）。即 收集方向“向上”，读取顺序“从根向下”——先从 cwd 向上把祖先都找出来，再反过来从根向下按顺序读。

1.3.2 加载顺序代码块（3 层 × 3 位置 = 9 候选）

假设 cwd = /root/apps/api（锚点在第3层）每一层内先读 CLAUDE.md / .claude/CLAUDE.md，后读 CLAUDE.local.md# 第1层 /root/   ——   作用域 = 整个仓库[1] /root/CLAUDE.md                 ← 团队项目规则（入 Git）[2] /root/.claude/CLAUDE.md         ← 与 [1] 等价的合法替代位置（入 Git；同级择一或并存）[3] /root/CLAUDE.local.md           ← 个人级（不入 Git；同目录内最后加载）# 第2层 /root/apps/   ——   作用域 = apps/ 子树[4] /root/apps/CLAUDE.md            ← 入 Git（apps/ 子树团队规则）[5] /root/apps/.claude/CLAUDE.md    ← 入 Git（与 [4] 同级等价；同级择一或并存）[6] /root/apps/CLAUDE.local.md      ← 不入 Git（apps/ 子树个人覆盖；同目录内最后加载）# 第3层 /root/apps/api/   ——   作用域 = api/ 子树（当前目录）[7] /root/apps/api/CLAUDE.md         ← 入 Git（api/ 子树团队规则）[8] /root/apps/api/.claude/CLAUDE.md ← 入 Git（与 [7] 同级等价；同级择一或并存）[9] /root/apps/api/CLAUDE.local.md   ← 不入 Git；最后加载，Recency Effect 最强（注：早期版本示例中的 `.claude/instructions.md` 非当前规范，已替换）

提示：这不是覆盖关系，而是全部拼接进 System Prompt。所有找到的指令文件内容都会被包含，按发现顺序排列。越靠近当前目录的文件排在越后面，也就是最后读取到的文件（离 AI 的“注意力”越近）。

1.3.3 三层作用域关系

第一层

作用域是全局（整个仓库），第二、三层目录在物理路径上是第一层的子级，所以它们的关系可以看成 作用域 3 ⊂ 作用域 2 ⊂ 作用域 1，文件之间没有引用/嵌入关系，是独立的三个文件，只是按作用域叠加拼接。

指令文件的加载方向是从 cwd 锚点向上（子孙→祖先→根）收集路径链：假设 cwd 锚点在第三层，它会向上加载第二、第一层；假设 cwd 在第二层 /root/apps（不进 api），则加载第二、第一层，第三层的 CLAUDE.md 根本不会被读取，自然也不会作用到第二层的工作上；如果 cwd 在第一层 /root，只加载第一层。

三层的关系更像带方向的漏斗：指令从大作用域往小作用域逐层追加；只有当 cwd 深入到哪一层，那一层（及更浅层）才激活。

1.3.4 路径层级与同级文件的两层区别

维度	区别
CLAUDE.md vs CLAUDE.local.md（同级）	前者入 Git、团队共享；后者默认进 .gitignore、仅本机可见。同目录内 local 后加载，Recency 更强，适合“本地红线 / 个人偏好”。
CLAUDE.md vs .claude/CLAUDE.md（同级）	官方定义为等价的两个合法位置，二选一即可（并存也会被全部加载）。选 .claude/CLAUDE.md 通常是为了把 .claude/ 作为所有 Claude 相关配置（含 rules/、commands/、agents/）的集中目录。
不同层级（如 /root/CLAUDE.md vs /root/apps/CLAUDE.md）	作用域递减——根级对整仓生效；子目录级只在 cwd 位于该子目录（或其更深子树）时才被命中（生效）。多层同时命中时追加拼接而非覆盖，越深的越靠后（注意力更强）。

1.3.5 cwd工作机制示例

示例 1：本人的工作区D:\claude（研究 claude 相关的工作原理、规则等）

1. cwd =D:\claude，拆出的路径链：

D:\               ← 盘符根D:\claude\        ← cwd

2. 逐层探测（本工作区实际就两层）：

层	探测路径	结果
D:\	D:\CLAUDE.md D:\.claude\CLAUDE.md D:\CLAUDE.local.md	❌ 都不存在
D:\claude\	D:\claude\CLAUDE.md	✅ 命中（就是那份工作手册）
D:\claude\	D:\claude\.claude\CLAUDE.md	❌ 未创建
D:\claude\	D:\claude\CLAUDE.local.md	❌ 未创建

最终被拼进 System Prompt 的指令文件：仅D:\claude\CLAUDE.md一份（加上全局的~/.claude/CLAUDE.md和 Managed policy——那两个不走目录树，是额外加载的）。所以本工作区实际只有一层命中，尽管机制本身允许多层。

示例 2：假设含三层指令文件的项目：/root、/apps、/api项目文件布局（9 个候选位置全部存在）：

/root/CLAUDE.md                       [1]/root/.claude/CLAUDE.md               [2]/root/CLAUDE.local.md                 [3]/root/apps/CLAUDE.md                  [4]/root/apps/.claude/CLAUDE.md          [5]/root/apps/CLAUDE.local.md            [6]/root/apps/api/CLAUDE.md              [7]/root/apps/api/.claude/CLAUDE.md      [8]/root/apps/api/CLAUDE.local.md        [9]

cwd 所在层不同，命中集合就不同：

启动时 cwd	路径链（向上收集）	命中文件（从根向下读取）	不命中
/root	/root	[1][2][3]	[4]~[9]（apps/、api/ 未踏入）
/root/apps	/root <- /root/apps	[1][2][3] + [4][5][6]	[7][8][9]（api/ 未踏入）
/root/apps/api	/root <- /root/apps <- /root/apps/api	[1][2][3] + [4][5][6] + [7][8][9]	无（全部命中）
/root/apps/web（假设存在的兄弟目录，且其中也有 CLAUDE.md）	/root <- /root/apps <- /root/apps/web	[1][2][3] + [4][5][6] + web 自己的那份	api/ 的 [7][8][9] 完全不命中（兄弟目录互不可见）

注释：/root/apps/web 与 /root/apps/api/ 是同级兄弟（都在第 3 层），只是换了个自定义项目名——Claude Code 的发现机制只认文件名（CLAUDE.md / .claude/CLAUDE.md / CLAUDE.local.md），不认目录名；api/、web/、backend/、mobile/ 等都是项目自定义命名，”同层多项目并存”是非常常见的案例，同级兄弟互不可见、不会被 cwd 锚中。

总结：cwd 就像一根“垂下的锚”——锚在哪层，从该层往上到文件系统根的这条直线通道上所有命中的指令文件都会被加载（向上收集路径链，向下读取指令）；通道外（兄弟目录、未进入的子目录）的指令文件一概不读。这就是为什么“漏斗方向”是向上收集：指令作用域越大越靠根，锚得越深，拼接进来的指令层数越多，末尾（Recency 最强/注意力最强）的永远是离 cwd 最近那一层。

1.3.6 入 Git 规则（通用常量，不随目录深度变化）

CLAUDE.md→ 入 Git（无论在仓库根还是子目录，均视为团队共享规则）
.claude/CLAUDE.md→ 入 Git（与同级 CLAUDE.md等价，性质相同）
CLAUDE.local.md→ 不入 Git（默认写进 .gitignore，仅本机可见）

结论：入 Git 与否由文件名决定，而非目录深度——CLAUDE.local.md 都不入 Git，均属于个人层级的文件。根级、apps/ 子树级、api/ 子树级…… 每一层都适用同一规则。作用域不同（生效范围），Git 属性相同（协作可见性）。

二. 指令文件位置与模型注意力的关系 (Recency Bias)

2.1 指令性文件位置和注意力机制

做个澄清：“注意力强”≠”记忆强”。所有指令文件的内容都被完整加载进模型上下文，没有任何内容被”忘掉”；位置只影响每段内容对模型决策的权重——末尾的指令更容易被遵循，不是因为模型记得更牢，而是因为模型生成时给了它更高的优先级

LLM（如 Claude）在处理长文本时，对序列开头和末尾的内容注意力更强，这种现象被称为“中间遗忘”（Lost in the Middle）。因此，指令文件在 Prompt 中的位置决定了其被关注的优先级。

指令位置	在Prompt 中的位置	模型注意力强度	适合写什么
~/.claude/CLAUDE.md 或项目根 CLAUDE.md	最前面	中等（Primacy Effect）	通用的、全局的项目规则 / 跨项目个人偏好
中间层目录的 CLAUDE.md	中间	最弱（Lost in the Middle）	中间层约定（可能被忽略）
当前目录的 CLAUDE.local.md	最后面	最强（Recency Effect）	当前任务最关键的、必须遵守的个人红线

实用建议：如果你有一条指令绝对不能被忽略，把它写在当前工作目录CLAUDE.local.md里，而不是根目录的CLAUDE.md里。

Q：我希望模型更多注意个人偏好，应该放在哪个文件？

A：同目录内 CLAUDE.local.md 加载顺序晚于 CLAUDE.md，位于 System Prompt 末尾（Recency Effect 最强），所以绝不能被忽略的个人偏好应放在 CLAUDE.local.md。跨项目的永久偏好放在 ~/.claude/CLAUDE.md。（早期版本曾建议写入 .claude/instructions.md，该路径非当前规范，已作废。）

如果还不理解，可以返回看“1.3.2 加载顺序代码块”，加载顺序和锚点顺序是相反的，而离锚点越近注意力越强，所以最后加载的注意力最强。比如CLAUDE.local.md就比CLAUDE.md强。注意力强就确定了它的指令强度。

2.2指令文件的存放目录和使用场景示例

为了满足不同IDE开发需求，我拓展了包括Claude，GitHub Copilot，VS Code的指令文件存放，以及相关的配置文件共同构成了项目根下的“配置生态”。了解常见存放目录有助于理解 Claude 的文件如何与这些工具共存。

2.2.1 常见存放目录对比（典型项目根布局）

├── .github/│   ├── workflows/                  ← CI/CD 流水线│   │   ├── test.yml                ← 推送时自动运行测试│   │   └── release.yml             ← 打 tag 时自动构建发布│   ├── copilot-instructions.md     ← ★ SCP 部署给 Copilot（Copilot 规范）│   └── prompts/│       └── scp.prompt.md│├── CLAUDE.md                       ← ★ Claude Code 项目级指令（项目根，纳入 Git，会话自动加载）├── CLAUDE.local.md                 ← ★ 项目级本地指令（不纳入 Git，个人偏好/环境数据）│├── .claude/                        ← Claude Code 项目配置目录│   ├── CLAUDE.md                   ← ★与 ./CLAUDE.md 等价的项目级指令（二选一或并存；集中管理时推荐此位置）│   ├── settings.json               ← 项目共享设置（纳入 Git）│   ├── settings.local.json         ← 本地覆盖设置（不纳入 Git）│   ├── commands/                   ← 自定义 slash 命令│   ├── agents/                     ← 自定义子代理│   ├── hooks/                      ← 钩子脚本│   └── rules/                      ← 分主题规则（*.md 递归加载，可加 paths 作路径作用域）│       └── scp.md                  ← ★ SCP(个人写的协议/规则) 部署给 Claude Code├── .vscode/│   ├── settings.json│   ├── tasks.json│   └── extensions.json             ← 推荐扩展列表（团队统一环境）

对照理解：

Claude Code 的 .claude/对标 VS Code 的 .vscode/——都是项目级的工具专属配置目录，集中存放该工具的设置、扩展点、命令等
Claude Code 的 CLAUDE.md + CLAUDE.local.md对标 Copilot 的 .github/copilot-instructions.md——都是“给 AI 的指令性文件”
settings.local.json / CLAUDE.local.md的 .local模式在 Claude Code 中用来区分“团队共享 vs 个人私有”；VS Code 没有直接的 .local约定，但通过 .gitignore+ 用户级 settings.json达到类似效果

2.2.2 按场景选组合（不必三种同时存在）

使用场景	推荐组合	说明
单人学习 / 临时研究（本工作区 D:\claude 即属此类）	仅 CLAUDE.md 或仅 CLAUDE.local.md	无需团队共享；若完全私人，用 CLAUDE.local.md 避免污染他处
单人多机项目，跨机器同步偏好	~/.claude/CLAUDE.md + 可选项目级 CLAUDE.local.md	全局偏好走 User 级，项目级红线走 local
小团队共享项目，无个人化需求	仅 CLAUDE.md（或 .claude/CLAUDE.md，两者等价择一）	所有约定入 Git 团队共享
团队项目 + 个人本地红线	CLAUDE.md + CLAUDE.local.md	团队规则入库，个人偏好走 local（加载更后）
.claude/ 目录统一管理 Claude 配置	.claude/CLAUDE.md + CLAUDE.local.md	把 CLAUDE.md、rules/、commands/、agents/ 集中到 .claude/ 下
大仓 + 子模块各自有特殊规则	根 CLAUDE.md + 子目录 CLAUDE.md（按需）	根级写通用，子目录只写差异项；作用域自动按路径收缩
组织强制策略（企业 IT 部署）	Managed policy CLAUDE.md + 以上任意	最高优先级，由 IT 通过 /Library/Application Support/ClaudeCode/ 等路径部署

最小可用原则：三种文件不必全开；多一份文件就多一份维护成本，且会占用指令文件预算（单文件上限 4,000 字符、总预算 12,000 字符，超出会 [truncated]）。

System Prompt篇章到此完结。总结一下，普通用户通过关注第9层的Instruction Files指令文件，这些文件可以注入类似于1~5层的静态指令。通过了解指令性文件的3个层级9个文件路径，知晓他们向下加载指令，向上收集路径的特点，cwd作为收集的锚点，离这个锚点位置越近的文件，大模型的注意力最强（Recency Effect）。基于这个特点，我们就可以将技术栈，个人偏好，持久性对话规则，绝对指令，规则权限等放在不同注意力层级的指令性文件里。

Hey🌺我是一只肥罗，坚持做一些有意思的事情

「愿始于我，但不止于我」

🍻研究+码字+反复修改不易，路过的朋友麻烦点赞关注~