← #806

Linear 的数据报告：软件团队的 AI 使用模式，PR 两年翻了一倍多

文章摘要

这是 Linear 数据负责人 Tim Qi 署名的「How teams build」系列第一期（EDITION 01），基于 Linear 自家付费工作区的聚合产品数据，试图回答「AI 到底怎么改变了产品开发流程」。Linear 的自我定位是：模型公司和编码工具已经发了大量 token 消耗量和代码量的数据，但那只覆盖了工作的一层；Linear 能看到从第一条 issue 到关闭它的那个 PR 的整条工作流。他们也如实声明了盲区——发生在 Linear 之外的 AI 使用完全看不见，所以这是自家客户群的画像，不是整个市场。

采纳率（Adoption）。2026 年 1 月到 6 月，各职能中「近 30 天使用过 Linear AI 功能」的用户占比全部翻倍以上：产品经理从 12% 涨到 34%（+22pp，涨得最快），工程从 12% 到 30%（+18pp），创始人从 14% 到 30%，设计从 6% 到 22%，离代码库最远的 GTM（市场销售）从 5% 到 18%。样本 N = 127,000 名在 1 月和 6 月都活跃的付费用户。

高管比下属更激进。在 201 人以上的公司里，CEO 的 AI 活跃率从 9% 蹦到 36%，+27pp，是整份报告里所有切片中涨幅最大的一项。CTO（201+）从 11% 到 35%，CPO（1-50 人公司）从 11% 到 36%。Linear 的解读是最资深的领导者在靠「上手用」而不是「读文章」学这项技术。样本 N = 13,300 名高管。

公司规模几乎不起作用。1001 人以上从 8% 到 25%，201-1000 人 9% 到 27%，51-200 人 9% 到 25%，1-50 人 8% 到 23%。通常最能预测新技术采纳速度的公司规模，这次基本没有区分度。

工作分布的变化。2025 年 6 月对比 2026 年 6 月，人均每月分钟数：工程在「创建与分诊」上从 24 分钟到 28 分钟（约 +17%），评论从 35 到 40 分钟；创始人的摆动幅度最大——创建 +17 分钟（40→57），评论 +26 分钟（39→64）。而规划类工作（客户请求、文档与项目）几乎原地不动，各职能变化都在 0-1 分钟内。Linear 由此推断：迄今为止 AI 改变的是团队「怎么执行」，远多于「怎么决定做什么」。

Issue 创建。两年前 AI 创建的 issue 不到千分之一；现在 Linear 里新建的 issue 中，将近一半由 AI（agents 与 MCP 客户端）撰写，按当前速度很快会超过「人 + 集成」的总和。

产出（Output）。近 30 天挂过 PR 的用户占比：产品经理两年内从 3% 涨到 10%，设计师从 1% 到 8%，工程从 20% 到 34%，创始人从 11% 到 23%。总 PR 量以 2024 年 6 月为基线上涨 111%——第一年基本持平，2026 年随模型质量和采纳率一起上翘。最关键的一张切片是接入了 coding agent 的团队与没接的团队对比：前者每周 PR 从 21 涨到 65（约三倍），后者从 8 只涨到 10。样本 N = 6,887 个付费团队（4,280 有 coding agent，2,607 没有）。

收尾的自我批评相当坦诚。Linear 明说他们无法得知产出增加是否带来了正面的业务结果，只能说 AI 采纳与加速之间存在很清晰的相关性。他们承认「PR 数量代表的是运动而非价值」，但认为这比数 token 已经是一步进步——一次机械重构可能烧掉大量 token，而一个有意义的 bug 修复或代码评审可能几乎不烧，所以拿 token 当价值的代理「将会被记成 AI 早期时代的遗物」。另一个诚实的观察是：这些收益没有变成节省下来的时间。既有任务的耗时都没缩短，AI 使用是叠加上去的一层新工作，所以产品开发的总投入时间是在往上走，而不是往下走——Linear 称这是 token 消耗之外的另一种 Jevons 悖论。方法论附录里也逐条列了口径：只统计付费工作区，PR 只数 opened 不数 merged，公司规模来自第三方数据补全，AI-active 的定义是 28 天窗口内至少一次 AI 交互。

HN 评论精华

这条帖子 199 分、66 条评论。讨论几乎一边倒地怀疑这份报告的指标效度——主线不是「AI 有没有用」，而是「PR 数量能不能算成果」以及「Linear 拿客户数据发报告合不合适」，另有一整条支线在争论「数据卖点其实是给 Linear 自己做营销」。

