问题
AI 评测研究者和治理/政策研究者面对的问题是：模型评测结果“reported across many formats, platforms, and outlets, often without enough information to reproduce them”。同一个模型在不同基准、不同平台上的成绩格式各异，缺少配置和环境信息，无法复现也无法横向比较，研究者要靠人工翻找零散报告来拼凑结论。第二条信号显示的是相邻的同类痛点——自由文本提交质量低、难以分拣——但已被 GitHub 用结构化表单原生解决，说明“结构化提交 + 必填字段”是被验证的解法方向。
目标用户
AI 评测研究者和治理/政策研究者（信号 1 的 target_user）。这是一个偏学术/治理的细分人群，规模不大但集中，活跃于基准测试社区。付费能力未在信号中得到验证。
解决方案
- 结构化报告 schema：提交表单强制填写结果、评测配置、环境信息（GitHub 信号证明了“必填字段”对治理低质量提交有效）
- 配置完整性检查：AI 检查提交是否包含复现所需信息（随机种子、硬件、提示词等），缺失项自动标红
- 跨基准检索与对比：按模型、基准、日期统一检索，生成可复现性评分
- AI 提取与规范化：用模型从已有的散乱报告（论文、博客、 leaderboard 页面）中自动抽取结果并映射到标准 schema
为什么是现在
信号显示评测生态在快速膨胀——FrontierMath、HealthBench、SWE-Bench Pro、Terminal-Bench 2.0 等大量基准涌现，结果散落在多种格式和平台上，碎片化痛点刚刚成型；同时 GitHub 信号表明 AI 生成的低质量提交正在泛滥，社区开始接受“结构化提交 + 强制字段”的治理方式，做标准化报告的时机窗口刚刚打开。
MVP 范围
第一版：一个带标准报告 schema 的提交表单（结果、配置、环境信息为必填项）、一个可按模型/基准检索和对比的结果库、以及一个简单的配置完整性检查器。不做：自动复跑基准做结果验证、多平台自动抓取聚合、不做 GitHub 漏洞报告类场景（该需求已被平台方原生功能解决）。
风险
- 在位者风险：Every Eval Ever 和 Evaluation Cards 已作为开放平台提供报告 schema 与核验结果，社区可能已默认采用其标准，后来者难以获取提交量。
- 付费风险：目标用户是研究者和政策研究者，习惯于免费开放的学术基础设施，商业化路径不明。
- 网络效应冷启动：平台价值取决于评测结果的覆盖面，初期没数据就没用户、没用户就没提交。
- 信任与核验：如 GitHub 信号所提示，AI 生成的低质量提交泛滥，缺乏核验机制会迅速污染数据可信度。
- 市场过小：这是学术治理类细分场景，天花板可能撑不起一个独立产品。
已有产品
| 产品 | 定位 | 价格 |
|---|---|---|
| Every Eval Ever | 信号中提到的开放平台，提供经核验的结果与配置信息，是本机会最直接的在位者 | — |
| Evaluation Cards | 信号中提到的开放报告模式与平台，覆盖了结构化报告的核心思路 | — |
信号证据
这张卡片依据的原始讨论。摘录保持原文，点“原文”查看上下文。
GitHub Changelog10月1日新能力
“A single free-text box made it easy to submit low-quality or AI-generated reports and hard for you to find the signal in them.”
Private vulnerability reports received via a single free-text box were often low-quality or AI-generated and hard to triage; GitHub now offers structured forms with required fields including reproducible proof of concept.原文
Hugging Face Blog9月22日新能力
“Yet results are reported across many formats, platforms, and outlets, often without enough information to reproduce them.”
Evaluation results are reported across many formats and platforms without enough information to reproduce them.原文