Claude Code 用了几个月最大的感受不是它能写多少代码而是它会用力过猛。你给它一句模糊需求它能自己脑补出一个完整方案顺带把无关文件也改掉你给它塞一整片项目代码它反而写出来的东西更不可靠。问题通常不在模型能力而在于我们对它的使用方式还停留在丢需求、等结果的阶段。Claude Code 可以自动读文件、执行命令、修改代码这种能力一旦被浪费就会变成低效和返工。这篇文章想把我在实际项目里总结出来的 8 条黄金法则完整拆开每条都讲清楚背后的原因和具体操作手法适合刚开始接触 Claude Code 的新手也适合已经用了一阵子但总觉得效率忽高忽低的人。1. 法则一让 Claude 先给计划而不是先给代码1.1 为什么模型容易自作主张Claude Code 的默认行为是尽快完成任务。当你直接说把这个接口优化一下它不会反问你要优化什么而是会基于自己的理解开始动手。它可能假设你要兼容旧版本、顺手重构错误处理、甚至把测试文件也一起改掉。这不是模型不聪明而是它缺少足够的约束信息。我在一次项目里让 Claude Code 调整某个分页接口原文只有一句改成游标分页别太复杂。结果它一口气改了四个文件接口、数据访问层、前端参数解析、还有测试夹具。前三个改动方向是对的但测试夹具改法完全违背了现有测试约定最后花了不少时间才还原。如果当时先让它给一个实施计划这一个小时完全可以省下来。1.2 一个可复用的任务描述模板现在我几乎不会直接说帮我改代码而是先用自然语言描述清楚任务的背景和约束然后要求它只输出计划不写代码。模板大致是这样的任务背景XX模块目前使用 offset/limit 分页需要改成 cursor 游标方式。 约束 - 不能改数据库表结构 - 旧接口需要保留一层兼容 - 完成后必须通过现有测试 请先给出实施计划不要写代码。计划里请列出 1. 涉及的文件夹和主要函数 2. 改动顺序 3. 可能的风险点这样做的原因很简单模型在计划阶段暴露出来的理解偏差修起来成本极低——你只需要在对话里纠正它然后再让它按修正后的计划执行。一旦它开始写代码错误就会散布到多个文件里排查和回滚都麻烦。1.3 什么场景可以跳过规划不是所有任务都值得走一遍完整计划流程。如果任务只有一行命令、只涉及单一文件、或者风险很低我一般直接让它动手。比如把 README 里的安装命令改成 pnpm这类操作没必要先等一份计划。判断标准是如果任务改动的文件数量可能超过两个或者涉及数据库、外部服务、权限配置我会强制先计划。2. 法则二把 CLAUDE.md 当操作规则库来维护2.1 新开会话等于失忆记忆全靠它Claude Code 每次新开会话都会重新认识这个项目。它不会天然知道你习惯用 pnpm 还是 npm不会知道哪些目录不能乱动也不会知道提交前必须跑什么校验。很多人以为模型已经理解了代码其实它理解的只是当前会话里出现过的片段。CLAUDE.md 就是用来解决这个问题的。它相当于给每个新会话一份项目的值班手册。官方提供的 /init 命令可以生成一个初始版本但初始版本通常偏向项目介绍真正好用还得靠你自己持续写。2.2 写规则的五条具体建议第一规则要写成命令式不要写成散文。不要写项目使用 pnpm 作为包管理器而应该写安装依赖使用 pnpm install禁止使用 npm install。模型对明令禁止的识别能力比对描述的推断能力强得多。第二把构建、测试、格式化的命令直接写死。每次让 Claude Code 运行测试时它不需要自己去猜命令直接读取 CLAUDE.md。第三明确边界。比如禁止修改 src/vendor 目录下的任何文件所有的数据库迁移文件都要同时更新 CHANGELOG。这些是你踩坑后的血泪教训一定要沉淀进去。第四控制篇幅。CLAUDE.md 不是开发文档它应该短小到模型每次都能完整记住。如果超过几百行相当于没有重点。第五定期维护。每当你发现 Claude Code 犯了一个低级错误并且原因是它不知道某个项目约定时就把这条约定补进去。2.3 用 /init 起步后期按需维护第一次使用 /init 生成的文件往往包含项目描述、技术栈、命令说明这些作为底子没问题。但我的习惯是删掉其中感叹式的介绍只留下可执行的规则。下面是我某个项目 CLAUDE.md 的大致模样# 项目规则 - 包管理一律使用 pnpm不要使用 npm 或 yarn - 测试命令pnpm test - 类型检查pnpm typecheck - 提交前必须同时跑通 test 和 typecheck - 禁止修改 public/vendor 下的文件 - 新增接口必须添加 OpenAPI 注释 - 数据库结构变更必须同步迁移脚本和文档这份文件我维护了大概两个星期之后 Claude Code 在新会话里的表现明显稳定了一个档次。它不会再反复问测试怎么跑也不会再试图改动那些不该动的目录。3. 法则三管理上下文靠引导式探索不靠堆文件3.1 上下文越长注意力越分散很多人的第一反应是让 Claude Code 读整个项目觉得信息越多理解越准确。实际效果恰恰相反。模型处理长上下文时注意力会被大量无关代码分散真正关键的那几行反而不容易被关注到。同时token 消耗也在快速增长。你为整库阅读付出的钱很多都花在了浏览日志、配置文件、第三方依赖这些无关信息上。我在一次大型重构里把整个仓库的文件树和核心模块代码一次性交给了 Claude Code。结果它做了非常多看起来合理但错误的判断为了兼容某一段根本不会走到分支额外加了一层抽象。后来我换成了引导式探索让模型自己找相关文件问题立刻消失了。3.2 引导式探索的完整流程推荐的做法是让 Claude Code 自己使用工具去查找而不是你手动粘贴文件内容。步骤大致如下先用目录树和 glob 找到项目结构了解整体模块分布。用 grep 定位与任务相关的关键字比如某个函数名、某个配置项。只让模型 View 真正相关的文件片段。如果任务跨多个模块分批查看而不是一次性全部打开。例如我想让 Claude Code 修改消息队列的消费逻辑会这么描述请先用 grep 找到消费入口文件的定义并查看与消息处理相关的函数。 不要读取整个 repository。目标是理解消息从进入到处理完成的链路。这样做看起来多了一步实际反而快。因为模型没有被海量无关信息淹没每个问题都能精准定位token 消耗也明显下降。3.3 什么时候才适合粘贴大文件有一种场景值得把完整文件直接喂给模型就是这个文件本身就是任务的核心而且你不希望它漏掉任何细节。比如修改一个加密工具类或者一个只有几百行的关键服务。但要注意喂完整文件不等于喂整库。我还会在描述里明确只处理这个文件其他文件不要动避免模型产生过度打开其他文件的冲动。下表是我个人对两种方式的对比方式上下文纯度token 消耗改动精准度适用场景整库粘贴低大量无关代码干扰高容易波及无关模块极少使用引导式探索高只暴露相关文件低高改动集中大多数任务单文件完整喂给中可能有少量依赖缺失中中需要模型自行推断核心小文件修改4. 法则四一次只改一件事并配套小步提交4.1 大改一次的成功率远低于小步迭代让 Claude Code 一次完成多个任务看起来省时间实际是给自己埋雷。模型在单个任务上的表现要好得多混在一起时它会因为不同任务之间的隐性冲突做出奇怪的决定。比如你让它同时优化错误处理和重构数据模型它可能为了错误处理而随意改变数据模型的边界结果两边都没做好。我试过让 Claude Code 一次性升级整个认证模块包括修改 token 生成、刷新逻辑、权限校验。改了大概八百行我检查的时候觉得每个局部都合理但合并后跑测试却出现一堆莫名其妙的失败。后来我把同样的改动拆成三个小任务分三次提交每次验证后再进行下一步整个过程反而更顺畅。4.2 提交节奏怎么定我会在每个逻辑单元完成后让它停下来自己跑一遍测试和类型检查然后人工看一眼 diff。确认没问题后提交提交信息要明确写清楚这次改动的边界。再继续下一个逻辑单元。这种节奏下任何一个环节出了问题都能清楚地知道是哪个改动引入的回滚也只是git revert一个小提交。这里的核心逻辑是降低单次变更的复杂度和风险边界。对 Claude Code 来说小步走同样有效因为它每一次改动的范围越小越不容易产生与现状相冲突的假设。4.3 限制 Claude 不乱动无关代码模型有一种天然的倾向就是顺手优化。你在让它修一个 bug它发现旁边有一行代码风格不符合规范就顺手改了。单独看这个改动也许没错但它会污染你的 diff也会给 review 增加负担。更麻烦的是如果它顺手改的代码里有隐藏的业务逻辑可能导致难以察觉的行为变更。我的解决办法是在任务描述里明确写一句只修改与任务直接相关的文件不要做任何额外重构或格式调整。如果它在结果里仍然动了无关代码我会直接要求它还原那些改动。这不是不信任模型而是保持 diff 可审查性的必要约束。5. 法则五用自动化测试当验收标准省去无休止的手工确认5.1 模型代码最容易犯看起来对的错误Claude Code 生成的代码有两个常见陷阱第一代码能跑通但没有覆盖边界条件第二代码在某个分支下正确但在另一个分支下会崩溃。人工 review 的时候很容易被代码的结构欺骗觉得写得很完整应该没问题。真实情况是模型对业务需求的理解可能只是表面真正的验证只能靠测试。我在某个项目里让它写过一个解析数据的工具它顺利生成了主流程单元测试也显示通过。但我在测试用例里补充了空字符串、异常编码、超大输入这些边界情况下它立刻露出了很多问题。此前那些没有覆盖边界的测试根本不足以证明代码可靠。5.2 先测试后实现的执行顺序现在我会尽可能让 Claude Code 先写测试再写实现。流程是这样的先用自然语言描述期望的行为让 Claude Code 生成测试用例。人工审查测试用例是否正确比如断言是否是真正需要的、有没有遗漏边界场景。确定测试无误后再让 Claude Code 实现功能目标是让测试通过。每次修改后运行测试用测试结果作为验收标准。这么做的好处是模型在写测试的过程中会加深对需求的理解实现阶段犯错的概率会降低。而且当测试失败时你能获得具体的失败信息不再是模棱两可的我觉得没问题。5.3 失败日志是最高效的排错材料当测试失败时不要只把错误信息复制给 Claude Code然后说你又写错了。更好的做法是把完整的失败日志、相关代码片段以及你的预期行为一起给它。模型擅长基于错误信息进行推理但如果你只给出断言失败它可能反复在一个小问题上打转。我还会给 Claude Code 设置修复次数的上限。比如让它尝试最多三次修复如果三次之后测试还是不过就停下来。这时候不要继续让它修而是重新整理思路可能是任务描述本身就有问题也可能是上下文里缺少某个关键约束。无限循环修复不仅浪费 token还会不断污染上下文。6. 法则六把反复出现的流程固化成脚本或命令6.1 自然语言描述流程不可靠Claude Code 可以执行命令但前提是它必须知道这条命令具体是什么。如果你每次都通过自然语言描述启动本地开发环境先设置环境变量再迁移数据库然后填充种子数据最后启动服务模型需要理解一长串流程。只要其中一步理解有偏差整个流程就会中断。更可靠的方式是把这些流程固化成脚本让 Claude Code 只需要知道一个命令名。比如把那套开发环境启动流程写进Makefile或package.json的 scripts 里命名为make dev。这样模型只需要执行make dev不需要猜测流程中的每个细节。6.2 什么值得抽成脚本我一般看两个标准第一这个操作在我的日常开发中重复出现比如测试、构建、启动服务、格式化第二操作步骤超过两步或者依赖环境变量和参数。符合这两个标准的我都会抽成脚本。最典型的例子是一键还原测试环境。这件事包括删除数据库、重新迁移、填充测试数据、启动测试服务。最初 Claude Code 每次都要我解释一遍后来我写了一个scripts/reset-test-env.sh它只需要执行这个脚本效率和稳定性都提升了一个档次。6.3 让 CLAUDE.md 记住这些脚本脚本写好之后一定要在 CLAUDE.md 里登记。比如- 重置测试环境bash scripts/reset-test-env.sh - 启动开发环境make dev - 运行全量测试pnpm test这样 Claude Code 在新会话里会直接读取这些命令。它不需要再问测试用什么命令跑也不会擅自创造一个不同参数的新命令。脚本名字本身要足够直白避免让模型去猜scripts/cleanup.sh是干什么的。7. 法则七控制 token 消耗学会拆分会话与善用子代理7.1 一次长会话让成本和效果同时失控Claude Code 的会话会累积上下文。前半段讨论的结论、中间犯过的错误、最后被丢弃的方案都会进入下一次请求的上下文窗口。这意味着会话越长每次请求携带的历史信息越多费用越高。同时这些历史信息中包含了大量旧错误模型推理时容易被污染导致越到后面越迟钝。我在一次连续调试中体会很深最初几次请求都正常三十多轮之后模型开始重复出现同一个错误甚至把之前已经讨论过并否决的方案又拿出来。这不是它变笨了而是上下文里残留了太多中间状态的模糊信息。7.2 会话拆分的判断标准如果任务本身是相互独立的就不要放在同一个会话里。比如你要实现三个互不相关的接口最合理的做法是三个独立会话分别处理而不是一个长会话连续做完。判断标准是后一个任务是否依赖前一个任务在上下文里的中间推论。如果不依赖就直接拆。当会话已经变得很长且中途出现了很多无效讨论我会考虑使用 /compact 压缩上下文。压缩后的会话会保留主要结论但剔除大量细节。在继续复杂任务前这个操作很值。下表是我平时决定如何处理会话的场景场景推荐操作3 个功能点互不依赖拆成 3 个独立会话同一个模块的连续重构保留同一个会话但定期压缩排查问题时大量失败尝试失败超过 5 次就新开会话大规模全仓库重构按模块拆会话每个模块独立验证7.3 子代理和 /compact 的用法如果任务里有一些相对独立的子问题比如把某个函数写成独立工具类并测试可以交给子代理执行。子代理有自己独立的上下文空间它产生的中间推理不会污染主会话这在大项目里很有用。主会话只需要接收最终的代码和测试结果。但子代理也不是越多越好。如果任务本身内部耦合很紧强行拆给子代理反而会增加沟通成本。我的判断依据是子问题是否真的可以被隔离。能够隔离就拆不能隔离就留在主会话里处理。8. 法则八合并之前必须人工审查 diff权限越大越要盯8.1 高权限模式下模型能做的事远超预期Claude Code 可以读取文件、修改文件、执行命令甚至自动批准一系列操作。当你启用跳过权限确认的模式后它理论上可以在你的项目里做任何它自己决定做的事。这种能力如果不加约束会产生两个问题一是它可能在你的仓库里留下意想不到的改动二是这些改动往往看起来合理但经不起推敲。我并不是说高权限模式不能用而是说它必须和人工 diff 审查配合使用。你给模型的自由度越高越要对自己看到的最终结果保持警惕。8.2 审查 diff 的具体动作每次让 Claude Code 完成一批改动后我不会直接相信它的总结而是执行这几步检查git status git diff --stat git diff git diff --checkgit status能看出它动了哪些文件如果出现了任务描述之外的文件我会立刻追问原因。git diff --stat能快速判断改动规模如果一次任务改了特别多行我会更加仔细。git diff是逐行审查重点看它为什么修改这些内容而不是它写了什么语法。git diff --check可以发现空白字符错误避免无意义的格式噪音。8.3 发现模型强词夺理时怎么处理有时候你指出某个改动不合理模型会给出看似合理的解释比如这样做是为了兼容旧版本这是为了保持一致性。不要被这种解释完全说服。最有效的验证方法是要求它在 diff 上逐行解释这一行为什么改如果不改会怎样如果它解释不清楚或者解释与实际场景对不上就让它回退。我一般采用这样的流程先让它详细解释改动意图如果解释有说服力则继续如果没有说服力就要求它 revert 那部分代码。至于解释有说服力的判断标准其实就是我是否真正理解了这个改动对业务逻辑的影响。如果我不理解永远不要合并。最近一次比较大的重构里我严格按照这 8 条法则执行了一遍。先写计划再写 CLAUDE.md 规则控制上下文小步提交配上测试把重复命令脚本化拆分会话最后逐行审查 diff。整个过程没有一次返工这在之前几乎不可能做到。最让我意外的是真正节省时间的地方并不是让 Claude 写代码本身而是让它少写错误代码以及让错误在早期暴露这件事。越早让模型给出计划和测试后续的成本就越低。希望这 8 条法则也能给你自己的 Claude Code 工作流带来一些启发。