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

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

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

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

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

如何在两分钟内设置

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

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

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

永远移除寒暄和填充语

Claude 很喜欢用“Great question”“Absolutely”“Of course”这类开场。它们礼貌，但浪费时间。可以要求它直接回答，不铺垫、不预热、不寒暄。

重大任务前先给方案

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

停止假装确定

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

按任务复杂度决定回答长度

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

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

重大改动前先说明并等待确认

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

只修改明确要求修改的内容

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

编辑后说明变更范围

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

没有当前会话确认，不执行外部动作

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

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

说明你是谁

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

说明你正在构建什么

通用上下文只会得到通用输出。应定义项目、目标、受众、语气和限制条件。上下文越清楚，Claude 越能给出贴合当前工作的回答。

锁定你的写作风格

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

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

创建 MEMORY.md

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

会话结束时写总结

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

追踪失败方案

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

定义永久事实

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

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

严格保持任务范围

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

破坏性操作前必须确认

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

设置硬性停止线

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

锁定技术栈

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

代码任务后总结变更

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

Karpathy 风格的 4 条底层规则

作者提到 Andrej Karpathy 曾强调过几条能提升 Claude Code 表现的行为规则，并将其总结为：

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

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

最终结论

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

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

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