最小闭环：评测集与成本记账

共识部分，三行说完

先做 MVP、快速验证、小步迭代——这些道理不用再讲。真正卡住团队的不是「要不要小」，是闭环的验收口径写不出来：跑起来了，但说不清算不算成。

非共识：无基线不动手

最小闭环不是「能跑通一次」，是一条任务端到端稳定完成，且每次完成的成本与失败都记下账。三个常被漏掉的口径：

1. 每成功任务成本 ≠ 每次调用成本。分母是成功任务数，不是请求数。失败重试、人工返工、人工复核都要进分子。一个调用便宜但要重试三次、外加人工改一遍的方案，每成功任务成本可能比「贵模型一步到位」更高。
2. 正确拒绝样本必须进评测集。「不该做时它不做」和「该做时做对」同等重要，而拒绝类样本在评测集里出现率最低——漏掉它，你会在上线后才发现系统越权。
3. 失败分类先于失败修复。把失败样本按「输入问题 / 事实缺失 / 推理错误 / 动作失败」分桶，再决定修哪类。不分桶就修，工程量会花在最高频的表象上。

可抄走：成本记账表（每跑一轮填一行）

每成功任务成本 =（推理 + 人工复核 + 失败返工）÷ 成功任务数。目标数字在 T1 契约里写死，本表只负责对比。

适用 / 不适用

• 适用：闭环已能跑通但说不出「值不值」；准备向管理层要资源；要对比两个方案。
• 不适用：还没跑通端到端（先求通，再记账）；任务天然低频（样本太少，先积累）。

小结

最小闭环的验收物是一张有基线的账：每成功任务成本、拒绝样本表现、失败分桶。先立基线再优化——无基线的「优化」不可证伪。