摘要

  • IETF秘书处于9月9日创建通用领域下的非工作组列表ai-in-standards，用途是讨论人工智能在IETF标准流程中的使用。写作前核查时，公开存档中只有创建通知一封邮件。
  • IETF主席在IETF 126全会上曾把“建一个邮件列表”称为容易的答案，并提出还要建立促进式结构，让社群输入能够进入社群决策。当前启动记录尚未标明促进者、决策对象、产出状态或交接到哪一项正式流程。

固定入口本身就是进展

秘书处公告只用了几行文字：列出列表地址、存档、订阅入口、所属领域与用途。ai-in-standards属于通用领域，讨论对象是人工智能在IETF标准流程中的使用。

这不是无关紧要的技术设置。此前，与AI相关的流程问题可能散落在全会发言、研究组议程、主席午餐会、通用讨论列表或某个草案的邮件串中。固定列表让参与者不必先掌握内部人脉才能找到讨论场所，也让后来的研究者能够从同一个时间线追踪提议、异议、修订与结案。

IETF的邮件列表说明指出，大量日常工作在邮件列表上进行，多数列表允许公开订阅、发言与查阅存档。非工作组列表指南还给出创建链条：申请需要适当的领域主任批准，秘书处维护列表，管理员同时承担版务职责。

因此，这不是私人群聊。它有明确的机构来源、公开地址和行为规则。但“由IETF运行”不能直接推导出“有权代表IETF作出任何决定”。

公告没有把该列表称为工作组或BoF，也没有说明它是否以组建工作组为目标——尽管通用指南把这种目的列为非工作组列表的一种可能用途。公告没有列出主持人、促进者、共识判断者、交付物、期限或申诉路径。这些缺项只界定当前公开记录的范围，不能证明IETF内部没有进一步准备。

7月全会提出的是两段式任务

真正形成对照的是IETF 126全会记录。7月22日，IETF主席Roman Danyliw说，AI已经改变草案编写、评审、邮件列表互动、会议运行与共识流程。IESG从参与者、评审组织和工作组主席处听到的反馈是，现有安排并不充分。

他随后把任务拆成两部分。建立邮件列表是容易的答案；更难的是建立促进式结构，收集社群输入，支持社群就实践或规范作出决定。对于最终形态，他并未预设答案，而是公开追问：会是RFC，还是更多，或更少？

这段话不是带发布日期的合同，也不等于IESG已经选择某项政策。它却提供了一份最小功能说明：入口、促进、讨论、处置与产出必须能够接起来。9月的新列表实现了入口与存档，尚未公开其余部分如何运作。

这一区别决定新闻应该怎么写。有人在列表上分享AI检索方法，属于经验贡献；有人提交个人Internet-Draft，属于个人提案；有人建议限速或披露，属于规则主张；有人把问题送往GENDISPATCH，才产生另一条有明确接受方的流程。它们不能因为出现在同一个官方域名下就被压成“IETF的立场”。

若状态没有标明，讨论热度很容易借走制度权威。重复最多的建议可能看起来像正在形成的规范；管理员的版务决定可能被误读为实体裁决；一份总结可能遮住仍未解决的反对意见；跨列表转发也可能被当成正式移交。

一封邮件构成可验证的零点

在本篇冻结证据时，ai-in-standards公开存档只显示一封邮件，即秘书处的创建通知。这个数字有明确时点，只能说明当时可见的初始状态。它不能说明讨论缺乏兴趣，也不能预测列表随后是否活跃。

初始状态干净，反而给记录设计留下机会。此后每个事件都可以带上类型：参与者提议、证据请求、实验方案、促进者综述、共识探询、转交流程、正式决定或无行动结案。日期能说明先后，事件类型才能说明权力与意义。

RFC 9245解释了为什么要给特定主题建立专门讨论场所：当有更合适的列表时，通用IETF列表不必继续承载全部讨论。新工作指南则把非工作组列表列为聚集兴趣社群的一条路径，旁边还有DISPATCH、BoF、领域主任赞助和独立出版。入口建立不等于后续路径已经选定。

