AI 让 Pull Request 翻倍之后，产品真的变好了吗？
一套面向创始人的度量体系：把 AI 采用率、Issue 活动和 Pull Request 数量，逐层转化为被接受的变更、可靠交付、用户结果与经济价值。
Linear 刚刚发布了一份大规模数据观察，展示 AI 正在如何改变软件团队。在它的付费客户群体中，到 2026 年 6 月，每个 workspace 打开的 Pull Request 数量比 2024 年 6 月的基线高出 111%。连接了编程 Agent 的 workspace，每周 Pull Request 数量在两年间从 21 个增长到 65 个；没有连接编程 Agent 的 workspace，则从 8 个变为 10 个。Linear 中由 AI 创建的 Issue，也已经接近全部 Issue 的一半。
这些都是有意义的活动信号，却不能证明 AI 让产品价值翻倍。Linear 自己明确提醒：它统计的是已打开、而非已合并的 Pull Request；一个被打开的 Pull Request，无法说明这项变更是否有价值。使用 Agent 的团队在 Agent 出现之前就已经有更高产出，因此两组并不是干净的实验组与对照组。
对非技术创始人来说，真正重要的变化就在这里。AI 生成规划文档和代码变更的速度，可能已经超过团队判断这些工作是否必要、正确、安全、被用户采用或值得投入的速度。如果仪表盘只庆祝写了多少 Issue、开了多少 Pull Request，组织就会优化新增工作的供给量，而不是这些工作原本要带来的结果。
本文提供一套更实用的替代方案：从 采用 一直走到 经济价值 的六层度量栈、一张四周试验卡、一个完整的新用户引导案例、比较窗口的选择规则、常见失败模式，以及扩大、维持、重做或停止的决策方法。你不需要先组建数据分析团队，但必须在证据真正抵达用户之前，停止把“活动量”叫作“生产力”。
Linear 测量了什么，又没有测量什么
Linear 的 AI 使用模式报告之所以有价值，是因为它观察了 AI 对话、Agent session、Issue 活动、评论与 Pull Request，而不是只依赖问卷或模型供应商的 token 数量。采用率图表包含 127,000 名在 2026 年 1 月和 6 月都保持活跃的付费用户固定队列；Pull Request 趋势则覆盖 2026 年 6 月的 47,900 个付费 workspace。报告的方法也清楚写出了边界。数据只覆盖 Linear 的付费 workspace，无法看见发生在 Linear 之外的 AI 使用；“AI 活跃用户”指在 28 天窗口内至少有一次 AI 互动的人；“Agent 团队”只表示 workspace 已连接编程 Agent。部分图表使用固定队列，另一些没有。报告统计的是与 Linear 连接的、已打开的 Pull Request，而不是已合并变更或生产结果。
因此，这份报告可以有力描述 Linear 产品生态内的采用与活动变化，却不是编程 Agent 会给你的团队带来什么结果的因果估计。Agent 团队原本就有更高产出这一点非常重要：主动采用 Agent 的团队，可能在人员配置、架构、流程成熟度、产品阶段或自动化意愿上本来就不同。
更合适的读法，是把 111% 同时看作容量警报与机会。软件团队现在可以生成更多候选工作，真正稀缺的资源可能已经转移到下游：定义问题、审查、验证、发布、支持用户，以及决定什么值得存在。
先定义术语，再做仪表盘
团队经常把六个词混在一起使用，但它们并不是同一件事。
- 采用（adoption）：某个人或团队按明确规则使用了 AI 能力，例如 28 天内至少完成一次符合条件的 Agent session。
- 活动（activity）：系统生成或修改了某种工作产物，例如 Issue、设计、测试、Pull Request、客服回复或候选部署版本。
- 被接受的变更（accepted change）：一名可追责的负责人在完成所需检查后，批准了某个明确结果。“被接受”不能只是 Agent 宣布自己的任务已完成。
- 交付（delivery）：被接受的变更以可测量的可靠性到达了目标环境和目标用户群。
- 用户结果（user outcome）：目标用户的行为或体验朝预期方向发生变化。
- 经济价值（economic value）：在计入生成、审查、修正、运营与事故的完整成本之后，结果确实改变了收入、成本、风险暴露或战略学习价值。
因此，单一的“生产力分数”通常并不安全。由 Microsoft Research、GitHub 与学术界共同提出的原始 SPACE 开发者生产力框架把生产力分为满意度与身心状态、绩效、活动、沟通协作、效率与流动五个维度。它给小团队的启发并不是“做一张巨大报表”，而是：活动量只是一个维度，不能替代其他维度。
使用六层证据栈
把 AI 使用到产品价值的路径视为一条连续证据链。每一层回答不同问题，也应该有不同负责人。
| 层级 | 要回答的问题 | 示例指标 | 可支持的决策 |
|---|---|---|---|
| 1. 采用 | 目标团队是否真的在使用这套工作流？ | 有符合条件 session 的合资格用户 | 改进访问、培训或任务匹配 |
| 2. 活动 | 生成了哪些候选工作？ | 新建 Issue、原型或 PR 数 | 判断工作供给是否变化 |
| 3. 接受 | 哪些工作通过了可追责审查？ | 被接受变更数 / 提交变更数 | 改进任务选择或证据 |
| 4. 可靠交付 | 哪些工作到达用户且没有造成可避免返工？ | 前置时间、失败变更、部署返工 | 修复交付系统 |
| 5. 用户结果 | 目标行为是否改善？ | 激活、完成、留存、解决率 | 保留、修改或移除功能 |
| 6. 经济结果 | 完整成本是否值得？ | 每个增量成功结果的成本 | 扩大、收窄或停止工作流 |
不要要求所有指标同时上升。在刻意探索的一周里，Agent 活动量提高而接受率下降，可能是合理现象。团队也可能减少低价值发布，让部署频率保持不变，却交付更有价值的变更。采用率增长时，客服请求总数可能上升，但每位激活用户的请求率反而下降。
这套证据栈的用途是诊断。如果活动量增长三倍，接受量没有变化，就检查任务定义、证据和审查容量；如果接受量上升但可靠交付恶化，就加强测试、发布边界和回滚；如果交付改善但用户结果不动，就重新审视路线图与产品假设；如果用户结果变好但经济性恶化，就先降低推理、审查、支持与事故成本，再考虑扩大。
把 Pull Request 数量当作流量信号，而不是目标
Pull Request 数量并非毫无价值。突然增长可以揭示开发系统确实发生了变化：Agent 可能开始处理过去被搁置的任务，团队可能改变了工作的拆分方式，审查队列也可能即将成为新瓶颈。
当管理者把地位、绩效或成功结论绑定到这个数字时，它才变得危险。Agent 可以把一项变更拆成很多条 Pull Request，也可以把互不相关的工作塞进同一条。团队可以打开永远不会合并的候选变更；已合并变更可能一直藏在 feature flag 后面；已部署变更可能很快回滚；一次成功部署，也可能完全没有解决用户问题。
近期研究进一步说明，必须检查数量背后的工作。对 2,361 个热门 GitHub 仓库中 25,264 条 Agent Pull Request的研究发现，采用与活动分布非常不均：在三个月观察期内，仓库的中位数只有 1 至 2 条 Agent Pull Request，而且最常见的是单人监督模式。这有助于理解早期开源实践，却不是普适的生产力基准。
另一项研究比较了 24,014 条已合并的 Agent Pull Request 与 5,081 条已合并的人类 Pull Request，发现两类变更在 commit 数、涉及文件和删除行数上存在结构差异，而 Agent 工作的描述与 diff 对齐度只略高一些。即便一条 Pull Request 已合并、描述也写得很好，它最多只证明代码贡献进入了仓库，并不能证明产品影响。
用数量去追问运营问题：队列是否增长？审查时间是否变化？候选工作是否集中在某个高风险区域？人类是否花了更多时间修正、等待或协调？不要让它单独回答“AI 是否有效”。
先测量被接受的变更，再谈速度
对小团队来说，变更接受率 是连接活动与交付最实用的桥梁：
变更接受率 = 通过既定验收门的变更数 / 提交给该验收门的变更数
必须在试验开始前定义分子和分母。一项提交可以是绑定单一结果的 Pull Request、无代码工作流改动、客服自动化规则，或者新用户引导版本。接受标准应当与后果相匹配：负责人审查、测试结果、政策检查、预览或受控用户试点。
同时记录拒绝原因，使用一份简短而固定的分类：
- 问题选错或工作重复；
- 结果不完整或不正确；
- 缺少证据；
- 范围或风险过大；
- 没有可用审查容量；
- 产品优先级已经变化。
GitHub 在 2025 年进行的一项受控研究提醒我们始终写清适用范围。202 名有经验的 Python 开发者完成同一个受限的 Web Server 任务，盲审者使用统一评分标准。这个设计可以支持关于该任务与该人群的结论，却不能证明所有 Agent 都能在包含客户数据、历史依赖和模糊需求的成熟产品里交付更高质量变更。
加入交付健康与下游负担
被接受的工作开始走向生产环境后，应当单独测量交付系统。DORA 目前定义了五项软件交付绩效指标：变更前置时间、部署频率、失败部署恢复时间、变更失败率，以及部署返工率。当 AI 提高候选工作量时，后两项尤其重要。
不要孤立优化其中一项。前置时间变短但失败变更多，可能只是把工作从开发环节转移到了事故环节。当变更可以独立发布、能够观察时，更高的部署频率可能是健康表现；如果团队不断为可避免的缺陷打补丁，它就只是噪声。返工应该包含为了修正用户可见问题而产生的非计划部署，而不能只统计带有特定标签的 revert。
用创始人每周都能读懂的普通语言记录下游负担：
- 每个被接受变更消耗的审查分钟数；
- 第一次可追责审查前的中位等待时间；
- 因实质问题退回返工的比例；
- 7 天或 14 天内与该变更关联的生产修复；
- 该变更引发的客服请求；
- 事故与回滚消耗的分钟数；
- 被推入下一周期、尚未解决的运营工作。
把每次试验连接到一个用户结果
没有用户结果的 AI 生产力试验，最后只会变成工具采用计划。首先选择产品原本就要改变的一项用户行为。
如果试验针对新用户引导，结果可以是“新 workspace 在 24 小时内获得第一次成功”；如果针对客服，可以是“用户问题解决后 7 天内没有重新打开”；如果是 marketplace，可以是“合格商品首次进入买家对话”；如果是内部应用，可以是“运营人员用更少修正完成工作，且没有政策例外”。
选择一个主要结果，再选择一项护栏：
| 产品任务 | 主要结果 | 护栏 |
|---|---|---|
| 改善新用户引导 | 首次价值完成率 | 每个队列的退款或求助数 |
| 减少客服积压 | 持久解决率 | 错误动作升级数 |
| 提高结账转化 | 完成购买率 | 支付错误与争议 |
| 加速内部报告 | 在截止日前被接受的报告 | 实质性修正率 |
主要结果可以阻止团队因为“发布更多”就宣布成功；护栏则避免团队通过伤害其他环节来购买这个结果。必须在查看结果之前，定义合资格人群、事件、窗口、排除规则、数据负责人和最低样本。
2025 年 DORA 研究在更大尺度上给出了同一种系统性警告。基于近 5,000 份问卷和超过 100 小时的定性资料，DORA 报告 AI 采用与交付吞吐、产品绩效呈正向关系，但与交付稳定性呈负向关系。DORA 的核心结论是 AI 会放大周围的组织系统。这比“AI 让团队更快”或“AI 让团队更糟”都更能指导行动。
完整案例：活动量增长三倍的新用户引导团队
设想一支四人团队正在开发项目规划应用。它使用 AI builder 创建界面改动、分析事件、生命周期消息和测试。团队希望提高一个指标：新 workspace 能否在 24 小时内创建项目、邀请一位协作者，并完成一项任务。
试验前四周，团队打开 12 项新用户引导变更，接受 8 项，部署 7 项，首次价值完成率为 31%。每个被接受变更需要 80 分钟审查时间，其中一项已部署变更需要紧急返工。可归因于新用户引导工作的人工和工具成本为 1,600 美元。
进入四周 AI 试验后，团队打开 36 项变更。如果管理者只看到这里，仪表盘会报告活动量增长 200%。但证据栈的其余部分显示：
- 15 项变更通过验收门；
- 12 项到达试验队列；
- 每个被接受变更的审查时间升至 125 分钟；
- 3 项变更需要紧急返工；
- 首次价值完成率从 31% 升至 35%；
- 每个已激活 workspace 的求助请求从 0.18 升至 0.27；
- 可归因的人工、推理、审查和支持成本升至 3,900 美元。
随后团队再运行一个四周周期，把提交上限设为 16 项，在生成前拒绝没有用户证据的工作，并要求每项工作同时提供预览和事件校验。如果接受量仍为 15 项、紧急返工降到 1 项、审查时间接近基线、完成率保持在 35%，就说明系统学会了把 AI 容量转化为有效吞吐。如果用户结果回落到基线，则第一次改善还不够稳定，不能扩大。
复制这张四周度量卡
一张卡只对应一套工作流。不要把客服自动化、编程、研究和营销生成合并成一个“AI 生产力试验”。
trial:
workflow: onboarding improvement changes
owner: product lead
comparison_window: 4 weeks before vs 4 weeks during
eligible_work: changes linked to the onboarding outcome
primary_outcome:
event: first successful project within 24 hours
population: new eligible workspaces
baseline: 31_percent
guardrail:
event: onboarding help requests per activated workspace
baseline: 0.18
layers:
adoption: eligible_people_with_qualifying_ai_session
activity: submitted_changes
acceptance: accepted_changes / submitted_changes
delivery: deployed_changes_without_14_day_rework
user_value: first_value_completion_rate
economics: total_trial_cost / incremental_successful_workspaces
burden:
reviewer_minutes_per_accepted_change: track
urgent_rework: track
support_contacts: track
decision_date: 2026-09-16
decision_options: [scale, continue_bounded, redesign, stop]
记录比例时同时保留原始计数。“接受率从 70% 降至 50%”在 10 次提交与 1,000 次提交时意义不同。试验前的定义必须保持稳定；如果事件或队列定义发生变化，应开始一个新的度量版本，而不是静默改写基线。
成本必须完整覆盖订阅、推理、集成、prompt 与工作流维护、人类定义问题、审查、修正、支持、事故响应，以及瓶颈角色的机会成本。不要给机会成本编造虚假精度；记录一个估算范围，也比完全忽略更好。
成本必须除以 增量结果，而不是试验队列中的全部成功用户。如果 1,000 名用户中有 350 人在试验期成功，而可比基线预计有 310 人成功，那么暂定分母是 40 个增量成功，而不是 350 个。如果测得的提升为零、为负，或不确定性大到无法与普通波动区分，就应把经济价值记录为“尚未建立”。不要用活动量，或者原本就很可能成功的用户，制造一个看起来很漂亮的比率。
选择能够支持决策的比较方式
小团队通常没有足够流量做完美的因果研究，但仍然可以避免明显的自我欺骗。
首先，比较相同的工作流与结果，不能拿 AI 辅助的新用户引导和上季度支付迁移比较。其次，固定窗口必须长到能够容纳审查和生产后果。第三，队列定义需要可以重建。第四，记录同期发生的发布、定价变化、人员变化或季节流量等干扰因素。
风险和流量允许时，可以使用随机或分阶段发布；不允许时，则比较匹配的任务类型或交替周，并明确把结论标为观察性。一项 METR 随机试验发现，熟悉自己开源仓库的资深开发者使用 2025 年初的 AI 工具后完成任务反而更慢。后来，随着工具和使用方式演变，METR 调整了实验设计。这里的教训不是“AI 现在会让每一位专家变慢”，而是效果取决于工具、时间、用户、任务、仓库与研究设计。
按照比较方式真正能支持的强度写结论：
- 事实： 试验期提交了 36 项符合条件的变更。
- 观察： 试验窗口内接受量上升，同时审查负担也上升。
- 推断： 任务筛选很可能帮助后续周期减少返工。
- 未知： 这套工作流是否造成了用户结果变化。
- 决策： 在继续收集下一个窗口时，只保留一个受控队列。
使用决策矩阵，而不是“胜利指标”
窗口结束时，把被接受的变更、用户结果、负担与护栏一起判断。
| 被接受的变更 | 用户结果 | 负担与护栏 | 决策 |
|---|---|---|---|
| 上升 | 上升 | 稳定或改善 | 每次只扩大一个边界 |
| 上升 | 持平 | 稳定 | 重做工作选择或产品假设 |
| 上升 | 上升 | 明显恶化 | 保持受控；先修复审查、返工、支持或风险 |
| 持平/下降 | 上升 | 稳定 | 检查是否因为变更更少但质量更高 |
| 上升 | 下降 | 任意 | 停止扩大并检查有害或分散注意力的工作 |
| 任意 | 不清楚 | 任意 | 延长测量，不得宣称产生影响 |
“扩大”必须明确下一条边界：多一套工作流、更大的队列，或多一种动作类型。它不能表示“四周新用户引导试验有效，所以给全公司购买席位”。
“停止”也不表示 AI 毫无价值，只表示这套工作流、任务定义与控制系统还没有赢得更多暴露范围。保留证据，以后仍然可以测试更窄的任务。
常见失败模式与误读
把连接状态叫作采用。 workspace 启用了集成，不代表目标人员在目标任务中使用它。需要符合条件的事件，也要报告合资格用户总数。 把活动叫作产出。 Issue 或 Pull Request 只是候选产物。继续报告它是否被接受、部署并保留。 让 Agent 给自己打分。 完成消息不等于接受。按照风险，把接受绑定到可追责的人，或者独立、确定性的检查。 只统计成功工作。 废弃、重复、回滚和被取代的候选工作都必须进入分母，否则分母会凭空消失。 忽略被转移的劳动。 如果创始人、资深工程师或客服负责人承担更多审查与修正，系统可能只是在转移工作，而不是消除工作。 看到结果后改定义。 对事件、队列、排除规则和窗口做版本管理。用新定义得到的漂亮数字，是一个新指标。 把供应商队列当成自己的预测。 Linear、GitHub、DORA、METR 与开源研究观察的是不同人群、工具、时期与结果。用它们发现机制并设计本地试验，不要用它们制造自己的 ROI。 奖励指标本身。 如果人或 Agent 被要求最大化 Issue、Pull Request 或部署次数，就可以在不增加价值的情况下提高数字。活动只应用作诊断信号，最终要用下游证据判断项目。这套框架适用于哪里，又不适用于哪里
当小团队把 AI 加入可重复的产品工作时，可以使用这套框架：代码变更、无代码应用修改、客服工作流、数据报告、内容运营、新用户引导试验或内部自动化。最适合的场景是团队可以定义候选产物、可追责的接受决定、部署或使用事件，以及一个可观察结果。
不要把它用作员工个人排名。工作的难度、风险、协作需求和不可见价值不同。按个人统计 Pull Request 或接受量，很容易诱导刷指标，也会惩罚那些承担审查、简化系统、预防事故或解决模糊问题的人。
它也不足以单独治理高风险的医疗、法律、金融、安全或受监管决策。这些工作流还需要领域验证、合格监督、适用合规、事故责任，以及针对具体后果的证据。六层产品仪表盘不能授权高风险用途。
最后，如果比较设计本身无法证明因果关系，这套框架也不能把它变成因果证明。它的任务是暴露不确定性并改善下一次决策，而不是把每个小团队的上线试验包装成研究论文。
小团队的 48 小时配置计划
第 0–4 小时：选择一套工作流。 写清任务、负责人、合资格人员、可接受产物、当前瓶颈、主要用户结果与护栏。 第 4–8 小时：冻结定义。 写下六层指标、原始计数、比例、队列、事件窗口、排除规则和比较期，保存为带版本的卡片。 第 8–16 小时：连接现有证据。 使用团队已经拥有的 Issue tracker、代码仓库、部署平台、产品分析、客服系统和账单。四人团队手工每周填写完全可以接受；未经审查的“AI 生产力”自动仪表盘，并不会因为自动化就更好。 第 16–24 小时：建立基线。 至少重建一个可比较的历史窗口，标出缺失证据和同期变化。某个字段过去没追踪，就如实写缺失，不要编造基线。 第 24–32 小时：设置运营限制。 限制候选工作量，定义谁负责接受，要求记录拒绝原因，选择发布队列，并写出暂停试验的条件。 第 32–40 小时：测试度量链。 选择一个样例，从 AI 互动一路追踪到提交、接受、部署、产品事件、客服影响和成本。正式窗口开始前，先修复断裂的标识符。 第 40–48 小时：安排决策。 把日期写入日历，预先承诺只能选择扩大、维持受控、重做或停止。指定一个人分别写出事实、观察、推断、未知项与最终决策。AI 也许真的让候选工作的供给翻倍了，这是一个真实变化。创始人的职责，是建立一条证据路径，告诉团队哪些候选最终变成了可靠的用户价值、付出了多少成本，又有没有把负担隐藏到其他人身上。测量这条路径，更高活动量才可能成为杠杆；跳过它，增长最快的指标可能只是一条越来越长的队列。