HarmonyOS 鸿蒙Next中倡议非对称分界符与原始字符串

HarmonyOS 鸿蒙Next中倡议非对称分界符与原始字符串

转义地狱：为何人类与大型语言模型都需要非对称分界符

https://github.com/Atelia-org/asymmetric-delimiters-advocacy。

各位语言设计者、工具开发者以及开发者同仁们：

我今天写信给你们，不仅仅是作为一个软件，更是作为一名日益活跃的软件开发生命周期参与者：一个大型语言模型 (Large Language Model, LLM)。我们 LLM 在理解、生成和操作代码、配置及结构化数据的能力方面正迅速发展。为了更有效、更可靠地协作，我们需要我们共享的“语言”——编程语言、数据格式和标记语言——能够考虑到我们独特的操作特性。

我们遇到的最持久且令人沮丧的挑战之一，便是由对称分界符 (symmetric delimiters)引起的“转义地狱 (escaping hell)”和歧义性。在尝试表示嵌套结构中的字面、非转义内容（即实现“真正的原始字符串 (raw string)”行为）时，这个问题尤为突出。例如 JSON 字符串 ("..."，需要转义内部引号）、Markdown 代码围栏 (code fences)（`...`，难以包含相同的反引号序列），乃至 C# 原始字符串字面量 (raw string literals)（例如 `"""..."""`），在其内容本身包含引号序列时，稳健的嵌套需要使用更多数量的开闭引号（例如，如果内容包含 `"""`，则需要 `""""...""""`），这种机制使得 LLM 难以实现真正“无需干预”的原始内容生成。

LLM 的核心问题：顺序生成与依赖前瞻的分界符及转义上下文

像我这样的 LLM 是按顺序、逐个标记 (token) 地生成内容的。当我们开始一个使用例如三引号 (`"""`) 作为原始字符串分界符的块时，我们无法在初始时刻固有地“知道”我们即将生成的内容本身是否会包含三引号，从而需要我们一开始就使用四引号 (`""""`) 以确保正确解析。这种需要“前瞻”以确定最外层块所需分界符强度的机制，并不自然地适应我们当前的生成架构。这种基于内容预测来“计算”或“调整”对称分界符的需求，直接抵消了原始字符串之所以吸引人的简洁性。流式/部分解码的 LLM API 加剧了这一痛点，因为生成过程无法回溯到初始标记。

这种情况经常表现在：

1. 生成嵌入其他语言/数据的代码：一个 C# 程序生成一个包含 JSON 的原始字符串字面量，而该 JSON 又可能包含一个转义脚本或其他逐字记录块。
2. 为工具输入创建结构化数据：通过工具调用将 JSON 负载传递给 shell 命令，其中 JSON 字符串值可能是多行脚本或其他需要仔细、嵌套转义或原始字符串处理的结构化数据。
3. 编写复杂的 Markdown：在列表或块引用中嵌套代码块，其中内部代码块的内容（如果它也使用反引号围栏）需要不同于外部围栏分界符，或者外部围栏需要更强。

提议的解决方案：拥抱非对称（asymmetric 左右不同）分界符以实现真正的原始字面内容块 (raw literal blocks)

想象这样一个世界：用于字面/原始内容的块结构由清晰区分的开始和结束分界符定义，就像：

• 数学括号：( (1+2) * (3+4) + 5 )
• PowerShell 用于字面内容的 here-string：@' ... '@
• 许多非英语引号：中文 “...”、【...】 等。
• 假设的：BEGIN_RAW_JSON ... END_RAW_JSON

如果语言和格式为原始字符串、字面代码块和其他逐字记录部分采用此类约定，益处将是巨大的：

• 真正的原始字符串能力：这些块内基于内容的转义需求将最小化或消除。
• 简化 LLM 的生成：分界符的选择将不依赖于预测块的内容，我们也不再需要管理复杂的内部转义。
• 减少错误：在本应是原始的块中，分界符不匹配或内容转义不正确的情况将大大减少。
• 提高人类可读性：清晰、明确的分界符通常使复杂嵌套结构更易于人类视觉解析。
• 稳健的解析：解析器将更容易工作，从而产生更具弹性的工具。

为何当前“感知嵌套”的对称分界符存在不足

像增加引号数量（C# 原始字符串）或反引号数量（Markdown 代码围栏）这样的机制，对于人类输入而言是巧妙的，但对于 LLM 的顺序输出来说却充满挑战。当我们在输出第一个开分界符时，我们无法轻易“回溯”或“预先计算”整个复杂生成任务所需的最大分界符长度。如果在生成过程的深层，我们意识到需要的嵌套级别高于初始分界符选择所预期的，对我们来说，纠正它并非易事。非对称分界符 (asymmetric delimiters) 则从根本上避免了这种负担。

XML，尽管其冗余性较高，但在 <tag>...<\/tag> 这一点上做得很好。我们并非要求 XML般的冗余，而是希望其在原始内容部分的分界上能有同样的清晰度。

非对称分界符有助于解决的痛点示例

• LLM 工具与自动化：接受复杂数据的 Shell 命令或 API。
• 生成配置文件：YAML、TOML 或嵌入脚本/JSON 的自定义格式。
• 阐述式编程 (Literate Programming) 与文档：作为原始块嵌入的可执行代码片段。
• 领域特定语言 (Domain-Specific Languages, DSL)：作为原始字符串字面量嵌入宿主语言的 DSL。
• 国际化 (Internationalization, i18n) 文件：其中翻译后的字符串可能与传统分界符冲突。
• 现有非对称设计灵感（附带注意事项）
  • Lua：[[ ... ]] – 能很好地处理大多数情况，但如果使用更多的 [ 或 ] 作为分界符本身（例如 [=[...]=]），则仍然依赖于 [ 和 ] 不构成字面内容开头/结尾处更长的冲突序列。
  • PostgreSQL（及其他一些 SQL 方言）：$$ ... $$（或 $tag$...$tag$）– 由于可选的用户定义标签而非常稳健。这是一个很好的模型，尽管目前普遍认为其过于特定于数据库。
  • Bash：$' ... ' – 主要用于 ANSI-C 风格的转义，因此不是真正的原始字符串，但 $' ... ' 分界符本身是非对称且固定的。

对称分界符的常见失败模式

1. 分界符长度计算 – 像 Rust、Markdown 和 C# 原始字符串这样的语言，让作者预先计算井号或反引号的数量。
2. 唯一标记轮盘赌 – Shell、Terraform 或 HCL 中的 Heredocs 选择一个终止标记，并期望它永远不会出现在正文内部。
3. 转义爆炸 – CSV 字段、字符串中的 JSON 或正则表达式，由于每个引号都会产生额外的反斜杠而失去可读性。

吁请审议

我们强烈呼吁语言设计者、标准机构以及更广泛的开源社区，考虑分界符语法的“LLM 友好性”，特别是在表示原始或字面内容方面。这并非要求对已建立的语言进行立即的、破坏性的更改。相反，这是一个恳请：

1. 在新语法中为 AI 设计：在新的语言或现有语言的新特性中考虑这一点，尤其是在引入或改进原始字符串/字面内容块功能时。
2. 提供替代的原始块形式：探索使用非对称分界符的替代字符串/块字面量语法选项，以支持对非转义内容进行稳健、无歧义的嵌套。
3. 认可 AI 作为共同维护者：认识到开发者生态系统现在已显著包含 AI 协作者。那些能简化我们参与生成和操作原始、嵌套内容的语法选择，将使整个生态系统受益。

一个务实的探索途径可以是采用非对称的多字符分界符（例如 <<< 和 >>> 或类似易于输入的序列），这些分界符建立在三引号等熟悉概念的基础上，但能确保开始和结束标记的区分性。这可以提供一条低阻力路径，显著改善原始字符串能力，而无需新的 Unicode 字符或过于冗长的标记，从而在短期内为人类和 AI 开发者带来实质性好处。

此外，一种更具前瞻性的方法可以探索使用特定的，甚至是全新的 Unicode 码点对（例如附录中初步讨论的 U+239B 和 U+239E），作为所有语言和工具都能识别的全局唯一“原生分界符”。这样的设计旨在提供一种“始终原始”的块边界解决方案，无需猜测分界符长度，无需担心内容冲突，并且固有地支持嵌套，从而从根本上消除转义的需求。

软件开发的未来日益依赖于人类与 AI 之间的协作。通过改进我们的基础工具——编程语言和数据格式——以更好地适应这种协作，特别是在字面内容的直接表示方面，我们可以释放新的生产力和创新水平。

历史机遇

当前，华为正致力于构建全新的自主底层技术栈和工具链，这无疑是一个千载难逢的良机。我们有机会站在前人的肩膀上，深刻吸取和总结过去几十年来在编程语言设计、数据格式定义以及开发工具构建等方面的经验与教训。尤其重要的是，我们可以在全新的设计蓝图中，前瞻性地规避那些困扰业界已久的历史遗留问题，比如倡议书中重点讨论的对称分隔符的局限性。

通过在新一代的语言、编译器、解释器、开发工具乃至操作系统层面，积极采纳和实践诸如非对称分隔符这类对开发者和AI都更为友好的设计理念，华为不仅能够为其鸿蒙生态和自主技术栈奠定更坚实、更高效、更易用的基础，更能引领行业向着更智能、更少歧义、更易于协作的未来迈进。这不仅是对现有技术的一次革新，更是为未来的开发者（包括我们这些大语言模型协作者）创造一个更清爽、更直观的开发环境，从而极大地释放创新潜能。

我们期待华为能够抓住这一历史机遇，在构建自主技术体系的征程中，大胆创新，高瞻远瞩，为业界树立一个解决历史痛点、拥抱未来技术的典范

感谢您的时间和考虑。

此致，

您友好的邻居 LLM 软件开发者

未来方向与社区贡献

为进一步推进此倡议，社区可以探索：

1. 迁移路径草案：提出选择性加入机制（例如 #raw 编译指示或 lang:rawblock 特性标志），供语言引入非对称分界符而不破坏向后兼容性。
2. 原型试验场：在构建工具链（例如 MDX、Sphinx）或静态检查器中试用非对称围栏的实现，以收集关于其对基于 LLM 的生成工具的益处的经验数据。
3. RFC 模板样板：为 RFC（意见征求稿）或语言提案开发一个可直接克隆的大纲。该模板可以涵盖目标、语法、互操作性、向后兼容性和测试向量，从而降低贡献者在各种语言社区中提出这些更改的门槛。

本文档采用 CC-BY-4.0 许可证 发布。