摘要

  • draft-fengfar-led-01 建议 IETF 参与者先形成自己的立场，再使用 AI，随后核验输出是否忠实于该立场，并“始终保持透明”；但它仍是一份活跃的个人 Internet-Draft，不是 IETF 政策。
  • 草案覆盖邮件、会议幻灯片、GitHub issue 与 pull request，也可能覆盖即时通信；它明确排除 Internet-Draft 和 RFC 正文，因为这些文本还受 BCP 78 与 BCP 79 的贡献和知识产权安排约束。
  • 可用的披露应绑定具体贡献，记录负责的人、工具功能、影响范围、材料边界、事实与忠实度核验、最终批准、是否允许自主发送以及纠正路径。一个 AI 标签无法替代这些字段。

一个标签回答不了三个问题

假设一封邮件末尾只有一句“本邮件使用了 AI”。读者仍然不知道工具是做了翻译，还是替作者寻找旧邮件；不知道它只改了一个段落，还是生成了全部论证；也不知道发送者是否核对过事实、引文与技术立场。

这不是措辞问题，而是责任对象没有定义。透明度只有在回答“做了什么、作用在哪里、由谁查验”时才开始提供治理价值。

draft-fengfar-led-01 的核心短句是“Always be transparent”。草案本身并没有假装细节已经确定。它把具体建议称为“极其暂定”，结论也明确表示现在下定论还太早。作者更强的主张是：IETF 应在参与者失去对邮件讨论的信心之前制定指引。

截至 8 月 28 日，Datatracker 将它列为一份活跃的个人 Internet-Draft，状态为 I-D Exists，没有 RFC stream、负责的 Area Director 或 telechat 日期。7 月 31 日启动讨论的邮件称其粗略、非规范、无权威性；8 月 6 日发布的 01 版吸收了通用讨论列表上的意见。这些步骤都不等于工作组采纳、粗略共识、IESG 批准或 IETF 规则。

8 月 26 日的新变化是关注度，而不是授权。George Michaelson 在 APNIC Blog 的文章把 IETF 的讨论与标准及 RIR 政策中的英语参与成本联系起来，并主张社区应把 AI 使用方式正式化。页面同时声明文章观点不一定代表 APNIC。它扩大了议题，没有替 IETF 或 APNIC 作出决定。

草案主动划出了一条边界

这份文本讨论的不是笼统的“AI 与互联网标准”，而是 IETF 讨论中使用的文字：邮件列表消息、会议幻灯片、GitHub issue 和 pull request，以及可能的即时消息。

Internet-Draft 和 RFC 正文被明确排除。原因是这些正式贡献还涉及 BCP 78 与 BCP 79 下的权利和知识产权安排。未来即使邮件列表形成一条披露指引，它也不会自动决定标准文档正文里的作者身份和贡献权利。反过来，在草案致谢中声明一次，也不能说明围绕草案的几十封邮件究竟被翻译、摘要、改写还是自主发送。

草案的起点正好展示了这种空白。一名参与者先独立形成想法，再借助 AI 改善表达；一名读者感到文本具有 LLM 风格，由于无法判断人的贡献而停止阅读。两位作者保留了这两种视角，没有宣布哪一方已经胜出。他们共同确认的是：现有规范不足以建立稳定预期。

“先决定自己要表达什么、再核验输出是否忠实、对署名发送的内容负全责”是一条有用的人类边界。但原则上的负责还不是档案中可查的负责。

节省的是写作时间，增加的可能是阅读时间

AI 辅助可以降低真实的参与门槛。理解一个协议与用地道英语解释协议是两种不同能力。翻译和编辑让参与者少花时间修整表面语言，把更多精力放在工程问题上。

同一工具也能把成本转移给读者。一个发送者可以迅速产出完整、礼貌且篇幅很长的回复，多名读者却必须逐项核验：来源是否存在、旧共识是否被准确概括、作者是否理解自己的断言。若多个代理彼此回复，数量可能制造出“社区高度关注”的外观，却没有增加独立判断。

因此，普通标签的信息密度太低。它不区分已完成立场的翻译、未经核验的事实生成、旧讨论的检索与摘要、整封邮件代写，或没有最终人工复核的自主发布。

写作风格也不能补齐证据。草案记录了对文字墙、异常自信和声音变化的担忧，但这些只是观察，不是来源记录。把流利英语、速度或检测器分数当作证明，会系统性地怀疑非英语母语参与者和使用无障碍工具的人。检测结果是推断，披露是可归属的陈述；两者都不能自动证明技术主张正确。

三套邻近规则不是同一项政策

RFC 9775 提供了一个接近但不能混用的参照。它是 IRTF 行为准则，代表 IRSG 共识，并明确说明不是 IETF 产品，也不是标准。它规定生成式 AI 不能列为作者；大量生成的文本或其他内容应披露，例如说明系统及其贡献；拼写、语法、翻译与呈现改善则无需披露。

