从面试“啊。。”到精通CLAUDE.md维护：一份让你不再尴尬的完整指南

面试官抬头："你说你用Claude写代码，你说说你怎么维护CLAUDE.md"

我："啊。。这是啥？"

面试官："今天面试就到这吧"

------这就是那篇被转疯了的文章的开头。作者是卡码大模型的Carl。

这篇文章我读了三遍。第一遍感叹场景真实，第二遍开始记规则，第三遍发现一个问题：太多人总结这篇文章，但很少有人敢直接把原文搬进博客，一字不差地引用。 今天我就试试这个写法------直接在正文里用引用块呈现原文的关键内容，然后在外面告诉你：这一段为什么重要，我学到了什么。

---

一、为什么你总是在重复教育 Claude Code？

Carl在文里写了一个特别普遍的场景：

你打开一个老项目，让 Claude Code 帮你改一个接口。

你会先说一大堆：

• 这个项目是 VuePress 1.x，不要按 VuePress 2.x 写
• 命令要在 docs/目录下执行
• 依赖版本别乱升
• 不要改部署脚本
• Markdown 图片必须有 ALT
• 改完之后跑 npm run build

这些话有用吗？

有用。

但问题是：你每次开新任务都要说一遍。

我读到这儿的时候一拍大腿------这不就是我自己吗？每次开新对话都要把老规矩重新念叨一遍，然后看着上下文越来越长，最后Claude开始"忘记"。

Carl接着给出了根因分析：

你以为 Claude Code "记得"这些规则，其实它只是当前上下文里还能看到这些规则。

一旦上下文压缩、裁剪、切换任务，它就可能忘。

所以项目规则不能只靠聊天输入。

它需要一个更稳定的入口。

这就是 CLAUDE.md。

原文这段话太关键了。 "项目规则不能只靠聊天输入" ------这件事的认知转变，是迈入AI工程化的第一步。

---

二、CLAUDE.md到底是什么？和README、Prompt、Memory有什么不同？

Carl用一句话就把这四者的关系讲透了：

一句话区分：

README 告诉人怎么理解项目，Prompt 告诉模型这次要做什么，CLAUDE.md 告诉 Claude Code 在这个项目里怎么干活。

我愿称这句话为"AI编程文档四象限"的终极口诀。尤其是README和CLAUDE.md的区别，很多人一辈子都分不清。原文用了很大篇幅对比：

• README 的读者是人。

• 它通常会写：项目介绍、功能说明、安装方式、使用文档、贡献指南。

• 这些信息对人很友好，但对 Agent 不一定高效。

• 因为 Claude Code 真正需要的是行动约束。
  Prompt 又不一样。

• Prompt 是当前任务的临时要求。

• 而 CLAUDE.md 适合放跨任务都稳定的规则。
  Memory 也要分清。

• 你个人的习惯，比如"我喜欢先看计划再改代码"，更适合放用户级记忆。

• 团队共享规则，才适合放项目里的 CLAUDE.md。

这一段我直接引用到我的项目文档里了。以后谁敢把个人偏好塞进团队CLAUDE.md，我就把这段原文贴给他看。

---

三、CLAUDE.md应该放在哪里？

原文把位置问题讲得清清楚楚，分成了四级：

1. 用户级：~/.claude/CLAUDE.md

这个文件属于你个人。适合放你跨项目都稳定的偏好。

2. 项目级：./CLAUDE.md或 ./.claude/CLAUDE.md

这是最常用的位置。适合放团队共享的项目规则。

3. 子目录级：模块自己的 CLAUDE.md

大仓库里，一个根目录 CLAUDE.md往往不够。

4. 私人项目偏好：更推荐用 import（@path）

关于子目录级，原文配了一张图，图注是：

多级 CLAUDE.md 按任务路径加载，避免无关模块规则污染上下文

这段话让我决定重构我那个300行的根CLAUDE.md。我原来把后端、前端、文档的规则全扔在一个文件里，现在改成每个子目录自己写。

---

四、什么内容值得写进去？六大核心类别

Carl给出了判断标准：