jdw64 的开场评论拿到了最高热度，是纯粹的体感描述：现在的工作变成「生成代码 20 分钟，然后花一小时读它」。tankaiji 接：再花几小时清理和重新提示。nik282000 说自己是业余爱好者，本地跑了个 LLM 想看看到底在热闹什么，结果就是「提示 2 分钟、等 5 分钟、调试 3 小时或者干脆自己写」，并有一句很扎人的总结——在代码跑起来抛错之前，LLM 对自己写出了完美代码百分之百地自信。whateveracct 的反问更直白：「我花 45 分钟写完，git commit 走人，因为我做出了好东西。这里谁赢了？」
hypfer 提出了本帖最有理论性的反驳：agent 从根本上无法产出优秀代码，因为优秀代码需要「意图」（intent），而意图恰恰是统计均值的反面。有合适的工作流你能拿到一个能跑的方案，但拿不到能规模化、真正可维护的方案。当 prolly97 用「是不是给的上下文不够」来回应时，他直接点破这是「你握持的方式不对」式的辩护，并说明自己否定的不是 agent 而是整个行业：这是概念上的不可能，不是技术障碍。wongarsu 则从另一侧反驳：所谓「意图」不就是一串优化目标吗——正确、可维护、易懂、行数少、耦合低——理论上给足规格和算力，约束求解器就能解，不需要人的意图；真正的问题是我们无法完整地把这些次级目标写出来，这是经典的回形针最大化问题。
对报告指标的攻击是评论区的主线。gkamal 说这是「在测量容易测的东西，而不是真正要紧的东西」，并加了一句刻薄的括号——按他的经验，PR 数、issue 数、CEO 花在 Linear 上的时间，跟好结果往往是负相关的。hexasquid 想把客户满意度叠上去看后续效应，猜测一部分会跃升、很多会暴跌，「不需要解释为什么」，但 Linear 不会有那份数据。onion2k 补充说这种归因本身就很难：这些应用其实是在把「用户当时在跟 AI 交互」的信号跟他们做出的改动做相关——「Bob 那时候用了 AI，差不多同一时间开了个 PR，所以 Bob 大概是用 AI 开的这个 PR」。cmiles8 直指这篇文章「闻起来像是在说『各位看我们客户拿到 ROI 了』，却没有任何他们真拿到了的证据」，并对创始人一直位于使用曲线顶端给了个有趣的解读——那可能只说明老大想让大家用，而不是这东西真有用，这恰恰是失败的 AI 部署的典型特征。Mugshelf 一句话总结了同一个意思：创始人在使用榜首，说明的是组织压力，而不是产品价值；自上而下驱动的采纳和结果驱动的采纳，长得不一样。
greatgib 提出了一个具体的口径质疑：「PR 两年涨了 111%」更诚实的说法应该是 Linear「检测到的」PR 数涨了这么多——因为这只在你配置了 git 仓库追踪并正确使用时才生效，所以分不清是更多团队在用 Linear 且用对了，还是 PR 真涨了这么多。well_ackshually 部分辩护：PR 翻倍并非不可信，AI 减少了 PR 的仪式感，让你以前没空做的小破改动变得可能、大清理变得至少可做——但 PR 翻倍不等于产出翻倍。
数据伦理构成了第二条支线。sebiandev 认为这不合适：仅仅因为你用了某个平台的服务，他们就能拿到你使用情况的私密细节，还这么大胆地把从客户数据里「偷」来的统计公开发表，这足以让他永远不推荐自己所在组织用这个平台。humbleharbinger 反驳说很多经济数据就是这么来的（比如 ADP 的就业数据），但 sebiandev 回击说那是他的行业——ADP 做的是几十万人规模的自愿调查，而且基本上是付费的，Linear 显然没做自愿调查。clintonb 认为数据是聚合的、不可能识别到单个用户，看不出问题；giraffe_lady 帮忙把反对意见讲清楚了——重点是这份使用数据有商业价值，Linear 在用这份价值获益，而提供数据的客户没有获益；他还引用 Matt Levine 对内幕交易的重构：问题不在公平，在于窃取——你本该靠自己的秘密洞见获得优势，不该拿你雇主得到的秘密洞见给自己捞优势。anon7000 则表示宁愿它免费发在博客里，也不要在自己不知情的情况下被卖掉。
jmtulloss 提了两条建设性意见：数据前面那段散文看起来是 AI 生成的，虽然不算大事但增加了读者的负担；更要紧的是 Linear 没有对自家平台过去一年的 AI 化改造做控制——平台本身变得 AI 集成度高得多，所以很多数字自然会动，没有对照组的话这份信号的用处有限。hobofan 补了一句：「AI 采纳已扩散到每个职能」这种标题只限于 Linear 追踪到的角色，Google 等近期的研究显示的采纳范围要宽得多。
0xbadcafebee 从自己的实践出发质疑了「AI 没有改变决定做什么」这个结论：他们主要用 AI 决定「怎么做」，但「做什么」也受到 AI 驱动的问题调研的影响，而那些调研发生在编码和桌面 AI 工具里，不在 Linear Asks/AI 里，所以测量口径可能有缺陷。他还顺手给 Linear 提了个不太妙的推论：在他自建的工具链下，人再也不用碰 ticket 了，那么任何有 API 或 CLI 的 ticket 系统都行——Linear 之所以是好产品是因为界面做得好，那当他用聊天机器人替掉这个界面之后呢？
agnishom 提供了一个反向视角：他都不知道 Linear 有「AI 功能」——Linear 很无聊，但这对他来说正好；他确实用 LLM 写代码，但这些完全不会出现在这份数据里。