Linux 7.2 一周收 400 多个修复，维护者反而更忙

400 多个修复，来自 230 多位贡献者，挤在 Linux 7.2-rc7 这个本该逐渐安静的版本里。

RC 是 Release Candidate，也就是正式发布前的候选版本。正常节奏里，越靠近最终版，新功能越少，修复包也该越薄。到了 rc7，维护者最想看到的画面通常是风平浪静，最好一眼扫完，周末还能早点关电脑。

Linux 7.2 没给这个面子。

rc6 按提交数算，已经是多年来最大的 rc6 之一。到了 rc7，修复量依旧没明显收住。公开报道把这波密集修复和多种 AI 审查工具联系在一起，驱动、文件系统、网络、架构代码，到处都被翻出边角问题。

这组数字很容易被写成一条 AI 胜利新闻。模型火眼金睛，人类终于可以下班，棒棒的。

可我顺着公开材料往下看，脑子里冒出来的却是另一张图。

缺陷发现的产能，第一次可能跑到了缺陷处理产能前面。

这才是 Linux 7.2 留给普通研发团队最值钱的提醒。AI Code Review 越强，代码库不一定越轻松。你的旧流程要是没跟着改，告警会比修复更快，工单会比结论更多，到头来得到的不是安全感，是一个自动膨胀的待办列表。

图片来自 TechRadar 原文，用于说明 Linux 内核语境

AI 没在替 Linux 写代码

先把最容易传歪的地方扶正。

Linux 7.2 的这些修复，不是模型生成代码后自己签名、自己发邮件、自己合进主线。AI 工具主要做审查和分析，把它认为可疑的路径、资源释放、并发关系或边界条件指出来。后面的活儿仍然在人手上。

有人要复现问题，有人要读懂相关子系统，有人要写补丁、跑测试、回应邮件，子系统维护者还要判断改动会不会制造新的回归。到最上游，补丁依旧要经过 Linux 那套公开、缓慢、甚至有点古典的维护流程。

好家伙，AI 把探照灯换成了体育场泛光灯，搬石头的人还是原来那拨。

这也是为什么 TechRadar 的报道 里有一句判断很关键。增长发生在发布后期的 bug 修复，而不是新功能。工具没有代替人承担修改责任，它只是更快地指出，地板下面还有东西。

把监控做得更灵敏，仪表盘往往会先变红。不是系统突然坏了，而是过去看不见的债一起冒了出来。

写过线上系统的人应该不陌生。新接一套日志分析，第一周通常不是欢呼，而是群里不停弹告警。十条里可能有六条真问题，两条重复，一条环境噪声，还有一条谁也说不清该归哪个团队。工具只负责喊，组织得回答「谁去看」「先看哪条」「修到什么程度」「这个版本敢不敢带上」。

Linux 的规模把这个矛盾放大到很夸张，普通团队却会原样遇到，只是数字小一点。

Sashiko 最厉害的地方，也最容易制造压力

Sashiko 是现在 Linux AI 审查里很有代表性的开源项目。它不是扔一句「帮我 review」给模型，然后祈祷模型今天心情好。

它把审查拆成 11 个阶段。先看提交目标和架构，再核实现实代码是否兑现了提交说明，接着顺执行路径找漏判和越界，然后盯资源生命周期、锁、并发、安全问题与硬件语义。后面还有去重、冲突消解、严重度估计和报告生成。

这套设计有点子牛逼，因为它承认一件很工程的事，代码审查不是一次 prompt，而是一组职责不同、互相校验的检查。

项目方公布的历史回测里，Sashiko 对一组已经进入主线、后来又被修复的已知 bug，检出率是 53.6%。项目也很坦白，误报率更难测，有限人工检查里多数落在 20% 以内。这是项目方自测，不是第三方审计，不能拿来做营销海报上的宇宙真理。

数据来自 Sashiko 开源项目说明，属于项目方自测，不是第三方审计

即便把数字打个折，它的方向依旧清楚。以前没被人类 Review 找出的缺陷，现在有一部分会被机器捞起来。

问题跟着来了。

假设工具每天报 100 条，准确率已经做到相当不错，仍可能留下接近 20 条需要人工排除的噪声。剩下的真问题也不会自己消失。每一条都可能需要复现环境、责任人、补丁、测试和发布窗口。发现能力涨十倍，后端处理能力只涨两倍，队列照样越堆越长。

这不是 Sashiko 做错了。恰恰是它把前半段做得足够好，后半段原本藏着的容量问题才露出来。

Sashiko 的公开实例 已经审查了数万组补丁和数十万条邮件。这个量级真正让我在意的，不是模型能读多少代码，而是维护者要如何让自动审查不压垮公开协作空间。发一条建议很便宜，要求别人证明它对不对，贵得多。

于是代码审查的核心指标也该换了。别再只数 AI 找了多少问题。要看多少问题被确认，多少修复真正合入，误报消耗了多少人时，高风险问题从发现到有人接手花了多久，以及版本发布后到底少逃出去多少 bug。

