别再把 Claude Code 当一次性聊天框了：CLAUDE.md 与持久上下文工作流

最近刷到一篇关于 Claude Code 里的 CLAUDE.md 的 X 长文，标题很典型：“你一直都在用错 Claude，CLAUDE.md 可以修复一切。”

营销味有点重，但它击中了一个真实问题：很多人不是不会用 AI，而是每次都在从零开始用 AI。

每开一个新会话，就重新解释：

• 我是谁；
• 我在做什么项目；
• 我喜欢什么表达风格；
• 哪些事情不要擅自改；
• 哪些操作必须先问我；
• 上次踩过什么坑；
• 这套代码、文章、业务有什么固定约束。

这不是 Prompt 不够好，而是上下文没有沉淀。

CLAUDE.md 的意义就在这里：它不是一个“万能咒语”，而是一份可以被 Claude 自动读取的长期工作说明书。它把你反复强调、反复纠正、反复补充的东西，变成项目级的持久上下文。

---

一、真正的问题：每次对话都从零开始

很多人使用 Claude Code、ChatGPT 或其他 AI 工具时，默认把它当成一个更聪明的聊天框。

这会带来一个很隐蔽的效率损耗：AI 每次都不知道你是谁，也不知道你之前怎么工作。

于是你会不断遇到这些情况：

• 简单问题，它先来一段“Great question”式废话；
• 让它改一段文字，它顺手重写了整篇；
• 让它修一个 bug，它顺手重构了三个无关文件；
• 让它总结资料，它编了几个看似合理但没来源的事实；
• 让它写文案，它写得很流畅，但完全不像你；
• 让它处理项目，它不知道哪些约束是历史原因，哪些可以调整。

这类问题不是模型“笨”。很多时候是因为它缺少稳定上下文。

模型不是你的同事。它不会天然记得你上周说过什么，也不会默认理解你的偏好。没有外部记忆机制，它每次醒来都是一个新实例。

所以我们真正要解决的，不是“这一轮 prompt 怎么写得更长”，而是：

如何把稳定、重复、长期有效的信息，从临时对话里抽出来，变成 AI 每次工作前都能读取的上下文？

这就是 CLAUDE.md 的价值。

---

二、CLAUDE.md 到底是什么？

简单说，CLAUDE.md 是 Claude Code 在项目目录里会自动读取的 Markdown 文件。

你可以把它理解成项目里的“AI 协作说明书”。它通常放在项目根目录，用来告诉 Claude：

• 当前项目是什么；
• 技术栈是什么；
• 用户偏好是什么；
• 代码风格是什么；
• 哪些目录不能碰；
• 哪些命令可以运行；
• 哪些操作必须确认；
• 已知问题和历史决策是什么。

它的价值不在于格式多高级，而在于它把“重复解释”变成“自动加载”。

一次写好，多次复用。

这件事很小，但会明显改变 AI 协作的手感。

flowchart TD
    A[临时 Prompt] --> B[只影响当前会话]
    C[CLAUDE.md] --> D[每次进入项目自动读取]
    D --> E[稳定偏好]
    D --> F[项目约束]
    D --> G[权限边界]
    D --> H[历史经验]
    E --> I[更少重复解释]
    F --> I
    G --> I
    H --> I

当然，CLAUDE.md 最直接服务于 Claude Code，不是 Claude 网页聊天框独有的“魔法”。它背后的思想更通用：AI Agent 需要持久上下文层。

不管这个层叫 CLAUDE.md、AGENTS.md、MEMORY.md、skills，还是某种向量记忆系统，本质上都在做同一件事：让 AI 不再只依赖当前窗口里的几句话。

---

三、我最认可的几类规则

那篇 X 长文列了 21 条适合放进 CLAUDE.md 的规则，内容不少。真正值得保留的，我认为主要是下面几类。

1. 沟通风格：少废话，结论优先

很多 AI 默认会把“礼貌”理解成一套固定话术：

• “Great question!”
• “Of course!”
• “Certainly!”
• “I’d be happy to help!”

这些句子本身没有错，但在高频协作里很烦。尤其是你只是想要一个结果，它还要先表演一遍“我很乐意帮助你”。

所以可以写进规则：

少废话，结论优先。不要用“好问题”“当然可以”“我很乐意”等开场白。简单问题直接给答案，复杂任务再展开分析。

这类规则看似小，其实很影响工作流。因为 AI 的语气不是装饰，它会决定你和它协作时的摩擦感。

2. 事实边界：不确定就明说

