270 万次 PR 告诉我们：智能体真正合并了什么

LinearB 在 2026 年发布的 AI 工程基准覆盖了 270 万次 pull request、83,000 名开发者与 253 个工程组织（LinearB，2026）。在这份数据里，最重要的一条不是「AI 让开发者快了多少」，而是「快在哪里、慢在哪里被拆开了」：把开发者按 AI 使用强度分档后，使用强度最高的一档（75% 以上的编码日都用 AI）在 2026 年 5 月的合并速度是 2025 年 6 月的 2.3 倍，而完全不用 AI 的一档基本持平。同一份数据还给出了一个容易被忽略的对照：在精英组织里，来自自主智能体的 PR 占比不到 5%，而智能体开的 PR 被合并的比例，明显低于人写的 PR。

合并率才是结果，AI 使用率只是输入

一、2.3 倍是怎么算出来的

分档的口径需要说清楚，否则数字会被误读：使用强度最高档指该开发者 75% 以上的编码日使用 AI，高档为 50% 以上，中档为 20% 以上。按同一批人同比计算，最高档的中位数提升是 95.7%，高档 65.4%，中档 24.4%，而完全不用 AI 的开发者同期下降 3.6%；由于少数人的极端收益会拉高均值，最高档的集体产出增幅达到 134%（LinearB，2026）。作者同时明确提示：这是相关性，只能说明「AI 用得越多、合并率越高」这一现象同步发生，不能证明是 AI 单独造成了结果。把这一点先讲清楚，后面的数字才站得住。

-- merge_rate_bands.sql - your own version of the 2.3x number
WITH dev_days AS (
  SELECT author_id,
         date_trunc('day', authored_at)                     AS day,
         COUNT(DISTINCT pr_id)                              AS prs,
         COUNT(DISTINCT pr_id) FILTER (WHERE ai_used)        AS prs_with_ai
  FROM pr_authors
  GROUP BY 1, 2
), banded AS (
  SELECT author_id,
         CASE WHEN AVG(prs_with_ai::numeric / prs) >= 0.75 THEN 'very_high'
              WHEN AVG(prs_with_ai::numeric / prs) >= 0.50 THEN 'high'
              WHEN AVG(prs_with_ai::numeric / prs) >= 0.20 THEN 'moderate'
              ELSE 'none' END                               AS ai_band
  FROM dev_days GROUP BY 1
)
SELECT b.ai_band,
       COUNT(DISTINCT p.id)                                   AS merged_prs,
       ROUND(COUNT(DISTINCT p.id)::numeric / COUNT(DISTINCT b.author_id), 1) AS prs_per_dev
FROM banded b JOIN pull_requests p ON p.author_id = b.author_id AND p.merged_at IS NOT NULL
WHERE p.merged_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY 1 ORDER BY 1;

-- LinearB's 2026 benchmarks put the very high band (AI on 75%+ of coding
-- days) at 2.3x its June 2025 merge rate, and the no-AI group slightly down.

无人认领的智能体 PR 往往就那样搁置着

二、采用率不等于杠杆率

「大家都在用 AI」与「AI 真的改变了交付」是两件事。在排名前 10% 的组织里，54% 的 PR 带有 AI 编码辅助，45% 已合并代码行由 AI 撰写，而来自自主智能体的 PR 只占 4.7%；AI 代码审查的占比是 57%，而前 30% 的组织只有 26%、前 60% 只有 8%（LinearB，2026）。这组数字的价值在于它提供了可比较的分位线：多数团队的「AI 使用率」听起来已经不低，但真正区分领跑者的，是 AI 参与评审的比例——那是一项七倍的差距。

# ownership.py - an agent PR with no owner is not a contribution
AGENT_ACTORS = ("codex-bot", "claude-agent", "cursor-agent")

def gate(pr):
    if pr["author"] not in AGENT_ACTORS:
        return {"ok": True}
    if not pr["requested_reviewers"]:                 # needs a human owner
        return {"ok": False, "action": "assign an engineer before CI spend"}
    if pr["changed_lines"] > 800 and not pr["linked_tests"]:
        return {"ok": False, "action": "require linked tests"}
    return {"ok": True, "label": "agent-assisted"}

# The benchmark explains the 79% vs 92% gap by ownership rather than
# capability: an agent PR nobody owns tends to sit unmerged.

在数据里，AI 代码审查是见效最快的一项

三、自主智能体不是捷径

