CML

CML围绕Token的优先级表达、结构可扩展、逻辑可正交三个核心需求维度，抽象出的具有高度表达力与组合力的5个语义结构基元，作为构建一切逻辑语义关系的基础单位。

这5种结构基元，分基本结构和复合结构、组合结构三大类，基本结构描述多个基元语义Token之间的简单结构关系，同时可作为复合结构的组成单元，而组合结构是更宏观的容器类型，可以连接任意语义Token、基本结构和复合结构。

a、补充关系^{（基本结构）}

右边语义对象对左边语义对象的补充说明或解释、限制，通常是语义附加，不改变原语义结构

f:A∋B∋C

以符号@来表达，越靠左优先级越高，表示权重应该更高。

比如

• name@identity@organization
• name@company@position

两组标记的权重优先级声明是不同的，都重点都是先强调姓名。

b、线性递进关系^{（基本结构）}

一种有序的、逐步推进的语义关系，可以表达各种带方向的轨迹：递进、流向、变换链、指向链、顺序、因果、类型细化、生命周期......

f:A→B→C

用符号.表达，左侧权重是否应该略高于右侧，需要LLM可以结合实际语义token来最终判断权重优先级。

比如

• 生物.动物.人，重点落在人这个子类上。
• 产品设计.开发.运营，结合语义token本身，可以很清楚的判定他描述了一个生命周期语义。

c、并列集合关系^{（基本结构）}

多个语义并列，类似集合、对象属性集、多分支描述，无优先级或顺序，可以互调位置。

f:{A, B, C}

用符号+表达，权重不分主次先后。

比如

• 男人+女人，相对人这个概念，正反组合都一样。
• 姓名+年龄+username，都是某个账号的注册信息。

d、映射关系^{（复合结构）}

一种语义结构到另一种语义结构的复合对照，k-v形式，两边都可以使用3种基本关系的自由组合，用于支持二维语义表达

f(A,B) ↦ f(C,D,E)

用符号:表示。类似于键值对，但构造更自由，无论是key还是value部分，都可以使用基本结构，而不仅仅是基元语义token。

<key-context-struct>:<value-context-struct>

比如下面都是合法的映射语义结构

• 网站:doc-war.com
• 网站@doc-war.com:文档战场@贡献判断力价值
• AI+LLM:ChatGPT+Claude@v3.7
• ask.answer: 请介绍CML语言?.CML语言是符合自然语义的语义结构语言

特别约束

CML不支持嵌套映射，避免带来语义结构本身的解析复杂度。比如用户:张三:删除+查询之类的表达，在格式上是非法的。

e、组合关系^{（组合结构）}

多个语义结构组合形成新的语义整体，而不损失其原语义，反之拆分亦然，本质上是一种可运算的“关系结构容器”。

      f(A)+f(B) =f(A+B)
      f(A) =f(A+B) - f(B)
      

用空格表示对任意两个结构的语义叠加。

由于空格的语义优先级最低，且左右顺序无优先级影响，他同时也是CML字符串的整体运算符，对明文格式的两个CML字符串使用空格自然拼接成一个新的CML字符串，仍然是一个合法的CML字符串，不影响原语义表达。

plaintext(A)+space+plaintext(B) = plaintext(A+space+B)

这种可自由拆分—>还原的无损还原特征，让CML字符串具备语义运算特征，而不仅仅是语义表达，为标记工作分工协同提供了坚实基础。

特别约束

由于空格承担了语义上的无损运算职责，比如如果 用户:张三怎么样之类的用法，虽然在格式上是合法的，但一定会破坏无损组合原则，当多个语义字符串被拆分重组之后，会因为位置不同而颠覆原有语义。

运算优先级

关系运算类似于编程语言的表达式解析：从左往右进行词法扫描，然后根据关系分割符的优先级，决定语义运算顺序。

CML定义了明确的优先级，以确保在标记、推理阶段对语义解释的一致性。

补充关系a > 线性递进关系b > 并列集合关系c > 映射关系d > 组合关系e

在语义表达的基础上，定义了2种标准的CML字符串标记模式。核心区别是，在什么阶段，用什么形式，来标记语义Token（semantic_token）本身。

自然语言格式