AI 最大的问题之一不是不知道，而是“很会装作知道”。

尤其是日期、数据、论文引用、版本号、API 行为、历史事件这类信息，一旦它凭印象补全，用户很容易被带偏。

所以这条规则应该长期存在：

如果不确定某个事实、数字、日期、引用或 API 行为，必须明确说明不确定。不要用听起来合理的内容填补空白。能查证就先查证。

这条比“回答要专业”重要得多。

专业不是语气自信，而是知道边界在哪里。

3. 修改边界：只改被要求改的东西

对于写作和代码来说，这是非常关键的一条。

你让 AI 改一个段落，它可能顺手重排全文；你让它修一个函数，它可能顺手重构整个模块；你让它优化一句标题，它可能把原本的表达风格全改掉。

这种“热心”在真实工作里很危险。

更好的规则是：

只修改用户明确要求修改的范围。不要擅自重写、重构、改名、移动文件或优化无关内容。如果发现其他值得改进的问题，单独列出建议，不要直接动手。

这条规则背后的原则是：AI 应该是精密工具，不是自动接管一切的实习生。

4. 权限边界：外部副作用必须确认

当 AI 只是聊天时，错误最多是文字不准。

但当 AI 接入工具之后，它可以：

• 发邮件；
• 发微博 / X；
• 发小红书；
• 删除文件；
• 覆盖代码；
• 部署服务；
• 调用外部 API；
• 操作数据库。

这时“别乱动”就不是偏好，而是安全边界。

适合写成硬规则：

发送、发布、部署、删除、覆盖、数据库迁移、生产环境操作、不可逆外部 API 调用，必须在当前会话获得明确确认后才能执行。历史上下文或推测意图不算确认。

这条规则应该放在所有 Agent 系统的最前面。

因为真正危险的不是 AI 不够聪明，而是它“聪明地误解了你”。

---

四、CLAUDE.md 不只是开发者工具

很多人一听 CLAUDE.md，会以为它只是 Claude Code 的开发者配置，或者只适合程序员。

这其实把它看窄了。

它更像一种“上下文工程”方法，可以迁移到很多场景。

写作者

写作者最需要沉淀的是声音和边界：

• 我的文章语气是什么；
• 句子长短偏好；
• 哪些词不要用；
• 标题风格；
• 是否允许鸡汤；
• 是否要保留个人表达痕迹；
• 哪些观点是长期立场。

没有这些，AI 写出来的东西往往是“正确但不像我”。

研究者

研究者需要沉淀的是信息结构：

• 文献总结格式；
• 引用要求；
• 不确定性标注；
• 对比维度；
• 公式和术语解释深度；
• 哪些领域知识不必过度解释。

这样 AI 才不会每次都把摘要写成泛泛而谈的科普文。

产品和运营

产品、运营、市场类任务需要沉淀的是受众和业务约束：

• 用户是谁；
• 产品定位是什么；
• 竞品有哪些；
• 不能承诺什么；
• 品牌语气是什么；
• 哪些表述有合规风险。

如果没有这些，AI 很容易写出“看起来很像营销文，但完全不贴业务”的内容。

开发者

开发者当然是 CLAUDE.md 最典型的受益者。

它可以记录：

• 技术栈；
• 包管理器；
• 测试命令；
• 目录结构；
• 代码风格；
• 禁止改动的区域；
• 部署和迁移权限；
• 常见错误及修复方式。

这会让 Claude Code 从“每次刚入职的新同事”，变成“至少看过项目 README 和踩坑记录的协作者”。

---

五、不要照抄 21 条规则，要按自己的工作流裁剪

那篇推文最大的问题，是有些规则听起来都对，但放在一起会互相打架。

比如它建议：

任何重要任务开始前，都先给 2-3 个方案并等待用户选择。

这在高风险任务里是对的，比如重构架构、迁移数据库、发布文章、改生产配置。

但如果用户只是说“帮我读一下这篇文章总结”，还非要先列 3 种总结方式让用户选，那就很烦。

所以规则不能机械照抄。更合理的做法是分层：

flowchart TD
    A[用户请求] --> B{是否有外部副作用或不可逆风险？}
    B -->|是| C[先说明影响范围并等待确认]
    B -->|否| D{是否存在明显默认做法？}
    D -->|是| E[直接执行]
    D -->|否| F[给 2-3 个方案让用户选择]

换句话说：

• 低风险、高确定性的任务：直接做；
• 中风险、多路径的任务：先给方案；
• 高风险、有外部副作用的任务：必须确认；
• 不确定事实：先查证或标注不确定。

