DX 最近公布了一项覆盖 400 多家工程组织的 16 个月纵向研究的结果：AI 工具使用率上升了 65%，而 PR 吞吐量的中位数仅增长了不到 8%。大多数组织落在 5% 至 15% 的区间。有提升，但远不及部分厂商所承诺的 3 倍甚至 10 倍。

在微软负责开发者生产力研究的 Brian Houck 给出了一种解释：编码只占开发者每周工作时间的约 14%。即便在编码环节取得显著提升，能节省的时间也十分有限。

剩下的 86%——比如评审、规划、调试、上下文切换、与利益相关方的反复沟通，以及在需求尚未厘清就仓促开工所导致的返工——并不会因为代码写得更快就跟着变快。

这并不是要否定编码工具，我每天都在用。但“全面推广编码工具”本身算不上一种策略，而我最近在 Mintel 的工作重心也转向了一个新方向：优化工程团队对 AI 工具的采用方式。如果我的职责是帮助团队提效，我就需要弄清楚哪些工具对哪些团队真正有帮助、真正的瓶颈在哪里，以及如何把投入精准投向团队实际遇到的问题。这首先是一个度量问题，然后才是工具问题。

DORA 只能告诉你是什么，而非为什么

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

两年前，我基于 GitLab API 拉取仓库活动中的部署频率和前置时间，搭建了一个内部看板。我们的工程经理都在使用它，相比只看 Jira 周期时间，它为讨论提供了更扎实的依据。但它的局限很快就显现出来：它能告诉你前置时间变长了，却无法帮你理解背后的原因。我和一些工程经理聊过，他们甚至会手动把指标导出到表格里去寻找规律——这清楚地表明，数据是有的，洞察却没有。

没有度量，我们靠感觉做事；有了度量却没有上下文，我们就只是对着图表做事。

更有依据的复盘

为了弥合这一差距，我一直在构建一个智能体，帮助把度量带入复盘讨论，将定量与定性结合起来以探究原因。它会从 Jira 和 GitLab 拉取冲刺指标（当前冲刺以及前两个冲刺），并将其输入 LLM，同时配备了查询单个工单和合并请求的能力。输出是一组面向团队冲刺复盘的假设和讨论要点：数据所暗示的模式、值得提出的问题、值得深挖的线索。

它并不是要让复盘自动化。复盘是团队对自身经历的反思，这个过程的价值恰恰在于它是由人来完成的。它能建立共识、揭示那些不会体现在指标中的信息，并营造出让坦诚对话成为可能的心理安全感。算法无法取代这一点。

它能做的是抓住一个问题，顺着线索深挖下去。以下几个例子就来自真实的冲刺：

• 周期时间飙升。智能体会梳理这些高周期时间工单在工作流中的流转过程，并发现其中很多工单曾多次反复进出“阻塞”状态。重点不是“周期时间上升了”，而是“周期时间上升了，而且其中很多工单曾反复处于阻塞状态——是不是在规划时没有考虑到某个外部依赖？”
• 一张工单拖了三周。智能体会追踪关联的 MR，发现工作分散在三个服务中。重点不是“这是一张很慢的工单”，而是“这张工单涉及三个服务——变更边界是否划分得当，还是说我们一直在为耦合付出代价，而且这个问题还会持续出现？”
• 一个 MR 在评审阶段停留了一周。智能体会查看 diff，发现有 40 多个文件被改动。重点不是“评审很慢”，而是“这个 MR 可能太大了，难以有效评审——是否存在把本应拆分的改动打包在一起的惯例？”

这些仍然只是假设。团队需要去评估、反驳、判断哪些假设更符合实际。目标是在由人主导的对话开始时，就提供由数据支撑的、更好的问题，让掌握完整上下文的工程师们去反思真正发生了什么。

超越代码编写的智能体

几乎所有关于工程领域 AI 的讨论，最终都会回到写代码上。DX 的数据表明，生产力的提升是真实存在的，但也是有限的。如果另外 86% 的工作占据了大部分时间，那么提升空间恰恰就在那里。

复盘智能体并不是在写代码。它在帮助团队看清时间都花在了哪里，并提出更好的问题。如果它能奏效，这将是一个用例，证明最有意思的智能体工作，可能看起来根本不像编码智能体。

这是本系列的第一篇。下一篇将介绍该智能体的工作原理：数据源、提示策略以及其中的难点。之后会分享我们如何落地推广，以及在实际使用中的收获。