摘要

  • 2026 年 3 月 24 日发布的文件是 W3C 咨询委员会 Group Note：它是稳定的建议性参考，不是 W3C Recommendation、全组织政策或大模型禁令。
  • 文件提出发布前核验、明确标注、个人承担责任、优先小型专用模型和保留深思讨论五项建议，却没有指定执行主体、证据记录或申诉路径。
  • 一份有隐私边界的“大模型使用问责回执”可以把投稿与实际适用的规则、人工核验人、数据边界、纠错记录和采纳机关连接起来。这是编辑性方案，不是 W3C 现行要求。

最重要的限制写在状态说明里

《Use of Large Language Models in Standards Work》没有把大模型描绘成万能工具，也没有要求把它逐出标准工作。文件承认几类可能有净收益的用途：快速制作概念演示、测试与示例；询问、拼写检查和编辑标准；为新概念寻找名称。

它列出的风险同样具体。训练材料可能带来版权问题；把 Member Confidential 信息交给外部服务可能造成泄露；生成内容可能只有细微错误，因而更难发现；模型不知道近期邮件和会议中的讨论；自动生成长篇回复会把审阅成本转嫁给其他参与者；自动生成会议纪要可能发生错误归因、偏向性归因、事实错误和无关扩写；模型的生产与使用还带来能源和用水压力。

说明最后提出五项护栏：分享前彻底核验；对主要由大模型生成的内容明确标注；由分享者承担全部责任；尽量选择更小、更专用的模型；不要用生成回复替代思考和讨论。

这些建议值得认真对待，但它们的效力不能脱离文件状态。说明明确表示，它记录的是咨询委员会截至 2026 年 3 月 24 日的当前思考；咨询委员会对它背书，W3C 本身和 W3C 成员没有背书；W3C Patent Policy 也不对它产生许可要求或承诺。

现行 W3C Process 进一步界定了发布机关。咨询委员会为 Team 提供战略、管理、法律、流程和冲突解决方面的持续建议，跟踪成员提出的问题并提出行动方案。咨询委员会本身与 W3C 董事会不同，在 W3C 内没有决策权。其成员只有在另行组成 W3C Council 时，才以那个身份行使裁决权。

因此，这份文件可以有影响力，却不能仅凭“W3C 发布”几个字变成所有参与者必须遵守的规则。

Group Note 不是等待自动生效的标准

W3C Process 对 Group Note 的定义很窄：它为“不打算成为正式标准”的有用文件提供稳定引用。发布 Note 的正式要求较少，它不具备 W3C Recommendation 的地位，而且可以无限期保持 Note 状态。W3C 的文档类型说明也明确提醒，Group Note 没有获得 W3C 整体背书，不应作为 W3C 标准引用。

Note 并非永远不能获得更高层级的认可。要升格为 W3C Statement，需要经历广泛审查、发布组的正式决定、对问题的正式处理、公开 Formal Objection、Advisory Committee 审查和 W3C 决定。大模型说明目前不是 Statement。博客把它称为咨询委员会首份公开 AI 立场说明，也没有跳过这些程序。

区分文档类型并不是贬低内容，而是保护责任边界。建议可以影响实践，可以成为各工作组制定本地规则的素材；它不能替一个尚未行动的有权主体作出决定。

“由个人负责”没有自动生成审计记录

个人责任的表述解决了一个道德问题：贡献者不能把错误推给模型。但它没有保存事后查明事实所需的信息。

假设自动整理的会议纪要把一句话归给了错误的人。一行“AI 辅助”无法说明录音或自动转写是否事先得到全体同意、会议适用何种保密等级、谁把文本与现场讨论逐项核对、哪些段落经过生成、修正是否会在档案中留下版本。若技术提案包含一个看似可信的错误，署名只能告诉人们谁提交了文稿，不能显示核验了哪些来源、使用了什么功能、异议应当提交给谁。

标注也有明确边界。说明建议在内容“主要”来自大模型时标注，并没有要求披露每一种使用。未标注不能推出未使用；标注也不能反过来证明存在错误、泄密或不当行为。拼写辅助、生成一段技术论证和处理保密会议纪要，不是同一类风险。