这比“所有事情都先问”更适合真实协作。

AI 协作最舒服的状态不是它永远谨慎，也不是它永远主动，而是它知道什么时候该大胆，什么时候该停手。

---

六、一个更实用的 CLAUDE.md 模板

如果你不想写很长，可以从下面这个精简版开始。

# CLAUDE.md

## 沟通风格

- 少废话，结论优先。
- 不要用“Great question”“Of course”“当然可以”等开场白。
- 简单问题短答，复杂任务再展开。
- 不确定的事实必须标注，不要编。

## 工作原则

- 优先执行，不要把简单任务变成反复确认。
- 如果存在明显默认做法，直接采用默认做法。
- 如果任务有多种路线且结果差异明显，先给 2-3 个方案让我选。
- 如果需要外部发送、发布、部署、删除、覆盖、数据库迁移或不可逆操作，必须先获得当前会话明确确认。

## 修改边界

- 只修改我明确要求修改的范围。
- 不要擅自重构、改名、移动文件或优化无关内容。
- 如果发现其他问题，列为建议，不要直接动手。
- 完成后简要说明改了什么、验证了什么、还有什么风险。

## 项目上下文

- 项目名称：TODO
- 项目目标：TODO
- 技术栈：TODO
- 包管理器：TODO
- 测试命令：TODO
- 禁止改动区域：TODO
- 常见坑：TODO

## 写作风格

- 语气：TODO
- 受众：TODO
- 常用表达：TODO
- 避免表达：TODO
- 标题风格：TODO

这个版本不追求全，而是先覆盖最容易反复纠错的部分。

真正好的 CLAUDE.md 不是一次写完的，而是在使用过程中慢慢长出来的。

每当你发现自己又对 AI 说了一遍“以后不要这样”，那句话就应该被沉淀进去。

---

七、从 CLAUDE.md 到更大的记忆系统

CLAUDE.md 解决的是项目级上下文，但它不是终点。

更成熟的 AI 工作流，往往会把上下文分成几层：

• 身份层：我是谁，我的长期偏好是什么；
• 项目层：这个项目的目标、结构、技术栈、约束；
• 任务层：当前这次要完成什么，验收标准是什么；
• 经验层：过去踩过什么坑，哪些方法有效，哪些方法失败；
• 权限层：哪些动作可以直接做，哪些必须确认。

这些层不一定都写在一个文件里。

有的适合放 CLAUDE.md，有的适合放 MEMORY.md，有的适合写成项目 README，有的适合沉淀成 skills，有的适合由 Agent 系统自动管理。

关键不是文件名，而是这套原则：

高频重复的信息，不应该永远留在临时对话里。
它应该进入一个可维护、可复用、可更新的上下文系统。

这也是为什么我觉得 CLAUDE.md 的意义被低估了。

它不是 prompt 工程的小技巧，而是 Agent 工程的一块基础设施。

---

八、它不能“修复一切”，但能修复大量重复摩擦

回到那篇推文的标题：“CLAUDE.md fixes everything。”

这句话显然夸张。

CLAUDE.md 不能让模型凭空变聪明，不能保证工具不报错，不能替代测试，也不能让 AI 永远理解你的真实意图。

但它确实能修复很多高频摩擦：

• 少解释一遍背景；
• 少纠正一次语气；
• 少发生一次擅自改动；
• 少踩一次历史坑；
• 少让 AI 编一次不确定事实；
• 少在危险操作上赌一次“它应该懂”。

这些单次看起来都很小，但叠加起来就是工作流质量的差距。

真正的 AI 协作，不是每次都写一个更长、更复杂的 Prompt。

而是把那些稳定有效的经验，一点点沉淀成系统。

CLAUDE.md 只是这个系统最朴素、最容易开始的一种形式。

---

结语：把 AI 从“会话”升级成“工作系统”

这篇推文真正值得带走的，不是那 21 条规则本身，而是背后的思路：

不要把 Claude Code 当成一次性聊天框，要把它接入你的工作系统。

聊天框只记得这一轮你说了什么。

工作系统会记得：

• 你是谁；
• 你怎么写作；
• 你怎么写代码；
• 你不喜欢什么；
• 你过去怎么决策；
• 你踩过哪些坑；
• 哪些事情必须停下来问你。

当这些东西被稳定沉淀下来，AI 才会从“聪明但陌生的工具”，慢慢变成“熟悉你工作方式的协作者”。

这才是 CLAUDE.md 真正有价值的地方。