W3C Advisory Board 在 2026 年 3 月发布的 Group Note 采用了另一个门槛：当内容主要由 LLM 产生时使用清晰标签，同时要求个人检查正确性、保护机密信息，并避免让自动回复取代商议。该文件由 Advisory Board 背书，不代表整个 W3C 或其成员认可。

IRTF 的“significant amounts”、W3C 文件的“primarily output”和 IETF 个人草案的“always be transparent”不是全球规则的三种表达，而是由不同主体提出或通过的三种边界设计。恰恰因为授权不同，IETF 不能静默借用其中任何一条。

Daniel Kade 提出的责任记录

最小的合适单位，是与一项具体贡献绑定的责任记录。

第一组字段是人和对象：人类发送者，以及稳定的贡献标识。第二组是工具功能：翻译、编辑、摘要、起草、检索、分析、编程、辅助审核，或自主发送。第三组把功能绑定到范围：整封消息、指定章节、附件、代码片段或特定断言。

记录还应标明材料边界：工具仅处理公开来源、发送者的本地笔记，还是机密材料。这一字段只需分类，不应公开材料本身。要求提交完整提示词、凭据、私人思考、未公开草稿、专有上下文或思维链，会把透明度变成新的安全事故。

接下来是人的工作：核验了哪些事实来源与引文，是否比较了文本与真实立场的忠实度，最终版本是否由人批准，工具能否在没有批准的情况下发送。最后附上适用的政策版本与日期，以及错误披露或错误贡献的纠正、替换路径。

模型名称可以是背景字段，却不应成为记录中心。供应商可能不改产品名就更新行为；更重要的是，知道模型名称不能证明某人理解协议、核对引文或承担责任。

这是 Daniel Kade 的制度设计建议，不是该草案已经提出的要求。它的目的，是让工具执行足够可审计，同时把立场与决定留在人类手中。

不能让执法先于定义

IETF 现有治理已经区分论坛角色。RFC 9245 定义通用讨论列表，并在没有更合适场所时容纳 IETF 方向、政策与标准流程问题。RFC 9945 则区分参与者、论坛管理员、版主、Area Director 与 IESG 的责任，把管理措施限定在破坏性沟通，并要求公开程序、重新考虑和申诉。

两份 RFC 都没有创建 AI 作者检测器，也没有把“像 AI”变成独立违规。如果未来指引与内容管理相连，披露规则必须先于惩罚出现：门槛、证据、通知、纠正和申诉都要先定义。否则，基于文风的指控会获得程序权力。

草案建议以非指责方式询问可疑的工具使用，也记录了新参与者可能不知道规则、不同工具可得性可能制造新门槛的担忧。安全顺序应当很窄：先定义功能和范围，再试验责任记录，测量它是否减少阅读负担与误判，最后才判断未披露属于建议未遵守、流程缺陷还是破坏性行为。

标签不应成为发言许可证，缺少标签也不应自动成为欺骗证据。

现有证据不支持哪些结论

IETF 尚未采纳或拒绝 AI 辅助参与。没有证据显示生成文本改变了某个实际共识结果，也不能说今天每一封辅助生成的消息都必须披露。

RFC 9775 即使位于 RFC Series，也不会自动约束日常 IETF 标准讨论。W3C Group Note 不代表 W3C 成员共识。APNIC Blog 文章不宣布 APNIC 政策。本证据包也没有显示某位具名参与者虚假陈述作者身份或授权工具自主发送。

可以下的结论更有限，也更可执行：草案正确定位了负责的人，却尚未定义使责任可以被读者检查的记录。“始终透明”是方向；当对象、权限、证据与纠正路径明确之后，方向才变成治理。

来源

  1. https://datatracker.ietf.org/doc/draft-fengfar-led/
  2. https://www.ietf.org/archive/id/draft-fengfar-led-01.html
  3. https://mailarchive.ietf.org/arch/msg/ietf/3VaBJ6pEdhtkpOtnZYA_HcVHejU/
  4. https://mailarchive.ietf.org/arch/msg/i-d-announce/_nalEUgYdyn7LdNfwQghXW9dPRc/
  5. https://blog.apnic.net/2026/08/26/the-emerging-role-of-ai-in-governance-discussion/
  6. https://www.ietf.org/rfc/rfc9775.html
  7. https://www.w3.org/TR/2026/NOTE-llms-standards-20260324/
  8. https://datatracker.ietf.org/doc/html/rfc9245
  9. https://datatracker.ietf.org/doc/html/rfc9945
  10. https://datatracker.ietf.org/doc/html/rfc5378
  11. https://datatracker.ietf.org/doc/html/rfc8179