先说个开场场景。上个月接手一个Qt桌面项目的收尾朋友发来一长串报错日志说“你赶紧把这段丢给Claude Code让它直接改几分钟就搞定”。我回了句“改之前我得先跟它说清楚你第一步不许碰任何文件先给我把问题讲明白。”朋友一脸不解AI不就是要来改代码的吗禁止它改那让它干嘛这就是我这篇文章想聊透的一件事让Claude修Bug最有效的开场白不是“帮我改一下”而是“你先别改先给我分析”。听起来反直觉但我实际用了大半年Claude Code踩了无数次“越改越乱”的坑之后才明白“先禁止改代码”不是限制而是把AI从“乱改一通”变成“可靠修Bug工具”的关键一步。这套方法适用于正在用Claude Code解决实际工程问题、但总感觉它“改完这个坏了那个”的开发者。下面我会从原理讲到实操把整个流程完整拆开。1. 为什么第一步必须“禁止改代码”1.1 修Bug最大的坑还没搞清楚问题就动手把报错丢给AIAI的第一反应是什么是立刻开始改。这是很多人的真实体验你贴一段报错它马上给你甩出一段“修改建议”甚至直接调用写文件工具把代码改了。结果经常是报错换了一个或者原来跑通的逻辑被弄坏你又得把旧代码捡回来。我见过太多人在这上面浪费时间最后结论是“AI改代码不靠谱”。问题不在AI而在你的指挥方式。修Bug这件事本质上是“先缩小原因的可能性范围再精准修改”。如果你跳过了诊断直接让AI进入修改状态它就像个闭着眼开药方的医生不管你是感冒还是肺炎先给你开一盒退烧药。更糟的是代码被改过之后原来的“作案现场”被破坏了你再也无法判断某个新问题到底是本来就存在还是AI刚才改出来的。1.2 “禁止改代码”的本质把角色从“执行者”切换为“诊断者”你让LLM做什么它就会顺着这个方向走。因为它生成内容是逐词推理、路径依赖极强的一旦第一句话是“帮我改”它之后的整个输出都会沿着“怎么改”这条路狂奔中间几乎没有停下来收集证据的意愿。反过来如果你在会话开头明确说“先只读分析禁止修改任何文件”它的工作模式立刻变了它知道要交付的是一份分析报告而不是一串补丁于是会去读文件、翻日志、追根因。从工程角度来看这也是把AI当“实习生”用的正确姿势。我经常跟人打比方你不会让一个第一天来上班的实习生直接改生产代码你会让他先看代码、复现问题、写个排查意见给你。等你看完意见说“这里可以改”他再动手。Claude Code也一样“禁止改代码”就是把你和AI之间的按钮切到了“顾问模式”。1.3 哪些场景尤其需要“只读先行”不是所有Bug都必须走只读流程但以下几类情况我强烈建议先禁止它碰代码重构导致的回归问题代码已经改到一半工作区里到处是痕迹AI再扑上去改新旧改动混在一起根本没法查。报错信息含糊不清的场景比如“程序卡死”“偶发崩溃”没有明确堆栈这时候AI直接改大概率是瞎猜。涉及权限、安全、数据一致性的问题这类Bug一旦改错代价不是编译不过那么简单必须先分析清楚在改。你还没看过diff的他人代码别人写的模块AI进去就是一顿乱改后续你连Code Review都做不了。只要落入这些场景我的建议就一句话第一步永远是“先分析不改代码”。分析清楚了改代码只是顺手的事。2. 在Claude Code里如何真正“禁止改代码”2.1 权限层面用settings直接拒绝写操作“禁止改代码”不能只靠嘴上跟AI说要靠权限来兜底。Claude Code提供了比较完整的权限控制体系我一般会在项目根目录放一个.claude/settings.json把写类工具直接deny掉让它在诊断阶段根本调不动Edit、Write、Bash。下面是我常用的配置示例{ permissions: { deny: [ Edit, Write, Bash ], allow: [ Read ] } }这个配置意味着AI只能读文件、搜索文件内容不能执行任何修改动作。如果个别场景需要让它跑测试命令我会临时把Bash放开但默认诊断阶段一定是全禁的。Claude Code还支持更精细的规则比如按文件路径控制Edit(src/utils/*)允许还是拒绝但刚开始不用搞那么细直接在全项目层面关掉写权限最省心。另外Claude Code的几种运行模式也值得说清楚模式行为适用阶段plan只做规划不执行修改类工具输出计划等待确认优先推荐最适合诊断default按当前权限策略执行可调用允许的工具日常修复acceptEdits自动接受所有文件编辑请求你已经完全信任改动时再用bypassPermissions跳过所有权限检查非常危险不推荐我在调整配置时会用/permissions命令查看当前会话的权限状态确保它确实是只读的。这里有个重要提醒不要为了方便用bypass模式。我见过有人图省事直接用--dangerously-skip-permissions启动结果Claude Code自作主张改了十个文件其中三个是无关的配置项回滚花了一下午。权限这层是底线别拆。2.2 提示词层面把“不改代码”写进第一句话权限层管住了工具调用但管不住AI的“想法”。为了让它的输出也更偏向诊断而不是修改我会在会话的第一条消息里就把约束写清楚。下面是我经常用的一个系统提示词模板直接粘贴即可你现在只做只读分析。禁止调用任何修改类工具禁止直接修改或创建任何文件。 你的任务是 1. 阅读我指定的代码文件确认问题发生的位置。 2. 找出根因列出证据链和可能影响的模块。 3. 输出一份诊断报告包含问题现象、相关代码位置、根因假设、证据/反证据、修复方案对比。 4. 在报告结尾给出具体修改建议但必须等确认后再实际修改。这段提示词最重要的地方在于给AI定义了明确的“交付物”是诊断报告而不是补丁。实测下来加上这一段之后AI的输出质量高了一大截——它不再急着给你改代码而是会主动说“我先看一下config.py里的加载逻辑”然后引用具体行号、给出证据。如果你用的是Claude Code的Skills功能也可以把这段规则保存成一个Skill文件比如“diagnose-only”以后直接通过/skills调用不必每次手打一大段。2.3 工作流层面用git worktree和临时分支隔离改动权限和提示词都做了但我进一步会用git把“可改区”和“只读区”物理隔离。最简单的方式是在主干上跑只读诊断把真正要实操的修改放到一个新分支或者临时目录里。我自己的习惯是开一个git worktree# 在项目目录外建一个独立工作目录用于AI修改 git worktree add ../project-ai-fix -b ai-fix这样Claude Code在那个新目录里折腾成什么样都不会污染我的主工作区。等它改完我先看git diff确认没问题再合回来。这招对“又想让AI干活又怕AI搞砸”的心理负担非常管用。你甚至可以把这个临时工作区当沙箱让AI在里面跑测试、改文件、反复试错你只负责最后审查。2.4 环境准备先把Claude Code安装配置好这部分本来想放在后面讲但考虑到很多读者可能还没跑通环境我提前把安装和配置一并说清楚。Claude Code本质是一个CLI工具依赖Node.js环境安装命令很简单npm install -g anthropic-ai/claude-code装完之后在终端输入claude按提示登录授权即可。如果你平时主要在VSCode里开发VSCode的Claude Code插件也能提供同样的能力界面里多一个侧边栏面板可以直接在编辑器中与它对话。有两点实操中比较常见的补充说明。第一如果终端提示“claude不是可运行程序”基本是npm的全局安装目录没进PATH检查一下Node的bin目录并配置环境变量就行。第二官方对新用户在某些时段会返回“unfortunately, claude is not available to new users right now”这种可用性提示这种情况一般等一等再试或者通过开放的API服务商接入。我自己会把Claude Code接入不同的模型来源比如DeepSeek开放平台、硅基流动的模型服务或者完全本地化的Ollama模型。常用工具是CC Switch它能集中管理多个模型服务商的配置在Claude Code和Claude Desktop之间一键切换provider也能把Ollama本地模型接进来。这不仅是“没有官方额度”时的替代方案也是省token、降成本的手段。3. 只读诊断阶段怎么把信息喂给Claude3.1 高质量Bug描述模板很多人抱怨AI分析不准其实源头往往是信息喂得太糙。你只丢一句“程序崩了”神仙也诊断不出来。我现在会让团队按照固定模板写Bug描述喂给AI分析时信息密度高很多- 复现步骤1. 点击导出按钮 2. 选择文件路径 3. 程序闪退 - 期望结果导出成功后提示完成 - 实际结果点击后闪退无错误弹窗 - 关键日志见附件最后20行 - 相关代码文件src/export.py、src/ui/dialog.py - 已尝试过重新安装依赖无效去掉中文路径仍崩溃这个模板的核心价值是把“模糊的抱怨”变成“可验证的事实”。AI拿到这些信息后可以自己判断该读哪些文件而不是大海捞针。3.2 让Claude主动寻找证据而不是瞎猜只读分析阶段最容易犯的错是让AI“根据描述直接下结论”。正确做法是引导它去读代码、找证据。我会在问题描述后面追加一句不要根据我的描述直接下结论。请先阅读我提到的文件再查看是否有其他地方引用了相关函数最后给出你的假设和证据。Claude Code的优势在于它真的会去读文件、搜符号。比如我问它“这个导出功能为什么崩”它会自动执行代码搜索找到所有调用导出函数的入口然后说“问题可能出现在dialog.py里处理文件路径的逻辑因为这里把空路径直接传给了底层库”。这个结论比我凭经验猜要准确得多。这里有个省token的技巧不要让AI一口气扫描整个项目。指定关键文件或者让它先给出“还需要看哪些文件”的清单你来决定是否放行。我会常让它用rg搜索关键词而不是直接读取几百行的整个文件既能定位又省钱。比如# 让Claude Code先搜索相关函数定义而不是全文件读取 rg export src --type py -n还有一个小技巧是可以要求它在报告里控制篇幅比如“每个假设不超过三句话最后给出结论”。一方面节省上下文窗口另一方面逼它提炼核心信息不会写一堆没用的分析绕着问题打转。3.3 诊断报告长什么样我贴一个实际用过的诊断报告结构你可以把它当成模板用- 问题现象导出功能闪退无错误对话框。 - 相关代码位置 - src/export.py:41 调用底层导出库 - src/ui/dialog.py:77 处理用户选择路径 - 根因假设 假设1路径含中文导致底层库崩溃与日志中UnicodeEncodeError吻合 假设2用户未选择路径时为空字符串未做空值校验 - 证据与反证据 支持假设1日志中可见UnicodeEncodeError发生在导出库内部 反对假设1开发者本机用中文路径复现过不崩溃所以可能与系统编码配置有关 - 修复方案对比 方案A在dialog.py中增加空路径校验成本低解决假设2 方案B在调用导出库前强制转换编码解决假设1但治标不治本 - 推荐方案先做A同时保留B作为备选。有了这样一份报告你只需要拍板“按方案A改”。改代码的执行成本极低真正的价值在诊断。我经常跟同事说AI值钱的部分不是它写代码的手速而是它读代码后给你梳理出的这张“因果地图”。4. 从“只读”到“可控修改”的切换策略4.1 先让Claude给出修改方案人审后再执行诊断报告出来后才是让AI进入修改阶段的时机。但这时候我依然不会说“你看着改吧”而是让它先产出一份具体的改动方案包括要改哪个文件、哪几行、改成什么样。如果在CLI里我会让它以diff或补丁形式输出审完再应用。例如# 让Claude Code给出具体改动但不直接应用 # 你可以要求它输出git diff格式然后你手动review后再apply claude 请展示修复方案A的具体diff先不要改动文件人工审查这一步不能省。因为AI再强它对项目整体设计意图的理解是有限的你作为人对业务约束的把握才是最终判断依据。你完全可以把AI当成一个“生成补丁的高级工具”审批权始终握在自己手里。4.2 小步快跑每次只让AI改一个点另一种我强烈推荐的思路一次只让AI修一个点而不是让它一口气把报告里的三个问题全部改掉。原因很简单改动越少回归时的变量就越少。如果我让它一次性改三个问题之后程序挂了你根本不知道是哪个改动引起的。如果每次只改一个验证通过后再改下一个出问题一查一个准。这个“小步快跑”的思路听起来慢实际上是最快的。因为它避免了最浪费时间的事情——在一堆改动里排查自己改出来的新Bug。4.3 变更后的验证闭环修改完成不等于修完必须验证。如果你在权限里允许了Bash可以让Claude Code自己跑一遍相关测试并输出结果。如果不能跑测试至少要让它列出“如何手动验证”的步骤。我在实操中还会做一件小事改完后让Claude Code自己总结一句“我改了哪些地方为什么这样改”。这句总结既方便我做Code Review也能反映AI是否真的理解了自己的改动。如果它的解释含糊不清或者和你之前的判断有出入那基本说明它改的时候思路已经漂了这时候最好的选择是回退重来。5. 常见问题与排查技巧实录写到这里把我在实际操作里遇到过的问题整理成一个速查表里面有几条是《使用教程》里不会写但特别实际的坑。问题现象常见原因解决办法终端提示“claude无法识别”npm全局目录不在PATH中重新安装Node.js并确保全局bin目录加入PATH启动后提示native binary not installedpostinstall脚本没跑成功重新执行安装命令或手动重跑postinstall脚本官方提示新用户暂时不可用官方服务拥挤或账号配置未生效稍后重试或用CC Switch切换到其他模型服务商如DeepSeek、硅基流动、OllamaClaude Code改完代码后越改越乱跳过了只读诊断直接进入修改回退到最近可用提交重开会话先跑一遍“只读分析”对话越长token消耗越快上下文累积了大量无关内容使用/compact压缩历史在提示词里限制输出长度指定阅读文件而不是全项目扫描VSCode关闭后找不到之前的对话记录没有保存会话或会话文件被清理操作开始时记录会话ID通过Claude Code的会话管理功能恢复涉及关键操作时先导出摘要5.1 一次“exe图标不生效”的实战复盘这里分享一个和标题特别贴合的实例正好也有读者问过“Qt怎么改exe图标”。当时我让Claude Code帮我处理一个Qt项目需求是改exe图标并重新打包我一开始直接对它说“帮我改图标”它立刻修改了.rc资源文件和.pro工程文件然后编译报错——图标资源找不到。这个时候我意识到自己又犯了“跳过诊断”的错。我把它切回只读模式重新下令“先不要改任何文件分析为什么改图标会编译失败。”它读了工程文件和资源文件后告诉我失败原因是.pro文件里缺少对.rc文件的引用图标资源根本没被打进资源编译器。之后我给了一条指令“修改.pro文件加入RC_FILE app.rc这一行其他的不要动。”一次通过exe图标正常更新。这个案例特别典型不是AI不会改而是它在没有全局信息时乱改一气。先禁止它改代码它反而能快速给出最精准的修改方案。我也建议所有被“QT exe图标不生效”困扰的人用这个思路先分析再说。5.2 关于Claude Code和Codex的选择很多人会问Claude Code和OpenAI Codex到底该选哪个。从我的体验来说如果你面对的是多文件、复杂项目里的Bug定位Claude Code的上下文处理和对代码库的自动探索能力更顺手Codex的优势在于和OpenAI生态的无缝配合以及如果你更习惯GPT系列的自然语言交互。工具没有绝对好坏核心还是那句话——不管用哪个修Bug的第一步都应该是“先看懂再动手”。你完全可以两个都试一下看哪个更贴合你项目的节奏。5.3 关于省token的几招实操最后补充几个我已经沉淀成习惯的省token技巧尤其是当你把Claude Code接到按量计费的模型服务上时这几个方法能明显降低开销先让AI自己列出“需要读哪些文件”你审核后再放行避免它扫整个仓库。重要但大段的代码不让它全文阅读而是用搜索命令提取关键片段。要求报告和回答“直接给结论”10行以内说完别让它写长篇解释。长会话定期/compact把前面的历史压缩成摘要防止token在无关讨论上浪费。把需求拆分一个会话专注一个Bug不要一个会话里连着干好几件事。这些技巧配合“只读诊断优先”的流程能让你手头的token预算多撑好几倍而且正确率反而更高。我也提醒一句不要为了省token跳过分析步骤最浪费的场景不是分析阶段花的token而是AI瞎改之后你来回排错消耗掉的那些token。两笔账算下来先把问题看明白永远是最省钱的。我在实际项目中养成的习惯是每次新开Claude Code会话第一句话永远先声明“只读分析不要改文件”。哪怕这次只是问一个小问题我也把它当成必须遵守的默认规则。等AI把问题讲透再由我做“是否修改”的决策。这套流程帮我省下的排查时间比我花在写那些提示词上的时间多一个数量级。如果你正被“AI越改越乱”折磨不妨下个项目试试第一步先禁止它改代码也许你会回来感谢这个反直觉的开场。