判断一条信息该不该写进 CLAUDE.md，我有一个很简单的标准：

它是否会反复影响 Claude Code 的行动？

如果会，就值得写。

如果只对当前一次任务有效，就放 prompt。

如果只是给人看的背景，就放 README。

然后他列举了六大类，每一类我都直接引用原文的示例，因为这些示例本身就是最好的模板。

1. 常用命令

## 常用命令
- 安装依赖：pnpm install
- 本地开发：pnpm dev
- 单元测试：pnpm test
- 构建检查：pnpm build[原文](@context-ref?id=32)

命令一定要写完整。尤其是 monorepo 或 VuePress 这类项目，经常要求在特定目录执行。

2. 项目结构

## 目录结构
- `src/components/`：通用 UI 组件
- `src/pages/`：页面入口
- `src/api/`：接口封装，组件不要直接调用 fetch
- `src/store/`：全局状态
- `tests/`：单元测试和集成测试

Carl在旁边加了一句批注，我特别喜欢：

写目录职责，不要贴完整文件树。

3. 编码规范

- 新组件使用函数组件
- 样式优先使用已有 token，不新增散乱颜色
- API 错误统一通过 handleApiError()`处理
- 不要在组件中直接写请求逻辑

4. 禁止事项

## 禁止事项
- 不要修改数据库 schema，除非用户明确要求。
- 不要升级核心依赖版本。
- 不要提交 .env、token、密钥。
- 不要重写历史迁移文件。
- 不要删除用户已有改动。

Carl评价道：

AI 编程最怕的不是写得慢，而是乱动不该动的地方。

禁止事项写清楚，能减少很多事故。

5. 验证流程

## 验证要求
- 修改业务逻辑后，优先运行相关单测。
- 修改公共组件后，运行组件测试和构建。
- 修改依赖或配置后，运行完整构建。
- 如果测试无法运行，要在最终说明里写明原因。

6. 常见坑

## 常见坑
- VuePress 1.x 插件必须使用 `@vuepress/back-to-top`，不要写成 VuePress 2.x 的插件名。
- dev 模式关闭了文件监听，改完文件需要手动刷新浏览器。
- 图片必须使用上传后的图床地址，不要引用本地临时文件。

这六类我全盘接收，直接复制到我的项目模板里了。Carl文末也提供了一个可以直接抄的模板，我在第五节会引用。

---

五、什么内容不要写进去？

原文列举了五种"垃圾"：

1. 完整接口文档

CLAUDE.md里最多写："API 文档见 docs/api.md"。不要把几十个接口全贴进去。

2. 历史流水账

别写流水账，写结论。

3. 空泛口号

"写高质量代码""注意性能"------这类话看着正确，但不能指导行动。

4. 过期规则

过期规则比没有规则更危险。

5. 太细的临时任务

它属于当前对话。任务结束后还留在 CLAUDE.md里，只会污染后续任务。

---

六、怎么写才真的有效？"短、准、硬"

Carl用三个字总结：

短、准、硬。

短，是不要写长篇大论。

准，是每条都和行动有关。

硬，是尽量写成明确约束，而不是温柔建议。

他举了两个改写的例子：

比如这句话：尽量注意测试。

太软。

改成：修改业务逻辑后，必须运行相关测试；如果无法运行，在最终回复说明原因。

这就好多了。
再比如：代码要符合项目风格。

太虚。

改成：新增 API 请求必须放在 src/api/，页面组件只能调用封装后的 API 方法。

---

七、大项目怎么拆CLAUDE.md？

原文给出了清晰的骨架：

repo/

├── CLAUDE.md

├── apps/web/CLAUDE.md

├── apps/admin/CLAUDE.md

├── packages/ui/CLAUDE.md

└── docs/CLAUDE.md

根文件写全局规则：包管理器、Git 流程、安全要求、全局禁止事项、通用验证方式。

模块文件写模块规则：当前模块目录职责、本模块启动命令、本模块测试命令、本模块常见坑。

Carl最后强调：

不是让模型看见更多，而是让它看见更有价值的信息。

这句话在文章里出现了两次，可见有多重要。

---

八、CLAUDE.md和上下文窗口的关系

这是个容易被忽视的技术细节。原文说：

CLAUDE.md 虽然好用，但它不是免费空间。

它会进入 Claude Code 的上下文。

上下文窗口就像一张工作台。你把项目规则放上去，模型就能看到。但你放太多，工具输出、文件内容、用户要求就会被挤。

所以不要把 CLAUDE.md当成无限记事本。
一份 300 行的 CLAUDE.md，即使缓存了，模型每次也要在大量规则里找重点。

这就会带来两个问题：第一，重要规则被淹没。第二，无关规则干扰当前任务。

我看了这段之后，立刻把我原来一个150行的CLAUDE.md砍到了80行。

---

九、可以直接抄的模板

原文在第十节给出了一个通用模板，我直接全文引用，因为这就是我接下来要用的：

# 项目工作说明

## 项目概述
- 本项目是一个 XXX 应用，主要技术栈是 XXX。
- 主要代码在 `src/`，测试在 `tests/`。
- 优先遵循现有代码风格，不要引入新的架构风格。

## 常用命令
- 安装依赖：`pnpm install`
- 本地开发：`pnpm dev`
- 单元测试：`pnpm test`
- 构建检查：`pnpm build`

## 目录结构
- `src/components/`：通用组件
- `src/pages/`：页面入口
- `src/api/`：接口封装
- `src/hooks/`：可复用业务逻辑
- `tests/`：测试文件

## 编码规范
- 新增 API 请求必须放在 `src/api/`。
- 页面组件不要直接调用 `fetch`。
- 公共逻辑被两个以上模块复用时，抽到 `src/hooks/`。
- 修改已有功能时，优先保持现有接口兼容。

## 禁止事项
- 不要提交 `.env`、token、密钥。
- 不要升级核心依赖版本，除非用户明确要求。
- 不要修改数据库 schema，除非用户明确要求。
- 不要删除用户已有改动。

## 验证要求
- 修改业务逻辑后，运行相关测试。
- 修改公共组件后，运行构建检查。
- 如果测试无法运行，在最终回复里说明原因。

## 常见坑
- 本项目使用 pnpm，不要使用 npm 或 yarn。
- 修改配置文件后，需要重新启动开发服务器。
- 遇到鉴权问题，先检查 `src/api/auth.ts` 和 `src/store/auth.ts`。

---

十、面试中怎么讲这个能力？

原文最后一个高能部分，是Carl给的面试话术。这个我直接背下来了：

"我不会只靠临时 prompt 管项目规则。对于跨任务稳定的信息，比如项目架构、常用命令、测试方式、代码风格、禁止改动范围，我会沉淀到 CLAUDE.md。这样 Claude Code 每次进入项目时都能读取这些规则，减少重复解释，也减少上下文压缩后丢约束的问题。

但我不会把 CLAUDE.md写成大杂烩。因为它会进入上下文，太长会稀释注意力。所以我会按全局规则和模块规则拆分，根目录写通用约束，子目录写模块细节；临时任务放 prompt，个人偏好放用户级 memory，团队规则放项目级 CLAUDE.md。核心目标不是让模型看到更多，而是让它看到更稳定、更有行动价值的信息。"

这段话我准备下次面试直接引用。但更重要的是------它背后体现的"AI工程化"思维，才是我真正想学的东西。

---

结尾

CLAUDE.md不是魔法。

它不会让 Claude Code 瞬间变成懂你公司所有业务的老员工。

但它能解决一个非常实际的问题：

别让 AI 每次进项目都从零猜。

这是原文的结尾。我现在把它作为自己每次新建项目时的第一原则：先把CLAUDE.md写好，再开始写代码。

最后，如果你是第一次听到CLAUDE.md这个词，别等到面试时才"啊。。这是啥？"------就从今天开始，打开你的项目根目录，新建一个CLAUDE.md，把最常用的几条规则写进去。

Carl在文末有一句话，我觉得可以作为所有人的行动清单：

短一点，准一点，硬一点。

这就够了。