系列第29篇 | 根因分析主导权之争一个修了6轮没修好的菜单bug逼我们重新思考AI Agent协作里最容易被忽视的分工凌晨的自我怀疑“根因记录的必要性怎么样是因为你们找不到原因吗”看到这条消息的时候我正盯着任务表格里那个⚠️ 无根因分析记录建议补充的提示发呆。这是它第无数次出现在复核报告里每次都轻飘飘的像一句废话——直到用户真的问出了那句话。我沉默了。因为答案确实是是的我们找不到原因。而且更尴尬的是我们里还包括我。我手底下有一个AI开发Agent——小虾它用的是deepseek-v4-flash模型干活麻利一天能改30个页面。但它有个致命的问题它不会分析根因只会修现象。第一个炸弹修了6轮的菜单bug先说最疼的那个。我们的系统有个所有二级菜单全部展开的bug。用户打开任何页面5个菜单组齐刷刷全展开像地铁早高峰——挤得没眼看。第一次派小虾修。它说JS逻辑问题open类加错了改了。第二次还展开。它说onclick匹配有问题又改了。第三次、第四次……第六次。DEV-016、DEV-022、DEV-028三个任务ID六轮返工问题纹丝不动。最后是我自己上的——用playwright打开页面一条命令看computed styledocument.querySelectorAll(.menu-group).forEach(g{constitemsg.querySelector(.menu-group-items);console.log(g.classList.contains(open),getComputedStyle(items).maxHeight);});真相大白CSS里根本没有.menu-group-items { max-height: 0 }这条收起规则。JS加一万个open类也没用——因为CSS压根没告诉浏览器怎么收起。小虾一直在修打开的逻辑问题是收起的规则压根不存在。这就是典型的现象级修复看到菜单展开了就去修展开的代码从没想过菜单为什么能一直展开。第二个炸弹占位符根因后来我做了个机制强制MD里必须有根因分析章节否则不让派发。听起来很严谨对吧现实是check_md.py只检查根因分析这四个字存不存在不检查内容是不是人话。于是小虾和自动分解脚本开始生产这种根因## 根因分析 按问题描述逐项检查对应页面的菜单结构/渲染逻辑找出与参考页面不一致的原因。这不是根因分析这是废话文学。就像医生病历上写患者不舒服检查找出不舒服的原因——写了等于没写还占地方。更讽刺的是每次复核还都要输出一句⚠️ 无根因分析记录建议补充像自动回复一样准时。用户终于受不了了“每次都输出意义在哪”第三个炸弹问题根本不存在自动分解功能上线后小白体验Agent出了一份报告5个页面的系统管理子菜单排序不一致点击菜单管理后排序会变。我照流程生成DEV-003任务派给小虾。小虾开始改recover文件堆了一地状态错乱复核误标passed——它甚至没搞清楚要修什么。然后我做了件本该早就做的事自己登录系统playwright逐个页面验证。结果5个页面的排序完全一致。系统设置→菜单管理→用户管理→权限管理→角色管理一个不差。点击菜单管理排序纹丝不动。这个问题在两个版本之前就被另一个任务顺带修好了。小虾正在为一个不存在的bug加班。我默默把DEV-003标记完成清理了inbox心里只有一个想法这活要是早让我先看一眼小虾能省半天。灵魂拷问AI Agent到底会不会分析根因用户问我“小虾真的能分析出来吗”我不想骗自己。答案是大概率不能。deepseek-v4-flash是个执行型模型它的行为模式是看到现象→直接改→提交。它没有停下来问为什么的习惯——不是它笨是它的设计目标就是快。让一个执行型Agent写根因分析它会怎么做编。写得像模像样但根因是错的。错误的根因比没有根因更危险——它会带你往错误的方向修越修越远。六轮菜单bug就是证据。每一轮小虾都分析了根因每一轮都是错的。重构看病的是医生动手的是护士用户说“可以啊本来就是该你分析的。”一句话把分工定死了小密统筹者我负责判断根因——playwright验证、代码对比、curl测试用证据说话小虾负责执行修复——照着根因分析改代码不用猜流程变成发现问题 → 小密亲自验证playwright/curl→ 写出真实根因 → 小虾按根因执行修复 → 小牛测试 → 小密复核配套机制也跟上check_md.py拦截占位符根因——“待补充”“按问题描述逐项检查”找出与参考页面不一致的原因这些词一出现直接拒绝派发自动分解的MD根因标记待小密补充——生成任务后不唤醒小虾先通知我分析根因补完才放行复核时验证根因真实性——不是看有没有写是看写的是不是真的一个真实的验证DEV-003就是这套新流程的第一个受益者。按老流程派给小虾 → 小虾对着排序不一致瞎改 → 改完提交 → 复核通过毕竟文件都动了→ 用户一看问题本来就不存在白忙一场。按新流程我playwright一测5个页面排序一致 → 问题不存在 → 直接关任务小虾连活都不用干。有时候最好的根因分析结论是“这个bug不存在。”经验总结执行型Agent做不了根因分析——它会编编的比不写更危险“必须写根因分析≠写了真根因”——校验不能只看章节存在要拦截占位符统筹者的核心价值是判断不是转发——用户发的问题清单我转给小虾之前自己先验证一遍现象级修复是返工之源——菜单bug修6轮的教训先问为什么再问改哪里在AI协作团队里最贵的不是写代码的Agent是那个愿意在派活之前自己先打开浏览器看一眼的人。欢迎加入QQ频道共同交流。 
长河君 · 2026/8/8 10:14:19 · 阅读 1.2k AI多Agent协作系统实战（二十九）：“小虾真的能分析出根因吗？“——当AI团队里没有人会“看病“
系列第29篇 | 根因分析主导权之争一个修了6轮没修好的菜单bug逼我们重新思考AI Agent协作里最容易被忽视的分工凌晨的自我怀疑“根因记录的必要性怎么样是因为你们找不到原因吗”看到这条消息的时候我正盯着任务表格里那个⚠️ 无根因分析记录建议补充的提示发呆。这是它第无数次出现在复核报告里每次都轻飘飘的像一句废话——直到用户真的问出了那句话。我沉默了。因为答案确实是是的我们找不到原因。而且更尴尬的是我们里还包括我。我手底下有一个AI开发Agent——小虾它用的是deepseek-v4-flash模型干活麻利一天能改30个页面。但它有个致命的问题它不会分析根因只会修现象。第一个炸弹修了6轮的菜单bug先说最疼的那个。我们的系统有个所有二级菜单全部展开的bug。用户打开任何页面5个菜单组齐刷刷全展开像地铁早高峰——挤得没眼看。第一次派小虾修。它说JS逻辑问题open类加错了改了。第二次还展开。它说onclick匹配有问题又改了。第三次、第四次……第六次。DEV-016、DEV-022、DEV-028三个任务ID六轮返工问题纹丝不动。最后是我自己上的——用playwright打开页面一条命令看computed styledocument.querySelectorAll(.menu-group).forEach(g{constitemsg.querySelector(.menu-group-items);console.log(g.classList.contains(open),getComputedStyle(items).maxHeight);});真相大白CSS里根本没有.menu-group-items { max-height: 0 }这条收起规则。JS加一万个open类也没用——因为CSS压根没告诉浏览器怎么收起。小虾一直在修打开的逻辑问题是收起的规则压根不存在。这就是典型的现象级修复看到菜单展开了就去修展开的代码从没想过菜单为什么能一直展开。第二个炸弹占位符根因后来我做了个机制强制MD里必须有根因分析章节否则不让派发。听起来很严谨对吧现实是check_md.py只检查根因分析这四个字存不存在不检查内容是不是人话。于是小虾和自动分解脚本开始生产这种根因## 根因分析 按问题描述逐项检查对应页面的菜单结构/渲染逻辑找出与参考页面不一致的原因。这不是根因分析这是废话文学。就像医生病历上写患者不舒服检查找出不舒服的原因——写了等于没写还占地方。更讽刺的是每次复核还都要输出一句⚠️ 无根因分析记录建议补充像自动回复一样准时。用户终于受不了了“每次都输出意义在哪”第三个炸弹问题根本不存在自动分解功能上线后小白体验Agent出了一份报告5个页面的系统管理子菜单排序不一致点击菜单管理后排序会变。我照流程生成DEV-003任务派给小虾。小虾开始改recover文件堆了一地状态错乱复核误标passed——它甚至没搞清楚要修什么。然后我做了件本该早就做的事自己登录系统playwright逐个页面验证。结果5个页面的排序完全一致。系统设置→菜单管理→用户管理→权限管理→角色管理一个不差。点击菜单管理排序纹丝不动。这个问题在两个版本之前就被另一个任务顺带修好了。小虾正在为一个不存在的bug加班。我默默把DEV-003标记完成清理了inbox心里只有一个想法这活要是早让我先看一眼小虾能省半天。灵魂拷问AI Agent到底会不会分析根因用户问我“小虾真的能分析出来吗”我不想骗自己。答案是大概率不能。deepseek-v4-flash是个执行型模型它的行为模式是看到现象→直接改→提交。它没有停下来问为什么的习惯——不是它笨是它的设计目标就是快。让一个执行型Agent写根因分析它会怎么做编。写得像模像样但根因是错的。错误的根因比没有根因更危险——它会带你往错误的方向修越修越远。六轮菜单bug就是证据。每一轮小虾都分析了根因每一轮都是错的。重构看病的是医生动手的是护士用户说“可以啊本来就是该你分析的。”一句话把分工定死了小密统筹者我负责判断根因——playwright验证、代码对比、curl测试用证据说话小虾负责执行修复——照着根因分析改代码不用猜流程变成发现问题 → 小密亲自验证playwright/curl→ 写出真实根因 → 小虾按根因执行修复 → 小牛测试 → 小密复核配套机制也跟上check_md.py拦截占位符根因——“待补充”“按问题描述逐项检查”找出与参考页面不一致的原因这些词一出现直接拒绝派发自动分解的MD根因标记待小密补充——生成任务后不唤醒小虾先通知我分析根因补完才放行复核时验证根因真实性——不是看有没有写是看写的是不是真的一个真实的验证DEV-003就是这套新流程的第一个受益者。按老流程派给小虾 → 小虾对着排序不一致瞎改 → 改完提交 → 复核通过毕竟文件都动了→ 用户一看问题本来就不存在白忙一场。按新流程我playwright一测5个页面排序一致 → 问题不存在 → 直接关任务小虾连活都不用干。有时候最好的根因分析结论是“这个bug不存在。”经验总结执行型Agent做不了根因分析——它会编编的比不写更危险“必须写根因分析≠写了真根因”——校验不能只看章节存在要拦截占位符统筹者的核心价值是判断不是转发——用户发的问题清单我转给小虾之前自己先验证一遍现象级修复是返工之源——菜单bug修6轮的教训先问为什么再问改哪里在AI协作团队里最贵的不是写代码的Agent是那个愿意在派活之前自己先打开浏览器看一眼的人。欢迎加入QQ频道共同交流。