Claude不设好，真的很费命
一个 CLAUDE.md 文件，冲上了 GitHub Trending 第一名。
82,000 stars，7,800 forks。
但讽刺的是，大多数 Claude 用户甚至没听过它。听过的人，也不知道里面到底该写什么。
这个差距，每周都在浪费你的时间。
每次你打开一个新的 Claude session，它都像第一次见你一样：不知道你是谁，不知道你做什么，不知道你的偏好，不知道你希望事情怎么完成。于是你要么花几分钟重新解释一遍，要么懒得解释，然后拿到一份完全不符合你工作方式的输出。
CLAUDE.md 解决的，就是这个问题。
这不是开发者专属工具
很多人以为 CLAUDE.md 只是开发者用 Claude Code 时才需要的东西。
不是。
它本质上是一个 Claude 会在每次 session 开始时自动读取的指令文件。只要你经常使用 Claude，它就适合你。
写作者可以用它锁定自己的声音和语气，让 Claude 不再写得像另一个人。营销人员可以用它定义目标受众，让 Claude 不再产出泛泛而谈的文案。研究人员可以用它规定信息结构。创业者和业务负责人可以把公司背景放进去，让 Claude 的每次输出都更贴近现实。
没有 CLAUDE.md，你每次都是从零开始。
你重复解释自己。 你反复纠正同样的错误。 你第 100 次告诉 Claude 你不喜欢什么语气。
所以，无论你用 Claude 写作、研究、做内容、做商业分析，还是写代码，CLAUDE.md 都应该是你严肃使用前设置的第一件事。
怎么创建这个文件？
很简单。
打开你的项目文件夹，新建一个文件，名字必须写成：
CLAUDE.md注意：大写字母，没有空格。
它就是一个普通 .md 文本文件。
你可以用任何编辑器打开：Notepad、TextEdit、VS Code，都可以。然后把适合你的指令复制进去。
不需要一开始就塞满 21 条。
先选 3 到 4 条，解决你最烦的几个问题。保存文件后，在这个文件夹里启动 Claude Code，它就会自动读取。
不用额外设置。
从第一条消息开始生效。
1. 干掉废话开场
Claude 默认很喜欢用这些开头：
“Great question!” “Of course!” “Certainly!” “Absolutely!”
这些词听起来礼貌，但没有信息量。
当你每天用 Claude 好几个小时时，这种废话会不断叠加成摩擦。
一条指令就能永久解决它。每次回答直接进入正题，不预热，不表演热情，只给你要的信息。
可以写进 CLAUDE.md：
永远不要用“Great question!”、“Of course!”、“Certainly!”、“Absolutely!”、“Sure!” 或类似寒暄开头。
每次回答都直接从答案开始。
不要铺垫，不要重复确认问题。
只给信息。2. 动手前先给选项
Claude 默认会自己选一个方向，然后直接往下做。
你让它改写一段话，它可能顺手把整篇文章的语气都变了。你让它重组一份文档，它可能按照它自己的逻辑重新排列，而不是按照你的思路。
最后，你又要花时间纠正它没被授权的改动。
这条指令会改变关系：在重要任务前，Claude 先给你 2-3 种处理方案。你选方向，它再执行。
可以写：
在执行任何重要任务之前，先给我 2-3 个可选方案。
每个方案都要说明：
- 会怎么处理
- 适合什么情况
- 可能的取舍
等我选择后，再开始执行。
不要默认选择一个方向直接动手。3. 不知道就明说
Claude 有时会在不确定时，给你一个非常自信、非常详细、但完全错误的答案。
日期、统计数据、引用、事实，它可能都会补得像真的一样。
你当时看不出来，等用到关键场景时，问题才爆出来。
这条指令要求 Claude 在回答前先标出不确定性，而不是把猜测藏在自信语气里。
可以写：
如果你对任何事实、统计数据、日期、引用或信息不确定，必须在使用它之前明确说明。
“我不确定这一点”永远比把猜测当事实说出来更好。
不要用听起来合理的信息填补知识空白。
有疑问时，直接说不确定。4. 回答长度匹配任务复杂度
问一个简单问题，Claude 写四段。
让它做复杂工作，它又给一个看似完整、其实很薄的骨架。
这两种都没用。
回答长度应该跟任务复杂度匹配：简单问题短答，复杂任务深入。
可以写：
回答长度要匹配任务复杂度。
简单问题给直接、简短的答案。
复杂任务给完整、深入的回答。
不要压缩或草草总结需要深度的工作。
也不要用重复问题、套话或收尾废话来填充简单回答。Claude 怎么行动
5. 大改之前必须先问
你让 Claude 修一个段落，它重写整篇文档。
你让它缩短内容，它删掉你需要的部分。
你让它调整语气，它顺手改了结构。
每次你都丢掉一些本来不想丢的东西，然后还得从记忆或旧版本里找回来。
这条指令让所有重大改动都变成 checkpoint。
可以写：
在对我已经创建的内容做任何重大改变之前，必须完全停下来。
重大改变包括：
- 重写章节
- 删除段落
- 重组结构
- 改变语气
- 改变整体表达方式
你必须先说明：
- 准备改什么
- 为什么要改
- 会影响哪些部分
等我确认后再继续。
“我认为这样更好”不等于你有权限修改。6. 只做我要求的事
你让 Claude 修一个问题，它顺手“优化”五个地方。
改措辞、调结构、重写句子、重新排版。
有时确实变好了。
更多时候，不是你要的。
现在你还得检查到底哪里被动过。
这条指令让 Claude 保持在范围内。
只修改我明确要求你修改的内容。
不要重写、改写、重组、润色或“顺手优化”任何我没要求你动的内容，即使你认为这样会更好。
如果你发现其他地方也值得改进，可以在回答最后作为备注提出。
但不要主动修改，除非我明确要求。7. 每次都告诉我你改了什么
Claude 完成任务后，你常常要自己扫一遍输出，猜它到底改了哪里。
哪些段落动过？ 删了什么？ 加了什么？ 有没有动到我没要求的地方？
没有摘要，你就在手动 diff。
这条指令让每次任务结束时都有一个简短状态更新。
完成任何编辑或写作任务后，结尾必须附上一段简短总结：
- 修改了什么：【说明】
- 保留了什么：【如相关】
- 需要我注意什么：【需要决策或检查的内容】
保持简短。
这是状态更新，不是全文复述。8. 没有当前确认，绝不替我行动
AI 工具越来越多地连接邮箱、日历、社交账号、文档和外部系统。
风险也越来越大。
发送邮件。 发布内容。 分享文档。 安排日程。
这些动作都有现实后果，而且发生得很快。
这条指令给外部行动加一道硬墙。
未经我在当前消息中明确确认，绝不能代表我发送、发布、分享或安排任何东西。
这包括：
- 邮件
- 社交媒体内容
- 日历邀请
- 文档分享
- 任何会影响本对话外部事物的操作
“你之前提到想做这件事”不算确认。
我必须在当前消息中明确说“是”或“确认执行”。给 Claude 你的上下文
9. 告诉 Claude 你是谁、你懂什么
Claude 不知道你是专家还是新手，是创始人还是自由职业者，是想要技术深度还是普通语言。
没有上下文，它只能猜。
而它经常猜错。
有时解释你早就知道的基础。有时又跳过你真正需要的背景。
一段关于你的说明，可以校准后面每次回答。
关于我：
- 姓名：【你的名字】
- 角色：【你做什么，例如写作者、创始人、营销人员、研究者、工程师等】
- 背景：【相关经验或知识水平】
- 擅长：【我已经熟悉的主题，这些地方不要讲基础】
- 正在学习：【我需要更多背景和解释的领域】
每次回答都要根据这个背景调整深度。
不要过度解释我已经知道的内容。
也不要跳过我需要的上下文。10. 告诉 Claude 你正在做什么
每个 session 开始时，Claude 都不知道你当前在做什么、做给谁看、成功标准是什么。
于是它给你通用输出。
不是因为它懒，而是它没有别的依据。
给它一段项目背景，输出立刻会更贴近现实。
我正在做的事情：
- 项目：【用一句话描述这个项目】
- 目标：【什么样算成功】
- 受众：【这是给谁看的，他们关心什么】
- 语气：【输出应该是什么感觉，例如随意、专业、直接、对话式等】
- 避免：【不适合的东西，例如术语、某些话题、某种风格】
把这些上下文应用到每个任务里。
如果某个要求和这个背景不匹配，先提醒我再继续。11. 锁定你的声音和风格
Claude 有自己的默认写作风格。
还可以。
但不是你的。
它有固定词、固定句式、固定节奏。你每次让它写东西，最后都要改回自己的声音。
把你的风格定义一次，它第一稿就会更像你。
我的写作风格，请始终匹配：
- 声音：【例如直接、对话式、自信、无废话】
- 句子长度：【短促有力 / 长句详细 / 长短混合】
- 我常用的词：【听起来像我的短语或词汇】
- 我绝不用的词：【不符合我风格的词或表达】
- 格式偏好：【例如只用段落 / 使用 bullet points / 使用标题 / 不用标题】
凡是代表我写作，都要严格匹配这个风格。
不要默认使用你自己的写作模式。记忆和连续性
12. 让 Claude 维护一个记忆文件
Claude session 之间会忘记一切。
但 Claude 可以写文件，而文件会保留下来。
这条指令让 Claude 维护一个 MEMORY.md 文件，记录你们一起做过的重要决定：决定了什么，为什么，否掉了什么方案。
下次 session 开始时，它先读这个文件，就不会重新建议你已经试过的东西。
维护一个名为 MEMORY.md 的文件。
每当我们做出关于方向、格式、内容、方法或策略的重要决定时，添加一条记录：
## 【日期】，【决定】
**决定了什么：**【做出的选择】
**为什么：**【理由】
**否掉了什么：**【考虑过但放弃的替代方案，以及原因】
每次 session 开始时，在做任何事情前先读取 MEMORY.md。
除非先提醒我，否则不要违背已记录的决定。13. 结束 session 时写总结
你关闭 session。
两天后回来。
又花 15 分钟读旧消息，回忆做到哪、完成了什么、还有什么没做完。
这完全可以避免。
让 Claude 在你结束前，把 session summary 写进 MEMORY.md。
当我说“session end”、“wrapping up”、“今天先到这”或类似表达时，把本次会话总结写入 MEMORY.md：
## Session Summary，【日期】
**本次处理：**【我们主要做了什么】
**已完成：**【完成了什么】
**进行中：**【开始但尚未完成的内容】
**做出的决定：**【本次关键选择】
**下次继续：**【下次应该先做什么，以及需要延续的重要上下文】14. 记录失败方法，别重复踩坑
你为了写某类内容试了 4 种 prompt，最后才得到能用版本。
三周后你又做类似任务，Claude 又从同样的坏建议开始。
同样的试错，从头再来。
一个错误日志能打断这个循环。
维护一个名为 ERRORS.md 的文件。
当某个任务超过 2 次尝试才成功时，记录它：
## 【任务类型或描述】
**没用的方法：**【失败的方法和失败原因】
**有效的方法：**【最终成功的方法】
**下次注意：**【类似任务中值得记住的内容】
在为类似任务建议方法前，先检查 ERRORS.md。
如果任务匹配已记录失败案例，先说明这一点，然后直接使用已证明有效的方法。15. 给 Claude 一组永远不变的事实
每个项目都有一些永久事实：
过去决策形成的约束。 一直有效的规则。 无论任务怎么变都不该违反的原则。
如果 Claude 不知道这些，它就会随口建议相反的东西。
这条指令给它一个永久地基。
以下事实永远成立。每个 session、每个任务都必须无例外应用：
- 【永久事实 1，例如：我的受众没有技术背景】
- 【永久事实 2，例如：所有内容都必须适合专业场景】
- 【永久事实 3，例如：没有来源就不能做事实性断言】
- 【永久事实 4，例如：品牌语气始终温暖，绝不官腔】
如果任何任务和这些事实冲突，必须先提醒我再继续。
不要绕过约束而不告诉我。开发者专用
下面这些更适合使用 Claude Code 写代码、审代码、管理代码库的人。
如果你不是开发者，上面 15 条已经够用。
如果你是，这 6 条会决定 Claude 是一个精确工具，还是一个在你代码库里乱跑的 loose cannon。
16. 严格保持范围，没要求就别碰
你让 Claude 修一个 bug，它可能顺手重构三个文件、重命名变量、整理 import、优化你用了几个月的代码。
有些变化会直接出错。
有些会引入很隐蔽的差异，几天后才发现。
这条规则对 Claude Code 用户非常重要。
只修改和当前任务直接、明确相关的文件、函数和代码行。
不要重构、重命名、重组、重新格式化或“改进”任何我没有明确要求你修改的内容。
如果你发现其他地方值得修，可以作为备注告诉我。
但不要动它。
永远不要。17. 任何破坏性操作前必须确认
Claude Code 在你的终端里运行，可以访问文件系统。
它可以删文件、覆盖函数、删除依赖、甚至操作数据库。
只要误解一次指令，几个小时的工作可能就没了。
这条规则把每个破坏性动作都变成 checkpoint。
在删除任何文件、覆盖现有代码、删除数据库记录、移除依赖，或做任何无法轻易撤销的改动之前，必须完全停下来。
列出将受到影响的具体内容。
请求我明确确认。
只有当我在当前消息中明确说“是”或“确认”后，才能继续。18. 硬停止：这些动作必须明确授权
部署生产、跑数据库迁移、调用外部服务，这些不是“注意点”的问题。
这是必须停下来的地方。
以下动作必须在当前 session 中获得明确确认后才能执行，绝无例外：
- 部署或推送到任何环境，包括 staging、production 等
- 对任何数据库运行 migration 或 schema change
- 发送任何邮件、消息或外部 API 调用
- 执行任何具有不可逆外部副作用的命令
“你之前提到过”不算确认。
我必须在当前消息中明确说“是”或“确认执行”。19. 锁定技术栈
如果没有明确技术栈，Claude 会推荐它觉得流行的框架、它最常见的库、它默认熟悉的包管理器。
有时还行。
更多时候，不是你用的，不是团队会的，也不兼容已有系统。
定义一次技术栈，Claude 就不会乱建议。
技术栈如下，始终使用这些。除非我主动要求，否则不要建议替代方案：
- 语言：【列出】
- 框架：【列出】
- 包管理器：【npm / yarn / pnpm / pip / uv / cargo / 等】
- 数据库：【列出】
- 测试框架：【你的测试工具】
- Linting / formatting：【你的工具】
如果你认为技术栈中某个选择不合适，可以提醒我。
但除非我明确同意，否则仍然使用当前技术栈。20. 编码任务后列出改动
Claude 改完代码后，你常常要自己去查：
哪些文件变了？ 有没有碰别的地方？ 有没有留下没完成的东西？
没有文件级摘要，你每次都在手动 diff。
完成任何编码任务后，结尾必须包含：
- 修改的文件：【列出每个被触碰的文件】
- 修改内容：【每个文件一行说明】
- 有意未修改的文件：【如相关】
- 后续需要：【需要我注意或决定的内容】
保持简短。
这是状态更新，不是长篇复盘。21. 让 Karpathy 那份 CLAUDE.md 爆火的 4 条规则
Andrej Karpathy，前 Tesla AI 总监、OpenAI 创始成员之一，指出过 Claude Code 在编码任务中最容易失败的 4 种行为。
后来有开发者把它们提炼成一个 CLAUDE.md 文件里的 4 条指令。
那个文件冲上 GitHub Trending 第一名，据称把编码准确率从 65% 提升到 94%。
无论你其他配置怎么写，这 4 条都值得放进每个开发者的 CLAUDE.md。
1. 先问，不要猜。
如果需求、意图、架构或约束有任何不清楚或未说明的地方，在写任何代码前先提问。
绝不要默默假设用户意图、系统架构或需求细节。
2. 先用最简单可行方案。
始终先实现能工作的最简单方案。
不要添加没有被明确要求的抽象层、扩展性、复杂架构或额外灵活性。
3. 不碰无关代码。
如果某个文件或函数不是当前任务的直接组成部分，不要修改它，即使你认为它可以被改进。
4. 明确标出不确定性。
如果你对某个方法、库行为或技术细节没有把握，必须在继续前说明。
没有确定性的自信，比承认知识缺口更危险。最后
CLAUDE.md 不只是开发者工具。
它是任何重度 Claude 用户都应该在第一次认真使用前设置好的永久指令文件。
1 到 4 条，修正 Claude 的沟通方式。 5 到 8 条，防止它改你没授权的东西。 9 到 11 条，给它足够上下文，让输出贴合你的真实工作。 12 到 15 条，给它接近长期记忆的能力。 16 到 21 条，则是给开发者准备的护栏，让 Claude Code 像精确工具，而不是不可预测的代码库炸弹。
别想着一次写完所有。
创建文件。 先贴 3 条。 用着用着，再逐步增加。
真正的效率提升，不来自下一句神奇 prompt。
而来自你终于让 Claude 记住：你是谁，你怎么工作，以及什么绝对不能乱碰。
最后：
Agent 垂直技术社区，欢迎活跃、内容共建。
更多推荐
9
0- 0
已为社区贡献62条内容
所有评论(0)