自然语言格式，面向文档工程师的明文编写体验，适用于人类可读场景。

以markdown语法中的反引号标记（inline code），来包裹语义Token（semantic_token）。文档工程师，可以使用所见即所得的markdown编辑器，作为语义结构的明文编辑环境，可以非常快捷、直观。

比如，用markdown编写明文字符串：

`token1`.`token2`@`token3`+`token4` `token5`:`token6` 

自动实时渲染成下面的自然语义效果，一目了然：

token1.token2@token3+token4 token5:token6

换行问题

在自然编辑中，从可读性角度，人类倾向于对长字符串进行换行分割，而不是坚持使用空格来分割。因此，CML编辑器应该支持符号等价兼容，在明文解析和存储时，将 \n、\r\n、\r 等各种换行符号，自动改成 空格。

内嵌反引号问题

由于反引号没有转义表示，明文格式遵循Markdown生态的事实性标准方案：对于内部带有反引号的Token，用更多的反引号来包裹Token。如标记 console.log(`hello,${name}`) 需要用下面的方式来实现。

```console.log(`hello,${name}`)```

编码格式

带反引号`的CML字符串，包括+号、空格，在某些特殊场景下，可能会带来偏离预期的解析边界和转义要求。而其他分隔符和内部的Token值，也可能在URL、文件、key、变量命名场景具有不安全性。

比如：

• 在模版字符串中使用反引号
• 在URL、正则中使用+号、空格
• 在sql语句、shell脚本中使用反引号
• 和html或其他格式的嵌套，尤其是semantic_token文本原文本身也含有反引号自身时
• ......

因此，面向嵌入、存储、解析、运算、命名场景，CML定义了更安全一致的编码输出格式。

CML提供多种模式的编码方案可选，以增强在短语义场景、大规模语义场景和传输限制场景的适应性。

编码模式

一个编码格式的CML字符串，无论何种编码，均由两部组成：<rule_token><semantic_payload>。由首位负责表达规则版本，映射协议及更具体的编码模式。

规则标识

标准规则集所对应的规则标识符，仅限于a-z26个小写字母，即预留了26种组合位置，大写作为极端保留范围冻结，正常不会启用。未来100%不会使用数字和其他特殊字符来做标识符，以确保天然可以安全用于key、变量场景。

当前只定义了4种标准规则。

助记说明

• c对应cpu缩写，追求cpu友好；
• q对应qrcode缩写，取意面向二维码场景；
• p是plaintext的缩写，取意明文；
• a则留给了Base58，因为这是最早设计的模式，具有最高的安全普适性。

a模式

a模式，指1.0标记协议+双层Base58编码规则。

示例

以下是a模式的编码示例。

`token1`.`token2`@`token3`+`token4` `token5`:`token6`

将以上明文CML字符串按如下顺序编码：

1. 从CML字符串原文中顺序提取语义Token和关系分隔符
2. 先将每一个语义Token原文（不包括反引号的token字符串），使用UTF-8编码成字节流，再对字节流进行Base58编码，生成Base58字符串
3. 再用关系分隔符原文重新拼接

zyvFCwFv.zyvFCwFw@zyvFCwFx+zyvFCwFy zyvFCwFz:zyvFCwG1

4. 再次用UTF-8+Base58进行整体编码，消除一切特殊字符，拿到整体语义荷载

3EkzyE8r5SqnU6KSbLS98LVLJxFoNvskzaazkuEEryWminqaGwJz13YoatvfoRWoDyrofwUCQ

5. 最后，拼接首位模式标识符a，构成最终的CML编码字符串

a3EkzyE8r5SqnU6KSbLS98LVLJxFoNvskzaazkuEEryWminqaGwJz13YoatvfoRWoDyrofwUCQ

解码环节基于首位进行模式路由，反向还原到原始明文格式。

c模式

c模式，指1.0标记协议+双层Base64URL编码规则。

与双层Base58编码的流程完全一致，只是将编码方式改成Base64URL，将原来O(n²log n)的编解码复杂度降低到O(n)。

q模式

q模式，指1.0标记协议+明文混编编码模式。

q模式依然遵循双层编码架构，但最大限度的减少不必要的双层编码，相比a模式、c模式，核心差异在于对token层是否编码采取动态、自动处理规则，而不是一刀切：

• 语义荷载内部支持<plaintextToken><separator><encodedToken>混编
• 明文优先，对于混编进来的<encodedToken>，使用编码标识符!进行尾部修饰，告诉解码器这不是明文，需要进一步解码。
• 如果一个Token内部包含任何cml分隔符（@、.、+、:、空格）和编码标识!6种字符，将被强制编码。
• 无论是Token层编码，还是外围的整体编码，均采用base64URL。

示例

对于原始的CML关系语义：`这是明文`@`这要编码！`，明文字符串如下：

`这是明文`@`这要编码！`

如果采用c模式编码，则在整体编码前，拼接出来的语义荷载是这样：

6L-Z5piv5piO5paH@6L-Z6KaB57yW56CB77yB

而采用q模式编码，则拼接出来的语义荷载是这样：

这是明文@6L-Z6KaB57yW56CB77yB!

再整体编码：

6L-Z5piv5piO5paHQDZMLVo2S2FCNTd5VzU2Q0I3N3lCIQ

最后前缀附加模式标识q，构成最终的CML编码格式字符串：

q6L-Z5piv5piO5paHQDZMLVo2S2FCNTd5VzU2Q0I3N3lCIQ

p模式

p模式，指1.0标记协议+不二次编码的明文混编模式。

p模式，是q模式的简化版本，剔除了双层编码架构，以最大限度的减熵。

同一个示例

对于原始的CML关系语义：`这是明文`@`这要编码！`

明文字符串如下：

`这是明文`@`这要编码！`

无论采用p模式还是q模式，编码后拼接出来的语义荷载都是这样：

这是明文@6L-Z6KaB57yW56CB77yB!

但p模式不再对语义荷载整体编码，而是直接附加前缀，构成最终的CML编码格式字符串：

p这是明文@6L-Z6KaB57yW56CB77yB!

五种关系分隔符，源自对自然语言的语义表达结构的抽象提炼，亦是对表达歧义与结构可控性问题的深入思考。

自然语言参考

CML定义的5种关系分隔符，参考的是自然语言中隐含的最基本的语义结构（修饰、顺承、并列、对照、组合）。这五种语义结构，与中英法日等具体自然语言的语法表达风格无关。

      自然语言示例：
      例子: 那个戴着帽子C 的高个子B男人C               (A←B←C)
      例子: 他起床A，穿衣服B，出门C                    (A→B→C)
      例子: 我喜欢苹果A, 香蕉B, 橙子C                  {A，B，C}
      例子: ChatGPTA和ClaudeB、DeepSeekC 都是 AID，也叫LLME   (A+B+C ↦ D+E)
      例子: 这朵花A + 很美B = 这朵花很美A+B             (A+B=AB)
      

理论上，借助这5种基元关系的组合，能表达绝大部分逻辑关系，具有相当的完备性。

Token内部语义

对于排除、量词区间、映射嵌套等逻辑关系，CML不做原生支持，下沉至Token 层，来配合补充关系进行灵活表达，避免结构污染，带来优先级运算和人类直观阅读的复杂度。

因为Token本身也可以表达结构。

      自然语言例子: “他的年龄大约18~25岁，一定不是中国人。”
      标记:
      ❌ `age`:`range`:`18-25`        （非法嵌套且毫无必要，完全可以往前或往后合并）
      ❌ `age`:`>18`+`<25`            （没必要拆这么细）
      ✅ `age`:`range:18-25`         （在Token内部嵌套是符合自然语义的）
      ✅ `age`:`18-25`      
      

这体现了结构的极简原则：

CSE范式并不试图预先显式解决一切结构语义上的歧义，而是在实际表达时，借助关系分隔符所连接的语义Token，作为关系语义的上下文，让LLM推理出最合理的语义关系和对应的权重优先级。

显式结构的核心价值

主张善用Token内部的语义结构表达，也反映了CML在显式编码上的核心价值。

CML之所以接近于自然语言，而不等于纯自然语言，除了用于声明重要语义，还有其表达上的必要性。相比自然语言推理在token切分上的完全不可控，显式分割的本质，是进行语义纵向层级和横向关系的拆分，进而消除关系歧义，最终提升可控性与可解释性。