摘要

  • 最终数据概览披露，中文文字专家在公众评议后又进行AI辅助分析，发现1,612个汉字相似案例；ICANN称，在进一步咨询文字专家后，这些案例按保守原则纳入中文、日文和韩文SSE数据。
  • 1,612不是申请数量、被拒字符串或最终争议关系。SSE工具只生成潜在争议集合；独立评估小组可以增删调整，须给出理由，申请人还可在收到结果后21天内就事实、程序或系统错误提出有限挑战。

一项数据变更的治理含义，不能只看它增加了多少行，还要看这些行最终能做什么。

ICANN在7月30日公布2026年新通用顶级域轮次的字符串相似性评估数据和指南。最终数据概览给出了一个此前草案没有的数字：公众评议结束后，中文文字专家利用四类AI辅助方法继续分析汉字形状，新增1,612个相似案例。文件列出的办法包括卷积神经网络、笔画结构分析、Zernike矩和网格直方图。ICANN表示，经进一步咨询文字专家，这批案例被纳入中文、日文和韩文数据。

这个数字值得报道，因为汉字同时进入三套相关文字环境，新增映射可能使更多完整字符串被送入人工检查。但它不能被写成“AI裁定了1,612起争议”。来源没有说这些案例对应1,612份申请，也没有说它们都形成潜在争议集合，更没有说任何申请已经因此失败。

它们扩大的是证据入口，不是裁决结果。

公众评议之后发生了什么

2025年10月公开征求意见的数据已经采用保守设计。遇到难以确定的形似关系，可以先纳入相似集合，让后续评估小组而不是早期过滤器拥有检查机会。由于变体和传递关系，专家没有直接判定为相似的两个元素，也可能机械地进入同一集合；这类关系会以特定理由代码和较低相似等级标识。

当时公开的范围包括一个Common Similarity Data文件和26个文字专用文件，覆盖Root Zone Label Generation Rules的完整字符范围。工具利用这些数据对大量比较进行预筛，产生潜在争议集合；草案从一开始就说明，小组可以改变工具提出的集合。

公众评议从2025年10月16日持续到12月4日，共收到11份提交。意见既包括应增加或移除哪些跨文字字符对，也包括应否公开SSE工具、如何持续维护数据，以及模糊案例是否应采取更保守等级。ICANN在汇总报告中回应了若干具体建议，并表示会讨论公开工具的技术与操作可行性；2026轮使用最终冻结版本，之后收到的资料排队进入未来工作。

最终文件公开披露了后续1,612个汉字案例以及所用方法、涉及的数据文件和进一步专家咨询。因此，“在公众评议后加入”不能自动推导出“绕过公众评议”。咨询程序本来就需要在截止后分析、修订和定稿。真正需要核验的是：重大变化能否从评议版追到最终版，变化如何产生，谁进行了专业复核，又如何进入后续结果。

目前公开材料没有提供一份逐行、机器可读的草案—最终版差异表，单独列出全部1,612项的旧状态、来源类别和专家处置；也没有显示其中哪些映射日后会遇到实际申请。这只是公开可见度的边界，不能用来声称ICANN内部没有更详细的变更记录或复核过程。

冻结数据，不冻结判断

最终SSE数据和最终指南都标为1.0版，日期为2026年7月23日。指南明确：这两个版本适用于本轮。之后仍可向ICANN提交意见，ICANN会记录并与相关专家讨论，但不会在2026轮中继续修改这套数据和指南。

冻结有明确的公平价值。同一轮申请不应在不断移动的比较底线下接受评估。若某个字符对在第一批申请中按A版本处理，到后一批又悄然换成B版本，结果就难以复现，也难以解释。共同版本让各申请面对相同输入。

然而，共同输入不是共同结论。SSE工具用冻结数据生成预筛报告，列出潜在争议集合。指南称，小组把报告作为一项输入，还可以考虑额外分析；它能够调整、增加或移除工具列出的潜在集合，并负责最终决定。每项决定需要相关理由，偏离工具结果时尤其要解释偏离。

这里必须区分字符与字符串。数据为单个码位或码位序列设定相似等级；小组面对的是完整顶级域字符串。形状在不同位置、字体、大小写、组合和文字环境中的效果，不能由一个孤立字符映射包办。指南还要求相关文字的母语阅读能力参与评估，并在难以判断时考虑保守结论。

