DX 最近发布了一项针对 400 多个工程组织、为期 16 个月的纵向研究结果：AI 工具的使用量增长了 65%，而 PR 中位吞吐量仅增长了略低于 8%。大多数组织的增幅落在 5% 至 15% 之间。这些提升确实有意义，但远未达到一些供应商所承诺的 3 倍或 10 倍。

Microsoft 负责开发者生产力研究的 Brian Houck（布莱恩·豪克）给出了一个解释：编写代码只占开发者工作周的大约 14%。即使编写代码这一部分取得了显著提升，能够节省的时间也相当有限。

剩下的 86% 包括代码审查、规划、调试、上下文切换、与利益相关者反复沟通，以及在尚未理解问题就开始构建某个东西后产生的返工。这些工作不会因为写代码变快了就自动变快。

这并不是反对编码工具的论点，我每天都在使用它们。但“推出编码工具”并不是一项策略，而我最近在 Mintel 转向了一个新的重点领域：优化工程团队采用 AI 工具的方式。如果我的工作是帮助团队加快速度，那我就需要知道哪些工具正在帮助哪些团队，真正的瓶颈在哪里，以及如何把投资用于解决团队实际面临的问题。这首先是一个衡量问题，其次才是工具问题。

DORA 只能告诉你是什么，不能告诉你为什么

大多数团队已经拥有能够说明一些情况的数据。DORA 指标（部署频率、变更前置时间、变更失败率、恢复时间）是一个合理的信号，但拥有指标和理解指标的含义是两回事。

两年前，我构建了一个内部仪表板，通过 GitLab API 从代码仓库活动中提取部署频率和前置时间。我们的工程经理会使用它；相比单独依赖 Jira 周期时间，它为我们的讨论提供了更扎实的依据。但它的局限性很快就显现出来了：它能告诉你前置时间变长了，却无法帮助你理解原因。我曾和一些工程经理交流过，他们开始手动把指标导出到电子表格中寻找模式。这清楚地表明，数据虽然存在，但洞察并不存在。

没有衡量时，我们凭感觉工作；有了衡量却没有上下文时，我们凭图表工作。

更有依据的回顾会议

为了弥合这一差距，我一直在构建一个 agent（智能体），帮助把指标带入回顾会议的讨论，将定量信息与定性信息结合起来，以理解事情为何发生。它从 Jira 和 GitLab 中提取迭代指标（当前迭代和之前两个迭代），并将这些数据提供给 LLM，同时配备了查询单个工单和合并请求的工具。它的输出是一组供团队迭代回顾使用的假设和讨论要点：数据所提示的模式、值得提出的问题，以及值得继续追查的线索。

它并不是在自动执行回顾会议。回顾会议是团队对自身经历进行反思的过程，而这一过程之所以有价值，是因为它具有人性。它建立共同理解，揭示那些不会出现在指标中的事情，并营造让坦诚交流成为可能的心理安全感。算法无法取代这一过程。

它能做的是接住一个问题，并开始顺着线索追查。下面是一些来自真实迭代的例子：

• 周期时间突然上升。智能体逐一梳理那些周期时间较长的工单是如何经过工作流的，并发现其中许多工单不止一次地进出“blocked”状态。不是“周期时间上升了”，而是“周期时间上升了，而且其中很多工单反复处于 blocked 状态——是不是有某个外部依赖没有纳入规划？”
• 一个工单拖了三周。智能体跟踪关联的 MR，发现这项工作分散到了三个服务中。不是“这是一个处理缓慢的工单”，而是“这个工单涉及三个服务——变更边界是否处于正确的位置，还是说我们正在为耦合成本付出代价，而这种代价还会不断出现？”
• 一个 MR 在 review 状态停留了一周。智能体查看差异，发现有 40 多个文件发生了变更。不是“审查速度很慢”，而是“这个 MR 可能太大，无法进行有效审查——是否存在把多个变更捆绑在一起的模式，而这些变更本应拆分？”

这些仍然只是一些假设。团队必须对它们进行评估、提出反驳，并决定哪些假设听起来符合实际。目标是在一场由人主导的对话开始时，就提出由数据支持的更好问题；拥有完整上下文的工程师可以据此反思实际发生了什么。

超越代码编写的智能体

几乎每次关于工程领域 AI 的讨论，默认主题都是编写代码。DX 的数据表明，生产力提升确实存在，但有其上限。如果其他 86% 的工作占用了大部分时间，那么生产力提升的空间就在这些工作中。

回顾会议智能体并不编写代码。它帮助团队看清时间花在了哪里，并围绕这些时间投入提出更好的问题。如果它有效，这就是一个用例，说明最有意思的智能体工作可能完全不像编码智能体。

这是本系列的第一篇文章。下一篇文章将介绍该智能体的工作方式：数据来源、提示词方法，以及其中棘手的部分。之后还会介绍我们如何推广它，以及从实际使用中学到了什么。