摘要

  • 2026 年 8 月 6 日，IETF Tools 团队表示，面向多数系统的大型 AI 辅助 PR 可能大量出现；若继续逐行阅读所有提交，审阅负担可能成为针对团队能力的“拒绝服务”。这是容量预判，不是已经发生的攻击或停机。
  • 8 月 25 日真正合并到组织级贡献指南的规则仍然是：所有贡献进入队列，由一名或多名维护者逐行阅读。AI 生成代码可以进入，但必须满足说明、可独立审阅的小提交、测试、依赖披露和政策适配等同一套要求。
  • 指南把责任落在具体的人身上，却没有虚构成人工原创。提交者须理解代码打算做什么、如何融入目标工具，读懂人类说明的每一行，并承诺处理后续问题。
  • 如果团队以后让低影响代码少接受人工审阅，应为每一个例外生成“审阅边界收据”，写明分类人、影响面、证据、实际人工审阅深度、AI 的辅助范围、合并授权人、维护责任、升级与回滚条件。

代码越来越多，能够承接代码的人没有同步增加

软件贡献过去有一种天然摩擦：写得越多，作者通常投入越多。生成式编程工具打破了这层约束。一个人可以在很短时间内交付跨越多个模块的重构、成批测试和完整说明。输出规模不再可靠地代表投入程度。

但接收方的成本没有按照同样速度下降。维护者不仅要判断语法和测试结果，还要理解旧架构为何如此设计、真实数据量会怎样放大查询、依赖升级会引入什么生命周期，以及贡献者离开以后谁处理故障。

IETF Tools 8 月 6 日更新把这种不对称说得很直接：团队预计多数系统会收到由 AI 辅助编写的大型、雄心勃勃的 PR；如果仍按现行做法逐行阅读，团队可能遭遇一种“拒绝服务”。

这句话需要保持原有边界。它没有记录恶意 PR，没有说明服务被打断，也没有证明 AI 代码已经损坏 IETF 数据。它谈的是一种可能发生的资源耗尽：提交者可以廉价制造审阅需求，而维护者必须用不可复制的时间来消化。

开放贡献并不意味着任何人都可以无上限地占用这种时间。接收代码的制度如果无法拒绝难以评估的输入，就会把“开放”变成向维护者转移成本的权利。

8 月讨论了两条路，正式规则只走了第一条

团队的公开讨论包含两个层次。

第一层是改变输入形态。大型贡献需要人类能够理解的总体计划，要拆成可单独审阅的小块，遵循既有风格，配备符合项目策略的测试，列出并说明新依赖，还要有一位愿意长期支持该 PR 的人。

第二层更加敏感：如果逐行阅读变得不现实，团队可能需要可信贡献者框架；在 AI 大量维护的代码库里，高影响代码继续接受完整人工审阅，低影响代码则可能主要依靠测试质量判断，或者让另一套 AI 做对抗式代码审阅。原文随即说明，这些做法仍在讨论中。

真正成为公开规则的是较为保守的第一层。

在固定于 8 月 25 日提交的组织级 CONTRIBUTING.md中，所有贡献仍进入同一个审阅队列，由一名或多名维护者阅读每一行代码。AI 生成代码没有被禁止，也没有获得单独的快速通道。

这次提交的不可变记录显示，相关要求于 8 月 25 日加入，内容来自团队闭门研讨所形成的共识。本文核查时，main 分支上的当前指南与该提交中的文件逐字节相同。

9 月 1 日执行主任提交董事会的公开报告又确认了一项状态：贡献指南已经更新，目的在于让团队能够审阅并安全吸收大型或 AI 生成的贡献，而不是把大部分时间都花在审阅上。报告没有宣布低人工审阅分级已经实施。

所以，准确结论不是“IETF Tools 已让 AI 审 AI”，而是：团队公开提出了容量问题，讨论了分级可能性，随后先采用了更严格的入站条件，同时保留逐行人工审阅。

正式指南先把理解成本还给提交者

新的要求不是为 PR 增添装饰，而是在重新分配成本。

说明必须与改动规模相称。提交要小到可以分别判断。代码要沿用项目风格，测试须覆盖改动并符合该项目的测试策略。新依赖必须被点名并说明为何需要。若代码暗含一项尚未作出的 IETF 社群政策决定，提交者应先解决政策问题，不能把选择预埋进软件。

这些条件无法证明代码正确。小提交也可能有漏洞，覆盖率也可能掩盖错误假设，漂亮的说明也可能误导。它们真正提供的是可拒绝、可定位的审阅单位。

