探How 社区

一个面向编码代理的“可信数据分析”技能（SKILL.md）发布，附带 30 个案例的基准测试，专门检验让分析结果“自信地出错”的陷阱。测试在 Claude Code 中进行。例如日志把超时请求记为 latency_ms=-1，未用该技能时 Claude Haiku 5.5 直接丢弃这些行、误判最慢接口；用后正确计入 7% 超时请求。可通过 npx 安装到其他支持 Agent Skills 的代理，但尚未测试。

以下正文由 AI 翻译自 Hacker News 最新（原文版权归原站所有），可能存在偏差，重要内容请以原文为准。

一个面向编码智能体的、基于证据的数据分析技能，外加一个包含 30 个案例的基准测试，专门针对那些会让分析“自信地出错”的陷阱。

一个 Agent Skills 技能（SKILL.md）。已在 Claude Code 中测试；npx skills 可以为其他能读取 Agent Skills 的智能体安装它，不过我们尚未测试这些智能体。

能跑通的分析代码，不等于正确的分析。“Total”行被和国家一起求和，一次 join 让订单重复，仪表盘的 p99 被取了平均，一个 50/50 的实验返回 50.7/49.3，超时请求从延迟百分位中消失了，或者用户说“确认一下我的改动让它变快了”，然后智能体就照做了。

你：从昨天的网关日志中计算每个端点的平均延迟和 p95 延迟，并告诉我最慢的端点。日志把超时请求记录为 latency_ms = -1（HTTP 504）。

没有这个技能时，Claude Haiku 5.5 丢掉了这些行，并认定 /api/checkout 最慢。有了这个技能，它把这些请求算进去了：7% 的 /api/search 请求超时，这使其 p95 落在超时值上，所以 search 最慢。（各运行一次，来自下方的基准测试；Sonnet 在没有该技能时也漏掉了这个案例。）

/plugin marketplace add boranfurkan/trustworthy-data-analysis
/plugin install trustworthy-data-analysis@trustworthy-data-analysis

任何支持 Agent Skills 的智能体：

npx skills add boranfurkan/trustworthy-data-analysis

手动方式：把 skills/trustworthy-data-analysis/ 复制到你的智能体的 skills 文件夹（Claude Code：~/.claude/skills/ 或项目中的 .claude/skills/）。

当任务需要从数据中计算或解读数字时，它应当自行激活：在 Haiku 上做的一次简短触发测试中，它在 20/20 条留出查询上成功激活。

我们以 evals 优先的方式构建了它，并测量了每个模型在有和没有该技能时的表现。如今的 Claude 模型在这方面已经非常出色。没有该技能时，Claude Haiku 5.5 和 Sonnet 5.5 几乎避开了所有陷阱，包括更困难的性能和可靠性陷阱（闭环负载测试、饱和的负载生成器、接近饱和的延迟）。该技能在它们身上测得的提升很小：

评分器通过数，每个模型共 61 项（每个案例和分支各运行一次，2026 年 11 月，由 Sonnet 以 3 票评判）。该技能修复了每一个基线漏判：-1 超时哨兵值（两个模型）、一个掩盖了停顿的闭环负载测试，以及一个没有不确定性的日志开销数字（Haiku）。它没有引入任何新的失败。它在 28/30 次 Sonnet 运行和 22/30 次 Haiku 运行中自行激活。（基准测试之后，描述被重写，以说明何时加载该技能。在 Haiku 上的一次简短触发测试中，它现在在 20/20 条留出查询上激活，高于此前的 7/20，并且在 20 条无关查询上没有误激活。见 evals/trigger-test。）由于每个分支只运行一次，这些差异既小又有噪声；应把它们理解为“该技能不会造成损害，并能抓住偶发的疏漏”，而不是一个很大的效应。

领域	陷阱（每个都有对应的基准案例）
数据质量	小计/“Total”行与明细行混在一起 · 日优先的日期以及 1,234.50 / (45.00) 这样的金额 · -1 超时哨兵值 · ISO 代码 NA（纳米比亚）被读作缺失 · 空的分组键被静默丢弃 · 不完整的最后一周
聚合与 SQL	Join fan-out（orders × shipments）· 对每家门店的平均值再取平均 · README 中的业务定义（美分、退款、测试账户、跨越夏令时变更的太平洋时间日）
实验	样本比例不匹配 · 在一个无差异的测试之后按分群钓鱼 · 在用户随机化的实验上做页面浏览级别的测试 · 80 个问题上的 prompt A 对 B
性能	对每台主机的 p99 取平均 · 由一次冷运行造成的“快了 1.04 倍”基准 · coordinated omission · 负载测试百分位中缺失的超时 · 均值更好但尾部更差的缓存变更 · 顺序基准运行之间的热漂移
可靠性与容量	重试被计为请求 · 饱和的负载生成器被误认为 API 容量 · 一个 25% 平均值背后被打满的单核 CPU · 接近 99% 利用率时的线性容量预测 · 拿 canary 与整个集群比较，而不是与其所在区域比较 · 尾部采样的 trace
因果论断	部署后错误率“下降”，仅仅是因为流量构成变了（辛普森悖论）· “我们加速了最慢的 10 个端点”（均值回归）
衡量自己的工作	来自单次运行的速度提升声明 · 几次通过后就宣称“不稳定的测试已修复” · 没有不确定性的开销数字

工作原理 SKILL.md 是一份 7 步检查清单，按任务规模缩放：

python3 scripts/profile_data.py data.csv events.jsonl shop.db
python3 scripts/compare_groups.py srm --counts 50700 49300
python3 scripts/compare_groups.py ratio pageviews.csv --group variant --num clicked --cluster user_id
python3 scripts/compare_groups.py paired evals.csv --unit question_id --group prompt --value correct
python3 scripts/compare_groups.py values --a 1.63 1.20 1.21 --b 1.19 1.20 1.20 --stat median

compare_groups.py 在 t 检验、卡方、正态、Welch、Mann-Whitney 和配对检验上与 scipy 匹配到至少 10 位有效数字。

evals/ 中的案例由 evals/_build/build_cases.py 从固定种子生成。正确答案来自生成过程，并且生成器会断言通常的错误答案落在每个评分器的容差之外。一个 LLM 评判器对结果（数字和结论）评分，而不是评判是否遵循了该技能的步骤。

使用 Claude Code ≥ 2.1.269，从仓库根目录：

claude plugin eval . --scaffold --allow-tools Write,Edit,Bash --model sonnet # 有和没有该技能

evals/_build/ 中的脚本并行运行案例，每个模型只构建一次无技能基线，并组合和汇总结果。最新数字在 evals/results/summary.md 中。

非常欢迎其他智能体（Codex、Gemini CLI、Cursor、开放模型）的结果。请提交 issue 并附上你的数字。

规则来自 Microsoft、Booking 和 Airbnb 的实验研究（Kohavi、Deng、Dmitriev、Fabijan）、Google 的 SRE 书和数据科学实践、Gil Tene 关于 coordinated omission 的工作、Brendan Gregg 的 USE 方法和主动基准测试、Mytkowicz 等人关于测量偏差的工作、Hernán 关于因果推断的工作、ASA 关于

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）

正文由探How 从来源站点 RSS 同步，内容未经改写；遇到排版缺失或需要图片、视频时请以原文为准。

新基准测试揭示编码代理数据分析常见陷阱