修Bug先别让Claude改代码：三步诊断工作流，效率翻倍

先说个有点反直觉的结论让 Claude 修 Bug最稳的姿势恰恰不是让它立刻动手改代码而是第一步先把它的手绑住。对你没听错真正高效的 Claude 修 Bug 流程第一步是明确禁止它改任何文件先逼它把问题讲清楚。这个习惯我一开始也没有踩了几次坑之后才发现很多“修完更坏”的翻车现场根源根本不是 Claude 能力不够而是我给了它太多自由。今天把这套工作流完整拆开聊聊适合正在用 Claude Code、VSCode 里的 Claude 插件或者接了各种本地模型的同学参考。1. 为什么“先禁止改代码”能少踩一半的坑1.1 直接让 Claude 改代码最容易翻车的地方在这我之前有个很坏的习惯遇到 Bug 就把报错信息往 Claude 一丢然后说“帮我看看哪里不对劲修一下”。几十秒后它往往已经改好了好几个文件还给出一个“自信满满”的 commit message。表面上看效率惊人实际上我后来发现这种操作方式隐藏着三个非常典型的问题。第一个问题是它靠“猜”而不是靠“查”来做决定。LLM 本质上是概率生成模型如果上下文里没有足够的信息当它被要求直接改代码时会倾向于生成一个看起来合理的修改而不是严格基于证据的修改。这就好比医生还没等检查报告出来就凭经验开药方向对了是幸运方向错了是常态。第二个问题是它经常“顺手”改掉无关内容。让 Claude 修一个按钮点击无响应的问题它可能把整个事件绑定的逻辑全部重构一遍顺手改了命名风格和注释。不是说重构一定错而是在一个 Bug 修复任务里无关改动意味着风险扩大原本正常的功能可能被它顺手弄坏。第三个问题是“假修复”特别多。Claude 改完之后你看一眼代码确实变了逻辑好像也说得通跑一下测试可能还过了。但上线之后发现 Bug 还在甚至出现了新的边界问题。原因很简单它没有真正理解问题产生的链路只是在表面打了个补丁。后来我总结出一个道理直接让 AI 修代码就等于允许它在信息不足的情况下做决策。而信息不足恰恰是 Bug 修复中最致命的敌人。1.2 诊断先行修复在后背后是逻辑链而不是灵感为什么“先禁止改代码”能大幅提升修复成功率核心原因在于它强制 Claude 进入“先建立逻辑链再给出修改”的模式。代码里的 Bug 几乎都有一个共性现象在 A 点根因在 B 点。前端按钮点了没反应现象在 click 事件根因可能是一个接口请求异常导致后续逻辑直接 return 了。如果你让 Claude 直接改它看到 click 事件附近有点可疑就把注意力全放在 A 点根因 B 反而被忽略。禁止它改代码之后它唯一能做的就是读代码、查调用关系、分析数据流。这个过程中它会被迫把“现象 → 中间链路 → 根因”这条逻辑链拉通。拉通之后再让它改它改的自然就是真正的病根而不是表面症状。这里可以打一个比方。你去看病医生不会第一句话就说“来把这盒药拿回去吃”。他会先让你做检查、看报告、判断病因然后才开药。如果有个医生上来就开药你多半会觉得这人不靠谱。但同样的道理放到 AI 身上我们却经常忘了——Claude 说它要改不代表它知道自己为什么要改。1.3 禁止改代码不等于不让 Claude 干活有人可能会担心我花了不少钱订阅 Claude结果第一步还不让它改代码那不是浪费吗其实恰恰相反。“禁止改代码”是一个阶段性的约束不是全流程的约束。它只是把顺序调整为“先分析再动手”让 Claude 在动手之前先把这个 Bug 为什么会发生、涉及的调用链有哪些、改动的影响面有多大全部说清楚。这一步本质上是在“榨干”Claude 做高价值判断的能力而不是浪费它的能力。分析阶段它做的是阅读理解、逻辑推理、方案设计只有到确认阶段才让它做代码生成。所以这个约束不是束缚而是让它的每一次修改都建立在确认过的判断上。对使用 AI 编程的人来说这个认知转变比学会任何具体 prompt 技巧都重要。2. 给 Claude 划权限让它“看得见、改不了”2.1 Claude Code 的工具权限比你想的更值得研究如果你用的还是网页版 Claude那你只能通过 prompt 去约束它。但如果你在用 Claude Code 这类终端工具或者 VSCode 里的 Claude 插件那你的手段就多了一样——工具权限控制。最近“claude code 安装”“vscode 配置 claude code”“claude code 使用教程”这些词热度很高说明很多人都在往这个方向折腾但折腾的重点大多停留在“怎么跑起来”很少有人认真研究权限这一层。Claude Code 的能力模型是“工具调用”。它不是一个单纯的对话模型而是一个有手有脚的智能体能读文件、搜代码、编辑文件、执行命令。默认状态下它对你项目的访问权限其实相当大。这就像你请了一个实习生给了他把整个代码库的读写权限还顺便给了个终端。能力是不错但风险也可想而知。所以我的建议很直接把工具权限拆开看哪些是“观察类”的哪些是“修改类”的哪些是“执行类”的分别设置不同的策略。工具类别代表操作在“分析阶段”的建议只读类Read、Grep、Glob、LS全部放行这就是它的眼睛写类Write、Edit、MultiEdit禁止或改为每次询问执行类Bash、Task仅放行测试、构建等安全命令这套权限设计思路和运维里的“最小权限原则”是同源的。你给 AI 的工具权限越小它越不可能把事情搞砸。反过来如果权限给得太大它就很容易在自信的幻觉中一顿乱改。2.2 实操在 Claude Code 里实现“只读优先”具体到 Claude Code一般有两种常见做法。第一种是通过启动参数或权限配置让整个会话先进入“只读模式”。在这种模式下Claude 可以大范围读文件、搜索关键词、分析调用关系但它无法执行写操作。这个阶段专门用来做“诊断”。第二种做法是通过配置文件对写类工具进行白名单或黑名单管理。团队项目里你可以把Write、Edit这类工具统一设成ask每次修改都需要人工确认。这样 Claude 不是不能改而是每次改之前必须征求你同意。单看效率这一步好像拖慢了进度但实际体验下来它帮你拦掉的问题远大于它浪费的时间。我个人的习惯是项目根目录维护一个.claude/settings.json把分析阶段的默认权限锁死。这种配置还有一个好处是可以提交到版本库整个团队共享。Claude 修改代码前必须先经过确认相当于把“AI 操作员”变成“AI 提议员人类确认员”。2.3 接 VSCode 和本地模型时权限更要收紧这两年大家还特别喜欢折腾一件事把 Claude Code 接进 VSCode或者用 Ollama、硅基流动这类渠道接 DeepSeek 等第三方模型。原因很直白省 token或者满足公司合规要求。但这里我要泼一盆冷水越是接本地模型、小模型越要收紧权限。原因很简单本地模型或第三方小模型在“指令遵循能力”上通常比大厂商的旗舰模型差一截。你让它“先别改代码只分析”它可能口头答应了转头就给你写了个新文件。这时候你依赖 prompt 约束是远远不够的必须靠工具层的权限限制兜底。所以流程上务必是先通过工具配置彻底封死写权限再开始对话。权限不是写在 prompt 里的建议而是写在配置里的规则这个区别很关键。3. 实操三段式 Bug 修复工作流3.1 第一段复现问题喂给 Claude 完整上下文任何 Bug 修复都从复现开始这句话不光对人类程序员成立对 AI 程序员更成立。Claude 修 Bug 的时候最怕的不是它不会修而是上下文太单薄。你只给一句“登录按钮点了没反应”它就只能瞎猜。正确做法是给足这三样东西第一项目模块的背景至少要说明这是前端还是后端核心框架是什么涉及哪个业务模块。第二Bug 的可复现路径最好精确到“在哪个页面、点了什么、期望什么、实际什么”。第三关键报错信息或日志片段。有这三样Claude 才能把问题锚定在一个具体范围内而不是在整个代码库里漫游。这里有个小技巧与其让 Claude 全库搜索不如先自己用 Grep 或全局搜索锁定几个可疑文件再把范围喂给它。就像找人办事你给他写清门牌号他当然比只看小区地图更快找到门。3.2 第二段要求 Claude 输出“病历”而不是“处方”上下文喂完之后就该进入“禁止改代码”的核心环节了。我给 Claude 的提示词模板大概是这样的接下来请先进入只读分析模式禁止修改任何文件。 1. 阅读相关代码模块梳理问题出现的调用路径和关键函数。 2. 给出根因分析说明为什么会出现这个 Bug证据是什么。 3. 列出你认为需要修改的文件、修改思路和预期的影响面。 4. 在你完成以上分析之前不得执行任何编辑操作。这个 prompt 的厉害之处在于它把 Claude 的角色从“改代码的执行者”拗成了“写诊断报告的工程师”。你得到的不再是一堆闪改之后的 diff而是一份可以仔细审阅的诊断说明。这也是整个工作流里含金量最高的一步。等 Claude 输出报告后你要做的是逐条审视而不是直接说“好的开始改吧”。重点审三处逻辑链是否通顺根因判断是否有代码证据支撑修改方案是否把影响面控制在了最小。如果报告本身含糊不清那基本可以判断它也没想清楚让它直接改大概率是翻车。3.3 第三段人工批准后让 Claude 做最小变更诊断报告通过后才进入真正的“改代码”阶段。但即便是这一步我也不会放任它一次改完就收工。我会在批准修改时附带约束“只修改你列出的文件只做和本次 Bug 相关的改动。”这个约束能够有效地抑制它“顺手优化”的冲动。改完之后还要做两道检查。第一道是git diff级别的检查逐行看它到底改了哪里有没有夹带无关内容。第二道是验证至少要把单测跑了再把人工绕一圈主流程。如果发现它改了方案之外的文件直接git checkout回滚对应文件再重新限定范围。这里强烈建议在动手前先建一个专门的分支。Git 是你和 AI 之间的安全网没有这个安全网翻车成本会高很多。有分支保护大不了git reset --hard重来毫无心理负担。用“小步快跑”的方式让 Claude 修 Bug每次都只处理一小块出了问题也好定位。3.4 记录一次真实修复从“改错地方”到“改对一行”拿我之前遇到的一个问题举例。一个 React 项目里列表页的下拉筛选框选中某个选项后列表不刷新。第一次我直接让 Claude 改它判断是筛选组件的 state 更新逻辑问题花了一堆代码重构了状态管理。跑起来之后筛选是生效了但下拉框本身的二次选择又坏了典型的按下葫芦浮起瓢。第二次我学乖了先禁止它改代码让它只分析调用链。结果它读了半天之后告诉我问题根本不在筛选组件本身而是筛选状态变化后触发的列表请求被上游一个重复的useEffect依赖项给拦截了请求根本没发出去。修复方案只需要在那个useEffect里加一个判断一行代码都不到。那次之后我就彻底服了不是 Claude 不能修 Bug而是之前我给它太快动手的自由让它绕过了真正该深挖的逻辑链。禁止它改代码是在强迫它走完“从现象到根因”这条路路走完之后修复本身就变得很简单了。4. 常见翻车场景与排查速查表4.1 改完 A 坏了 B范围失控是最常见的问题让 Claude 直接修 Bug最常遇到的翻车就是“修好了报错的点破坏了原本正常的功能”。根源在于它修改时没有守住“最小变更”的原则。你让它修登录报错它顺手优化了会话管理的代码然后又顺手改了一个接口请求的封装每一个单点看起来都合理合起来就成了一个不稳定系统。遇到这个情况我的处理流程是先git diff看全貌确认哪些改动和原始 Bug 无关然后逐一回滚无关改动。如果无关改动太多干脆git checkout整个文件再用第三段的“最小变更”流程重来一遍。记住一个原则AI 改得越多你 review 的负担越重Bug 复发的概率也越高。4.2 测试过了但 Bug 还在“假阳性修复”要警惕还有一种更隐蔽的翻车Claude 把代码改了测试也跑过了你甚至都准备提测了结果产品经理一试Bug 照旧。这就是“假阳性修复”表面症状解决了根因一点没动。处理这类问题靠测试结果是不够的要靠过程记录。也就是 Claude 分析阶段输出的那根“逻辑链”。回查它的根因报告看它说的根因和真实场景是否匹配特别是“证据”是否站得住脚。如果它当初根本没说清楚根因只是给了一个“看起来能跑的修改”那十有八九就是假修复。防患于未然的方式还是回到第二段规则报告不通过坚决不让动代码。4.3 权限设太死Claude 直接“罢工”怎么办有的朋友看到这里回头就把所有写权限都关了结果 Claude 分析完之后说“我这边无法进行修改”整个流程卡住了。这种情况也很常见属于权限和任务阶段不匹配。分析阶段禁止写操作没问题但到了执行阶段你得把修改权限放开或者把指定工具的权限改成“每次询问”。所以我在 2.2 节特意强调“只读优先”而不是“只读为主”。这是一个阶段性开关不是永久性的枷锁。推荐的配置方式是把读操作放行、写操作ask、危险命令全程禁用。这样 Claude 能干活但每一步都在你的监控下。权限过松和权限过死都是坑中间那个“询问确认”的位置才最舒服。4.4 Token 花得快但产出少上下文策略出了问题用 Claude Code 修 Bug另一个高频吐槽点是 token 烧得快。这个问题的原因通常很简单把整个项目目录丢给了 Claude让它全库读了一遍。文件读得越多上下文越长费用越高到后期模型甚至因为上下文拥挤而“变笨”回答质量断崖式下跌。正确做法是控制上下文范围。先在分析阶段用 Grep、Glob 这类只读搜索工具定位到具体文件再让 Claude 增量阅读关键代码。对大日志做摘要再丢进去不要整段贴。同时尽量在一个会话里把诊断和修改做完整避免反复重新加载上下文。这些技巧堆起来实际 token 消耗能降三分之一还多。4.5 问题排查速查表现象大概率原因处理建议修好 A 又弄坏 B改动范围过大未守住最小变更回滚无关改动最小变更重来测试通过但 Bug 还在假阳性修复只改了表面回查根因逻辑链要求补证据Claude 分析后不能修改写权限被锁死阶段不匹配把写操作改成 ask而不是全禁Token 消耗过高上下文范围失控全库读取用搜索工具缩小范围增量阅读Claude 改完带出全新语法错误同时打开了太多文件上下文混乱限定会话范围要求改完立刻 self-check最后再分享一个习惯上的小变化这套流程用久了之后我最大的感受是跟 Claude 协作的方式越来越像带一个初级工程师。你带新人时不会上来就把整个模块丢给他自由发挥一定是先让他看代码、讲理解、出方案你点头之后才让他动手。Claude 虽然知识量巨大但它在面对一个陌生代码库时缺乏的恰恰是那种“先搞清楚为什么再去想怎么做”的克制。我现在接手任何新项目都会先让 Claude 以只读模式把核心模块给我讲一遍当它能把一条调用链讲得明明白白的时候说明上下文真正对齐了。这个习惯后来也延伸到了 Code Review 场景效果意外地好。如果你最近正被“Claude 修 Bug 越修越乱”折磨不妨试试这个看似绕路、其实是捷径的思路先绑住手让它用脑子干活。