更硬的规则在其他文件里

W3C 已有一些真正可执行的控制面，只是它们不来自这份 Note。Process 要求主席确保访客遵守组章程规定的保密等级；工作组应保留会议纪要，并必须记录正式决定；音视频记录和自动转写必须提前公告并取得所有在场者同意，公告还要交代访问范围、用途和保留期限。

Process 也规定了正式处理问题的方式、出现新信息后重新开启决定的机制、Formal Objection 和申诉渠道。对于 Member-only 与 Team-only 信息，它要求授权接收者合理保护保密性，并限制谁可以改变信息的保密等级。

2024 年 3 月 18 日的现行 Code of Conduct 是另一层约束。它经过 W3C 成员审查并由 W3C 背书，要求诚实并尊重隐私与保密，禁止故意传播错误信息，还提供主席、Team 联系人和 Ombudspeople 等投诉渠道，要求处置与阻止伤害直接相关并保持比例。

后来发布的编辑草案增加了一项拟议文字，把因疏忽造成的错误信息——包括未经核验的自动系统输出——列为不可接受行为。公开 issue 432 记录了提案理由。但草案自称仍在编辑中，不能与现行 Code 混用。咨询委员会仓库中的 issue 319 询问疏忽分享后应有何种后果，issue 326 讨论标注应放在开头还是结尾；它们说明执行细节仍在讨论，不是已经生效的全组织政策。

因此，“W3C 的 AI 政策”是过度压缩。一个投稿可能同时受 Process、现行 Code、工作组章程、已记录的本地决定、雇主规则和普通法律约束。咨询委员会 Note 可以为这些制度提供建议，却不会取代它们。

缺少的是一份问责回执

若一份模型辅助内容可能影响规范文本、会议纪要、正式异议或保密讨论，最小可用证据不必是完整提示词。它应是一份把投稿与权力和复核连接起来的回执。

回执至少应保留十项事实：

  1. 适用场景、具体投稿和责任主体；
  2. 是否使用大模型，以及涉及哪些段落或功能；
  3. 已知情况下的工具、功能和版本，以及输入数据的边界；
  4. 适用保密等级、批准和外部处理目的地；
  5. 人工核验责任人及其核验范围；
  6. 对主要生成内容的标注位置和颗粒度；
  7. 归因、引语、来源和会议发言人身份核验；
  8. 更正、撤回与版本历史；
  9. 异议、复核与申诉路径；
  10. 保留期限，以及在建议已被强制采纳时，有权机关、采纳文件和版本。

回执必须有隐私边界。很多情况下，一个哈希值、一名复核人、一条决定记录和一段数据边界声明已经足够。为了证明做过核验而公开私人提示词、专有模型信息、受保护会议内容或个人数据，会制造新的风险。

这份回执是 Daniel Kade 的编辑性建议，不是 Group Note 的组成部分，也不是 W3C 现行规则。

让采纳行为可见

工作组若要把某项建议变成强制要求，应当在权力发生的位置留下记录：哪个机构作出决定，使用什么文件，覆盖哪些贡献和参与者，何时生效，如何处理保密冲突，由谁审查，又向谁申诉。

不同场景可以有不同强度。公开头脑风暴、Member-only 会议和正式规范评审不需要同一种回执。一个组可以禁止在保密会议中使用外部服务，同时允许普通文稿使用拼写辅助；也可以要求自动纪要接受双人复核，而不声称 W3C 已全面禁止大模型。

规则的正当性不来自措辞严厉，而来自授权清楚、范围有限、记录可查和决定可复核。

证据边界

公开资料没有给出 W3C 参与者使用大模型的比例，也没有穷尽每个工作组和雇主的内部要求。它不能证明任何具名个人或组织曾泄露信息、错误归因或提交虚假内容。公开沉默也不能证明本地规则不存在。

现有资料足以确认的是：Note 的文档状态、咨询委员会的通常权限、Process 与现行 Code 的操作性规则，以及草案和公开 issue 尚未被采纳的状态。问责缺口可以在不虚构事故的情况下成立。

来源