大多数 AI 项目失败的姿势惊人地相似：需求阶段说「做一个智能助手」，开发三个月，上线时业务方说「这不是我要的」，然后开始无限返工。根因只有一个——没有在开工前定义什么叫「好」。
先出考卷，再写代码
我们把软件工程的测试先行推到极限：需求阶段的产出不是 PRD 文档，而是量化验收标准 + 三层 Benchmark：
- 知识诊断层：领域知识分层评测，量化「模型知道多少、缺多少」；
- 能力诊断层：给了资料也答不好的，才是真正需要微调的能力缺口；
- 端到端业务层：真实业务场景的完整链路测试。
更关键的是生成方式：70% 基于客户真实素材改写，30% AI 扩展衍生，再过四重过滤（事实校验、难度校准、反事实验证、污染检测）。考卷不是拍脑袋出的，也不是模型自嗨生成的。
一份标准，三处复用
这是整个方法论的杠杆点：
- 需求基线——开工前双方签字确认「达到什么分数算验收通过」；
- 编码验收——夜间无人值守批量编码时，机械执行同一套标准，三态入账（过 / 挂 / 待审）；
- 回归判定——每次迭代后重跑，分数下降自动拦截发布。
交付扯皮消失了，因为「好不好」在开工前就已经变成了数字。
分数即代码
在我们的 Benchmark 平台上，每次评测结果自动记账入库，历史可追溯；判分器改动必须重跑自检门禁——连「裁判」都在被监督。这不是偏执，是让信任建立在可审计的事实上。
如果你正打算启动一个 AI 项目，第一个交付物不应该是代码，而应该是一套考卷。愿意接受这个纪律的供应商，才值得把项目交给它。