企业官网建设流程全解析

先说个开场场景。上个月接手一个Qt桌面项目的收尾，朋友发来一长串报错日志，说“你赶紧把这段丢给Claude Code，让它直接改，几分钟就搞定”。我回了句：“改之前我得先跟它说清楚，你第一步不许碰任何文件，先给我把问题讲明白。”朋友一脸不解，AI不就是要来改代码的吗？禁止它改，那让它干嘛？

这就是我这篇文章想聊透的一件事：让Claude修Bug，最有效的开场白不是“帮我改一下”，而是“你先别改，先给我分析”。听起来反直觉，但我实际用了大半年Claude Code，踩了无数次“越改越乱”的坑之后才明白，“先禁止改代码”不是限制，而是把AI从“乱改一通”变成“可靠修Bug工具”的关键一步。这套方法适用于正在用Claude Code解决实际工程问题、但总感觉它“改完这个坏了那个”的开发者。下面我会从原理讲到实操，把整个流程完整拆开。

1. 为什么第一步必须“禁止改代码”

1.1 修Bug最大的坑：还没搞清楚问题就动手

把报错丢给AI，AI的第一反应是什么？是立刻开始改。这是很多人的真实体验：你贴一段报错，它马上给你甩出一段“修改建议”，甚至直接调用写文件工具把代码改了。结果经常是，报错换了一个，或者原来跑通的逻辑被弄坏，你又得把旧代码捡回来。我见过太多人在这上面浪费时间，最后结论是“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的几种运行模式也值得说清楚：

我在调整配置时会用/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. 只读诊断阶段怎么把信息喂给Claude

3.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. 常见问题与排查技巧实录

写到这里，把我在实际操作里遇到过的问题整理成一个速查表，里面有几条是《使用教程》里不会写但特别实际的坑。

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越改越乱”折磨，不妨下个项目试试：第一步先禁止它改代码，也许你会回来感谢这个反直觉的开场。