你的系统已经存在盲点，AI 只会让它们更糟。

2022 年，在生成式编码工具成为我们日常工程工作的一部分之前，我写道 关于我对工具选择的哲学。它的表现比我预期的更好。当时，我主张从你实际要解决的问题出发，了解自己的弱点，并优先考虑如何使用工具，而不是盲目跳到听起来最好的工具并期望它能奏效。了解自己和自己的目标，这样才能为你的工具设定合理的期望。

当时，我在思考 SaaS 膨胀，而不是 AI 生成的代码。但今天，我的哲学更加紧迫，也更值得坚持。

我们中的许多人已经阅读了 2025 DORA report，发现与前一年不同，AI 采用现在与交付吞吐量正相关。其背后的发现是交付不稳定性持续上升，他们测试了速度提升是否能弥补这一点。结果是否定的。这与我们的经验相符。我们的团队采用了代理式软件开发，吞吐量在两个季度内提升了 48%，随后稳定性问题增加了 16%。十人是一个小样本，但这也是我能够看到全局的样本，且模式得以保持。

AI 采用已经不再是一个问题。你要么刚刚起步，要么已经深陷其中。现在的不同之处在于，工程领袖被期望采用 AI 并且证明其产生了回报。CEO、董事会和财务部门都想了解如何优化他们的 AI 投资。他们在询问你选择的工具是否在高效地解决真实问题。

差距一直存在，AI 只让它更大。

作为首席技术官，我把相当多的时间用于与其他工程领袖交流，包括客户、潜在客户和我的同行，比较我们在 AI 方面的成就和抱怨。经过足够多的对话，我开始看到 AI 采用及其结果的模式。

主要观察并非我的独创。DORA 已经在这方面领跑两年：AI 放大了组织中已有的情况，无论是优势还是弱点。拥有清晰架构和健康审查习惯的团队会更快。刚好将技术债务收拾到能够交付代码的团队，现在发现技术债务正演变为主要阻碍。不过，这种框架忽略了为何会让这么多团队措手不及。AI 并没有隐藏这些弱点；我们依赖的系统从未将它们显现出来。

大多数工程组织使用的工单和报告系统是为了解答人类的问题、以人类速度、由大致了解“完成”意义的人员构建的。它从未是完美的记录，而是始终是一种近似，由人对底层更混乱的情况进行概括填补。现在，AI 增加了工作量，并带来生成新活动的新输入。传统的、非 AI 的开发方法所使用的系统（或工具）从未为此而设计。

尽管如此，我们仍然负责相同的目标。你仍然要掌控速度、质量、成本以及团队的实际表现。只是你不能再盲目信任去年的仪表盘了。

这里有一个合理的反对意见。 DORA’s 2026 ROI report 描述了一条 J 曲线：在采用后立即出现生产力下降，原因是学习曲线、验证 AI 生成代码的成本以及尚未跟上的下游流程。他们称之为转型的“学费成本”，并警告领导者不要把它误认为是失败。说得有道理。但在基于工单构建的仪表盘上，学费和真实问题看起来完全相同。如果你无法判断自己处于哪种情况，就没有耐心，只是在猜测。

我们需要回归基础。了解自己。了解你的团队。了解你正在解决的问题。

如何用 AI “了解自己”？

通过我的交流，我识别出五个主要领域，在这些领域中，为人类生成、人类报告的工作而构建的传统系统存在盲点。忽视它们，你在继续采用 AI 时就有放大自身弱点的风险。

盲点 1：速度幻象

更多的提交和更多的 PR 可能让人感觉进展明显，且往往确实如此。AI 自动提升这两个数量。一个 Stanford case study 显示，采用 AI 后 PR 数量提升了 14%。但你忽视了其中有多少活动是实际交付的特性工作，而不是维护、返工或因重构未能保留而产生的 churn。

为了解决此问题，需要关注特性工作与维护之间的划分，并将部署频率和交付周期与自己的历史基线进行比较，而不是行业平均值。没有这种划分，你报告的进展无法得到实际验证。

盲点 2：审查债务

审查容量不会自动随产出而扩展。验证税不是你可以跨过的阶段；它是代理开发的固定成本的一部分。 最近对工程领导者的调查发现80%的团队在审查上至少花费10%的时间，约十分之一的团队花费超过40%。在这种负荷下，团队在积压增长和机械批准之间摇摆，两者都不是根本的解决方案。

发布的限制不再是代码写得有多快，而是 人类能够多快真正确信变更是正确的，缺陷能够多快且多准确地被检测和处理。观察审查负荷在团队中的实际分配；否则你可能会让资深工程师超负荷，推迟发布，或导致重大生产问题。

盲点 3：隐藏工作

重构和架构变更往往隐藏在其他工单中，甚至可能根本不出现在工单系统里。AI 会产生更多此类工作，而不是更少。一个代理不会犹豫去修改十二个文件来修复一个 bug，而人类可能会停下来重新考虑。跳过记录系统的工作也会跳过规划，这意味着你的容量模型是错误的，所有基于它的预测也同样错误。

为了了解实际完成了多少工作，你需要观察代码库和拉取请求历史中实际的变更量。没有这些数据，你的容量计划只能基于人们记得记录的内容，而不是他们实际做了什么。

盲点 4：质量漂移

同一调查发现，近一半的工程领导者每周都难以发现安全问题。复杂性、重复性以及不太合适的依赖在大量小的、各自看似合理的变更中累积。单独来看它们并不显得危急。在同一 Stanford 案例研究中，代码质量下降了 9%，其方差超过了三倍。虽然平均值略有变化，但差异（你注意到的部分）变化很大。在 AI 规模下，这些问题的叠加速度快于大多数审查流程的捕捉速度。漂移往往表现为一次值班警报，追溯到一个没人记得审查过的依赖。等到发生时，客户很可能已经先注意到了。

关注安全发现、依赖以及故障与恢复的趋势线——而不是单个提交。数周累积的复杂性和重复性比审查中标记的任何单一变更更重要。没有这些，你捕捉漂移的方式仍然和大多数团队一样：在它已经导致事故之后才发现。

盲点 5：未验证的支出

一旦 AI 采纳不再是争论焦点，AI 支出和投资回报率就成为大家关注的核心。财务部门想了解哪些支出可以资本化，哪些是运营费用。领导层想知道投资产生了什么成果。大多数团队仍然依据直觉而非金钱与交付工作之间关联的证据来决定工具、席位和人员配置。

关注工程工作实际在代码库中的流向，按季度观察——而不是路线图上说的流向。没有这层关联，你只能用轶事来为明年的预算辩护，而在与 CFO 的严肃对话中，轶事是站不住脚的。

从看不见的开始

财务关于资本化支出的问题以及凌晨 2 点的值班页面看似无关，实则不然。两者都可以从活动中“估算”。更重要的是，它们都可以通过代码本身提供的证据得到答案。

DORA 对此的答案就是工程系统本身：平台质量、工作流清晰度、团队协同。这是正确的，但它也不是第一步。你无法修复看不见的系统。必须先观察到这五个领域中的每一个，才能为对其投入进行论证。

首个有用的步骤并不是新工具或新流程，而是诚实地认识自己，确定这五个领域中哪些是缺乏真实证据的盲点。大多数领导者能够立刻识别（并关注）其中一个领域的问题。然而，正是信息最少的领域，在你继续采用 AI 时最容易出现并对你造成困扰。