过去两个月,我用同一套 fact-check 流程核了 11 篇报告:独立 subagent 在干净上下文里逐条比对原文,发现问题就改,再换一个新 subagent 重核,直到零问题。 每一轮都老老实实记进了项目的 STATUS。这些数字不是跑分,是真实工作流里攒下来的账本。
横轴是 11 篇报告按时间排开,纵轴是它们各自跑到「全部通过」用了几轮。前六篇在 3-4 轮高位反复横跳,过了 05-29 那条线,几乎贴着「1 轮」走。
每篇报告的核查轮次都来自它自己的 STATUS 记录,不是事后凑的。哪一轮发现了几个问题、是事实错还是措辞不准,当时就写下来了。
| 报告 | 轮次 | ||
|---|---|---|---|
| AI 原生创业的失败模式 05-15 |
3 | ||
| Claude Code 啃大型代码库 05-21 |
4 | ||
| Anthropic 重建销售组织 05-22 |
3 | ||
| Agent 友好的 CLI 05-26 |
3 | ||
| Agent 原生的验证 05-26 |
3 | ||
| 零信任 AI Agent 05-28 |
3 | ||
| ━━━━ 切到 OPUS 4.8 · 2026-05-29 ━━━━ | |||
| 用 LLM 给源码做安全 05-29 |
1 | ||
| 动态工作流 05-30 |
1 | ||
| 如何"圈住"Claude 06-01 |
1 | ||
| 动态工作流 · 模式篇 06-03 |
2 | ||
| LLM 攻击导航器 06-04 |
1 | ||
要说服力,光看平均数不够。挑一篇数字密度最吓人的——它最容易翻车,结果一轮就过。
全篇塞满了精确读数:账号样本量、观测次数、攻击成功率的前后变化、相关系数、两组评分的对比、ARiES 三维分值…… 以往只要数字一多,subagent 总能挑出几处搬运时串了行或抄错小数点。这次独立核查重点就是逐个数字回原文比对,结果一处没动。
832 个账号
13,873 次观测
33% → 56%
r = 0.28
56.4 vs 46.8
ARiES 三维分值