完整权责链至少有四个状态：

  1. 某个相似案例进入文字数据；
  2. 工具依据冻结数据提出潜在争议集合；
  3. 小组对完整字符串作出结论并说明理由；
  4. 申请人可在时限内就事实、程序或系统错误提出挑战，结果可能维持或重新评估。

如果把第一步直接写成第三步，就把记录当成权力；如果把第二步看作不可质疑的技术事实，就把便利当成授权。

后果来自小组结论

Applicant Guidebook说明了最终结论的实际影响。字符串与现有顶级域、仍在处理的上一轮申请、国家和地区代码顶级域、被请求的国际化国家和地区代码、Blocked Names、两字符ASCII字符串或本轮其他申请的关系不同，结果可能使申请无法继续、暂时搁置或进入争议集合。一个变体字符串集合中的相关字符串共享评估结果。ICANN还承诺在Evaluation Results Page公布结论及理由。

这使“谁在决定”不再是措辞问题。数据负责呈现可能值得查看的字符关系；工具负责压缩人力无法逐一枚举的比较空间；小组负责判断完整字符串能否共存；ICANN负责落实本轮规则中的后果。

申请人并非没有纠错途径。现行说明给予申请人自收到结果起21天提出Evaluation Challenge，可主张事实错误、程序错误或系统错误。确认错误后，评估会结合该发现重新进行；没有发现错误，原结论维持。这个渠道不是无限制重审，也不能用实质改变后的申请替代对原评估错误的证明。

这样设计比完全自动化更克制，也比无结构的专家自由裁量更可问责。问题只会在各层脱节时出现：结果没有标明所用冻结版本，外界无法复现；小组只重复工具标签而不解释，建议就冒充了裁决；挑战改变了结果却没有留下更正沿袭，后人就看不清旧结论为何失效。

建立“变更—决定回执”

解决办法不是在申请资料依法公开前曝光申请人，也不是公开受保护的小组讨论，更不是把每个专家分歧变成舆论投票。更合适的控制，是为重大数据变化和后续决定保留一条可核验但克制的连接。

Daniel Kade提出的“变更—决定回执”先固定数据版本和文件指纹。对公众评议版到本轮冻结版之间的重要新增、删除或重分类，它记录涉及的码位或序列、变化前后状态，以及来源类别：公众意见响应、专家纠错、专家扩展、AI辅助候选、传递关系注入或机械转换。

回执还应保留输入日期、方法、理由、受影响文字文件和专家咨询状态，区分用于预筛的映射与仅供说明的关系；公开材料没有证明一致同意时，不能把咨询写成全体专家背书。

若某项映射日后确实参与生成潜在争议集合，受保护记录再连接工具版本和具体作用。在规则允许公开的阶段，外部记录连接小组对完整字符串的结论、所用指南和采用、增补、移除或推翻工具建议的理由。挑战、错误发现、重新评估、更正和取代关系必须随之保留。

这份回执不是ICANN已经宣布的政策要求，而是一种把现有分层做实的治理建议。ICANN已经公开最终HTML/XML数据和方法概览；若再提供机器可读的草案—最终版差异、各文字及来源类型的汇总变更数量，公众就能看见重大移动，又不必提前接触受保护申请信息。

1,612个新增案例既不应被包装成危机，也不应被当作正确性的证书。它们说明规模与克制必须同时存在：自动化帮助找到更多候选，文字专家提供文化和字体知识，独立小组判断完整字符串，有限挑战纠正明确错误。每层之所以可靠，恰恰因为它没有假装自己拥有下一层的权力。

来源

  1. ICANN：发布字符串相似性评估数据和指南，2026年7月30日
  2. ICANN：最终String Similarity Evaluation Data概览1.0版
  3. ICANN：最终String Similarity Evaluation Guidelines 1.0版
  4. ICANN：String Similarity Evaluation资源页
  5. ICANN：SSE数据公众评议程序
  6. ICANN：SSE数据公众评议汇总报告
  7. ICANN：用于公众评议的SSE数据概览草案
  8. ICANN：2026轮新通用顶级域Applicant Guidebook
  9. ICANN：字符串相似性评估结果挑战问答