用 Claude Code 写代码上手门槛很低真正用好的人却不多。多数人打开终端敲下claude丢一句“帮我优化一下登录接口”然后盯着屏幕看它忙活半天拉出git diff才发现它把不该碰的模块也改了或者改出来的代码跟项目现有风格完全不是一回事。这不是模型不行是你还没掌握使用它的正确方式。Claude Code 本质上是一个跑在终端里的 AI 编程代理能读项目结构、定位文件、批量修改代码、执行命令、看测试结果能力上限非常高。但它的输出质量高度依赖三样东西你给它的信息、你给它的边界、你建立的验证节奏。我在不同规模的项目里持续用了相当长时间从最开始被它带偏、反复回滚到后来形成一套稳定可复制的工作流最后沉淀下来的就是 8 条黄金法则。这篇文章不整虚的每条法则都会讲清楚解决什么问题、背后是什么逻辑、具体怎么落地。1. 规则一把需求嚼碎了再交给它1.1 一句话需求是翻车的根源大型语言模型本质上是概率预测器不是读心术师。“优化登录模块”这句话在不同项目里可以有十几种理解是改性能改用户体验修 Bug换算法还是统一代码风格信息越模糊模型的猜测空间越大最终产出就越不可控。我刚开始用的时候特别喜欢偷懒一句话甩过去结果它给我改了一堆文件把接口响应结构变了连带改了前端调用还顺手重构了一个根本不用动的工具函数。单看每一处改动都说得通合在一起就是一场灾难。从那以后我给自己定了一条死规矩凡是超过 5 分钟的任务必须把需求写清楚再交给它。1.2 一条好提示词必须包含的四个要素我把完整的任务描述拆成四块缺一不可目标要产出什么结果。不是“优化”而是“将登录接口的超时时间从 30 秒调整为 60 秒并记录超时日志”。范围明确允许修改哪些路径明令禁止触碰哪些路径。比如“只改动src/auth/login.ts不要动前端页面和数据库表结构”。约束沿用什么风格、能不能引入新依赖、是否需要兼容旧接口。比如“保持现有函数签名不变继续使用项目已有的日志工具不要新增 npm 包”。验收标准任务怎么算完成。比如“执行npm run test:unit全部通过Diff 文件数不超过 3 个”。这四个要素写进提示词模型的自由度被收窄到一个可控范围产出的质量稳定性会立刻提升一个档次。1.3 一个可以直接抄的任务模板如果你懒得每次重新组织语言直接套这个结构任务修复 [具体文件] 中 [具体问题] 背景目前的现象是 [现状]期望行为是 [目标效果] 约束只修改 [路径]不调整 [无关模块]保持 [既有约定] 完成标准执行 [具体命令] 通过并输出所有修改文件的清单和摘要举个例子“修复src/utils/formatDate.ts中月份从 0 开始导致显示错误的问题。目前getMonth()返回值比实际月份小 1期望格式化后月份显示为 1-12。只修改该文件内部逻辑不改函数签名。完成后运行npm test并列出改动摘要。” 这样的提示词Claude Code 基本不会跑偏。2. 规则二管好上下文窗口别让它读太多没用的东西2.1 上下文窗口是有限资源Claude Code 的每一次对话都会把历史消息、读取过的文件内容、工具返回结果累计进上下文。上下文窗口再大也有上限而且不是越大越好——关键信息会被无关内容稀释模型反而容易“忘了”你最开始强调的约束。最典型的反面操作是上来一句“先读一下整个项目了解一下结构”然后放任它在项目里疯狂搜索。小项目还好中大型项目动辄几千个文件它可能把无关模块的源码全塞进上下文之后你让它改某个函数时它记得的可能是被无关代码淹没之后的“混合印象”。2.2 CLAUDE.md 是项目记忆的最好载体Claude Code 有个机制会自动读取项目根目录下的CLAUDE.md文件把它当作全局指令。这个文件就是给 AI 看的项目记忆也是最值得养成的习惯。我通常在CLAUDE.md里放这些内容项目简介与技术栈框架、语言版本、包管理器构建、测试、Lint 的完整命令目录结构的关键职责比如src/api是接口层src/shared是公共组件代码风格约定缩进、单引号还是双引号、命名规范已知禁区比如“不要修改db/migrations下已提交的迁移脚本”“不要用any类型”只要把这份文件维护好每次开启新会话时Claude Code 就等于自带项目记忆不需要你在提示词里反复重复基础背景。2.3 一个会话只干一件大事别在一轮对话里连续塞好几个不相关任务“帮我改完登录接口顺便把首页样式调一下再写个 README。”每切换一次任务模型都要重新理解目标且前面的任务上下文会持续占用窗口后面任务的质量往往明显下降。我的做法是一个会话只围绕一个任务。任务做完了就/clear清空上下文重新开一个干净会话做下一件事。如果中途发现方向错了别将就着继续聊直接clear换思路重来代价远小于在错误上下文里硬掰。提示/clear清空的是对话历史不会删除已修改的文件。清空之前只要确认代码已落盘就没什么好担心的。3. 规则三大改动先走 Plan 模式再进 Build 模式3.1 两种模式的分工Claude Code 有 Plan 和 Build 两种核心模式。Plan 模式只做分析和规划读代码、梳理依赖、给你输出一套详细的实施方案但不会修改任何文件。Build 模式才是真正动手写代码、执行命令的模式。很多人不知道这个区别上来就 Build等于蒙着眼睛让 AI 开车。尤其是跨文件的重构、新功能开发这类复杂度高的任务AI 很可能在第一步就选错了架构方向然后一路错到底等你发现时已经改了十几个文件。3.2 评审 AI 方案时的检查清单Plan 模式输出方案后你要像评审同事的设计文档一样去审它它列出的影响文件清单是否符合预期有没有漏掉你在提示词里强调的约束实施步骤的先后顺序是否合理方案里有没有包含验证步骤还是只写了“改代码”有没有试图引入不必要的依赖或重写不该动的模块如果方案里有任何一点让你觉得不对劲直接指出来让它修正不要带着隐患进入 Build。3.3 从计划到落地的衔接方法我现在的大任务标准流程是在 Plan 模式下让它输出编号步骤。我自己逐条确认必要时让它修改方案。确认无误后切到 Build 模式让它“严格按上述方案的第 1 步执行完成后停下等待确认”。每完成一步就检查、测试、确认再让它执行下一步。每一步都卡着节奏走AI 就没有机会一口气跑偏太远。哪怕真出了问题回滚范围也被限制在单步以内排查成本极低。4. 规则四权限别全开让关键命令留在自己手里4.1 不要迷信“跳过所有权限”Claude Code 在执行 shell 命令前会请求用户授权这是它最重要的安全护栏。我知道很多人嫌弹确认烦直接用--dangerously-skip-permissions跳过所有权限门槛图省事。这个做法我极度不建议。跳过权限意味着 AI 可以自由执行删除、覆盖、安装依赖、git 提交推送等操作。模型猜错指令、执行错命令的概率客观存在一旦犯错就是实打实的破坏。我见过有人让 AI 清理“临时文件”结果它把构建产物和本地数据库备份一起删了的真实案例。4.2 我推荐的权限策略操作类型权限策略读文件、搜索、查看目录放行编辑已有文件放行但要求输出 diff 后我审阅新建文件放行但关注路径是否合理安装依赖、执行构建脚本每次确认删除文件、覆盖文件、git 写操作一律手动确认git push、git reset、rm -rf这类操作我甚至在提示词里直接写明“禁止执行”。给 AI 加写操作权限事后追责远不如事前限制来得省心。4.3 一个被坑过的真实场景有一次我让 Claude Code 修完一个 Bug 后顺手提交代码它确实执行了git commit但把我在调试时加的一堆console.log和临时代码一起提交了进去。更麻烦的是它紧接着执行了git push等我发现问题时错误代码已经推到远端分支。那次之后我立了规矩模型可以写代码、跑测试但所有 git 的提交和推送动作都由我在终端手动执行AI 永远不许碰 git 写命令。这个规矩一直沿用到现在。5. 规则五一次只改一件事每一步都可回滚5.1 大锅烩式改动为什么可怕如果你的任务描述里出现“顺便”“以及”“顺便优化一下”就要警惕了。让 AI 一次改 40 个文件看似效率高实际上是把风险集中引爆。一旦测试挂了你根本不知道是哪一处改动引入的问题排查的时间往往比重新写一遍还长。5.2 推荐的小步工作节奏我的标准节奏是确认当前git status干净。只交给 Claude Code 一个能独立验证的小任务。让它执行对应的测试或 Lint。git diff逐文件审阅。手动 commit。再进入下一个任务。每轮改动的粒度和影响面都控制在一个可解释、可回溯的范围内。哪怕中途方向错了回滚成本也只是一个小 commit。5.3 中间检查点技巧在每个任务收尾时我都会加一句“把你修改过的文件清单列出来并为每个文件写一行改动摘要。”这一步有两个作用一是强迫模型回顾自己的操作减少“改完忘了自己动了哪里”的情况二是让我拿到一份天然 review 清单不用自己去git diff猜它到底干了什么。6. 规则六强制测试闭环让 AI 自己证明没改坏6.1 在 AI 编程里测试是第一安全网模型写代码的 Bug 率客观存在你不能指望它每次输出都是对的。在传统开发里代码审查和经验判断还能兜底但 AI 生成的代码量大且快靠肉眼审查根本看不过来。这时候唯一可靠的验证手段就是自动化测试能跑通就是没改坏跑不通就是有问题不需要争论。我见过很多开发者让 Claude Code 改完代码后不跑测试直接交付结果上线才暴露问题。用 AI 编程的最大前提就是项目里必须有一层测试保护网。如果项目目前没有测试第一件事不是开发新功能而是让 AI 先把核心模块的测试补上。6.2 明确要求 AI 写测试在任务提示词里加上一段话效果立竿见影请为 [函数/模块] 添加单元测试覆盖正常流程、边界值、异常输入这三类场景。 完成后运行 [项目测试命令]确保所有用例通过。如果有用例失败修复代码直到全绿为止。关键是要把“运行测试”也囊括进来而不仅仅是“写测试”。写出来但没跑等于默认它写的就是对的这恰恰是问题所在。6.3 重构前的基线测试技巧做重构或大改动前先让 Claude Code 把现有测试完整跑一遍记录结果作为基线。之后每次它改完代码再重跑测试和基线对比。这个方法非常朴素但能有效防止 AI 在“优化”过程中悄悄改变接口行为或者弄坏原有功能。7. 规则七让 AI 做完活先自检再交给你审7.1 追问变更影响面Claude Code 完成一个任务后不要急着让它收尾走人。我通常会追加几个问题“这次改动会影响哪些现有调用方”“有没有破坏性变更旧代码还能不能兼容”“如果想回滚这次改动最小操作是什么”这几个问题会强制模型进入一种“自我 review”的状态。它往往会重新检查一遍自己的代码然后发现之前忽略的问题。这个技巧带来的正确率提升非常明显甚至比单独提示“请检查你的代码”更有效。7.2 先自查 Lint 和类型再交差写完代码先别急着给我看我会要求它“先跑一遍类型检查和 Lint有问题先修完再汇报最终结果。”这样一来很多低级错误在它内部就已经被消化掉了交到我手上的代码干净程度明显提高。7.3 最终的代码审查应该由人来做模型自检再认真也有盲区尤其涉及业务语义、数据安全、用户体验这类需要领域判断的地方。我习惯把 Claude Code 当成一个执行力很强的初级工程师而我是那个负责把关的资深开发者。AI 负责快速产出和自验我负责方向判断和最终审查。两者角色一旦混淆风险就会失控。8. 规则八把经验沉淀进 CLAUDE.md让工具越用越顺手8.1 每次踩坑都是可沉淀的资产如果你发现 Claude Code 对同一个问题犯了第二次错这就是写入CLAUDE.md的信号。比如它连续两次用了一个项目里已经废弃的 API那就把“本项目禁止使用 XXX 库/API改用 YYY”写进项目记忆。写进去之后后续所有新会话都会自动遵循这条规则你不需要反复在提示词里强调。我现在的CLAUDE.md已经积累了几十条这类约束每一条都对应一次真实翻车。这些约束让 Claude Code 在项目里的表现越来越像一个“熟悉团队规矩”的老人而不是一个每次都从零开始猜的陌生开发。8.2 让规范随仓库共享给整个团队CLAUDE.md是跟着仓库走的文件提交到 git 之后团队里所有人用 Claude Code 时都会自动加载同一套项目规范。这点非常关键。市面上那些靠个人习惯形成的提示词技巧很难在团队里复制但把规范写进仓库文件就等于把个人经验变成了团队基础设施。我在团队里推了一段时间后新加入的同学用 Claude Code 的首次产出质量明显高于没有这套文件时的表现。这就是沉淀的价值。8.3 把常用任务流程模板化如果你发现某些任务反复出现在工作中比如“修复接口超时问题”“给新模块补测试”“重构某类样式代码”可以把对应的提示词模板存成文档或者用 Claude Code 的自定义斜杠指令来固化。这样就不需要每次重新组织语言直接调用模板再根据具体情况微调即可。8 条法则全部讲完了但如果只让我选一条最想强调的建议我会说从一开始就把 Claude Code 当成一个需要“项目背景 明确边界 验证闭环”的协作对象而不是一个会读心术的许愿池。你越舍得花时间把任务描述清楚、把项目记忆沉淀下来、把测试和审阅环节卡住它回报给你的效率提升就越可观。这套方法我也是踩了无数坑才换来的希望你不用再踩一遍。
