谨慎型团队自主送货策略指南

目前，各团队在采用编码代理的方式上存在着一种奇怪的二元对立现象。有些团队完全放手，采取了彻底放任的模式——由代理负责所有工作，人类仅偶尔检查结果；而另一些团队虽然也使用了同样的工具，却让工程师始终紧握控制权，时刻关注进展，一旦出现异常便立即介入处理。

第二类人看待第一类人时，往往既心生羡慕又难以置信。他们能够看到最终的理想状态，但却很难找到从当前处境出发的实现路径。这通常是有充分理由的，也完全合情合理——代码库中存在着无人能完全理解的隐性复杂性，而合规要求或声誉风险则可能让本就不理想的变更变成一场噩梦。

从工程师掌控一切的工作模式转变为代码能够自主部署的模式，这确实是一大跨越。但正常情况下，也不会让新人直接承担如此重要的任务。新员工在入职第一周是不会被安排处理生产环境数据库迁移工作的，而是会从一些简单且可撤销的任务开始，随着逐渐了解他们的能力，再逐步赋予他们更多职责。

自主性也应遵循类似的路径——它更像是一个调节旋钮，而非开关。

在与 TheGP 旗下多家投资公司的合作中，我们一直逐步为系统增添自动化功能。

第一层完全不会自动部署任何内容。当有错误报告或功能需求出现时，会有相应的代理程序来处理这些请求。该代理能够访问生产环境的数据以及 Sentry 的追踪信息，从而像人工操作员一样进行根本原因分析。那些繁琐的工作已经被移交出去，且不会产生任何负面影响。之后就有人工操作员来接手处理这些已经初步分析过的问题了。我本身就不擅长提交工单，甚至有时会专门为了触发代理程序的处理而提交工单。

我们新增的另一个环节是分类处理步骤。一旦这类代码部署代理能够熟练完成分析工作，它就能判断自己提出的修复方案范围是否足够狭窄，从而可以立即提交 Pull Request。你可以根据需求灵活调整这个标准——可以是仅涉及单行代码的修改，或是不会影响到 API 接口的改动，总之在任何你认为合适的范围内均可。

之后就是调整了。当该编码代理在某类任务中展现出出色表现时，就可以扩大它的处理范围。一旦出现错误，也无需彻底废弃它，只需增设相应的保障机制，然后继续使用即可。此外，调整的方向也可以是向回的。

在代码变更的处理流程中，还有另一个调整维度。一旦代码开始自动编写并自动接受审查，人们就会意识到并非所有变更都需要人工审批。同样，应从简单的情况入手——先自动批准那些仅涉及单行代码的修改，再是那些已有测试结果证明其正确性的低风险修复。这两个环节可以各自独立发展：要么大胆地赋予编码代理更多自主处理权限，同时对未经审核的合并操作保持谨慎；反之亦然。

对于那些担心合规问题与声誉风险的团队而言，这部分内容应当起到安抚而非恐吓的作用。这些控制参数实际上就是可供审计的边界——你可以明确指定代理程序允许操作的内容，确定每种变更需要通过何种检查，还可以有意识地逐步扩大其操作范围，而非一次性全部放开。而在实际应用中，许多检查机制与审核流程都是确定且可预测的。

这种可预测性至关重要。要想让系统的性能再提升一个层级，就需要更廉价且更可靠的检测手段。更聪明的代码代理并不一定就更加值得信赖。真正能做到将“我认为它运行正常”转变为“我可以确认它确实运行正常”的，是契约测试、执行追踪以及专用测试框架。

正是在这里，最初那些难以察觉的复杂性会变成一份待办清单。旧系统之所以难以处理，是因为仅通过阅读代码往往无法判断其在运行时的行为。而对于那些无法轻易进行验证的工作，自然也无法放心地交由自动化系统处理。因此，在旧系统中逐步获得自主控制权其实并非什么光鲜的事：需要逐一通过测试和追踪来让系统在运行时的行为变得透明，直到相关的验证成本低到足以让人信任为止。实际上这是个相当枯燥的工作，但最终取得的成果却相当出色。

让那些态度谨慎的团队感到意外的是，这一切其实并不像他们所担心的那样会有剧烈的转变。并不会有一天你就突然开始使用自动送货功能。某個星期二，你才会发现有一大类变更已经在你不知情的情况下被持续送入系统数周之久，而且并未引发任何问题。

那些如今选择不直接干预的团队，并不比那些始终紧握控制权的团队更勇敢。前者会先调整某个参数，观察相应的检测效果如何，然后再进行调整。而后者所羡慕的最终状态，往往只是同一家公司在自动化程度上又提升了一些，能够以更低成本完成那些他们曾花时间去优化检测的工作。

因此，你无需获得许可即可实现这一目标。你需要一个首先不交付任何内容的初始层，同时还要有足够的耐心，仅以检查机制所能承受的速度来逐步推进进展。

丹·普皮乌斯是全年龄标准杆公司的首席技术官，他负责领导该公司以及旗下投资企业的各项工程工作。