业务质量的度量：Benchmark 驱动的反馈环

前面几层反馈解决的都是 IT 层面的问题：代码能不能编译、测试能不能通过、系统有没有报错、环境是不是一致。但 IT 层面的正确不等于业务层面的正确。

一个推荐系统，所有测试通过，CI 全绿，部署顺利，可观测性指标一切正常。但上线后推荐的全是同一个商品。从 IT 角度看无可挑剔：接口响应快、无报错、数据库读写正确。从业务角度看完全失败。这类问题不会被测试捕获，因为测试验证的是"代码做了它该做的事"，而不是"代码做的事是不是用户需要的"。

Benchmark 提供的是业务维度的反馈通道。它度量的不是代码的正确性，而是代码产出的业务价值：推荐的精准度、搜索结果的相关性、风控模型的召回率。这些指标没有简单的通过或失败，而是一个连续的分数。修了一个 bug，benchmark 上升了 3 分。改了一个算法，benchmark 下降了 5 分。这个信号足够明确、足够快速，可以驱动持续迭代。

Benchmark 驱动的反馈环之所以重要，是因为它把团队的注意力从"代码对不对"拉到"业务对不对"。没有 benchmark 的团队容易陷入一个陷阱：所有测试都绿了，所有代码审查都通过了，但产品上线后用户不买账。测试保证的是下限（代码不出错），benchmark 牵引的是上限（代码产出多少业务价值）。

构建 benchmark 的挑战在于：业务质量的评估往往没有标准答案。代码对不对，跑一下测试就知道。推荐好不好，谁说了算？一种做法是用历史数据构建评估集：把过去已知效果好的案例作为基准，度量新版本在这些案例上的表现。另一种做法是用 A/B 测试的结果反馈回来更新 benchmark。无论哪种方式，关键是让 benchmark 成为一个 Agent 可以消费的、数字化的信号，而不是一个需要人类主观判断的定性评估。

对 Agent 来说，benchmark 的价值在于它提供了一个可以自主优化的目标函数。Agent 可以修改代码、跑 benchmark、看分数变化、决定是保留修改还是回退。这个循环不需要人类介入，但前提是 benchmark 本身足够可信、足够稳定。如果 benchmark 的噪音太大（每次跑分数都不一样），Agent 无法区分真实的改进和随机波动。如果 benchmark 和真实业务指标脱节，Agent 优化的方向可能和业务需要的方向相反。

Benchmark 的维护和演进本身也是平台工程的一部分。业务在变，用户行为在变，评估标准也需要跟着变。一个一年前设计的 benchmark 可能已经无法反映当前的业务优先级。和规约一样，benchmark 也需要持续维护，否则它会从有用的信号退化为误导性的噪音。