# 99% 的 Claude 用户每周都在浪费时间：一个隐藏文件可以立刻修复它

原文：99% of Claude users are wasting hours every week. One hidden file fixes it instantly: CLAUDE.md  
作者：Ajit kumar（@ajitcodes）  
来源：https://x.com/ajitcodes/status/2060763204490502526  
文章链接：https://x.com/i/article/2054615364483596288  
原文日期：2026-05-30

---

这篇文章的核心观点是：大多数 Claude 用户每周都在重复解释、重复纠正、重复提示，而一个项目根目录中的 `CLAUDE.md` 文件可以把这些重复劳动系统性消除。

很多人甚至没听过 `CLAUDE.md`。听过的人，也常把它当成随手记录的普通说明文件，而不是整个 Claude 工作流中最关键的配置层。

问题在于：每次新开 Claude 会话，它默认都从零开始。它不知道你是谁、你的写作方式、你正在构建什么、你的偏好、你的流程和你的规则。于是每个会话都变成同一个循环：重新解释、重新纠正、重新提示、反复来过。更糟糕的是，Claude 还可能自信地给出完全不像你的输出。

`CLAUDE.md` 的作用，就是把 Claude 从通用聊天机器人，变成围绕你和你的项目工作的系统。

## 如何在两分钟内设置

1. 打开任意项目文件夹。
2. 创建一个文件，名称必须是 `CLAUDE.md`。
3. 用任意文本编辑器打开它。
4. 写入你的规则和偏好。
5. 保存。

在该文件夹中工作时，Claude 会读取这个文件中的说明。作者强调，这不需要插件、不需要额外设置界面，也不需要复杂配置。

## 第一部分：修复 Claude 的沟通方式

1. **永远移除寒暄和填充语**  
   Claude 很喜欢用“Great question”“Absolutely”“Of course”这类开场。它们礼貌，但浪费时间。可以要求它直接回答，不铺垫、不预热、不寒暄。

2. **重大任务前先给方案**  
   Claude 默认会选一个方向直接执行。你只是想改一点文字，它可能重写整段风格；你只是想调整结构，它可能推翻原有组织方式。可以要求它在重大任务前先给 2 到 3 个方案，等你选择后再继续。

3. **停止假装确定**  
   Claude 有时会用自信语气回答不确定内容，尤其是数据、日期、引文和技术事实。应明确要求：不确定时先说明不确定，不要把猜测当事实。

4. **按任务复杂度决定回答长度**  
   简单问题不需要长文，复杂问题也不能只给表层回答。可以要求它根据任务复杂度控制篇幅，不用重复和无意义总结填充答案。

## 第二部分：修复 Claude 的行为边界

5. **重大改动前先说明并等待确认**  
   当你只想调整一段内容时，Claude 有时会重写半篇文档。应要求它在对既有内容做重大编辑前，说明会改什么，并等你确认。

6. **只修改明确要求修改的内容**  
   Claude 经常顺手“优化”你没要求动的地方，导致你不得不重新审查全文。可以要求它只改你明确指定的部分，其他改进建议单独列出，不直接动手。

7. **编辑后说明变更范围**  
   每次编辑任务完成后，Claude 都应该说明：改了什么、哪些地方没有动、还有哪些需要注意。

8. **没有当前会话确认，不执行外部动作**  
   当 AI 工具接入邮件、日历、社交媒体和文档后，这条尤其关键。应要求 Claude 不在没有明确确认的情况下发送、发布、安排或分享任何内容。

## 第三部分：给 Claude 真实上下文

9. **说明你是谁**  
   Claude 不知道你是新手、专家、创始人、营销人还是工程师。缺少上下文时，它只能猜，而且常常猜错。应在 `CLAUDE.md` 中写明角色、背景、专业程度和正在学习的领域。

10. **说明你正在构建什么**  
    通用上下文只会得到通用输出。应定义项目、目标、受众、语气和限制条件。上下文越清楚，Claude 越能给出贴合当前工作的回答。

11. **锁定你的写作风格**  
    Claude 有默认语气，但那不是你的语气。可以要求它匹配你的句长、词汇、格式、措辞偏好和整体风格，让初稿更接近你本人。

## 第四部分：给 Claude 延续性记忆

12. **创建 `MEMORY.md`**  
    Claude 会忘记会话之间的细节，但文件可以保留。作者建议让 Claude 维护一个 `MEMORY.md`，记录已经做出的决策、被否决的想法、进行中的工作，以及选择背后的原因。

13. **会话结束时写总结**  
    如果没有总结，重新打开旧项目时常要花很久回忆进展。可以要求 Claude 在会话结束时写入完成内容、当前进度和下一步。

14. **追踪失败方案**  
    很多问题会反复出现，是因为 Claude 忘记了哪些方案已经失败。可以创建 `ERRORS.md`，记录失败内容、失败原因、最终有效的方案和经验教训。

15. **定义永久事实**  
    每个项目都有长期不变的事实：技术栈、品牌语气、商业限制、合规规则等。把这些写进文件，并要求 Claude 在每次会话中默认应用。

## 第五部分：面向开发者的规则

16. **严格保持任务范围**  
    修一个 bug 时，Claude 可能顺手重命名变量、整理 import、重构无关代码，甚至破坏本来正常运行的系统。应要求它只修改和当前任务直接相关的代码，不重构无关文件。

17. **破坏性操作前必须确认**  
    删除文件、覆盖函数、丢弃记录都可能毁掉数小时工作。应要求 Claude 在破坏性操作前列出会改什么，并获得明确确认。

18. **设置硬性停止线**  
    有些动作永远不应自动执行，比如生产部署、数据库迁移、外部 API 调用、发送邮件等。每次都必须确认。

19. **锁定技术栈**  
    没有明确说明时，Claude 会倾向于使用网上最常见的框架，而不是你的项目实际技术栈。应写明语言、框架、数据库、测试工具和包管理器。

20. **代码任务后总结变更**  
    编码任务完成后，Claude 应列出修改了哪些文件、改了什么、哪些文件没动、后续还需要做什么。这样审查会快很多。

21. **Karpathy 风格的 4 条底层规则**  
    作者提到 Andrej Karpathy 曾强调过几条能提升 Claude Code 表现的行为规则，并将其总结为：

    - 不确定时先问，不要假设。
    - 优先采用最简单可行方案。
    - 不触碰无关代码。
    - 明确标出不确定性。

    原文还提到这些规则“据称”能显著提升编码准确率。这里应按作者说法理解，不把具体数字当作独立验证结论。

## 最终结论

`CLAUDE.md` 不是隐藏的开发者技巧，而是严肃 Claude 用户的操作系统。

前 4 条规则改善沟通方式；第 5 到 8 条阻止不想要的行为；第 9 到 11 条注入真实上下文；第 12 到 15 条建立跨会话记忆；第 16 到 21 条让 Claude Code 更安全、更稳定。

作者的建议很简单：今天先创建文件，写入 3 条最重要的规则，然后随着工作流逐步扩展。你会从第一次会话开始看到差异。