honey-gain

Honey Gain

报告已提交的基准测试结果——绝不能猜测或报告单次会话的数字，也绝不能使用可能与基准测试结果脱节的内嵌副本。

应做事项

1. 使用时从已提交的记录重新计算——不要凭记忆复述，并且优先使用原始记录，而不是任何渲染后的表格（渲染结果会过时，记录不会）：

   cd bench && node src/report.js --stamp full-opus48 --by-type
   

   离线运行，无需 API 开销。将 --stamp full-gpt55 替换为跨提供商数据，去掉 --by-type 可查看整个测试套件。Hive 交接数据 → bench/hive/RESULTS.md。

2. 简要报告各变体的分层表：Δ LOC 和 Δ output，各自附上 p 值；判定为胜、负或平；并列出测试通过率。分层本身就是结果——代码和交接任务上的差异最大，而面向用户的输出在统计上持平（润色例外）。优先列出 Δ LOC：它直接衡量 Lever 1；而 output tokens 混合了代码与周边文本，两者并不一致（Ponytail 虽减少行数，却会长篇叙述）。

规则

• 引用差值时必须同时给出其 p 值，并将 (ns) 结果称为平局，而非胜利。每个数值都是按任务配对计算的中位数；不能引用两组总量的比值。
• 文本渲染结果（bench/README.md、results/combined.md）仅供参考。若其结果与新运行的 --stamp 计算不一致，以重新计算的结果为准——指出渲染结果未同步。
• 质量是持平，不是提升——这是诚实的说法。不要夸大。
• 成本／CO₂ 节省是建模的反事实估算，并非实测；相关内容属于 honey-eco，该项目会明确标注。不要在此处声称节省了多少美元。
• 如果有人询问这个仓库的数据：基准测试衡量的是该技能在固定任务套件上的表现，而非用户的代码库——建议运行 cd bench && npm run bench，不要进行外推。
• 诚实地说明一次局限即可：23 个由作者编写的任务，评审结果存在噪声——客观的测试通过率列才是可靠的正确性指标。
• 绝不要重新引用旧的、无法复现的 92%/78%/73% / −57%/−65%/−70% 数据，也不要引用已被取代的各组总量数据（代码 −49%、总计 −15%）——参见 bench/METHODOLOGY.md。