软件团队AI使用模式：从采纳到产出

软件团队中的人工智能使用模式每天有数万个团队在 Linear 内部构建软件。六年来，我们详细了解了从 AI 被广泛采用之前到现在的产品开发过程。模型公司和编码工具已经发布了大量关于 token 使用量和代码量的数据，但这只涵盖了工作的一部分。

我们拥有独特的优势，能够看到构建产品背后的整个工作流程，从第一个 issue 到关闭它的 pull request。我们无法看到 Linear 之外的 AI 使用情况，因此这反映的是我们自身客户群内部的采用情况，而非整个市场。

我们关注这一转变中的三个方面：谁在使用 AI，它如何重塑团队在 Linear 上花费时间的方式，以及它是否改变了他们的交付量。这些共同为 2026 年 AI 辅助产品开发的现状提供了一个基准，并可作为衡量下一版本的参照。

AI 的采用已扩展到各个职能2026 年 1 月至 6 月期间，每个职能中活跃使用 AI 功能的用户比例都增加了一倍以上。产品职能增长最快，从 12% 上升到 34%，甚至与代码库距离最远的“市场进入”职能也从 5% 上升到 18%。

我们通过标准化职位名称来对角色进行分类，这在边缘存在一些误差，但这一模式过于广泛，不可能是标签化造成的假象。

按职能划分的 Linear AI 功能活跃用户百分比（最近 30 天）采用率一路延伸至最高管理层高管个人使用 AI 的活跃度与团队相当甚至更高。

在拥有 201 名及以上员工的公司中，CEO 的活跃率在六个月内从 9% 上升到 36%，这是本报告中所有细分群体中增幅最大的，这表明最资深的管理者正在通过实际使用而非阅读来学习这项技术。公司规模数据来自第三方增强，因此这一细分覆盖的工作区数量少于报告其他部分。

按高管团队划分的 Linear AI 功能活跃用户百分比（最近 30 天）各种规模的公司采用率一致从初创公司到企业，AI 的采用率几乎都增长了两倍。公司规模通常是预测组织采用新技术速度的良好指标，但在这里几乎没有体现。

按公司规模（员工人数）划分的 Linear AI 功能活跃用户百分比（最近 30 天）团队在系统上投入的时间更多2025 年 6 月至 2026 年 6 月期间，几乎所有职能在创建、分类和评论上花费的时间都有所增加，其中工程职能在创建和分类上的时间增加了约 17%。

创始人的波动幅度更大，创建时间增加了 17 分钟，评论时间增加了 26 分钟，尽管他们人数较少，因此数据噪音也更大。更多的工作似乎需要更多的协调，而这种协调越来越多地为智能体提供行动所需的上下文。

每位用户每月平均分钟数，2025 年 6 月 vs 2026 年 6 月AI 撰写了近一半的 issue两年前，由 AI 创建的 issue 不到千分之一。

现在，团队使用 AI 撰写了 Linear 中创建内容的一半左右，按照目前的速度，AI 很快将超过人员和集成创建的总和。

按来源划分的每周创建的 issue（千）规划时间在 Linear 内没有变化在本报告几乎所有其他指标都上升的一年里，用于客户请求、文档和项目的时间保持稳定。不同团队的规划实践差异很大，而且很多规划发生在对话中，之后才落地，因此平均值混合了重度规划者和轻度规划者。

这种稳定性表明，到目前为止，AI 对团队执行方式的影响远大于对决策方式的影响。

每位用户每月平均分钟数，2025 年 6 月 vs 2026 年 6 月出现了一个新的工作层面与 AI 聊天和将 issue 委托给智能体是一年前不存在的工作类别，现在它们出现在每个职能的每周活动中，其中产品职能投入最多。

没有其他工作缩减来腾出空间，这表明 AI 是叠加在现有工作之上，而非取代任何工作，至少目前如此。

每位用户每月平均分钟数，2025 年 6 月 vs 2026 年 6 月非工程师正在交付更多代码产品经理关联 pull request 的比例在两年内从 3% 上升到 10%，设计师从 1% 上升到 8%。

我们只统计连接到 Linear 的仓库中的 pull request，因此任何在该流程之外交付的内容在这里都不可见，这使得这些数字是下限而非上限。过去描述变更的人越来越多地自己交付变更。

关联了 pull request 的用户百分比（最近 30 天）Pull request 数量两年内增长了 111%每个工作区打开的 pull request 数量相比 2024 年 6 月的基线增长了 111%。

第一年产出大致持平，随后在 2026 年随着模型质量和采用率的共同提升而向上弯曲。我们统计的是已打开而非已合并的 PR，打开的 PR 并不能说明变更的价值，但这一拐点很难忽视。

自 2024 年 6 月以来每团队每周 pull request 的百分比变化——所有付费工作区编码智能体是加速的主要驱动力连接了编码智能体的团队在两年内每周 pull request 数量大约增长了两倍，从 21 个增加到 65 个，

而没有连接编码智能体的团队则从 8 个增加到 10 个。这些团队在编码智能体出现之前产出就已经更高，因此水平不能直接比较，但每个队列相对于自身基线的变化讲述了一个清晰的故事，而且几乎所有增长都发生在智能体一侧。

每团队每周 pull request——固定队列（付费工作区）AI 对产品开发影响的最明显迹象是，过去两年使用编码智能体的团队经历了显著的产出增长。

我们无法知道这种产出增长是否带来了积极的业务成果，但它显示了 AI 采用与加速之间的非常明显的相关性。也许更有趣的是这种采用的构成，以及它如何似乎模糊了角色界限。高级领导者正在做更多亲力亲为的 IC 工作，积极采用 AI 来帮助他们完成这些工作，而非工程师也在提交代码。

组织中每个人都在成为“构建者”的说法似乎方向上是正确的。然而，这些收益并没有体现为节省的时间。Linear 中现有任务上花费的时间保持不变，而 AI 的使用作为新的工作层面出现，这意味着花在产品开发上的总时间在增加而非减少。

据我们观察，团队的工作量在增加而非减少，这表明 AI 具有超越 token 消耗的杰文斯悖论特质。许多人会合理地指出，查看 pull request 反映的是活动而非价值，这当然是对的，但这仍然是比衡量 token 更进一步。

一次机械重构可能会消耗大量 token，而有意义的 bug 修复或代码审查则不会，因此 token 支出与价值完全不对应，用前者作为后者的代理将被视为 AI 早期时代的遗留物。

在未来的报告中，我们打算更深入地研究工作的完整生命周期，从 token 支出一直到结果，这是我们现在能够新观察到的，因为代码和代码审查也通过 Linear 进行。

附录方法论本报告使用 Linear 的聚合产品数据。数据包括 AI 对话、智能体会话、issue 活动、评论和 pull request。它仅涵盖付费工作区及其用户。我们以聚合方式报告所有指标，以展示团队如何使用 AI 构建软件的广泛模式，而非个人行为。

我们在固定时间窗口内衡量每个指标。窗口为一个日历月或最近 30 天。同比图表使用 2025 年 6 月和 2026 年 6 月的数据。采用指标使用 30 天滚动窗口，时间序列图表汇总为每周数据点。

这两个步骤都减少了短期噪音。某些图表仅保留在两个窗口中均活跃的用户。定义AI 活跃用户：在 28 天窗口内至少有一次 AI 交互（应用内或 Slack 对话，或智能体会话）的用户。智能体团队：连接了编码智能体的工作区。