编码智能体更快了，团队交付为什么没变快？

一个工程师很快写完实现，PR 随即进入等待。评审发现需求描述不清，QA 需要有人帮忙把服务跑起来，跨仓库测试时下游消费方直接报错。编码环节确实更快了，可剩下的活一点没少。 这正是 Sohit Kumar 在 Prinevo.ai 上提出的问题：更快的编码智能体，能不能让工程团队交付更快？他的判断是，只有当省下的实现工作真正传导到已完成的变更上，答案才是肯定的。要验证这一点，得把交付路径上的人力投入和等待时间都算进去，再看返工和缺陷有没有变多。代码行数更多、打开的 PR 更多，本身回答不了这个问题。 r/EngineeringManagers 上有一场讨论直接指向这里：如果一个工程师产出变更的速度更快，这些产出最终落在评审、QA、集成还是别的团队身上？ 先定义什么叫“更快” 打开的 PR、通过验证的 PR、已合并的变更、客户可用的变更，是四个不同的终点。只统计到“打开 PR”的时间，就把评审、验证、集成和发布排除在结果之外。这可以作为一个有用的实现指标，但不足以描述团队的交付表现。 对编码智能体试点来说，通过验证的 PR 可以作为一个务实终点：需求行为明确、相关检查已运行、评审者拿到与受测版本和环境绑定的证据。衡量团队吞吐时，则要先定义完成单元和统计周期——是准备好评审的已验证变更，还是已交付生产的变更，这个区分要一直摆在明面上。 吞吐量和前置时间也要分开。吞吐量统计一个周期内完成的单元数，前置时间跟踪一个变更从约定起点到终点花了多久。两者都要记，并且记录足够的工作细节，比较才有意义。一个文案改动、一次迁移、一个横跨多个服务的功能，不会因为各自挂了一张工单就变成可互换的生产率单位。 跟着一个变更走出实现环节 设想一个功能：客户升级订阅后获得某项付费能力。它牵涉升级界面、权益 API 和计费事件消费方。实现智能体更新了 API 并写了测试，前端智能体更新了升级流程，两边产出的变更看起来都合理。 然后评审者问：计费事件延迟到达时应该怎么处理？需求里没写。产品负责人需要拍板，实现就此暂停等待决定。之后 QA 启动集成流程，测试账号缺少触发升级所需的状态，一名工程师去修种子数据。场景跑通后，QA 又发现 API 和消费方对某个事件字段的理解不一致，受影响的实现被修复并重新检查。 这些都是交付该功能必需的工作，更快的实现步骤并不会让它们消失。值得追问的是具体的：延迟事件的行为能不能在实现前就定下来？智能体能不能自己启动所需服务、准备好测试账号？契约检查能不能更早暴露字段不匹配？评审者拿到的是需求、影响和验证证据，还是得自己重新拼出来？ 作者在四月的一篇文章里记录过类似情形：一个服务发出的是 created_at，消费方期待的却是 createdAt。两个仓库各自的测试都通过，是沙箱里的集成检查抓到了不一致。代码两边看起来都合理，边界仍然需要检查。 把智能体周围的人也算进账 从接触这个变更的人开始数：谁澄清了需求，谁补上了缺失的上下文，谁开通了权限、修好了环境、评审了 diff、排查了失败的检查、又把某个决定解释了一遍。这些活动发生在智能体会话之外，同样属于这笔账。 活跃的人力投入要和流逝的时间分开记录。一个变更可能在等评审者，期间没人在动手；另一个变更流转很快，却有好几个人在修。这是两类不同的问题。并发工作也要注意，不能把每个人的工作时间加起来当作前置时间，也不能在多个系统都记录同一次干预时重复计数。 这还回答了另一个问题：团队是在相同工时下交付更多，还是产出不变、投入减少？需求增长也可能把省下的产能吃掉。解读结果之前，先确定自己在评估哪种结果。Token 用量和工具开销能解释资源消耗和成本，但不能证明团队交付了有用的变更。 质量要摆在吞吐数字旁边 更多完成的变更，只有在团队能为交付的东西负责时才有价值。看智能体报告完成之后发生了什么：实现有多少在评审中被改动？哪些验证检查失败？还有什么没被测到？发布后是否出现缺陷，又制造了多少工作？ 定义要保持稳定。首次验证和最终验证回答的是不同问题，最终通过可能发生在好几轮昂贵的修正之后。评审返工可能包含真实缺陷、遗漏的需求，也可能是证据缺失导致结果难以判断，这些原因要分别标注。发布后的缺陷要在约定的观察期内跟踪严重程度和影响——刚发布的变更暴露问题的时间比老变更短，暂时没报缺陷只是观察有限，不是正确的证明。 还要检查测试是否在验证被接受的行为。如果智能体写代码和写测试基于同一个错误假设，全绿的检查只是在确认这个假设。需求、契约和已知回归提供了假设之外的参照。最后要问，这个变更是否解决了原本要解决的问题：交付量和技术质量都重要，但它们不能证明客户需要这个功能。 改掉真正卡住流程的那一环 如果评审在等缺失的上下文，再开更多实现智能体只会加长队列。如果智能体跑不起应用，再加一个评审者也修不好环境。用观察到