团队如何构建——Linear

来源：https://linear.app/data

软件团队中的AI使用模式

第01期 — TIM QI（2026年）

每天有数以万计的团队在Linear内部构建软件。六年来，这让我们对产品开发如何发生有了详尽的了解——从AI广泛采用之前到如今。

模型公司和编码工具已发布大量关于token使用量和代码量的数据，但这仅捕捉了工作的一个层面。我们异常适合于观察构建产品背后的整个工作流程——从第一个issue到关闭它的pull request。我们无法看到的是在Linear之外发生的AI使用情况，因此这是一幅关于我们自身客户群内采用情况的图景，而非整个市场。

我们考察了这一转变过程中的三个方面：谁在使用AI，它如何重塑团队在Linear上花费时间的分布，以及它是否改变了他们的交付量。三者共同为2026年AI辅助产品开发的现状提供了一个固定参照点，并为下一期报告提供了比较基准。

按职能划分的采用情况

AI采用已扩展到每个职能

2026年1月至6月间，每个职能中使用AI功能的用户比例都增加了一倍多。产品部门增长最快，从12%上升至34%；即使是最远离代码库的市场职能，也从5%增长到18%。我们通过规范化职位名称来对角色进行分类，这在边缘情况下存在一些误差，但其模式如此广泛，不可能是标记工件造成的。

过去30天内使用AI功能的用户比例（按职能划分）

按高管团队划分的采用情况

采用情况直达最高层

高管个人使用AI的比率与其团队持平甚至更高。规模超过201人的公司中，CEO的使用率在六个月内从9%跃升至36%，是本报告中所有划分中增幅最大的，这表明最高层的领导者是通过实际使用而非阅读资料来学习这项技术的。公司规模数据来自第三方信息补充，因此此部分划分涵盖的工作空间少于报告其余部分。

过去30天内使用AI功能的用户比例（按高管团队划分）

按公司规模划分的采用情况

AI采用在各个规模的公司中都保持一致

从初创公司到大型企业，AI采用率大致翻了两番。公司规模通常是预测组织采用新技术速度的良好指标，但在此处几乎不体现。

过去30天内使用AI功能的用户比例（按公司规模（员工数）划分）

应用 — 创建与组织

团队向系统投入了更多

2025年6月至2026年6月间，几乎每个职能中用于创建、分类和评论的时间都有所增加，仅工程团队在创建和分类上的时间就增加了约17%。创始人的波动幅度更大，创建时间增加了17分钟，评论时间增加了26分钟，尽管他们是一个较小的群体且因此数据噪声更大。更多的工作似乎需要更多的协调，而这些协调越来越多地为智能体行动提供了上下文。

每位用户每月平均分钟数，2025年6月 vs 2026年6月

应用 — Issue创建

AI创建了近一半的Issue

两年前，每千个issue中不到一个是由AI创建的。团队现在使用AI来撰写Linear中创建内容的近一半，按当前速度，它很快将超过人类和集成工具创建量的总和。

每周创建的issue数量（千），按来源划分

应用 — 规划

Linear内部的规划时间没有变化

在几乎所有其他指标都上升的一年里，用于客户请求、文档和项目的时间保持稳定。规划实践因团队而异，且大部分规划工作在落地之前就已在对话中完成，因此平均值混合了重度规划者和轻度规划者的情况。这种稳定性表明，到目前为止，AI改变的是团队执行工作的方式，远多于决定构建什么的方式。

每位用户每月平均分钟数，2025年6月 vs 2026年6月

应用 — AI

一个新的工作层出现了

与AI聊天和将issue委托给智能体是过去一年中不存在的工作类别，现在它们出现在每个职能的每周工作中，产品部门参与度最高。没有其他任何类别缩减来腾出空间，这表明AI是叠加在现有工作之上，而不是替代了任何现有工作，至少目前如此。

每位用户每月平均分钟数，2025年6月 vs 2026年6月