Note Well适用于列表贡献，约束权利、披露与行为。它证明邮件进入了哪套贡献规则，却不能证明文字必然由人独立撰写、事实正确或受到机构认可。贡献身份是来源标签，不是真实性证书。

既有讨论同时揭示收益与压力

IETF 126期间，RASPRG的议程把AI参与放在一组张力之中：工具能降低语言等参与障碍，也能让缺少人类投入的发言变得廉价，从而挤压有限的专家注意力。会议记录保存了对更稳健规则、实验方法、明确使用规范和机构处理能力的讨论。

这些材料提供问题清单，却不是IETF全体已经通过的政策。研究组场次、全会主席发言、非工作组列表与未来流程文件各有独立来源和权力边界。把它们合写成“已经决定”，恰恰会取消新论坛应该完成的治理工作。

帖子数量也无法替代判断。生成工具可以低成本写出十条措辞不同的支持意见；同一家公司也可以协调多名真人发言。另一方面，第二语言使用者可能借助AI更准确地表达原创技术异议。相同的计数可能对应完全相反的制度意义。

RFC 7282强调，共识来自对问题与异议的实质处理，而不是点人数。它还要求共识判断有理由、有承担者。最终决定在邮件列表上确认，不表示任何邮件列表都能决定任何事项；授权范围、主持责任和后续交接仍须存在。

最小可行治理不是长章程

下一步可以很小：在订阅与存档旁增加一个版本化的论坛记录页。

第一部分界定范围。“AI进入标准流程”可能包括写作、评审、翻译、检索、代码生成、参与、版务、会议和共识评估。记录页既要说哪些问题由此处处理，也要为范围外事项给出真实去向。

第二部分拆开角色。谁负责列表运行，谁执行版务，谁编排议程，谁可以总结未决问题，谁能对哪类产出判断共识？删除违规邮件的权力不等于采用一条实践规范的权力。

第三部分给提案定义状态。可用词可能包括“已提出”“等待证据”“拟开展实验”“起草中”“转交GENDISPATCH”“提交IESG”“独立出版”“已取代”“不采取行动”“记录异议后结案”。具体词汇应由IETF确定，关键是不能把消息量当成进度。

实验也需要单独的证据字段：问题、样本、工具版本、误报与漏报风险、人类复核、纠错入口，以及实验允许影响的决定。促进者综述应链接原始异议，而非替代它。事项离开论坛时，应记录日期、接受方和新的权威状态。

最后需要修订历史。AI工具与风险变化很快；旧建议若被静默覆盖，未来参与者无法判断过去的决定依据是什么。

开放入口还需要可导航的出口

RFC 3935把开放流程与技术能力、质量和相关性放在一起。专门列表改善开放入口，促进结构则把输入整理为可验证问题，并送到有权处理它的地方。

新人需要的是公开路线，而不是先找到私人担保者；评审者需要看到请求的是哪一种关注，而不是被迫把每封邮件视作同等优先；机构需要能够写“已收到”而不等于“已认可”，写“已转交”而不等于“已采用”，写“已结案”而不把沉默伪装成共识。

9月9日的列表开设是真实进展。下一项值得检验的证据，不是收件箱变大，而是讨论如何变成有来源、有状态、可纠错的处置结果。

来源

  1. IETF秘书处：创建ai-in-standards列表
  2. ai-in-standards当前公开存档
  3. IETF 126全会记录
  4. RASPRG议程：AI in Standards Participation
  5. RASPRG会议记录
  6. IETF非工作组列表指南
  7. IETF邮件列表说明
  8. IETF引入新工作指南
  9. RFC 9245：IETF讨论列表章程
  10. RFC 7282：IETF的共识与哼声表决
  11. RFC 3935：IETF使命声明
  12. IETF Note Well
  13. Lu Heng：The Policy Mirror
  14. Lu Heng：Running Code Primary
  15. Lu Heng：Why BTW Media Exists