如果一个巨型 PR 只能整体接受或整体退回，维护者会承受沉没成本压力：已经读了很多，就更难在后段拒绝。拆分以后，某个依赖、数据迁移或政策前提可以在早期独立暴露。审阅者不必为了验证一处争议而先理解数千行无关变化。

这也阻止“输出丰富”被误当成“准备充分”。AI 可以自动生成长说明和大量测试，但只有当说明准确描述了系统约束、测试真正覆盖风险时，它们才构成证据。

为什么逐行阅读仍有现实对象

贡献指南给出了维护者逐行审阅的理由：可维护性、效率、安全、数据完整性，以及核心逻辑是否放在正确位置。

这些不是抽象的代码洁癖。

一段查询在开发数据上可能很快，在生产规模下却形成 SQL 风暴。一个新依赖可以迅速完成某项功能，同时带来更新频率、许可证、安全修复和维护者可信度等新负担。一段看似局部的逻辑可能重复另一服务里的核心判断，使两处未来产生不一致。

IETF Tools 的多数系统面向公开信息，但“公开”不等于“无完整性风险”。谁担任某个角色、文档处于哪个状态、记录何时改变、哪个流程可以继续，这些公开数据一旦错误，也会影响机构记忆和参与者行为。

测试对这些问题非常有价值，却只回答被写进测试的问题。人工阅读也不是绝对可靠，疲劳和架构盲点同样存在。正确的比较不是“人一定优于机器”，而是每一种证据能支撑什么判断。

现行规则把测试与逐行阅读叠加使用。如果未来测试要替代部分人工阅读，就必须记录替代发生在哪里，以及测试实际覆盖了哪一种风险。

提交者承担的是维护承诺，不是原创表演

指南对使用 AI 编程代理的人提出了几项具体要求。

最低限度是理解代码意图，以及它如何融入目标 IETF 工具。提交者还必须读懂 PR 人类说明的每一行。若说明或文档由 AI 撰写，应当改成清楚的技术英语，删掉妨碍人类阅读的代理式套话。

这段文字没有说提交者亲手写了每一行，也没有要求其宣誓理解每一行生成代码。把规则转述成后者，会把一项可核验的责任扩张成公开文本没有写下的保证。

更强的控制在于合并以后。提交者不只是把名字放在作品上，还承诺修复由这段代码引起的问题。如果不履行，代码可能被移除，之后的贡献也可能被拒绝。

这是一种维护保证。它不会消除最终运营方的责任，也无法确保某个人永远有空。但它改变了收益与成本的分配：提交者不能只获得“完成大型功能”的声誉，把后续复杂性全部留给团队。

指南还预期，经常提交 AI 代码的人会逐渐变得“已知且可信”。良好历史确实有信息价值。反复提供清晰说明、及时修复缺陷、熟悉架构的人，和第一次出现就提交巨型改动的人，不应被视为完全相同的未知量。

不过，信任是关于关系的证据，不是代码属性。现行指南没有定义信任分数、年限、豁免或自动合并权。在所有贡献仍逐行审阅时，这些空白不必强行补齐；一旦信任可以减少技术检查，就必须明确它能影响哪些环节、不能替代哪些证据。

“低影响”不是代码自己长出来的标签

分级审阅最有吸引力的理由，是不同改动的后果确实不同。

一个可以立即撤销的展示调整，不应与认证、私人会议资料、标准元数据、邮件状态或机构记录的迁移消耗完全相同的人力。把维护者平均分配给所有变更，反而可能延误真正危险的问题。

困难在于影响的单位。

几行代码可能写入核心表。一个不保存私人数据的页面，可能决定公众看到哪一种状态。程序包可以回滚，已经变更的数据却未必能自动复原。测试环境里的低流量结果，也不等于生产规模下低影响。

因此，“低影响”至少包含四个决定：划定什么对象；考虑哪些后果；由谁评估；在何种不确定性下升级为完整审阅。给出分类的人不是简单贴标签，而是在批准一种不同的证据标准。

如果提交者自己分类，他有加快合并的利益。如果负责清理队列的人分类，他有提高吞吐量的压力。如果审阅者在耗费大量时间后分类，疲劳可能把“应该可回滚”变成“已经证明可回滚”。这不必导致庞大委员会，却需要一条独立复核规则，特别是涉及数据、安全、认证、机构记录或迁移时。

为降低人工审阅的例外建立一张收据

公开审阅边界不等于公开提示词、凭据、漏洞细节或个人信息。真正需要保存的是让例外成立的决策状态。

