绝大多数 Claude 用户都忽略的 21 个设置

绝大多数 Claude 用户都忽略的 21 个设置 绝大多数 Claude 用户都忽略的 21 个设置 Modified May 13 每次会话开始时，Claude 先读取这个文件。它就能知道两个月前你为什么做了某个选择，不再反复建议你已经尝试过的方案，而是在既有决定之上继续推进。 Code block Plain Text 维护一个名为 MEMORY.md 的文件。每当我们在方向、格式、内容、方法或策略上做出重要决定后，新增一条记录： [日期]，[决定] 决定了什么： [做出的选择] 为什么： [背后的理由] 放弃了什么： [考虑过哪些替代方案，以及为什么排除] 每次会话开始，在做任何事之前先读取 MEMORY.md。 未经提醒，不得违背已记录的决定。 13 会话结束摘要，不丢进度 你关闭会话，两天后回来，又花 15 分钟翻旧消息，回想之前做到哪里、哪些已经完成、哪些还在进行中。几乎每个经常用 Claude 的人都会遇到这种浪费，但它完全可以避免。 这条指令让 Claude 在你收尾前把会话摘要写入 MEMORY.md。下一次会话会带着完整上下文打开，你可以从上次停止的地方继续，不需要从头重建现场。 Code block Plain Text 当我说 “session end”、“wrapping up”、“let's stop here” 或类似表达时，把会话摘要写入 MEMORY.md： 会话摘要，[日期] 处理了什么： [本次主要关注的内容] 已完成： [已经完成的事项] 进行中： [已经开始但尚未完成的事项] 做出的决定： [本次会话中的关键选择] 下次会话： [下次优先接上的任务，以及需要延续的重要上下文] 14 记录无效方案，避免重复解决同一个问题 你为一段内容尝试某种提示方式，花了四次才得到可用结果。三周后，你又遇到类似任务，Claude 从头开始提出同样糟糕的建议。一样的试错、一样的时间浪费，又重来一遍。 错误日志可以打断这个循环。每个失败方案都被记录下来：尝试了什么、为什么没用、最终什么方法有效。下次 Claude 先查日志，直接避开已知无效路径。 Code block Plain Text 维护一个名为 ERRORS.md 的文件。当某种方法超过 2 次尝试才成功时，记录下来： [任务类型或描述] 哪些方法没用： [失败的方法以及原因] 哪个方法有效： [最终成功的方法] 下次注意： [类似任务值得记住的事项] 在为类似任务提出方案前，先检查 ERRORS.md。 如果当前任务匹配已记录的失败案例，先说明这一点，然后直接采用已验证有效的方法。 15 给 Claude 一组永远不变的事实 每个项目都有永久事实：来自过往决策的限制、出于重要原因存在的规则、无论具体任务如何都始终成立的工作前提。没有这条指令，Claude 不知道这些事实存在，可能随口建议与之冲突的方案，撤销你有意做出的工作，或者让你第 100 次停下来解释同样的背景。 这组内容会成为 Claude 每个会话、每个任务、每次输出都遵守的固定基础。你不必反复解释，Claude 也能在你的真实约束里工作，而不是在某个通用版本的现实里工作。 Code block Plain Text 以下事实始终成立。无一例外地应用到每个会话和每个任务中： [永久事实 1，例如 “我的受众没有技术背景”] [永久事实 2，例如 “所有内容都必须适合专业场景”] [永久事实 3，例如 “没有来源就不做断言”] [永久事实 4，例如 “品牌语气始终温暖，不能有企业腔”] 如果任何任务与这些事实冲突，先提醒我再继续。 不要在不告知我的情况下绕过约束。 给开发者 下面这些指令专门写给使用 Claude Code 编写、审查或管理代码的人。如果你不是开发者，上面的内容已经够用。如果你是，下面这 6 条规则决定了 Claude 是一个可靠的编程助手，还是一个会在代码库里乱开火的工具。 16 严守范围，不碰没有被要求处理的内容 你让 Claude 修一个 bug，它可能重构三个文件、重命名变量、重排 import，并且顺手“优化”你已经用了几个月的代码，全程不问你。有些改动会直接破坏功能，有些会引入很隐蔽的差异，几天后才排查出来。 这是所有 Claude Code 用户最重要的规则之一。范围控制决定了它是一个精确工具，还是代码库里的不稳定因素。 Code block Plain Text 只修改与当前任务直接且明确相关的文件、函数和代码行。 不要重构、重命名、重组、重新格式化或“优化”任何我没有明确要求修改的内容。 如果你在其他地方发现值得修的问题，可以写在备注里。 不要动它。永远不要。 17 任何破坏性操作前必须确认 Claude Code 在你的终端里运行，可以访问文件系统。它可能删除文件、覆盖函数、删除数据库表，而且不会犹豫，因为它认为这是你要求它做的事，即使你并没有完全意识到自己指令的后果。一次误读，就可能让几个小时的工作没有回退路径。 这条规则把每个破坏性动作都变成检查点。Claude 停下来，列出会受影响的内容，等你明确说可以后再继续。 Code block Plain Text 在删除任何文件、覆盖现有代码、删除数据库记录、移除依赖，或执行任何无法轻易撤销的改动之前，必须完全停下来。 列出会受影响的具体内容。 请求明确确认。 只有在我于当前消息中明确同意后，才能继续。 18 硬性停止项：没有明确许可绝不执行 部署到生产环境、在真实数据库上跑迁移、向外部服务发送 API 请求，这些不是“谨慎一点”就可以的场景，而是必须让你清醒在场、明确说可以的完整停止点。这条规则为这些动作建立永久边界。 Code block Plain Text 以下操作在执行前必须获得当前会话中的明确确认，没有例外： 部署或推送到任何环境，包括 staging、production 等 在任何数据库上运行迁移或 schema 变更 发送任何邮件、消息或外部 API 调用 执行任何带有不可逆外部副作用的命令 “你之前提到过这件事”不构成确认。 我必须在当前消息中明确说可以。 19 锁定你的技术栈 如果没有定义技术栈，Claude 会推荐它认为最流行的框架、它最常见的库，以及它默认偏好的包管理器。有时候没问题，但经常并不是你在用的东西，也不是团队熟悉的东西，更不一定兼容已经构建好的系统。 一次性定义技术栈，Claude 就会停止建议你不想要的东西。它写出的内容也会贴合你实际在构建的系统。 Code block Plain Text 技术栈，始终使用这些，除非我要求，否则不要建议替代方案： 语言：[列表] 框架：[列表] 包管理器：[npm / yarn / pip / cargo / 等] 数据库：[列表] 测试：[你的测试框架] Lint / 格式化：[你的工具] 如果技术栈中的某个选择看起来不合适，可以提醒我。 但除非我另行说明，否则仍然按这个技术栈执行。 20 始终明确展示改动了什么 Claude 完成任务后，你经常要自己扫一遍输出才能弄清差异。哪些文件变了？有没有动到别的地方？有没有留下未完成事项？没有文件级别的变更说明，每次让 Claude 做事，你都在手动做 diff。 Code block Plain Text 完成任何代码任务后，始终在末尾给出： 修改的文件：[列出所有被触碰的文件] 修改内容：[每个文件一行说明] 有意未触碰的文件：[如相关] 需要跟进：[任何需要我注意或决策的事项] 保持简短。这是状态更新，不是复盘。 21 让 Andrej Karpathy 的 CLAUDE.md 走红的 4 条规则 Andrej Karpathy 曾任 Tesla AI 总监，也是 OpenAI 创始成员之一。他指出了 4 类会让 Claude Code 在编程任务中失败的具体行为。一位开发者把它们提炼成 4 条指令，写进一个 CLAUDE.md 文件。这个文件登上 GitHub Trending 第 1 名，并把编码准确率从 65% 提升到 94%。 下面就是这 4 条规则。无论你的 CLAUDE.md 里还有什么，每个开发者都值得把它们加进去。 Code block Plain Text 1. 先问，不要假设。 如果某件事不清楚或需求不完整，先提问，再写第一行代码。 不要默默假设用户意图、架构设计或需求细节。 2. 优先采用最简单的可行方案。 始终先实现能够工作的最简单方案。 不要添加未被明确要求的抽象层、额外结构或弹性设计。 3. 不碰无关代码。 如果某个文件或函数不是当前任务的直接组成部分，不要修改它，即使你认为它可以被改进。 4. 明确标出不确定性。 如果你对某个方案、库的行为或技术细节没有把握，先说清楚再继续。 没有确定性的自信，比承认信息缺口更容易造成损害。 CLAUDE.md 不只是开发者工具。它是一个永久指令文件，任何认真使用 Claude 的人，都应该在第一次真正开始工作前配置好它。 第 1 到第 4 条修正 Claude 的沟通方式。第 5 到第 8 条阻止它修改你没有授权的内容。第 9 到第 11 条给它足够上下文，让输出贴合你的真实工作。第 12 到第 15 条让它拥有接近真实记忆的连续性。第 16 到第 21 条面向希望 Claude Code 表现得像精确工具、而不是不可预测工具的开发者。 创建这个文件。先粘贴 3 条指令。之后边用边加。 关注 @AnatoliKopadze，获取更多真正改变 AI 工作方式的系统。 @AnatoliKopadze 每次会话开始时，Claude 先读取这个文件。它就能知道两个月前你为什么做了某个选择，不再反复建议你已经尝试过的方案，而是在既有决定之上继续推进。 13 会话结束摘要，不丢进度 你关闭会话，两天后回来，又花 15 分钟翻旧消息，回想之前做到哪里、哪些已经完成、哪些还在进行中。几乎每个经常用 Claude 的人都会遇到这种浪费，但它完全可以避免。 这条指令让 Claude 在你收尾前把会话摘要写入 MEMORY.md。下一次会话会带着完整上下文打开，你可以从上次停止的地方继续，不需要从头重建现场。 14 记录无效方案，避免重复解决同一个问题 你为一段内容尝试某种提示方式，花了四次才得到可用结果。三周后，你又遇到类似任务，Claude 从头开始提出同样糟糕的建议。一样的试错、一样的时间浪费，又重来一遍。 错误日志可以打断这个循环。每个失败方案都被记录下来：尝试了什么、为什么没用、最终什么方法有效。下次 Claude 先查日志，直接避开已知无效路径。 15 给 Claude 一组永远不变的事实 每个项目都有永久事实：来自过往决策的限制、出于重要原因存在的规则、无论具体任务如何都始终成立的工作前提。没有这条指令，Claude 不知道这些事实存在，可能随口建议与之冲突的方案，撤销你有意做出的工作，或者让你第 100 次停下来解释同样的背景。 这组内容会成为 Claude 每个会话、每个任务、每次输出都遵守的固定基础。你不必反复解释，Claude 也能在你的真实约束里工作，而不是在某个通用版本的现实里工作。 给开发者 下面这些指令专门写给使用 Claude Code 编写、审查或管理代码的人。如果你不是开发者，上面的内容已经够用。如果你是，下面这 6 条规则决定了 Claude 是一个可靠的编程助手，还是一个会在代码库里乱开火的工具。 16 严守范围，不碰没有被要求处理的内容 你让 Claude 修一个 bug，它可能重构三个文件、重命名变量、重排 import，并且顺手“优化”你已经用了几个月的代码，全程不问你。有些改动会直接破坏功能，有些会引入很隐蔽的差异，几天后才排查出来。 这是所有 Claude Code 用户最重要的规则之一。范围控制决定了它是一个精确工具，还是代码库里的不稳定因素。 17 任何破坏性操作前必须确认 Claude Code 在你的终端里运行，可以访问文件系统。它可能删除文件、覆盖函数、删除数据库表，而且不会犹豫，因为它认为这是你要求它做的事，即使你并没有完全意识到自己指令的后果。一次误读，就可能让几个小时的工作没有回退路径。 这条规则把每个破坏性动作都变成检查点。Claude 停下来，列出会受影响的内容，等你明确说可以后再继续。 18 硬性停止项：没有明确许可绝不执行 部署到生产环境、在真实数据库上跑迁移、向外部服务发送 API 请求，这些不是“谨慎一点”就可以的场景，而是必须让你清醒在场、明确说可以的完整停止点。这条规则为这些动作建立永久边界。 19 锁定你的技术栈 如果没有定义技术栈，Claude 会推荐它认为最流行的框架、它最常见的库，以及它默认偏好的包管理器。有时候没问题，但经常并不是你在用的东西，也不是团队熟悉的东西，更不一定兼容已经构建好的系统。 一次性定义技术栈，Claude 就会停止建议你不想要的东西。它写出的内容也会贴合你实际在构建的系统。 20 始终明确展示改动了什么 Claude 完成任务后，你经常要自己扫一遍输出才能弄清差异。哪些文件变了？有没有动到别的地方？有没有留下未完成事项？没有文件级别的变更说明，每次让 Claude 做事，你都在手动做 diff。 21 让 Andrej Karpathy 的 CLAUDE.md 走红的 4 条规则 Andrej Karpathy 曾任 Tesla AI 总监，也是 OpenAI 创始成员之一。他指出了 4 类会让 Claude Code 在编程任务中失败的具体行为。一位开发者把它们提炼成 4 条指令，写进一个 CLAUDE.md 文件。这个文件登上 GitHub Trending 第 1 名，并把编码准确率从 65% 提升到 94%。 下面就是这 4 条规则。无论你的 CLAUDE.md 里还有什么，每个开发者都值得把它们加进去。 CLAUDE.md 不只是开发者工具。它是一个永久指令文件，任何认真使用 Claude 的人，都应该在第一次真正开始工作前配置好它。 第 1 到第 4 条修正 Claude 的沟通方式。第 5 到第 8 条阻止它修改你没有授权的内容。第 9 到第 11 条给它足够上下文，让输出贴合你的真实工作。第 12 到第 15 条让它拥有接近真实记忆的连续性。第 16 到第 21 条面向希望 Claude Code 表现得像精确工具、而不是不可预测工具的开发者。 创建这个文件。先粘贴 3 条指令。之后边用边加。 关注 @AnatoliKopadze，获取更多真正改变 AI 工作方式的系统。 @AnatoliKopadze 原文链接：https://x.com/AnatoliKopadze/status/2050225292585607440 一个单独的 CLAUDE.md 文件刚刚登上 GitHub Trending 第 1 名，获得了 82,000 个 star 和 7,800 次 fork。 大多数 Claude 用户甚至没听说过它。听说过的人，也常常不知道到底该往里面写什么。 这个差距，正在让很多人每周白白耗掉好几个小时。 每次你开启一个新的 Claude 会话，它都是从零记忆开始的。它不知道你的名字、你的工作、你的偏好，也不知道你希望事情以什么方式完成。你要么先花几分钟重新解释一遍所有背景，要么不解释，然后 Claude 给出的东西就和你真实的工作方式对不上。CLAUDE.md 可以一次性解决这个问题。 为什么这对每个人都重要，而不只是开发者 很多人以为 CLAUDE.md 是开发者工具。其实不是。它是一个指令文件，Claude 会在每次会话开始时自动读取；只要你经常使用 Claude，它就适用。 写作者用它固定自己的声音和语气，让 Claude 不再写得像另一个人。营销人员用它定义受众，让 Claude 不再输出泛泛而谈的文案。研究人员用它约定信息结构。企业主用它把公司的完整背景交给 Claude，让每一次输出都贴合真实业务。 没有 CLAUDE.md，你每一轮会话都在从零开始。你会反复解释自己，反复纠正同样的错误，第 100 次说明自己的偏好。 不管你用 Claude 做什么，只要是认真工作，CLAUDE.md 都应该是你最先配置的东西。 如何创建这个文件：2 分钟就够 1. 打开你的项目文件夹，新建一个文件。文件名必须准确写成 CLAUDE.md：大写字母、没有空格。它只是一个带 .md 扩展名的纯文本文件。 2. 用任意文本编辑器打开它：记事本、TextEdit、VS Code，或者你平时用的编辑器都可以。把你的指令直接以纯文本形式粘进去。 3. 从本文中复制对你有用的指令。粘贴进去。不需要一次性写满 21 条，先从最让你困扰的 3 到 4 个问题开始。 4. 保存文件。之后你每次在这个文件夹里打开 Claude Code 会话，Claude 都会自动读取它。不需要额外设置，也没有额外步骤，从第一条消息开始生效。 Claude 如何与你对话 1 去掉客套填充 Claude 默认会用 “Great question!”、“Of course!”、“Certainly!”、“Absolutely!” 这类句子开头。这些话没有信息量，只会浪费时间。当你每天连续使用 Claude 好几个小时时，这种摩擦会不断累积。 一条指令就能永久去掉它。每个回答都直接从答案开始。没有热场，没有“我很乐意帮忙”的表演，只有你真正要的信息。 2 动手前先给出选项 Claude 默认会选一个思路，然后直接一路做下去。你让它改写一个段落，它可能把整篇文章的语气都改掉。你让它重构一份文档，它可能按一种并不符合你思考方式的逻辑重新组织。结果你又要去修正那些自己并没有要求它改的东西。 这条指令会彻底改变这种互动方式。在任何重要任务开始前，Claude 先给你 2 到 3 种处理路径。你选择最合适的方向。接下来产出的内容才会更接近你真正想要的结果。 3 不知道时要诚实说明 Claude 有时会给出一个自信、详细、但完全错误的答案，而不是承认不确定。它会用听起来很合理的信息来补空白，包括日期、统计数据、引用和事实。这些内容看起来像真的，但并不一定是真的。等你把这些信息用到关键场景里，问题才会暴露出来。 这一条指令会改变这种行为。Claude 会在回答前先标出不确定性，而不是把不确定藏在自信的表达里。回答一开始出现“这一点我不确定”，比你基于不存在的事实继续推进要安全得多。 4 回答长度匹配真实需求 问 Claude 一个简单问题，它可能写四段。让它做一个复杂任务，它又可能给出一个看似完整、实则很浅的框架。两种都不好用。回答长度应该与任务本身匹配：答案本来就短，就短；任务需要深度，就给足细节。 这条指令用来校准这种关系。简单问题不再被填充成大段文字，需要实质深度的工作也不再被压成浅层输出。 Claude 的行为边界 5 做大改动前先询问 你让 Claude 修一段文字，它可能重写整篇文档。你让它缩短内容，它可能删掉你需要的章节。你让它调整语气，它可能连结构也一起改了。每一次，你都会失去一些并不想失去的内容，然后不得不凭记忆或旧版本重建。 这条指令会把每一次重要改动变成一个检查点。Claude 停下来，明确告诉你它准备改什么、为什么改，然后等你确认后再动手。后续产出才是你同意过的工作。 6 只聚焦我提出的需求 你让 Claude 修一个问题，它可能顺手“优化”另外五个地方：调整措辞、重组结构、改写你本来满意的句子。有时这些改动确实更好，但很多时候并不是。现在你还得逐一检查到底哪里被改过。 这条指令让 Claude 保持在任务范围内。只修你要求它修的东西，其他内容原样保留。如果它发现别处也值得处理，可以提出来，但不能在没有明确要求的情况下直接动手。 7 始终告诉我改了什么 Claude 做完任务后，你经常要自己扫描输出，弄清它和原来有什么不同。哪些章节变了？有没有删掉内容？有没有加入你没要求的东西？没有变更说明，你每次都在手动做 diff。 这条指令要求 Claude 在每个任务结束时给出简短状态：改了什么、哪些没动、哪些需要你注意。这样你仍然掌控自己的工作。 8 未经确认，不要替我执行外部动作 随着 AI 工具连接到邮箱、日历、社交账号和文档，Claude 执行非本意操作的风险会随着每一种集成而上升。发送消息、发布内容、共享文档、安排日程，这些操作都会产生真实后果，而且发生得很快。 这条指令建立一条硬边界。无论 Claude 认为你想做什么，只要会对会话之外产生影响，就必须在当前时刻得到你明确同意后才能执行。 你的上下文 9 告诉 Claude 你是谁、你懂什么 Claude 不知道你是专家还是新手，是创始人还是自由职业者，也不知道你想要技术深度还是通俗表达。没有这些上下文，它只能猜，而且猜对和猜错的概率差不多。有时它会解释你早就熟悉的基础知识；有时又会跳过你真正需要的背景。 一段关于你自己的说明，可以校准 Claude 从那之后给你的每一个回答。它不再把你当陌生人，而是开始像了解你的人一样与你协作。 10 给 Claude 你正在做的工作的背景 每次新会话开始时，Claude 都不知道你在做什么、不知道内容面向谁，也不知道真正重要的约束是什么。它给出泛泛的输出，是因为它没有别的依据。它不知道你的受众、目标，也不知道塑造你每个决定的限制条件。 一小段项目背景会改变很多。建议不再泛泛而谈，而是开始贴合你的真实情况。Claude 会知道内容写给谁、什么语气合适，以及哪些取舍对你最重要。 11 固定你的声音和风格 Claude 有自己的默认写作风格。它不差，但也不是你的风格。它会使用某些固定表达，以特定方式组织句子，语气也不一定符合你的真实表达方式。每次你用 Claude 写东西，最后都要再把它改回自己的声音。 在 CLAUDE.md 里一次性定义你的声音，Claude 从第一版开始就能尽量贴近。后期编辑更少，产出也更像你本人。 记忆与连续性 12 让 Claude 维护一个记忆文件 Claude 在会话之间会忘记一切。每次对话都是重新开始。但 Claude 可以写文件，而文件可以长期存在。这条指令让 Claude 维护一个 MEMORY.md 文件，记录你们共同做出的重要决定：决定了什么、为什么这样决定、考虑过但放弃了哪些替代方案。