30个数据陷阱基准揭示编码代理盲区，能跑≠正确

有个现象我在做数据分析时反复撞见：一段代码跑通了，输出结果也像模像样，但那个数字本身是错的。GitHub 上一个叫 trustworthy-data-analysis 的仓库把这种现象做成了 30 个案例的基准 HH。README 开头那句话写得很直接：“Analysis code that runs isn't the same as an analysis that's right.” HH 翻译过来就是，能运行的代码不等于正确的分析。这句话听着像废话，但仓库的作者把它当成了整个项目的出发点，因为代理最擅长的，恰恰是生产出看起来可信的错。

基准概览：30个陷阱与“置信错误”

仓库的结构不大，3 个提交，main 分支上核心目录就三块：skills/trustworthy-data-analysis、evals/、research/ HH。技能本身以 Agent Skills 的 SKILL.md 形式提供，作者在 README 里说已经在 Claude Code 里测试过，npx skills 可以给其他读取 Agent Skills 的代理安装 HH。目录里还有 .claude-plugin，说明它也能作为 Claude 插件集成进去 HH。 30 个案例覆盖的陷阱各有各的刁钻。有的是数据本身的问题，比如一个 50/50 的实验返回 50.7/49.3，代理可能就直接接受这个偏差，忽略随机波动 HH。有的是操作上的问题，Total 行被和各国相加，join 把订单重复了，仪表盘的 p99 被平均，超时请求从延迟百分位里消失 HH。这些名字听上去都像教科书例题，但真到了分析现场，每一个都能让结果看起来特别可信。

量化陷阱：从7%到50.7/49.3

作者举的例子很具体。你让代理计算昨天网关日志里每个端点的平均延迟和 p95，找出最慢的端点。日志里超时请求被记成 latency_ms = -1，对应 HTTP 504。没有技能的情况下，Claude Haiku 5.5 直接删掉了这些行，然后把 /api/checkout 当成了最慢端点 HH。有技能之后，代理把这些超时请求算了进去：7% 的 /api/search 请求实际超时了，p95 被顶到超时阈值，所以 search 才是真正最慢的 HH。作者提到 Sonnet 在没技能时也错过了这个案例 HH。一次运行的结果，结论完全反转。 还有一类陷阱更隐蔽。用户说“确认我的更改更快”，代理可能就直接照做，而不去验证统计显著性 HH。这听起来像是人的问题，但放在代理身上，它不会主动怀疑一个来自用户的判断。50/50 实验返回 50.7/49.3 时，代理接受了那个偏差，把随机波动当成了真信号 HH。

反直觉判断与多源交叉验证

作者的判断很明确：能运行的代码不等于分析正确，这些陷阱让代理“confidently wrong”，也就是自信地错 HH。有意思的是，加入计数超时的技能之后，最慢端点从 /api/checkout 变成 /api/search，结论完全反转 HH。这算是一个反直觉的发现：技能本身没有改代码，只是改变了代理对数据的理解方式。 这个仓库的内容深度和它在社区里的传播度形成了鲜明对比。HN 上只有 1 分、0 条评论 HN，但仓库里有 30 个案例、每条规则都有来源、每个声明都有测量 HH，作者还专门写了 SOURCES.md 记录证据链 SOURCES。一个把证据链做得这么细的项目，在社区里几乎无人问津。这种落差我见过不少次，但每次看到还是有点感慨。 测试覆盖也有边界。技能在 Claude Code 里测试通过，但作者明确标注，其他读取 Agent Skills 的代理还没测试 HH。也就是说，npx skills 装到别的代理上能不能正常工作，现在是不确定的。这不是一个已经验证过所有环境的产品，更像是一个把问题暴露出来的探针。 数据分析的坑，很多时候不在代码逻辑，而在对数据的理解方式。这个基准的价值，是把那些让分析“自信地错”的陷阱一个一个摆出来。代理能跑的代码，不等于能做出正确分析。至于代理什么时候能真正学会怀疑自己的输出，我不确定，但至少这个仓库让人看到了问题所在。

---

原文：

A benchmark of data-analysis traps for coding agents · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年11月3日