关于自主智能体，数据给出的结论比宣传要冷：在排名前 10% 的组织，智能体开的 PR 在 30 天内被合并的比例是 79%，而纯人类 PR 是 92%；到了前 60% 的组织，智能体的这一比例掉到 37%（LinearB，2026）。LinearB 对这一差距的解释不是能力，而是归属：当智能体开出的 PR 没有工程师认领时，它倾向于一直搁置。换句话说，智能体在交付流程边缘做实验很容易，真正进入交付主干需要有人为结果负责。这也解释了为什么「自主 PR 占比」这个指标在精英组织里依然低于 5%——不是不会用，而是还没找到让它负责到底的方式。

# ai_review_routing.py - attach AI review where the baseline is weakest
THRESHOLDS = {
    "needs_focus": 0.08,    # bottom half: 8% of PRs get AI review
    "good": 0.26,           # top 30%
    "elite": 0.57,          # top 10%
}

def should_ai_review(pr, current_share):
    if current_share >= THRESHOLDS["elite"]:
        return True
    # cheapest wins first: large or cross-module diffs benefit most
    return pr["changed_lines"] > 200 or pr["modules_touched"] > 1

# In LinearB's data, AI-reviewed PRs merge at the highest rate of any
# category, up to five points above the all-PR baseline.

四、见效最快的一项：AI 代码审查

如果只能从这份数据里挑一件事先做，那就是 AI 代码审查。带 AI 审查的 PR 在全部类别中合并率最高，相比全体 PR 基线最多提升 5 个百分点，相比纯人类 PR 最多提升 7 个百分点，而且提升幅度在基线最差的团队里最大（LinearB，2026）。它的好处是几乎不需要改变工作方式：不引入新的合并权限，不改变分支策略，只是让每一份 diff 在人工阅读之前先拿到一遍机器意见。对已经买了 AI 编码工具但 PR 流程没变的团队来说，这是同一笔预算里最容易被浪费掉的一半。

-- token_cost.sql - put the 481 dollar figure in context
WITH monthly AS (
  SELECT developer_id,
         date_trunc('month', ts)          AS month,
         SUM(cost_usd)                    AS ai_cost_usd
  FROM llm_usage
  WHERE ts >= CURRENT_DATE - INTERVAL '3 months'
  GROUP BY 1, 2
), ranked AS (
  SELECT month, developer_id, ai_cost_usd,
         PERCENT_RANK() OVER (PARTITION BY month ORDER BY ai_cost_usd) AS pct
  FROM monthly
)
SELECT month,
       ROUND(AVG(ai_cost_usd), 2)                                        AS avg_usd,
       ROUND(MAX(ai_cost_usd) FILTER (WHERE pct >= 0.90), 2)             AS cost_at_p90
FROM ranked GROUP BY 1 ORDER BY 1;

-- LinearB reports 481 dollars per developer per month at the 90th
-- percentile of spend, still under 4% of a fully loaded developer cost.
-- Measure your own p90 before arguing about the average.

五、成本与复盘：把 p90 和首评时间放到同一张表上

最后是两个常被忽略的数字。其一是成本：在 AI 支出的第 90 百分位上，每位开发者每月约 481 美元，仍不足一名开发者全成本的 4%（LinearB，2026）。这句话的正确用法不是「所以可以放心花」，而是「先量自己的 p90 再讨论均值」——均值会把少数失控的调用掩盖掉。其二是时间：智能体 PR 的落地率与「首次评审等待时间」高度相关，而多数团队从未把这个指标单独看过。下面五段代码分别处理：分档复算合并率（示例 1）、给智能体 PR 加上必须有人的门禁（示例 2）、把 AI 审查投到基线最弱的地方（示例 3）、算自己的 p90 成本（示例 4）、按 30 天窗口拆解智能体 PR 的落地率与首评时间（示例 5）。做完这些，你就能用自己仓库里的数字回答「AI 到底有没有让我们更快」。

-- agent_yield.sql - why agent PRs do or do not land in 30 days
SELECT CASE WHEN age_in_days > 30 THEN 'over_30d' ELSE 'within_30d' END AS window,
       COUNT(*)                                                       AS prs,
       ROUND(100.0 * COUNT(*) FILTER (WHERE merged) / COUNT(*), 1)     AS merge_rate_pct,
       ROUND(AVG(reviewer_count), 2)                                   AS avg_reviewers,
       ROUND(AVG(hours_to_first_review), 1)                            AS hours_to_first_review
FROM agent_pull_requests
GROUP BY 1;

-- LinearB: 79% of agent PRs merge within 30 days at top-decile orgs versus
-- 92% for human-only PRs, and only 37% at the top 60%. Time-to-first-review
-- is the lever most teams have never looked at.