代码突然不稀缺了，但交付速度没快多少——这是Zendesk工程团队最近的真实困惑。

他们提出一个新概念叫「吸收能力」：组织把变更安全转化为可靠价值的能力。当生成式人工智能（Gener式AI）让代码产出像拧开水龙头，真正的制约因素从「写不写得出」变成了「接不接得住」。

打开网易新闻 查看精彩图片

「吸收能力」到底是什么

这个概念由Zendesk工程师Bence A. Tóth提出，涵盖四个环节：清晰界定要构建什么、让实现与整体架构保持一致、通过验证确保可靠性、判断变更是否真正提升客户价值。

他用农业和制造业打比方：只优化单一环节，若系统存在其他约束，整体吞吐量未必提升。在软件领域，生成式AI已大幅降低代码生产成本，「实现环节不再是最大瓶颈」。

这让人想起Margaret Hamilton那张标志性照片——阿波罗登月时代的代码写在纸上，当时编写代码确实是软件交付的主要制约因素。现在，这个前提正在失效。

为什么快反而成了问题

Tóth的核心判断是：AI会放大代码库与交付流程中已有的结构性问题。

在模块边界清晰、不变量有文档说明、实现路径少的系统中，AI能提升效率，也更容易引导与校验。但在规范模糊或存在架构漂移的系统中，同样的加速会加剧不一致性、加重评审负担，并降低对代码变更的可信度——局部看似合理的变更，可能在更大范围内损害系统。

Agoda近期在InfoQ的报道中也表达了类似观点：编码从来不是真正的瓶颈。随着实现速度加快，规范与验证的重要性愈发凸显。

Zendesk更进一步，把新制约因素明确定义为组织设计问题：如何在不影响架构稳定性与交付质量的前提下，提升团队吸收快速变更的能力。

四项务实应对措施

文章给出了具体解法，指向协作方式与工程实践的重构。

第一，问题定义是产品与工程团队的共同责任，而非单向交接。模糊的需求会导致看似合理、实则偏离目标的实现。

第二，完善验证闭环以降低试错成本，包括持续集成（CI）检测、静态分析、安全检查、可观测性建设、分阶段发布，以及部署后的快速产品反馈。

第三，架构与工程规范作为AI辅助交付的支撑框架，包括清晰的边界划分、统一的命名规范、通用模板、轻量级的架构决策记录（ADR），以及在CI流程中强制落地的防护机制。

第四，衡量整体交付效能而非单纯产出量，优先关注前置时间、评审队列耗时、变更失败率、回滚频次及事件负载等指标，而非代码行数、PR数量或词元数量。

对工程负责人的启示

真正的优势不属于生成代码最多的团队，而是属于能够安全、高效地吸收更多有价值变更的团队。

这句话重新定义了AI时代的竞争力来源。当工具层差距被快速拉平，组织设计与工程纪律成为新的分水岭。那些提前把架构清晰度、验证自动化、跨职能协作打磨好的团队，反而能在AI加速中获得复利；而技术债沉重的团队，只会被更快的产出速度拖入更深的维护泥潭。

代码稀缺性的终结，暴露的是软件工程长期被掩盖的复杂性——问题定义、系统整合、价值验证，这些从来都比打字更难。