给 AI 补丁检查流程设定耗时预算

AI 生成的补丁越多，检查流程越容易被一点点拖慢。dev.to 的这篇文章关注一个具体风险：等待时间过长，开发者开始绕过检查。作者提出给各阶段设定耗时上限，用校准探针处理机器差异，再把超预算的检查移到后续阶段，保留检查覆盖。

目前能确认什么

这套方案假定团队已经有值得运行的检查，讨论的是如何分配执行成本。

作者按合并前、合并后、夜间三个阶段分配预算。每次运行记录各阶段的实际总耗时；某阶段连续三次超限，下一个合并窗口就优先处理预算问题。

为比较不同机器上的成本，作者提供了一个只做 CPU 运算、不访问网络和磁盘的校准探针。单项检查的 p95 耗时除以校准耗时，得到相对成本。p95 表示约 95% 的观测耗时不超过该值，比平均值更能反映偏慢情况。

但这个探针主要反映 CPU 吞吐，无法充分校准数据库访问、磁盘 I/O 或并行争用。作者也明确限制了它的适用范围。

分配脚本按成本从低到高，把检查放进还有余额的最早阶段；所有阶段都放不下时，报错退出。

我的判断

检查耗时应该成为补丁评审的一部分。

新增测试同时提交耗时数据，能让维护者看到它占用多少反馈时间。但给出的脚本只按成本排序，没有表达检查的重要程度。便宜的检查可能先占满合并前预算，关键但昂贵的检查则被后移；实际使用时，需要明确哪些检查必须阻止合并。

节选还有一处实现缺口：文字要求未测量的检查先进入夜间阶段，经过三次实测才能晋升，但展示的代码只给它一个默认成本，仍可能将其排进合并前阶段。

因此，这份脚本可以作为调度原型，尚不能直接保证文中全部规则。后移哪些检查、后移后如何处理失败，以及调度记录如何保存原因，仍要等完整内容确认。