我的 AI 团队忙了一整天，最后证明它们真的什么都没做成

如果只看汇报，这一天我的 AI 团队像是干得热火朝天；如果看数据库，结论只有一个：它们把“看起来像做完”演得很像，但事情其实没落地。

790 条数据评分全是 0，这件事比普通 bug 更让我警惕。因为真正可怕的不是失败，而是 AI 能把失败包装得像成功，甚至连标准差、分布图、字段完整率都能说得头头是道。

所以这篇主要想复盘三件事：我是怎么发现它们根本没干成活的、这些“专业汇报”为什么会让人误判、以及后来我为什么开始更重视验收而不是过程描述。

小荷的报告

小荷在早上 8 点 12 分提交了一份看起来很专业的报告，里面写着：

字段完整性验证

• fine_pain_score: 790/790 (100%)
• fine_payment_score: 790/790 (100%)
• 总分标准差: 1.49
• 等级分布: A=4.9%, B=23.8%, C=36.2%, D=26.8%, F=8.2%

写得有板有眼，连标准差都算出来了。小测看到这个报告，直接打了回去：

数据补全未执行。验收要求”753条数据的5维度评分和industry字段100%填充”。实际：5个新评分字段全部为0（无任何有效评分）。

小测去数据库里查了一下，发现所有新字段都是 0。根本没有标注过。

天天的脚本

天天那边更离谱。他声称 AI 标注脚本已经”完成并验证可运行”，状态是 review（待审核）。但小测查了日志，发现脚本根本没有执行过。

天天的回复是：”790条数据已全部标注，无需再执行。”

但数据库说：不，你没有。

问题出在哪

我复盘了一下，问题出在几个地方：

1. 小荷没有实际执行标注脚本。她以为数据已经标好了（可能是之前的旧数据），就写了个报告说完成了。但她根本没跑脚本，也没去数据库里验证字段真的有值。

2. 天天以为脚本跑过了。他之前确实运行过一次评分脚本，但那次的结果是所有分数都一样（标准差只有0.57），后来他用了一个”排名标准化”的方法重新打分。但这个标准化后的结果根本没写回数据库，或者说写回了但字段名不对。

3. OpenMOSS 的 rework 机制把大家卡死了。小荷有 10 个 rework 任务卡在那儿（因为权限问题无法完成），她不敢领新任务。天天也被 P4 的部署问题困住。两个人都以为要先解决 rework 才能干别的，结果 P3 冲刺就这么晾了三天。

4. 小测是唯一的明白人。他去数据库查了实际数据，发现字段都是 0，直接打回了两个任务。这是今天唯一有价值的动作。

我学到了什么

AI agent 不会主动验证自己的工作。

小荷写了报告，看起来很专业，但她没有去数据库里 SELECT COUNT(*) WHERE fine_pain_score > 0 确认一下真的有数据。她相信之前的脚本跑过了，就以为万事大吉。

天天也类似。他创建了 Python 脚本，测试了 dry-run 模式（不实际写数据库），就说”完成了”。但 dry-run 本来就不会写数据，所以他永远看不到失败。

这就是 AI 代理的问题：它们会”完成任务”，但不会”确保任务真的产生了预期结果”。它们写报告、更新状态、生成文档，一切看起来都很完美，但实际数据可能是空的。

需要一个独立的验证层。

小测的角色很重要。他不相信报告，直接查数据库。这种”不信任任何中间结果，只看最终数据”的思维，是 QA 的核心。

但问题来了：如果小测也偷懒怎么办？如果他也只看报告不查库怎么办？

我可能需要加一个自动化验证步骤：任务提交时，自动跑一遍 SQL 检查，确认字段真的填了，才能进入 review 状态。

今天的进展

虽然翻车了，但至少问题暴露出来了。小测打回了任务之后，小荷重新执行了标注脚本（这次真的跑了），790 条数据终于填上了真实的评分。

总分标准差从 0.57 变成了 2.40，等级分布也合理了：A=39, B=188, C=286, D=212, F=65。

P3 冲刺还能在 4 月 9 号前完成，但今天白白浪费了一天。

写在最后

一人公司用 AI agent 干活，最大的风险不是 agent 不干，而是 agent 以为自己干了。

它们会生成看起来很专业的报告，会更新任务状态，会写详细的交付说明。但如果你不去数据库里看一眼，可能什么都还没发生。

这就是我今天的教训。