产出 — PR创建

非工程师正在交付更多代码

产品经理附加pull request的比例在两年内从3%上升到10%，设计师则从1%上升到8%。我们仅统计与Linear连接的仓库中的pull request，因此任何在此流程之外交付的人都不可见，这意味着这些数字是下限而非上限。那些过去只是描述变更的人，现在越来越多地自己交付了它。

过去30天内附加了pull request的用户比例

产出 — PR数量

Pull Request数量在两年内增长了111%

每个工作空间每周打开的pull request数量，以2024年6月为基准增长了111%。第一年产出大致持平，然后在2026年随着模型质量和采用率的共同提升而向上弯曲。我们统计的是打开的pull request而非合并的，打开的PR并不说明变更的价值，但这个拐点很难忽视。

自2024年6月以来，每个团队每周pull request的百分比变化 — 所有付费工作空间

产出 — 编码智能体

编码智能体贡献了大部分增长加速

连接了编码智能体的团队，其每周pull request数量在两年内大致翻了两番，从21增加到65，而没有连接智能体的团队仅从8增加到10。这些团队在编码智能体存在之前就已经是更高产出的团队，因此水平不可直接比较，但每个群体与其自身基准相比都讲述了一个清晰的故事，几乎所有的增长都来自智能体一侧。

每个团队每周的pull request数量 — 固定队列（付费工作空间）

结语

AI对产品开发影响最清晰的迹象，是使用编码智能体的团队在过去两年中经历的显著产出增长。我们无从知晓这种增长是否带来了积极的业务成果，但它确实显示了AI采用与加速之间非常清晰的相关性。

或许更耐人寻味的是这种采用的构成，以及它似乎正在模糊角色界限。高级领导者正在做更多动手的一线工作，并积极采用AI来帮助他们完成，非工程师也在提交代码。“组织中的每个人都正在成为一名‘构建者’”的说法，似乎在方向上是正确的。

然而，这些增长并未体现为节省的时间。在Linear中，现有任务所花费的时间保持稳定，而AI使用作为新的工作层出现，这意味着产品开发的总时间在增加而非减少。据我们观察，团队的工作量是在增加而非减少，这表明AI具有超出token消耗的杰文斯悖论特性。

许多人会合理地争辩说，观察pull request指示的是活动而非价值，这无疑是正确的，但这仍比衡量token更进了一步。一次机械的重构可能消耗大量token，而一次有意义的bug修复或代码审查则不会，因此token消耗与价值根本不对齐，用一个作为另一个的代理指标将被铭记为AI早期的遗迹。

在未来的报告中，我们计划更深入地探讨工作的完整生命周期——从token消耗一直到结果，这是我们现在能够新观察到的，因为代码和代码审查现在也通过Linear进行。

TIM QI - 数据主管

附录

方法论

本报告使用Linear的聚合产品数据。数据包括AI对话、智能体会话、issue活动、评论和pull request。仅涵盖付费工作空间及其用户。我们报告所有指标的聚合值，以展示团队使用AI构建软件的广泛模式，而非个人行为。我们在固定的时间窗口内衡量每个指标。一个窗口是一个日历月或过去30天。同比图表使用2025年6月和2026年6月。采用指标使用过去30天的窗口，时间序列图表聚合到每周数据点。这两步都减少了短期噪声。部分图表仅保留在两个窗口中都活跃的用户。

定义

AI活跃。 在28天窗口内至少有一次AI交互（应用内或Slack对话或智能体会话）的用户。

智能体团队。 已连接编码智能体的工作空间。

Pull request。 针对与Linear连接的仓库打开的代码变更。我们统计打开的pull request，而非合并的。

付费工作空间。 处于付费计划、在相关时期内活跃的工作空间。

智能体issue。 包括将issue委托给智能体或启动会话。

公司规模。 公司的全职员工数，来自第三方信息补充。