Zendesk 最近提出，生成式 AI 改变了软件交付的核心制约因素——从编写代码转变为所谓的“吸收能力”。所谓吸收能力是指组织清晰界定问题、将各类变更融入整体系统、验证功能行为正确性并将落地成果转化为稳定可靠价值的综合能力。在 Zendesk 的论述框架下，当代码供给变得充足，核心挑战便不再是快速产出代码，而是要避免快速生成的内容与架构一致性、评审能力及交付流程脱节。
在 Zendesk Engineering 的一篇博文中，Bence A. Tóth 用农业与制造业的类比阐述了这一观点。他认为，若系统中仍存在其他约束条件，仅优化某一环节未必能提升整体吞吐量。他在文中写道，在软件领域，生成式 AI 已大幅降低代码生产成本，实现环节不再是最大瓶颈。
回看 Margaret Hamilton 那张标志性的阿波罗登月软件照片，当时代码编写仍是软件交付的主要制约因素（来源）
Tóth 提出的 “吸收能力” 这一概念涵盖了将生成式代码转化为可靠成果所需的各项工作，包括明确要构建的内容、让实现方案与整体架构保持一致、通过验证确保可靠性，以及判断最终变更是否切实提升了客户价值。
文章提出了四项务实应对措施。首先，问题定义应成为产品与工程团队的共同责任，而非单向交接，因为模糊的需求可能导致看似合理、实则偏离目标的实现。其次，团队应通过完善验证闭环来降低试错成本，包括 CI 检测、静态分析、安全检查、可观测性建设、分阶段发布，以及部署后的快速产品反馈。
第三，架构与工程规范应作为 AI 辅助交付的支撑框架，包括清晰的边界划分、统一的命名规范、通用模板、轻量级的架构决策记录（ADR），以及在 CI 流程中强制落地的防护机制。最后，团队应衡量整体交付效能而非单纯产出量，优先关注前置时间、评审队列耗时、变更失败率、回滚频次及事件负载等指标，而非代码行数、PR 数量或词元数量。
他认为，AI 会放大代码库与交付流程中已有的结构性问题。在模块边界清晰、不变量有文档说明、实现路径少且易于理解的系统中，AI 能够提升研发效率，同时也更容易进行引导与校验。而在规范模糊或存在架构漂移的系统中，同样的加速效果反而会加剧不一致性、加重评审负担，并降低对代码变更的可信度——这些变更在局部看似合理，却可能在更大范围内对系统造成损害。
在 InfoQ 近期一篇关于 Agoda 对 AI 编码工具看法的报道中，Agoda 同样认为，编码从来都不是真正的瓶颈。随着实现速度加快，规范与验证的重要性愈发凸显。Zendesk 则进一步深化了这一观点，明确指出了新的制约因素，并将其定义为组织设计问题：如何在不影响架构稳定性与交付质量的前提下提升团队吸收快速变更的能力。
对于架构师和工程负责人而言，这意味着真正的优势并不属于生成代码最多的团队，而是属于能够安全、高效地吸收更多有价值变更的团队。
【声明：本文由 InfoQ 翻译，未经许可禁止转载。】
查看英文原文：https://www.infoq.com/news/2026/04/zendesk-absorption-capacity/
