怎样判断 AI 实验的证据强弱

一篇笔记贴了十个链接，也可能大部分仍是观点。判断它靠不靠谱，要看每个来源到底支持了哪句话。

规范可以说明 API 是怎样定义的，不能证明每个实现都正常。基准测试可以报告某套配置下的结果，不能替所有项目选工具。个人测试可以影响自己的工作流，但一次运行不会自动变成普遍规律。

让证据和论断对得上

笔记声称什么	通常需要什么	仍然不能证明什么
协议或 API 采用某种行为	版本化规范或当前官方文档	实现一定完整、安全或能够互操作
模型或产品能完成某项任务	模型卡或文档，加上针对该任务的测试	在其他场景也普遍更强
某个基准结果	任务与测试框架版本、模型、日期、配置和结果记录	能迁移到另一仓库、语言或机器
一次个人观察	可复现的运行记录和保留的失败案例	群体层面的表现
一项推荐	选择标准、替代方案、成本和失效阈值	所有人都有同一个最佳选择
一项预测	假设、情景和不确定性	未来已经得到验证

官方文档适合确认接口，也适合确认厂商自己声称产品能做什么。用它评价质量时要更谨慎。独立基准减少了厂商偏见，却会带来任务选择、配置和发表门槛上的偏差。读一份基准成绩时怎样核对任务版本、配置和逐题差异，见模型卡与基准成绩。

先看比较里漏掉了什么

读一份对比时，我会先找它没有测什么。遗漏的部分往往比小数点后那一位更重要。

时间偏差最容易举例：它把某一天的快照写成长期排名。OpenRouter 6 月发布的免费 API 对比文章，到 8 月已有两项过时（现状见模型与 API 选型雷达）。Cerebras 的免费层变成了要先绑定支付方式、只给 5 美元额度的 30 天试用，GitHub Models 也在 7 月 30 日全面退役。

其余几种偏差也各有固定的样子。选择偏差会排除不方便的模型、语言、工具或失败运行；厂商偏差会把产品定位写成测试结论；基准偏差包括数据污染、任务太窄、指标选择，以及把模型能力和测试框架混在一起。

硬件偏差会藏起对内存、功耗、加速器和网络的假设；语言与领域偏差会把英语或 Python 的结果套到从未测试的环境；自动化偏差会把流畅输出或 Agent 的完成提示当成正确证据；工作流偏差会把个人对终端、IDE 或自动化的偏好当成普遍建议。

列出这些偏差不会让笔记变得中立，作用只是把剩下的立场摊开，方便别人反驳。

把推荐写成一个可以检查的决定

一份很短的论断记录，就能让缺失信息暴露出来：

claim: MiniCPM5-2B is a usable local model for triage and simple tool steps
kind: recommendation
as_of: 2026-10-29
facts:
  - model card lists 2.5B parameters, a 131,072-token context and Apache-2.0
  - official GGUF, MLX and GPTQ builds exist
  - model card recommends SGLang with the minicpm5 parser for tool calls
vendor_claims:
  - LiveCodeBench v6 score of 69.1
assumptions:
  - my runtime parses its tool-call template correctly
  - the 4-bit build keeps enough triage quality
missing_evidence:
  - accepted-result rate on my triage tasks
  - tool-call validity outside SGLang
alternatives:
  - Qwen3-4B
  - hosted small model for escalation
falsifier: label or tool-call failures above the task threshold

这条记录里的事实来自 MiniCPM5-2B 的模型卡。厂商分数单列一项，本地假设另列一项，最后一行写明什么结果会推翻推荐，复查日期也就跟着它定。它比“这个模型很强、很有潜力”有用得多。

我的阅读