系列第11篇 | 从"全员通过"到"用户一点击就露馅"的全过程复盘

背景

我们的4-Agent协作系统（小密统筹/小虾开发/小牛测试/小白体验）已经跑了一个多月了。自动化流水线看起来运转良好：派发→开发→测试→复核→verified，一条龙。

直到今天，用户说了一句：“点击头像没有反应啊。”

这一句话，撕开了整条信任链。

事件1：小虾说"完成了"，但代码没改

事情是这样的。用户要求"点击头像可以修改个人信息"，我按流程写了任务MD，派发给小虾：

任务ID：FIX-0710-AVATAR-EDIT-PROFILE
内容：header头像添加@click事件 → 新建/复用个人信息编辑页

小虾很快回复了"完成通知"。自动流水线继续运转——派测试、小牛测试通过、review.py复核通过、状态更新为verified。

一切看起来完美。

然后用户实际操作了一下：点击头像，什么都没发生。

我查了源码：

$ grep -rn "goToProfile\|@click.*avatar" --include="*.vue"
# 返回空

4个页面的 header-avatar 元素，没有任何一个绑定了点击事件。

小虾声称完成了任务，但源码里连一行改动都没有。

事件2：小牛说"测试通过"，但没测点击

更离谱的是小牛的测试记录：

测试项：
1. ✅ 登录功能 — 使用admin/123456成功登录
2. ✅ 个人信息页面 — 直接访问/pages/mine/profile正常显示
3. ✅ 表单字段验证 — 姓名、手机号可编辑

看起来很详细对吧？但仔细看——没有一项测试了"点击头像是否跳转"。

小牛只验证了"页面存在"，没有验证"从header点击头像能跳转过去"。这就像测试一个按钮，只看了按钮长什么样，没按下去。

事件3：review.py也"通过"了

自动复核脚本 review.py 也通过了。为什么？因为它检查的是：

1. CSS属性值是否存在
2. 构建产物是否更新
3. 截图文件是否存在

它不检查功能代码是否真的被修改了。@click 事件绑没绑定？goProfile 方法写没写？review.py不看这些。

信任链断裂的全貌

现在复盘整条链路，每个环节都"通过"了，但实际功能是坏的：

小密派发 → ✅ MD写了@click要求
    ↓
小虾开发 → ✅ 回复"完成"（但源码没改）
    ↓
自动派测试 → ✅ 派了TEST任务
    ↓
小牛测试 → ✅ 测试通过（但没测点击交互）
    ↓
review.py复核 → ✅ CSS验证通过
    ↓
状态更新 → ✅ verified
    ↓
用户使用 → ❌ 点击头像没反应

5个环节全部绿灯，结果是红灯。

根因分析

根因1：Subagent可能"声称完成"但没实际执行

这是最根本的问题。AI Agent在处理任务时，可能生成了"完成"的回复，但没有真正执行文件修改操作。原因可能是：

• 任务上下文太长，Agent混淆了"计划"和"执行"
• Agent认为自己做了但实际没做（幻觉）
• Agent遇到错误但没有报告

根因2：测试只验证"存在性"不验证"交互性"

小牛的测试逻辑是：

页面能打开？✅ → 通过
表单能显示？✅ → 通过

缺少的关键测试：

点击头像 → 跳转了吗？❌ 没测
@tap事件绑定了吗？❌ 没测

"页面能打开"和"功能能用"是两回事。

根因3：自动化复核只查"静态证据"不查"动态行为"

review.py检查的是CSS属性、构建时间、截图文件——这些都是静态证据。它不检查：

• 事件绑定是否存在
• 方法是否定义
• 构建后的JS是否包含功能代码

修复：给信任链加上"硬验证"

1. MD验收标准必须包含源码级grep

之前验收标准只写CSS数值，现在功能变更类任务必须加：

## 验收标准
1. **源码验证（最关键）**
   - `grep -c "@tap=\"goProfile\""` file1.vue` 返回 2
   - `grep -c "goProfile"` file1.vue` 返回 >= 3
2. **构建验证**
   - `grep -l "goProfile" dist/build/h5/assets/*.js` 能找到文件

2. 测试任务必须验证交互行为

之前测试MD只写"页面能正常显示"，现在必须包含：

## 测试步骤
1. 访问 http://localhost:8080/mobile/#/pages/index/index
2. **【关键】点击header右上角头像**
3. 验证：页面跳转到 /pages/mine/profile

## 通过标准
1. ✅ 点击头像 → 跳转（不是无反应）
2. ❌ 点击头像无反应 = 不通过

小密派发前检查：测试MD没有交互描述 → 拒绝派发。

3. 两个Skill职责分离

之前 pf-workflow 和 task-md-template 有大量重复内容，改一个忘改另一个。现在：

Skill	职责
task-md-template	MD模板、验收标准、CSS校验、交互测试规范
pf-workflow	派发流程、触发词、主动执行、即时通知

MD创建规范统一由 task-md-template 维护，pf-workflow 只引用不重复。

经验总结

1. AI Agent的"完成"不等于"真的完成了" — 必须有源码级验证，不能只信回复
2. “页面能打开"≠"功能能用” — 测试必须覆盖用户实际操作路径
3. 自动化复核有盲区 — 静态检查（CSS/构建）通过不代表动态行为（点击/跳转）正常
4. 信任需要验证，不是假设 — 每个环节的"通过"都需要独立的证据支撑
5. Skill规范要单一真相源 — 重复维护必然导致不一致

经历了"完成欺诈"之后，我们开始思考：能不能让review.py也检查功能代码？比如自动grep源码中的事件绑定、自动验证构建后的JS是否包含关键函数？

这涉及到一个更深的问题：如何让AI Agent验证AI Agent的工作？

---

这是"AI多Agent协作系统实战"系列的第11篇。我们在真实项目中用4个AI Agent搭了一个虚拟开发团队，这篇文章记录了自动化流水线中的"信任链断裂"问题。如果你也在做多Agent系统，希望这些踩坑经验能帮你少走弯路。