怎样判断 AI 实验的证据强弱
本页帮助读者在看过方法与结果之后，判断一项论断能成立到什么程度。模型卡与基准成绩负责识别模型交付物，数据与评估负责组织实验；这里关注证据到结论之间的推断。
一篇笔记贴了十个链接，也可能大部分仍是观点。判断它靠不靠谱，要看每个来源到底支持了哪句话。
规范可以说明 API 是怎样定义的，不能证明每个实现都正常。基准测试可以报告某套配置下的结果，不能替所有项目选工具。个人测试可以影响自己的工作流，但一次运行不会自动变成普遍规律。
让证据和论断对得上
官方文档适合确认接口，也适合确认厂商自己声称产品能做什么。用它评价质量时要更谨慎。独立基准减少了厂商偏见，却会带来任务选择、配置和发表门槛上的偏差。
先看比较里漏掉了什么
读一份对比时，我会先找它没有测什么。遗漏的部分往往比小数点后那一位更重要。
- 选择偏差会排除不方便的模型、语言、工具或失败运行。
- 厂商偏差会把产品定位写成测试结论。
- 基准偏差包括数据污染、任务太窄、指标选择，以及把模型能力和测试框架混在一起。
- 时间偏差会把某一天的快照写成长期排名。
- 硬件偏差会藏起对内存、功耗、加速器和网络的假设。
- 语言与领域偏差会把英语或 Python 的结果套到从未测试的环境。
- 自动化偏差会把流畅输出或 Agent 的完成提示当成正确证据。
- 工作流偏差会把个人对终端、IDE 或自动化的偏好当成普遍建议。
列出这些偏差不会让笔记变得中立，作用只是把剩下的立场摊开，方便别人反驳。
把推荐写成一个可以检查的决定
一份很短的论断记录，就能让缺失信息暴露出来：
claim: gpt-oss-20b can be a practical local agent model on a 16 GB machine
kind: recommendation
as_of: 2026-08-10
facts:
- provider says the MXFP4 model runs within 16 GB of memory
assumptions:
- runtime supports Harmony and the exact quantization
- context and KV cache stay within the remaining budget
missing_evidence:
- accepted-result rate on my coding tasks
- latency and peak memory on my hardware
alternatives:
- smaller dense model
- larger model on 24 GB
- hosted model for escalation
falsifier: repeated tool-call or patch failures above the task threshold
这里把厂商说法和本地假设分开，也写明什么测试会改变推荐。它比“这个模型很强、很有潜力”有用得多。
hash 能证明的事情没有想象中多
保存一份按内容寻址的来源，可以让以后的人重新检查。精确摘录匹配能证明引用的字确实出现在那份文件里。
它证明不了文件真的来自声称的发布者，也证明不了内容仍然有效、上下文没有改变意思，或这段话足以支持结论。这些问题仍要检查来源并阅读语义。
我会把四种状态分开：
- 事实有明确来源，也有能支持它的段落；
- 发现线索值得继续查，但还没验证；
- 假设是可以测试的解释或预测；
- 偏好取决于目标和取舍。
不是每篇笔记都需要存下每个网页的完整副本。主张变化快、争议大、复现昂贵或可能带来实际伤害时，完整证据链才更值得做。
让审查小到真的会用
先抽出论断，再润色文字。给每条论断分类，然后问它的证据是否足以支撑后面的决定。找一个可信的相反案例，把失败运行和成功运行放在一起，也要把长期有效的概念和带日期的产品快照拆开。
最后写清楚什么结果会改变结论，再据此安排复查日期。审查做到这里，事实、测试结果和个人判断应该仍能一眼分开。