摘要

  • ICANN 于 9 月 3 日公开了一封日期为 8 月 28 日的信。通用接受专家工作组两位联合主席称，工作组已在审阅公众意见后，以共识支持最终文件并交给 ICANN 总裁兼首席执行官考虑。
  • 信中列举的一项修订，是利用人工智能技术推动通用接受；最终文件还提出实施优先次序，以及从认知、政策支持、实施和能力建设四方面衡量进展的框架。
  • 公众意见记录同时给 AI 安排了两个方向：它可用于找出和修复 UA 缺陷；代码助手、邮件安全工具、地址解析器和语音服务等 AI 系统自身也应成为测试对象。
  • 每个结果都应标明角色、版本、测试范围、人工授权链、分母和证据状态。生成建议、批准上线、组件通过和用户全程成功不能合并成一个“AI 贡献”数字。

一次交接，把同一个名词放到了测试线两端

ICANN 通信索引在 9 月 3 日刊出了 Edmon Chung 与 Sarmad Hussain 的来信。两人以 Universal Acceptance Expert Working Group 联合主席身份，在这封8 月 28 日的信中回顾：工作组自 2025 年 8 月开始工作，2026 年 2 月至 4 月公开征求意见，随后修订文本，并将成员形成共识的最终文件提交 ICANN 总裁兼首席执行官 Kurt Erik Lindqvist 考虑。

信中没有复述全部修订，只举了一个例子：利用 AI 技术推动 UA。它还称最终文件给出了实施优先次序，并提出衡量认知、政策支持、实施和能力建设进度的框架。

这两句话合在一起，会立即产生一个计量问题。AI 可以在系统外部工作：生成测试用例、扫描代码库、指出旧式 ASCII 校验、起草补丁，或者帮助维护者定位失败。此时，AI 是手段。可核验的是输入了什么、产出了什么、人如何复核，以及谁有权接受或否决修改。

AI 也可能在系统内部：邮件安全模型决定是否拦截一封 EAI 邮件；代码助手生成验证逻辑；语音助手采集本地文字的域名；模型驱动的客服或身份流程读取、保存和显示地址。此时，AI 是被测组成部分。问题变成它对既定测试集作出了什么反应，而不是它帮助别人生成了多少修复建议。

两个方向可以出现在同一项目里，却不能共享一个含义模糊的分子。“扫描了一千个仓库”是活动量；“规定的一千条完整用户路径中有九百八十条成功”是运行结果。前者可能解释后者的变化，不能充当后者的证据。

已完成的是工作组文件，不是全网实施

这封信使用了清楚的权限边界：工作组把文件提交给 ICANN “考虑”。工作组共识能够确定自身交付物的状态，却不会自动批准经费、指定实施者、修改注册服务或要求第三方平台执行。ICANN 仍须分析可行性、排定项目和报告动作；各运营者仍控制自己的生产系统。

公开版本还有一道可见边界。截至本文核查时，通信条目链接的是封面信，没有附上最终指南。已经结束的公众意见页面仍把 2 月文件列为征求意见的提案，并用将来时表示 ICANN 会与工作组完成并发布指南。ICANN 的 UA 公告索引也尚未列出最终文件。

这并不证明文件不存在，也不能据此断言内部没有启动任何工作。它只限定了公众能复核的材料：可看到草案、意见汇总和联合主席对最终文件的概述，但不能从一页来信推导最终条文、编号或优先等级。因此，本文只把“加入利用 AI 的内容”归于来信，把两种 AI 角色的具体范围归于公众意见记录。

UA 本来就不是单点通过

2 月草案用一串动作界定 UA 就绪：系统要能够依照适用标准，接受、验证、存储、处理、显示所有有效域名和邮箱，并与之互操作，其中包括国际化域名与 Email Address Internationalization。

这些动作必须拆开看。表单接受输入，不等于接口不会改写；数据库能保存，不等于登录服务能调用；登录成功，不等于找回账号的邮件可达；邮件服务器接收，不等于安全过滤不会误判；一个从左到右的测试通过，也不能涵盖双向文字和右到左书写。

草案的四类指标同样处在不同因果距离。举办活动、传播信息属于认知；制度和采购要求属于政策支持；真实系统使用和端到端路径属于实施；课程、培训、工具和人才属于能力建设。四者都值得记录，但不能像同一种货币一样相加。上游数据越便宜，混合分数就越容易被上游活动占满。

37 份意见把镜像关系说清楚了

公众意见汇总报告整理了 37 份提交。报告记录了使用 AI 辅助软件开发、与开发工具企业合作、建立自动检查、扩大测试和检测非 UA 应用等主张。这些设想把 AI 当作降成本、扩覆盖的工具。

同一份报告也记录另一种建议：把 AI 系统作为独立的利益相关者类别。举例包括大语言模型、AI 邮件安全系统、代码生成器、域名和邮箱解析工具、垃圾邮件过滤器、语音助手、训练数据链与诊断工具。它们不是站在测试仪旁边，而是会影响用户输入、通信或身份是否成功的依赖项。

ISPCP 的提交进一步提出 AI 专用指标、分阶段实施、里程碑和治理安排。这些内容仍是意见，不是 ICANN 已采纳的政策，更不是合同义务。它们的价值，在于揭示一个总称背后存在两种证据方向。

先分角色，再形成证据链

Daniel Kade 建议为每项 AI/UA 试点建立“双面角色与证据表”。第一栏说明 AI 是诊断工具、建议生成器、决策辅助、被测组件，还是拥有既定权限的自动操作方。同一技术若承担两种工作，就建立两行并明确关联。

第二栏写授权链：谁选择工具和测试集，谁审阅结果，谁能合并代码、批准上线、停止或回滚。模型提供者不会因为生成了补丁而获得运营者的权限；补丁也不能批准自己进入生产。

第三栏固定对象状态：在可知范围内记录模型或服务版本、测试说明、输出或补丁、代码修订、构建版本、关键依赖和执行时间。模型、规则或库发生变化时，应新开一次测试，或说明旧结果为何仍可比较。

第四栏限定 UA 环节：输入、验证、存储、处理、显示、登录、恢复、邮件投递或互操作。第五栏给出测试集边界：脚本与语言、有效和故意无效的标识符、长度、双向文字、域名组合、供应商路径、抽样方式和排除项。没有分母的通过率只会奖励最容易的案例。

最后必须标示主张类别：警报、拟议修复、人工审阅后的代码、授权部署、组件测试结果或端到端用户结果。每类都保留时间、分子分母、失败类型、误报漏报、纠正渠道和重测触发器。

这张表不需要公开模型权重、私人数据或可被攻击利用的安全规则。它只防止证据越级：发现不等于修复，修复建议不等于上线，上线不等于全覆盖，组件通过不等于用户全程可用。

来源

  1. ICANN 通信索引
  2. UA 专家工作组联合主席 2026 年 8 月 28 日来信
  3. ICANN：UA 指南草案公众意见页面
  4. 推动通用接受的指南草案
  5. 公众意见汇总报告
  6. ISPCP 提交意见
  7. UA 专家工作组章程
  8. ICANN 通用接受公告与博客索引