几千名开发者同时写代码，每天产生上千个补丁，没有上下级关系，没有项目经理排优先级——Linux 内核可能是人类历史上最大规模的去中心化协作工程。它运转了三十多年，不但没崩，还在持续扩大。
最近读了 Linus 的自传《Just for Fun》，我开始想一个问题：Linux 社区这种看似松散的模式，对一个正在被 AI agent 重构的软件团队，有什么可借鉴的？
研究下来，我找到了四条启发。但也发现了一条容易被忽略的前提——这条前提可能比四条启发加起来都重要。
启发一：MAINTAINERS 文件——治理即代码
Linux 有一个文件叫 MAINTAINERS。它列出了内核每个子系统的负责人、审查人、邮件列表、状态标记。全是机器可读的。一个补丁提交进来，根据它修改的文件，自动路由到对应的 maintainer 审查。
这不是文档，是治理基础设施。它解决三个问题：谁有权批准这个变更？谁应该被通知？这个子系统的健康状态是什么？
现在的 AGENTS.md 或 CLAUDE.md 是这个模式的雏形——告诉 agent 项目的边界在哪、用什么规范、怎么跑测试。但它少了两个关键能力：路由（agent 生成的代码自动流向对的审查人）和状态（根据变更风险动态调整审查深度）。
AI-native 团队可以直接拿 Linux 的模式用：把 AGENTS.md 升级为真正的治理文件，每个子系统有命名负责人，变更自动路由，审查深度根据变更影响的子系统状态调整。不用发明什么，抄三十年的作业就行。
启发二：渐进审查不只是层级，是信任建立过程
Linux 的补丁审查有几个阶段：表面正确性检查 → 编码风格合规 → 逻辑审查 → 架构影响评估。每一层通过之后，审查者对补丁质量的信心更高，后续审查可以聚焦更深层的问题。
这个模式看起来只是"从浅到深"。但它的真正功能是信任积累。一个贡献者连续三个补丁通过了表面和风格检查，maintainer 就开始信任他的基础能力，后续的逻辑审查可以更聚焦而不是从头检查。
这给 AI 团队一个提醒：最容易自动化的审查环节恰好是信任建立的起点。当你用 agent 自动处理 lint、格式检查、简单 bug 检测时，你省掉了劳动，但也消除了人类审查者通过这些环节建立信任的过程。没有前几层的信任积累，人类对 agent 产出的更深审查也缺乏信心基础——不是因为深度审查做不了，而是审查者没有经历过"这个贡献者（或 agent）在基础层面是可靠的"这个信任建立过程。
结论不是"不要自动化审查"。而是：如果你自动化了审查的前几层，需要在某个地方重建信任积累机制——也许是 agent 附带自动化的质量评估报告，让审查者从"信任基础能力"转向"信任评估体系"。
启发三：声誉是让大规模协作运转的粘合剂
Linux 能把审查权委托出去，核心原因是 maintainer 的名字押在每一次批准上。你批准了一个补丁，你的声誉就为它背书。如果补丁引入了严重 bug，损害的是你的名字。这个社会压力让审查质量有基本保障。
这个机制在 AI 团队里完全缺失。Agent 没有声誉可押。它不会因为批准了坏代码而损失什么——它没有"什么"可损失。这意味着 Linux 最核心的规模化机制（声誉背书的委托链）在 agent 参与的流程里直接断裂。
这不是一个可以通过更好的 prompt 或更严格的测试来解决的问题。声誉机制是一种社会结构，不是技术参数。AI-native 团队如果想安全地扩大 agent 的审查和决策权，需要发明某种等价机制——也许是人类对 agent 决策的连带责任（你对你的 agent 产出的代码负责，就像 maintainer 对他批准的补丁负责），也许是 agent 行为的可追溯信用记录。但目前还没有成熟的方案。
启发四：Merge Window——节奏是特征而非瓶颈
Linux 的开发节奏很特别：每 10 周左右开放一个两周的 merge window，接受新功能；然后关闭窗口，进入 6-8 周的稳定期，只修 bug。所有新功能必须等下一个窗口。
这不是效率瓶颈，是设计特性。它让几千名并行开发者有同步的节奏——知道什么时候提交新功能，什么时候专注于稳定。更重要的是，它创造了可审查的批次。两周的变更量有限，maintainer 能逐个审查。如果持续不断地合并新功能，审查量会迅速超过人的处理能力。
AI-native 团队默认的是 continuous delivery——agent 生成、测试、合并，持续流动。但当 AI 生成量超过人类审查能力时（这已经在发生了），merge window 的节奏优势就显现了：批次创造可审查性，可审查性创造质量保障，质量保障创造信任。
代价是故意放慢管道中本可以更快的那部分。但对于一个审查已经跟不上的系统，更快只是更快地积累技术债。
被忽略的前提：用户即开发者
上面四条都是从治理结构看的。但 Linux 早期成功有一个更底层的条件，很容易被忽略：早期 Linux 的用户同时也是开发者。
1991 年用 Linux 的人是系统管理员和 CS 学生，他们既用这个系统，也能写代码改它。这意味着需求信息不需要从用户传到开发者——因为就是同一个人。不需要写需求文档，不需要做用户调研，不需要做 NPS 调查。哪里不爽，自己改。
Eric Raymond 在《大教堂与集市》里把这一点列为第一条规则："每一个好的软件作品都始于 scratching a developer's personal itch。"von Hippel 用四十年的研究给出了学术版：需求信息是"粘的"——从一个人脑中传递到另一个人脑中的成本极高。当用户和开发者是同一个人时，传递成本为零。
三个独立框架从不同方向走到了同一个结论。信息粘性理论（von Hippel）：需求信息跨人传递成本极高，合一时归零。隐性知识理论（Nonaka）：用户需求大量是隐性的，跨人传递必须先显性化，损失不可避免，合一时隐性知识直接行动。委托-代理理论（经济学）：生产者和消费者分离产生三类损失——监督成本、激励偏差、剩余损失（Standish Group 数据：约 45% 的已交付功能从未被使用），合一时全部消除。
Linux 服务器端成功和桌面端失败正好证明了这一点。同一套社区、同一套治理，在服务器端（用户是技术人员）大获成功，在桌面端（用户不是技术人员）持续挣扎。用户即开发者保证了"为自己这类人"的产品契合度，但不保证对其他类型用户的契合度。
这对 AI-native 团队意味着什么？直觉可能是：AI 降低了编码门槛，更多人能参与生产，用户-开发者重叠扩大了。这个直觉是对的，但需要修正。
AI 创造的是"用户即规格说明者"，而非真正的"用户即开发者"。非技术用户可以用自然语言告诉 AI 要什么，但无法深度验证 AI 给出的实现是否正确。信息折损减少了——需求不需要跨人传递——但没有消除——用户无法在实现层面确认需求被正确满足。我把这叫"浅重叠"：规格说明统一了，验证能力却分散了。
所以更实用的设计原则不是"让生产者做消费者"，而是：让决策点和验证点在同一个 人身上，即使执行点委托给 AI。
决策（要什么）和验证（对不对）在同一人，信息零损耗。执行（怎么做）可以委托，因为执行是信息损耗最小的环节——它可以被规格完全约束。拆开决策和验证，就是在重新引入用户-开发者重叠本来消除的那三类信息损耗。
一个产品经理决定了做什么，应该由同一个产品经理验证做出来的对不对——不能把验证推给 QA。一个架构师设计了架构，应该由同一个架构师验证实现——不能把审查推给另一个审查者。AI 执行，人决策和验证，作为统一职能。
听起来简单。但实操中这很反直觉——AI 让执行变便宜后，组织的第一反应往往是让执行者（AI）承担更多验证，让决策者（人）去"更高层次"。这恰好拆开了不该拆的东西。
Linux 教不了的
最后说一个 Linux 教不了的事。
Linux 社区运转的底层社会架构——声誉背书、命名问责、信任链——恰恰是 AI 替换人类时最先消失的东西。没有一个 agent 会在审查坏代码时"损失声誉"，也没有一个 agent 会因为长期贡献而"赢得信任"。Linux 能教我们的是这些机制为什么重要，但替代品需要我们自己发明。
也许最终 AI-native 团队需要的不是一个更好的技术架构，而是一个新的社会架构——一个在 agent 和人之间重建声誉、问责和信任的社会架构。这个架构长什么样，我现在还没有答案。
参考文献
- Torvalds, L. & Diamond, D. (2001). Just for Fun: The Story of an Accidental Revolutionary. HarperBusiness. Linus 自传，描述了 Linux 的起源和个人动机——他需要一个终端模拟器连接大学服务器，然后迭代构建了自己需要的系统。
- Raymond, E. S. (1999). The Cathedral and the Bazaar. O'Reilly. 开源理论奠基作，第一条规则"每一个好的软件作品都始于 scratching a developer's personal itch"是用户即开发者假说的经典表述。提出 Linus's Law："given enough eyeballs, all bugs are shallow"。
- von Hippel, E. (1994). "Sticky Information and the Locus of Problem Solving." Management Science 40(4). 提出信息粘性概念——需求信息跨人传递成本极高，问题解决应发生在信息所在的位置。用户即开发者时传递成本为零。
- von Hippel, E. (2001). "User Toolkits for Innovation." Journal of Product Innovation Management. 当厂商无法理解用户需求时，应给用户提供创新工具包。AI 编码助手是这一理论的终极实例化。
- von Hippel, E. (2005). Democratizing Innovation. MIT Press. 综合性著作，将开源软件作为用户创新典范。发现用户开发了约 80% 最重要的科学仪器创新和大多数半导体工艺创新。
- Nonaka, I. & Takeuchi, H. (1995). The Knowledge-Creating Company. Oxford University Press. SECI 模型区分隐性知识与显性知识，用户需求大量是隐性的——用户即开发者时隐性知识无需显性化即可直接行动。
- Jensen, M. C. & Meckling, W. H. (1976). "Theory of the Firm: Managerial Behavior, Agency Costs and Ownership Structure." Journal of Financial Economics 3(4). 委托-代理理论的奠基作，定义了监督成本、激励偏差和剩余损失三类代理成本。
- Standish Group. CHAOS Reports (ongoing since 1994). 持续追踪软件项目失败原因，发现约 45% 的已交付功能从未被使用——生产者-消费者信息折损的实证。
- Nichols, D. & Twidale, M. (2003). "The Usability of Open Source Software." First Monday 8(1). 指出开源系统性地产生较差的可用性，因为开发者为和自己一样的人设计——用户即开发者假说的关键反证。
- Bezroukov, N. (1999). "A Second Look at the Cathedral and the Bazaar." First Monday 4(12). 对 Raymond 理论的系统性质疑，同时确认早期 Linux 贡献者"同时是用户和开发者"这一结构性优势。
- Franke, N. & von Hippel, E. (2003). "Satisfying Heterogeneous User Needs via Innovation Toolkits." Research Policy 32(7). Apache 用户研究中，自行定制安全功能者满意度显著高于未定制者（4.3 vs 2.6, p=0.010）。
- Linux Kernel MAINTAINERS File. 内核源码中的治理即代码实践——每个子系统的拥有者、审查人、邮件列表和状态标记在一个机器可读文件中定义。