输出数量是工具的成绩，处理结果才是团队的成绩。

真正的新瓶颈，在分诊和责任归属

Triage，中文常叫分诊。这个词最早让人想到急诊室，放到软件团队也很贴切。不是每个问题都立刻修，得先判断真假、轻重、归属和时机。

AI 审查把分诊从辅助动作，推成了基础设施。

第一道压力是去重。同一条空指针路径，模型可能从调用链、异常分支和资源释放三个角度各报一次。三份报告看着都专业，背后却是一件事。没有跨报告聚类，Review 群很快就会变成复读机。

第二道压力是所有权。模型知道 drivers/net 里有问题，不等于它知道这个补丁应该由谁接、哪个维护窗口能动、哪个硬件实验室可以复现。代码归属表、最近修改者、子系统维护规则、值班安排，这些组织上下文常常不在模型的上下文窗口里。

第三道压力是修复预算。一个低概率资源泄漏可能是真的，但当前版本也许只剩三天。此时硬塞补丁，修掉旧风险的同时又引入回归，账就不好算了。维护者需要的不是更多红点，而是带证据的优先级。

第四道压力更隐蔽，是责任。AI 可以给出建议，却不会在补丁导致服务器启动失败时接电话。真正按下合并按钮的人，仍然需要看得懂改动、认可测试范围，并愿意承担结果。

Linux 内核关于代码辅助工具的公开说明 保留了这条边界。工具可以参与，贡献者仍对提交内容负责。这个原则听着朴素，却是自动化 Review 不滑向甩锅机器的地基。

很多团队接 AI Review 时，最爱先画一条漂亮链路。PR 一开，agent 自动扫，自动评论，自动生成修复，再自动提交。厉害了，看起来除了出事时找不到人，其他都很自动。

我自己的判断是，发现、建议和执行必须拆权。模型可以发现问题，甚至可以准备补丁，但谁批准、谁测试、谁合并，要清清楚楚。权限越接近生产，证据门槛越高。没有这一层，速度会先赢，责任会在后面追得气喘吁吁。

普通团队怎么接住这股修复洪水

如果你准备把 AI Code Review 接进 GitHub Actions、GitLab CI 或内部代码平台，我建议别从「全仓库扫描并自动评论」起步。那是最容易做 demo、也最容易把同事惹毛的方案。

先跑影子模式。

让工具扫描真实 PR，但结果只进单独的看板，不直接打扰作者。连续跑两到四周，人工抽样记录四个数，确认率、重复率、平均分诊时间、真正合入的修复率。样本不够时别急着宣布准确率，尤其不要拿十几条漂亮案例当长期能力。

接着按风险分层。内存安全、权限绕过、数据损坏可以进高优队列，命名、风格、可读性建议留给现有 linter。Semgrep、CodeQL、编译器和单元测试已经能稳定判断的事，别再让大模型换一种口气重复。贵的模型判断，要留给传统规则够不到的语义问题。

然后给告警设预算。每个仓库、每个 PR 最多推多少条，每天最多进入人工队列多少条，超过之后是降采样、延后，还是只保留高置信度结果，都要提前写进规则。限流不是削弱 AI，是保护 Review 信道不被自己淹死。

再给每条高风险发现绑定负责人和时限。没有 owner 的告警，只是墙上的红灯。可以按 CODEOWNERS、子系统目录、最近修改历史自动推荐，但最终要有人接单，也允许明确标记「暂不修」并写下理由。让风险可见，也让取舍可追溯。

还有一条经常被漏掉，给误报一个便宜的反馈入口。开发者只需要点一次就能标记重复、无法复现、上下文误判或已知风险，别逼人写一篇申诉论文。反馈应该回到提示词、检索范围和置信度校准里。否则同一种噪声每天回来问候你，谁都扛不住。

自动修复得放在靠后。只有当某类问题的确认率、测试覆盖和回滚路径都稳定了，才把 agent 从「只读审查者」升级成「能提补丁的协作者」。即便到了这一步，也先让它开 PR，不要直推主分支。

顺序看着慢，实际上更快。因为你是在给自动化修路，不是在高速上边开边补护栏。

Linux 7.2 的故事很有意思。AI 没有接管内核，它只是把灯照得更亮。灯一亮，尘土、裂缝、旧电线全出来了。以前团队可以说没看见，现在不行。

但看见不等于解决。

接下来真正稀缺的，可能不再是发现 bug 的眼睛，而是愿意判断、修复并为结果签字的人。模型会把更多问题推到岸边，人类得决定哪些先捞，哪些能等，哪些看着像宝贝，其实只是一块反光的玻璃。

所以别把 AI Code Review 的目标写成「找出更多问题」。把它改成「用可承受的人力，更早解决更重要的问题」。

少这半句，修复洪水迟早会变成工单洪水。