产出确实涨了，而且差距集中在有没有用 agent
先说涨的部分。两年前，Linear 上由 AI 创建的 issue 还不到千分之一，现在接近一半，照这个速度很快会超过人和集成之和。PR 侧，自 2024 年 6 月起每个工作区的 PR 数涨了 111%——但这个平均值掩盖了分化：用编程 agent 的团队周均 PR 从 21 涨到 65，翻了三倍；没用的团队从 8 涨到 10，基本原地踏步。 采用率的扩散也不再限于工程。2026 年 1 月到 6 月，各职能活跃使用 AI 功能的比例普遍翻倍：产品经理从 12% 涨到 34%（+22 个百分点），工程从 12% 到 30%，设计从 6% 到 22%，市场销售侧从 5% 到 18%；201 人以上组织的 CEO 涨幅最陡，达 27 个百分点。同时，非工程岗开始直接产出代码：产品经理挂 PR 的比例从 3% 到 10%，设计师从 1% 到 8%。
没降的那一头
同一份数据里，2025 年 6 月到 2026 年 6 月，花在创建、分诊和评论上的时间在几乎所有职能上都是增加的：工程仅创建与分诊就多花约 5 分钟／月，创始人在创建上多花 17 分钟、评论上多花 26 分钟；另外多出一个新类别「和 AI 聊天」，各职能每月占 2–5 分钟。规划类工作（客户需求、文档）则基本没变。 把两头放一起，这份报告说明的不是「AI 让开发变慢了」，而是产出增加之后，协调成本跟着一起增加——写得更多，要分诊、要评论、要对齐的东西也更多。这跟直觉相反的地方在于：很多团队买 AI 工具时预期的是协调时间下降。
别把 Linear 和 LinearB 的数字混着用
这里有个容易搞混的点：Linear（linear.app）和 LinearB 是两家公司，最近各自发了报告，媒体常把两边的数字拼在一起。上面这些来自 Linear 自己产品的聚合数据；LinearB 的 2026 基准报告是另一套样本（约 4800 个团队、810 万个 PR），结论是人工 PR 有 84.5% 在 30 天内合并，而 AI 辅助的只有 32.7%，评审接手时间从约 200 分钟拉长到约 1050 分钟。两组数据指向的方向一致，但口径完全不同，引用时别互相替换。 对在做工程效能评估的人，这份报告最实用的一条是它的对照组设计：把「用了编程 agent」和「没用」的团队分开看，差距是 3 倍而不是 11%。如果你们的 PR 数没动，问题多半不在模型好不好，而在有没有真的把 agent 接进流程。