为什么大模型时代需要一种全新的文本格式？

“Markdown 诞生的 2004 年，还没有人需要一份能被程序原子化改写的文档。”

1. 两个读者坐到了同一张写字台前

在过去的二十多年里，文本格式的演进遵循着一条清晰的分水岭：

  • 一类是给人看的排版标记（以 Markdown、HTML 为代表）：核心诉求是排版简洁、肉眼可读、方便渲染成富文本页面；
  • 另一类是给程序读的数据序列化格式（以 JSON、YAML、XML 为代表）：核心诉求是结构严谨、强类型、易于 AST 遍历与机器持久化。

在这两套体系下，人类工程师与计算机各司其职，相安无事。

然而，随着大语言模型（LLM）与自动化 AI Agent 深入软件研发与知识协作的一线，一个不可逆的历史性转折发生了：文档不再仅由人类编写、供人类阅读，而是由人类与 AI Agent 共同创作、实时修改与持续维护。

AI Agent 成了文档的第二个读者，同时也是高频介入的共同写作者。

当人机坐到同一张写字台前时，我们今天习以为常的文档基础设施开始全面瓦解。

2. 老范式的三大困境

困境一：Markdown 的“全量重写税”与格式漂移

Markdown 诞生于 2004 年，John Gruber 当初设计它的初衷极其纯粹——让写作者能够用直观的纯文本快速排版并转换成 HTML。它从来没有被设计用来承载“程序的原子级局部改写”。

因为缺乏确定性的区块边界与机器可识别的唯一标识，当 Agent 需要修改 Markdown 文档中的某一个参数或某一段逻辑时，常见的做法只有两种：

  1. 靠 Prompt 约束（“请只输出需要修改的段落”）：极其脆弱，多轮之后极易出现上下文断层与定位失误；
  2. 全文重新生成（Full-Text Rewrite）：为了修改 10 个字，让模型重新读入并吐出 5000 字。

在 Agent 的多轮执行循环里，全文重写带来了可怕的恶果：

  • 注意力被白白稀释：昂贵的上下文窗口被大量未变更的字符吞噬；
  • 格式漂移与幻觉：每一次全文重写，都为模型引入了一次破坏排版、遗漏段落、甚至篡改非相关逻辑的随机性风险。

困境二：JSON / XML 的“语法噪点”与人类可读性剥夺

如果说 Markdown 太过松散，那为什么不直接用 JSON 或 XML 存储一切？

答案同样显而易见：包裹语法太沉重，且人类心智无法直接承受。
大段嵌套的括号、引号、闭合标签与转义符，不仅让程序员失去直接阅读与沉浸编辑的欲望，更在长上下文中占据了相当比例的无效 Token。

困境三：状态碎片化与“副本漂移”

在现有的 Agent 架构中，知识往往被拆碎：一部分在向量数据库里，一部分在短期记忆里，一部分在临时 Prompt 模板里，还有一部分散落在各种复制粘贴的 Markdown 副本中。

软件工程有一条朴素的真理：副本自诞生起就在漂移。
当多处副本无法通过单一源头自动同步时，Agent 面对的就是充斥着版本分歧与事实冲突的混沌状态。

3. 历史的启示：文档需要的不仅是格式，而是一组动词

2000 年，Roy Fielding 在其博士论文中提出了 REST 架构风格。REST 并没有发明任何新的网络硬件，它的核心创见在于：为互联网上散落的所有资源赋予唯一的名字（URI），并为它们定义了一组标准的操作动词（GET / POST / PUT / DELETE）。 这一极简约定奠定了现代互联网协作的基石。

今天，面对文档内部散落的无数逻辑块、规则定义、系统参数与任务结论，我们遇到了完全相同的问题。

解决人机共写冲突的答案，不是发明一个更加复杂的富文本编辑器，而是将 REST 的思想引入纯文本：

Doc-as-a-Base（文档即真相之源）：
为文档内的每一个逻辑块赋予唯一的名字（#id），并赋予标准的操作动词（get / set / add / delete）。

4. GEML 的解法：四大定律与物理隔离

为了让 Doc-as-a-Base 从哲学变成确定性的工程实践，GEML (geml-spec) 确立了四项不可分割的运行定律：

1. 寻址律 (Addressing)

每个结构块必须有稳定的机器主键，脱离上下文即可被单独读取与替换。

GEML 将纯文本划分为类型化区块（Typed Blocks），每个块拥有明确的 #id。
get(id) 只读取那一块，set(id) 只写入那一块。在 Agent 操作局部内容时，其余部分不仅不修改，在 Prompt 中甚至根本不加载。

“没被加载的东西不可能被改坏——要隔离，不要自律。”
依靠物理级的上下文隔离，彻底消灭全量重写带来的幻觉与 Token 浪费。

2. 投射律 (Projection)

引用必须是视图端的动态取值，而非静态复制。

GEML 原生支持跨文档与跨区块的嵌入引用。源头单一定义，渲染与消费时动态求值。彻底终结跨文档复制粘贴导致的“副本碎片化”噩梦。

3. 校验律 (Validation)

块间引用必须在构建期受核验，坏写入挡在落盘之前。

写入即防御。当 Agent 产生破坏性的语法结构或产生悬空断引用时，GEML 解析器在落盘前直接拦截报错，不等人工 Review 介入。

4. 回退律 (Rollback)

出错时必须能只回滚出错的那一块。

GEML 借助伴生的 .gemlhistory 文件，记录每次 Block 的变更历史。Agent 哪怕改错了一处参数，也支持单块原子回退，不影响整篇文档的其他内容。

“不是 Git 不好，是它不在这一层。”
Git 负责文件与 Commit 级别的版本管理，GEML 负责文本内部细粒度的块级撤销。

5. 边界声明：它不是什么？

任何成熟的工程规范，其信誉都建立在“主动讲清自己不主张什么”之上：

  1. 它不是数据库：查询是 O(N) 的字符流遍历，没有索引，并发写至多依赖整文件锁。GEML 借用的是数据库的操作语义（寻址、读写、校验、回退），而非它的运行时属性。
  2. 它不取代向量库与 Agent 运行时记忆：向量库管语义相似度，短期记忆管会话窗口；GEML 的定位始终是可持久化、可审计、可精确读写的文档真相底座。
  3. 它不承诺虚无的“零开销”：=== type {#id ...} 语法本身具备轻量结构开销，GEML 主张的是语法克制（Syntax Austerity）——不为排版浪费一个多余的 Token，把宝贵的上下文留给内容。
  4. 校验拦不住内容写得烂：它拦的是结构破坏与断引用。Agent 把一段话写得很蠢，校验器一个字都不会说。

6. 写在最后

寻址、投射、校验、可逆——这四种能力在各自领域都有极其成熟的对应物：数据库有主键，XML 有 XInclude，Schema 能校验，Git 管历史。

不寻常的不是其中任何一项，而是将这四样能力，同时装进了一种人类肉眼可读的纯文本之中。

Doc-as-a-Base 不是要创造一个沉重的系统，而是用极简的约定，给混沌的人机协作带来秩序。

让每段文字拥有名字，让每次修改拥有边界。