上篇讲完用 Zread 读懂陌生项目，这篇进入开发者每天都要面对的场景------修 Bug。
传统修 Bug 流程：看到报错 → 搜索引擎查 → 翻十几篇帖子 → 猜测原因 → 改一版 → 不对 → 再猜。运气好半小时，运气不好一下午。而 ZCode 的 Agent 模式是另一条路：把报错连上下文丢给它，它自己去读代码、定位根因、给出修复方案、改完还能跑测试验证。
这篇用一个前端 Bug 和一个后端 Bug 的完整实战，拆解 ZCode 修 Bug 的全链路------以及你该怎么配合，成功率才最高。
先说关键：报错信息的"喂法"决定成败
同样一个 Bug，两种喂法效果天差地别。
低效喂法（只丢一行报错）：
帮我修一下这个错：TypeError: Cannot read properties of undefined (reading 'map')
高效喂法（报错 + 上下文 + 复现路径）：
页面在点"订单列表"跳转时报错：TypeError: Cannot read properties of undefined (reading 'map')。报错堆栈指向 OrderList 组件第 47 行。这个页面是从 /orders 路由进来的，接口数据由 useOrders hook 拉取。帮我定位根因并修复，修复前先说明你的分析。
差别在哪？第一种，ZCode 只知道"哪里炸了"，得自己去猜去撞；第二种，它知道炸在哪、什么时候炸、数据从哪来------直接沿调用链查就行。报错信息里的每一行上下文，都是帮 Agent 剪掉搜索空间的线索。
实操建议：报错全量粘贴（别只截图）、说明复现路径、指出相关文件或组件名。这三样给齐，定位速度至少快一倍。
实战一：前端渲染报错（列表页白屏）
场景 ：一个 React 项目，订单列表页点进去白屏，控制台报 Cannot read properties of undefined (reading 'map')。
第一步：丢给 ZCode
把完整报错 + 堆栈 + 复现描述发给它。ZCode 的推理路径长这样：
- 读堆栈，定位到
OrderList.tsx第 47 行------一个对data.items的.map()调用 - 向上追：
data来自useOrders()hook 的返回值 - 读 hook 源码：接口正常时返回
{ data: { items: [...] } }，但接口失败时返回{}------data.items就是 undefined - 根因浮出：接口失败时缺了兜底，渲染层直接炸
注意这个过程------它不是"猜"的，是沿着调用链一层层读代码读出来的。这就是 Agent 修 Bug 和搜索引擎修 Bug 的本质区别：前者基于你项目的真实代码，后者基于别人的相似案例。
第二步：审阅修复方案
ZCode 给出的修复：hook 里对返回值做默认值处理 { data: { items: [] } }，组件里加空状态渲染。两个改动，各三五行。
关键动作：它在改文件前会展示 diff，你逐行看一遍。看什么？看改动是不是只动了根因相关的最小范围------好的修复是外科手术式的，如果它顺手"优化"了一堆无关代码，拒绝并让它收窄。
第三步：验证
让它跑一遍相关测试（或自己点一遍页面）：正常数据、空数据、接口报错三种状态都过，这个 Bug 才算修完。
实战二：后端依赖报错（ModuleNotFoundError）
场景 ：Python 服务本地跑不起来，报 ModuleNotFoundError: No module named 'yaml'。
这种问题看着简单，但背后可能有分叉：没装依赖？装错环境？requirements 漏了声明？虚拟环境没激活？
丢给 ZCode：
启动报错 ModuleNotFoundError: No module named 'yaml'（完整报错如下）。项目用的是 venv 虚拟环境，requirements.txt 在根目录。帮我排查原因并修复。
它的排查链：
- 读
requirements.txt------发现里面声明的是pyyaml而不是yaml（这其实是对的，PyPI 包名和导入名不同，ZCode 确认了这点） - 检查当前 Python 环境------运行
which python，发现激活的不是项目 venv，而是系统全局 Python - 根因：依赖装在了 venv 里，但启动时用的解释器不对
修复：激活正确的 venv 再启动，问题解决。
这个案例的价值在于：报错显示的"缺模块"往往不是真根因。单行报错会把你引向"装个包就好了"，而 ZCode 顺着环境配置往下查，找到的是"解释器选错了"。这就是 Agent 排查的优势------它不满足于表面报错，会验证到链条闭合。
修 Bug 过程中的风险控制
Agent 修 Bug 的风险点在"改错了怎么办"。三道保险：
保险一：确认模式不关。ZCode 默认改文件前要你确认。修 Bug 场景下别嫌麻烦开自动审批------diff 展示的就是你的审查窗口，十秒钟可能挡掉一次错误修改。
保险二：修之前先 commit 。让 ZCode 动手前，确保当前代码已提交。万一修复方向错了，git diff 看改动、git checkout 一键回滚，代价为零。没 commit 就让 Agent 大改，是对自己的不负责。
保险三：用 git diff 验收 。修完后别只看"能跑了"，让 ZCode 列出所有改动文件，逐个 git diff 过一遍。确认改动范围和根因匹配、没有夹带私货------这步做习惯了，你会对 Agent 的信任建立得非常快。
提高成功率的四个习惯
- 报错全量给：堆栈、日志、复现步骤，信息越全，Agent 的搜索空间越小
- 复杂 Bug 分步来：先让它"只分析不改代码，输出根因判断"，你确认方向后再放它改------分析对了，修复基本不会歪
- 修不动就补充线索：它第一轮定位偏了，别急着重开任务，把新线索（"我试过 XX 了""XX 是正常的"）追加给同一个任务，上下文还在，比重新开任务效率高
- 修完跑测试：有测试就让它跑测试，没测试至少手动过一遍主流程。"改完了"和"修好了"之间隔着验证
总结
- 喂报错的三件套：完整报错 + 复现路径 + 相关文件，比只丢一行报错快一倍
- ZCode 修 Bug 的本质是沿调用链读代码定位根因，不是搜索引擎式的相似案例匹配
- 报错显示的问题未必是真根因（如 ModuleNotFoundError 实为环境问题），相信 Agent 的链条验证
- 三道保险：确认模式不关、修前 commit、修后 git diff 逐文件验收
- 复杂 Bug 先"只分析"再"放行修改"，方向确认了再动手
下一篇讲另一个高频刚需：让 ZCode 给存量代码补单元测试，覆盖率从 0 拉到 80% 的完整打法。
如果这篇帮你理清了 AI 修 Bug 的正确姿势，欢迎分享给天天和 Bug 搏斗的同事。你把报错丢给 AI 时踩过什么坑？评论区聊聊~