第一部分记录对象：仓库、组件、受影响的服务或记录面、PR 标识和不可变提交集合。贡献来源可以分为人工编写、AI 辅助或主要由代理生成，无需假装能够精确计算机器作者比例。

第二部分记录责任与分类：持续负责的提交者、影响等级、分类人、分类日期和所依据的政策版本。安全、数据完整性、隐私、性能、可用性、标准记录保管和可逆性应当分别回答，而不是压缩成一个没有解释的分数。

第三部分把风险与证据对应起来。人类计划、测试覆盖、依赖变化、性能结果、安全检查、数据迁移验证、分阶段发布和回滚演练各自支持不同结论。如果减少人工阅读的理由正是“测试足够好”，只写“测试通过”就没有信息量，必须说明测试证明了什么、没有证明什么。

第四部分记录实际发生的审阅。哪些文件或逻辑由人逐行看过？审阅者是谁？哪些面没有看？如果另一套 AI 做了对抗分析，它能读取哪些上下文、寻找哪些缺陷、留下哪些未解决发现？AI 是证据生产者，不是合并授权主体。

最后一部分写明人类合并批准者、部署负责人、维护责任人、强制升级条件、监控期和回滚或移除触发点。后来重新分类时，应追加新状态，不应覆盖最初判断。

完整人工审阅的普通贡献可以保留简短收据。详细记录只用于较少审阅的例外，避免审计本身重新耗尽维护者。

让另一套 AI 找错，不等于让它承担后果

对抗式 AI 审阅不是伪命题。第二个系统可以主动寻找边界条件、缺失测试、异常依赖或跨文件矛盾，在短时间内提出很多人类可能没有想到的失败路径。

9 月执行主任报告提供了一项不同但相关的积极证据：在两个 Datatracker 性能问题中，AI 辅助把原本可能持续数周或数月的诊断缩短到数小时，团队很快实施缓解措施，随后完成实质修复。

这不意味着 AI 引发了那些性能问题，也不意味着诊断成功就自动获得合并权。

两套模型可能共享训练模式、上下文限制和同一套错误需求。提示词可以让第二套系统表现得更“对抗”，却不能创造一个真正承担损失的独立主体。模型不会值班、修复数据、维护未来版本，也不会向社群解释为什么批准例外。

所以，机器审阅的有效状态应当是“在明确范围内提供了某些发现”，而不是“AI 已审阅，可以结束”。决策责任必须落回具体的人。

运行支撑很重要，但不因此获得标准制定权

IETF Tools 的公开团队页显示，它隶属于 IETF Administration LLC，负责开发和运行支持 IETF 各项工作的应用。IETF 社群依赖这些软件撰写、讨论和发布标准，因此其安全与完整性具有制度意义。

但重要性不等于规范权力。

RFC 8711把日常运行与行政支持交给 IETF LLC，同时明确它对 IETF 的标准制定活动没有权力。贡献指南要求先解决社群政策决定，再提交依赖该决定的代码，正是在软件层落实这条边界。

未来的影响分类不能绕过它。维护者有权决定怎样实现已经确定的规则，却不应当以“改动很小”或“测试完整”为理由，把尚有争议的政策选择直接变成运行事实。

Heng Lu 的运行代码优先原则在这里应当窄用：可验证的运行状态必须约束机构叙事。这并不是说部署代码可以凌驾于 IETF 的标准流程，而是说机构不能用一个行政标签遮住代码为何获得运行资格、依靠什么证据、由谁负责。

他的互联网治理委托代理问题则提醒我们看激励。提交者想让功能被接受，编程代理被优化为生成看似完整的方案，队列负责人想缩短等待，疲劳的审阅者想结束任务，组织和用户承担长期尾部风险。一张审阅边界收据不会统一这些利益，却能阻止所有责任被“AI 代码”四个字吞掉。

先保留规则，再把例外写清楚

现有证据没有显示 IETF Tools 已经采用低审阅等级，没有显示恶意 AI PR，也没有显示团队违反指南。它展现的是更值得保留的次序。

团队先承认旧有审阅经济可能无法扩展，再把提交组织、测试、依赖和持续支持责任写进规则，同时保留逐行人工阅读。更深的分级方案仍停留在公开讨论状态。

下一步不需要一句笼统的“人类始终在环”。一个人只看摘要后按下按钮，也可以被描述为在环。真正有意义的问题是：哪个人、在哪个环节、看过什么、没有看什么、采用哪些机器证据、依据哪个版本，并在出错后承担什么。

AI 造成的是审阅供需变化。制度修复应当减少无效工作，而不是减少对授权和后果的可归属性。