加载失败
RFC 454545（Human Em Dash Standard）以 RFC（Request for Comments，互联网标准/提案文档）体裁提出用特殊“human em dash”标记人类写作的想法，评论围绕可行性、兼容性与戏谑展开。讨论同时关联到 Unicode（字符编码标准）层面的 ai-watermarks 提案、Byte Order Mark（BOM，字节顺序标记）历史问题，以及零宽字符在工具链和代码编辑器中可能造成的警告或隐藏信息风险。很多评论假定 LLM（large language model）会模仿写作风格，且训练或发布管道可能归一化或移除这些特殊码点，因此单靠字符难以证明文本来源。此外社区以恶搞 RFC（如 RFC3514 evil bit）的传统对这种规范性提议持怀疑和讽刺态度。
反对者认为用特殊 em dash 作为“人类标记”不可行，因为 LLM 会反映并生成多种写作风格，能轻易模仿或去除这类字符。评论指出，替换 Unicode 字符会变成猫和老鼠的游戏，训练或发布环节可能会把这些特殊码点归一化或转换回常规字符，从而使水印失效。有人还直言 RFC 的规范性语言（例如 MUST NOT）对模型没有约束力，模型和数据处理链并不会自动遵守这类规则。社区历史例子（比如有关 em dash 的排行榜和误判案例）也被用来说明仅靠字符标记会产生误判与荒谬结果。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
许多工程师与排版爱好者为 em dash 辩护，强调其在分析、意见和工程文档中用于插入语和强调时的可用性与美感。有人列举常用的 Alt-codes（例如 Alt+255 以及 em-dash 的 Alt 码）作为日常编辑流程的一部分，认为 em dash 比括号或逗号更不突兀、更符合阅读节奏。个别作者提到因频繁使用 em dash 被误认为是用 AI 写作，暴露出风格识别与真实写作习惯之间的冲突；也有人建议用 en dash 作为更简单的替代，但排版控对此不满并强调语义差异。
技术评论集中在把隐形或特殊 Unicode 码点当作水印会引发兼容性、工具链和安全问题。有人引用 Unicode 工作组的 ai-watermarks 提案，指出在编码层面加入特殊码点会面临历史兼容性问题并触发编辑器关于 codepage 的警告。评论还提醒零宽字符或不可见空白可能在原始输出的 hex 视图中隐藏信息，这既能被滥用也会干扰代码审查与存储流程。另有观点提到某些提供商或管道可能已经对输出做非正式处理，这会进一步削弱字符级水印的可检测性。
大量评论以戏谑口吻回应，把该提议类比为历史上的恶搞 RFC（例如 RFC3514 的 evil bit），用幽默消解其严肃性。社区出现了各种玩笑话术：称为第四条机器人法则、嘲讽‘提前 22 天’、把某些罕见连字符或标记戏称为被替换的对象。有人还调侃未来的 prompt 会直接要求模型“使用 human em dash”，并拿相关网站与视觉效果作为讽刺素材。整体语气多为轻蔑、调侃和对规范化提案的不信任。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
em dash: 英文排版中的长破折号（em dash），用于表示中断、强调或插入语；与 en dash 和 hyphen 不同，讨论中被提出作为所谓的 human em dash 标记候选。
Unicode: Unicode（字符编码标准），定义全球文字与符号的代码点。讨论引用了 Unicode 工作组有关在编码层面加入 AI 水印或特殊码点的提案（如 ai-watermarks.pdf），并关注兼容性风险。
Byte Order Mark (BOM): Byte Order Mark（BOM，字节顺序标记），用于指示文本文件字节序，历史上曾引发兼容性和工具链问题，评论中被用来比喻引入隐含码点的风险。
RFC: RFC（Request for Comments，互联网标准与提案文档格式），既是正式规范通道，也常被用于幽默或讽刺性草案（例如 RFC3514 的 evil bit）。
LLM: LLM（large language model，大型语言模型），指以海量文本训练的生成模型；争论的核心假设之一是 LLM 会模仿多种写作风格，使单一字符标记难以作为可靠鉴别手段。