AI代码提速后，验证基础设施究竟该证明什么

Blacksmith于2026年10月21日宣布C轮融资，使持续集成（CI）基础设施再次受到关注。CI负责在代码变更合入之前完成构建和检查。借这个机会，更值得追问的是：团队购买更快的验证能力时，究竟买到了什么？公司公告

对于使用编程代理的团队，一个可能出现的约束是，写出补丁所需的时间减少了，判断补丁是否值得成为产品一部分的时间却没有同步下降。这是本文的分析命题，并不意味着所有团队都已遇到同一种瓶颈。测试快速且可靠的小型应用，可能仍受产品决策限制；大型代码库即使机器充足，也可能缺少真正理解故障模式的人。

这里需要区分两项成本：等待证据的成本，以及判断证据究竟能证明多少的成本。增加算力可以降低前者，却未必改善后者。在某些情况下，它甚至只是让一个容易误导人的结果更快出现。

更快回答了一个不完整的问题

设想一家零售商正在修改折扣计算方式。这是一个假设案例：代理改写了定价函数，并添加测试，证明符合条件的购物篮能获得优惠。构建通过了。但退款、汇率转换，以及两种促销同时生效时，结果是否仍然符合业务要求？如果测试规格没有表达这些行为，更频繁地运行原有测试，并不会自动补上缺失的规则。

这不是否定生成式测试的价值。代理可以帮助列举边界情形，也能把一次已知故障变成回归测试。真正需要注意的是独立性：如果实现代码与预期输出都来自同一个错误理解，两者彼此一致，只能提供有限证据。更有效的挑战需要来自其他依据，例如必须保持的业务约束、现有客户合同，或者由业务负责人审阅过的反例。

Chenglin Li等人的论文于2026年8月6日修订，报告称更强的测试揭示了被错误接受的基准修复。实验针对代码库修复基准，而非生产事故率。研究论文

实验场景与实际业务的差异，限制了可以推导出的结论。这项研究不能说明某家公司的发布会以多高频率失败。对运营团队而言，更稳妥的推论是：测试通过，只能为它能够区分的行为提供证据，无法认证从未被表达出来的需求。即使执行测试越来越便宜，设计测试依然是一项持续的工程责任。

执行器结束后，队列还在继续

再看另一个假设团队。它的测试已经比较充分地覆盖变更，但每份运行结果仍需有人解释。某些失败来自补丁本身，某些来自暂时不可用的依赖，还有一些来自过期的测试数据。候选变更数量翻倍，可以增加诊断工作，却不一定增加有能力处理这些问题的人。

这时，屏幕上可见的CI排队时间可能缩短，等待解释的结果却越积越多。只测量任务开始到完成的时长，会错过瓶颈的转移。更有意义的观察范围，应持续到有人能够据此作出有依据的合并决定，并把重跑和排查纳入其中。否则，供应商可能完全履行了执行速度承诺，团队的实际交付却没有明显改善。

Martin Fowler在2011年4月14日的文章中讨论了间歇性失败的测试如何削弱团队对测试套件的信任。这是长期工程经验，而非对当下AI工具的新测量。原文

从经济角度看，不可靠的信号会消耗稀缺的注意力。审阅者反复遇到无法解释的失败，可能逐渐形成先重跑、后调查的习惯。代价不只是浪费机器分钟数，也包括失去区分“变更有问题”与“测试有问题”的可靠依据。增加测试量要真正有用，组织需要维持这种区分，并明确由谁修复已经退化的检查。

吞吐量能告诉采购者什么

Google于2025年9月23日发布的DORA研究介绍，将AI采用与更高的软件交付吞吐量联系起来，同时指出验证仍有挑战。这是历史调查证据，不能当作某家供应商效果的受控估计。研究介绍

因此，也不应反过来否定更快基础设施的价值。缩短反馈周期，可以让开发者在尚未离开变更思路时获得结果；充足的测试容量，也能让原本过于昂贵的检查变得可行。关键在于识别它缓解了哪个约束。如果可靠的检查正在等待资源，更快执行有直接价值；如果问题仍是“正确行为应该是什么”，速度的即时作用就比较有限。

采购比较需要相对稳定的工作单位。每分钟CI费用容易观察，却可能鼓励不完整的比较。更快的机器每分钟更贵，跑完同一套检查的总成本却可能更低；更便宜的测试套件，也可能只是省略了昂贵检查；每次成功运行的低价格，则可能掩盖此前反复失败的成本。内部评估可以尝试追踪一项可比变更，直到它获得经过审阅的发布决定，同时保留检查范围。

这个单位也不完美。变更的风险各不相同，有些事故会在发布很久后才出现。界面装饰修改，不适合直接与重写客户余额的数据迁移比较。区分变更类别、记录例外情况，虽然不如一个统一的生产力数字简洁，却能让所谓改善更容易解释。

不必把测试预算无限扩大

一种可能的运营设计，是让低成本检查快速回答较窄的问题，把覆盖更广的检查与人工注意力留给影响可能更大的变更。这是本文提出的运营假设，不是普遍适用的固定流程。涉及安全关键组件或陌生依赖时，合理的平衡可能不同。重要的是，更快的路径不能悄悄移除原本支持批准决定的证据。

过度谨慎同样有成本。如果每次无害修改都要经历相同的昂贵审查，团队会失去自动化收益，也可能为了减少手续而把不相关的变更打包提交。目标并非把测试数量推到最大，而是把剩余不确定性说清楚，使组织能够判断这项变更、它的影响范围及恢复路径是否可以接受。

因此，围绕CI的商业机会比出售处理器更广，但也不能无限延伸为随时供应“可信度”的承诺。供应商可以降低取得证据的成本，团队仍须定义值得保护的行为、维护检查并解释结果。代码生成加速之后，这种责任分工会更清楚地体现在交付一项用户真正能够依赖的变更所需的成本中。