这个"病"长什么样
你发现了一个 bug，描述给 AI 听。
它立刻开始干活——改代码、调样式、重构逻辑，速度很快，看起来信心满满。
你跑完一看——它修的根本不是你遇到的问题。
你跟它说"表格列错位了"，它去调 CSS 间距。
你跟它说"API 返回格式不对"，它去改数据库字段。
你跟它说"这个按钮点了没反应"，它去重写事件绑定逻辑。
你急了："不是这个问题！我说的是 XX！"
它说："好的，我来修复 XX。"
然后它修了 YY。
它不是在理解你的问题——它在根据自己的"第一反应"猜一个最像的问题，然后去修那个问题。
等你第三轮纠正完，它终于修对了。但前两轮的时间、token、耐心，全浪费了。
我的真实案例
我在做一个测试用例展示表格。表格有好几列：用例编号、用例标题、优先级、测试步骤、预期结果。
有一天我发现"优先级"那一列显示的内容不对——它显示的不是"P0""P1""P2"，而是测试步骤的内容。"优先级"列和"测试步骤"列的内容串到一起了。
我找到 AI，告诉它：
"表格的列错位了。优先级那一列显示的是测试步骤的内容，需要修复。"
AI 秒回："好的，我来检查前端列渲染逻辑。"
它分析了半天，认为是前端表格的列映射硬编码出了问题——某两列的索引搞反了。然后它开始改代码，调整了 CSS 的列宽和列顺序。
改完跑一看——常规用例的表格好了。列对齐了，数据也对上了。
我松了口气。
但切到"安全缺陷模式"的用例表格——还是错位。 只不过这次错的位置变了，从"优先级"列跑到了"预期结果"列。
我回去找 AI：
"常规用例修好了，但安全缺陷模式的用例还是错位。"
AI 又分析了一轮："安全缺陷模式的表格结构不同，需要单独处理列映射。"
它又改了一版。跑完——好了。
我正准备收工，切了另一个筛选条件——第三种用例类型又错位了。
三轮了。每次修一种，下一种又错。
这时候我停下来想了想：不对，这不是前端渲染的锅。
我去查了 Agent 生成的原始数据——
问题根本不在前端。 是 Agent 在生成不同模式的用例时，输出的数据列结构本身就不一样：
- 常规模式：[编号, 标题, 优先级, 步骤, 预期]
- 安全缺陷模式：[编号, 标题, 步骤, 优先级, 预期]——优先级和步骤的位置反了
- 其他模式还有自己的排列方式
前端只是一个"忠实的渲染器"——数据给什么它就显示什么。 AI 去调前端的列映射，相当于给一个翻译错误的问题去改显示字体——方向完全错了。
真正该修的是 Agent 的输出格式——让它在所有模式下都输出统一列结构的数据。
AI 在错误方向上跑了整整三轮。
为什么 AI 会这样？
1. AI 的"问题诊断"其实是"模式匹配"
当你告诉 AI"表格列错位了"，它不是在做一个系统性的根因分析。它是在训练数据里搜索"表格列错位"最常见的修复方式——而最常见的答案是"调整列映射/CSS"。
它把"表格列错位"匹配到了"前端列映射错误"这个模式上，然后直接走了最常规的路径。
它没有停下来想过：在这个具体的项目里，列错位的根因到底是什么？
2. AI 倾向于"修看得见的东西"
前端代码是"看得见"的——HTML 结构、CSS 样式、JavaScript 渲染逻辑。AI 很容易定位到这些地方。
而"Agent 生成的数据列结构不统一"是一个更深层的问题——它需要 AI 去追溯数据从哪来、格式是怎么定义的、不同模式下的输出是否一致。这种"往上追溯"的诊断路径，需要 AI 主动去探索不确定的区域。
"改 CSS"比"查数据源"更容易、更快、更确定。 AI 选择了更容易的路。
3. AI 不会主动质疑你的描述
你说"表格列错位了"——AI 接受了这个描述，然后去找"列错位"的修复方案。它没有问你：
- "是所有用例类型都错位，还是只有特定类型？"
- "错位是前端渲染的问题，还是数据本身的问题？"
- "你能给我看一下原始数据吗？"
如果它问了这些问题，可能第一轮就能定位到数据源。但它没有——它直接开始修了。
AI 把"快速给出解决方案"看得比"正确理解问题"更重要。
这种病的隐蔽之处
"答非所问"最坑的地方不在于"修错了"——修错了你总能发现。
坑在于它修错的方向看起来"合理"。
"表格列错位→调列映射"——这个逻辑链没毛病。任何前端工程师看到这个描述，第一反应也确实是去查列映射。
问题不在于"修的方向不合理"，而在于"这个具体场景下，根因不在那里"。
AI 犯的错不是"逻辑错误"，而是"假设错误"。 它假设了根因在前端，然后逻辑正确地推导出"应该改列映射"。但假设就是错的，逻辑再正确也没用。
这种错比纯粹的代码 bug 更难发现——因为它的每一步推理都是"对的"，只有最底层的那个假设是错的。你得自己去挖那个假设。
怎么治
方法 1：让 AI 动手之前，先复述一遍它理解的问题
在你让 AI 开始修 bug 之前，加一个步骤：
"在你动手之前，先告诉我：你理解的问题是什么？你认为根因在哪？你打算从哪个方向修？"
等它回答完，你看一眼。如果它理解偏了，立刻纠正——然后它就不会在错误方向上浪费时间。
这个方法看起来很"多余"，但实际上能省掉大量的无效迭代。一轮 30 秒的确认，能省掉三轮 30 分钟的错误修复。
拿我的案例来说，如果 AI 在动手前告诉我：
"我理解的问题是：前端表格的列映射和实际数据列顺序不匹配，我打算调整前端代码中的列映射逻辑。"
我一看就知道——方向错了。根因不在前端，在数据源。一句话就能纠正它。
但它不问我，我也不检查，它就闷头改了三轮。
方法 2：给 AI 提供上下文，而不是只给症状
❌ 容易出问题的描述方式：
"表格列错位了，修一下。"
✅ 更好的描述方式：
"表格列错位了。我看了下原始数据，Agent 生成的安全缺陷模式用例里，优先级和步骤的列顺序跟常规模式不一样。帮我修 Agent 的输出格式，让所有模式输出统一的列结构。"
把你知道的上下文给到 AI，尤其是你已经判断过的根因方向。 不要让它自己猜。
AI 不是不能解决复杂问题——是它在信息不足时，会用"猜"来填补信息空白。你给的信息越多，它猜错的概率就越低。
方法 3：第一轮修完后，不只验证"修好了没"，还要验证"修对了没"
AI 修完一个 bug，大部分人的验证逻辑是：
"我刚才遇到的问题还在不在？"
这个验证是不够的。你还需要问：
"它的修复方式对不对？有没有可能引入新问题？"
拿我的案例来说：第一轮修完后，常规用例确实好了——"修好了"。但如果我当时多检查一种用例类型，立刻就能发现"没修对"——因为根因不在前端，换个数据结构就又不行了。
验证时多做一步"边界检查"——不只是验证你报告的那一个 case，还要验证相邻的 case。 如果 AI 的修复方式是对的，它不应该只修好一个 case 而让其他 case 坏掉。
方法 4：复杂 bug，先让 AI 做诊断，再让它修
对于简单的、一眼就能看出根因的 bug（拼写错误、少传参数、样式覆盖），直接让 AI 修没问题。
但对于需要"想一下"才能定位的 bug——先让 AI 做诊断，确认诊断对了，再让它修。
诊断指令示例：
"这个 bug 的表象是 XX。请先分析可能的根因，列出 2-3 个可能的方向，并说明你倾向哪个方向以及为什么。不要直接改代码。"
等它分析完，你看一眼方向对不对。对了，再让它修。不对，纠正它的假设，重新分析。
把"诊断"和"执行"分开，是防止 AI"答非所问"最有效的结构性方法。
一句话总结
AI 修 bug 的速度很快——但它可能修的是它以为的问题，而不是你的问题。动手之前，先花 30 秒确认方向。方向错了，修得越快浪费越大。