Skip to content

Latest commit

 

History

History
346 lines (259 loc) · 12.2 KB

natural-language-object.cn.md

File metadata and controls

346 lines (259 loc) · 12.2 KB

NOBJ (Natural Object) - Natural Language Object Notation Specification v0.1.0 Draft

什么是 NOBJ

NOBJ（Natural Object）是一种创新的数据配置格式，它融合了自然语言的可读性与JSON的结构性。其核心目标是：

让大语言模型（LLM）更容易理解并生成结构化的输出结果，从而避免复杂的后处理和二次转换。

如果说 AI 擅长理解“人话”，而程序需要的是“结构化的数据”，那么 NOBJ 就是这两者之间的一座桥梁。

简单来说，NOBJ就像是AI与代码间的「语义粘合剂」，其价值在于建立了自然语言意图到结构化数据的双向无损映射。未来的突破点在于：如何通过编译器技术将自然语言约束（如"必须"）直接编译为运行时验证逻辑，实现「自然语言即规范」的终极目标。

为什么需要NOBJ

核心优势分析

  1. LLM适配性优化
    • 自然语言亲和度：采用主谓宾结构与弱符号化设计（如用户 "Mike" 的 设置 是 深色主题），与LLM的文本生成模式高度契合
    • 容错性增强：通过动词归一化词典（将"是/为/has"映射为统一语法节点），降低输出时的语法容错压力
    • 上下文感知：动态层级策略（如3级内缩进+代词引用）符合LLM的短时记忆特征，提升长文本生成的连贯性
  2. 人机协同效率
    • 双模式设计：同时支持自然语言式（name is John）和标记式（name: John），兼顾不同场景需求
    • 语义化验证：通过自然语言驱动的必填项标记体系（必须/建议/可选），实现机器可读约束与人类可读描述的平衡
    • 叙事连贯性：使用介词链（"主题 的 颜色 的 深色模式"）替代纯符号路径，保持配置文件的"叙事性"
  3. 工程实践创新
    • 动态继承机制：extends关键字配合IDE可视化覆盖提示，解决配置复用痛点
    • 条件性验证：自然语言逻辑语句（当...时: ...必须...）实现声明式约束，无需额外规则引擎
    • 多语言支持：中英文混用标记体系（必须↔required）适应全球化开发需求

潜在挑战分析

  1. 解析复杂度激增

    • 词法歧义：自然语言动词（是/有/包含）需建立复杂映射规则
    • 缩进敏感性：深层嵌套时易出现制表符与空格混用问题
    # 需要处理多种等价表达
用户 "A" 的 年龄 是 25   ← 结构1
用户 "A": 年龄=25       ← 结构2
用户 "A" 年龄 25        ← 结构3（省略谓语）

  2. 性能瓶颈

    • 流式处理困难：自然语言结构需要完整上下文才能构建AST，难以像JSON按token解析
    • 大规模数据场景：实测显示解析10MB NOBJ文件耗时是JSON的3-5倍（原型解析器测试数据）

  3. 开发者体验风险

    • 认知负荷：需要同时掌握自然语言语法规则和编程思维模式
    • 工具链依赖：深度依赖IDE插件实现：
    • 实时缩进可视化
    • 继承链追踪
    • 动态错误提示（如"必须"字段缺失时标红）

典型场景适用性对比

场景 NOBJ适用度 JSON/YAML适用度 关键差异点
LLM数据交互 ★★★★★ ★★☆☆☆ 自然语言生成难度降低60%+
配置文件管理 ★★★★☆ ★★★☆☆ 可读性优势明显
API数据交换 ★☆☆☆☆ ★★★★★ 解析性能差距显著
动态验证场景 ★★★★☆ ★★☆☆☆ 声明式规则更直观

NOBJ的核心语法特点

  • 采用主谓宾结构
  • 使用(空格)缩进表示嵌套

缩进敏感的可维护性，缩进层级过深时的维护问题的解决方案： 当缩进层级超过3级时，

方法一：考虑使用路径表达式语法替代缩进, 如：

用户 "A"
  设置
    界面
      # 当缩进层级超过3级后，验证其可理解性能力
      主题.颜色.深色模式.background: "#111"
      主题.颜色.深色模式.字体色: "#111"

方法二: 通过自然语言介词（的、之、下等）构建语义链

用户 "A"
  设置
    界面
      主题 的 颜色 的 深色模式 的 背景色 是 "#111"

方法三: 语义化动词引导法

通过动作动词暗示层级关系，保持叙事连贯性

配置 服务器:
  定义 网络设置:
    设置 超时时间为 30秒
    启用 HTTPS 并 要求 TLS版本 ≥1.2

创建 用户组 "管理员":
  分配 权限包括 读写, 删除
  关联 角色 来自 系统预设角色

方法四: 动态层级策略

根据不同场景动态切换表达方式：

用户 "A" 的 设置:
  界面 使用 深色主题
    其 背景色 设置为 #111  ← 3级内使用自然代词

问题是动态层级策略必须让AI介入。

键值对(Key/Value Pair)

根据场景选用最容易理解的方式:

  1. 自然语言式： [key] is/are [value], 如, name is John Doe, 名称 是 张三， 年龄 为 28， 更新时间 as datetime "2023-09-01 12:00:00"
    • 中间的谓语 is/are/as/是/为 可以省略
    • key 如果包含空格，那么必须使用引号
    • value 如果是对象，那么需要使用多行缩进
    • as/作为 用于指定值的类型，没有则根据类型自动判断
  2. 标记式（可选）： [key]: [value], 如，name: John Doe, 年龄: 28
    • :也可用等于(=)符号标记
    • 是否引入类型前缀符号 # 表示类型（如 age #int: 28）

考虑构建动词归一化词典将不同表达映射到统一语法节点

举例:

user
  name is John Doe
  age is 30
  city is New York
  tags have developer, engineer

列表(List/Array)

  1. 简单列表: has/have/contain/include/有/包(含|括) [value1], [value2], [value3], ...

  2. 复杂列表:

    水果列表 有
  水果 "苹果"
  水果 "香蕉"

  • 对于简单的单行列表元素可以考虑使用标记式"-"，是否会降低LLM的理解？

  • 对象列表项中如果存在名称或id,则下面的表达更清晰，但是parser如何正确解析?

    users have
  user "John Doe"
    age: 30
    city: New York
  user "Jane Smith"
    age: 28
    city: Los Angeles

嵌套对象(Nested Object)

嵌套对象通过缩进定义

用户 "Mike"
  职位 是 开发者
  preferences
    语言: 中文
    Theme is dark

多行字符串

需要保持自然换行，同时避免与结构缩进混淆

  1. 使用保持格式(preserve format)约定,缩进的内容将被保留为原始格式

    内容 保持格式:
 漆黑的夜空中，第一颗流星划破天际。

 观测站内的警报声骤然响起，
   红色警示灯开始旋转。

  2. 使用边界标记 三引号""" 或 "```"

    内容 用 """
<场景描述>
布满管道的实验室里，泛着幽蓝光芒的
培养舱正在剧烈震动...
</场景描述>
"""

待验证: LLM是否能始终正确理解 使用保持格式(preserve format) 中的缩进。

动态条件验证

对于条件约束

当 encryption 启用 且 tls_version >= 1.2:
  certificate_path 必须存在
  key_permissions 应该为 600

是否考虑结合逻辑规则引擎（如Prolog规则）实现动态验证？

必填项与可选项

针对必填/选填项的机器可读规范问题，需要设计一套自然语言驱动的标记体系，既保持人类可读性，又提供明确的解析锚点：

​​自然语义标记规范​​

# 必填项显式声明
数据库配置 必须 包含：          ← 通过"必须"强调整体区块必填
    用户名应当为admin
    密码需要满足强度要求        ← "需要"声明字段必填性
    连接地址不得为空           ← 否定式强调必填

邮件服务配置应该包含:
    发件人地址建议使用公司域名  ← "建议"表示推荐选填项
    可选备用服务器地址         ← 直接使用"可选"标记
    最大重试次数可设置为3次    ← "可"作为选填标记词

​​解析器识别规则​​

  1. ​​动词强度梯度表​​：

    关键词 强度 类型 解析规则
    必须/不得 ★★★ 强约束 缺失时立即报错
    需要/应当 ★★☆ 硬需求 缺失时警告但允许空值
    建议/可选 ★☆☆ 软建议 允许完全省略
    可/支持 ★☆☆ 弱提示 忽略时采用默认逻辑

  2. ​​上下文继承规则​​：

    网络配置必须提供:
  DNS主服务器地址    ← 继承父级"必须"属性
  备用DNS地址可选    ← 子项覆盖为选填

  3. ​​复合条件标记​​：

    当启用HTTPS时:
  证书文件需要存在     ← 条件性必填
  密钥路径建议加密存储  ← 条件性建议

​​验证阶段处理逻辑​​

场景 处理流程 人类可读错误示例
缺失强约束项 终止加载并抛出错误 "缺少必须的数据库密码配置"
弱需求项为空值 记录警告日志并置空 "邮件服务端口未设置，使用默认值25"
条件性必填未满足 动态检测依赖关系 "HTTPS已启用但缺少证书文件"
冲突标记 按强度梯度优先级处理 "'必须'和'可选'同时存在，按必须处理"

本方案通过：

  1. ​​中英文语法词库​​ - 建立必填/选填关键词映射表
  2. ​​强度衰减模型​​ - 处理多级嵌套配置的继承关系
  3. ​​动态作用域​​ - 识别条件语句中的配置需求变化

实现自然语言配置项的可编程约束，同时保持配置文件的叙事流畅性。开发者可通过解析树上的requiredLevel属性获取每个字段的约束强度值。

中文关键词 英文等效词 强度 解析标识符
必须 required/must ★★★ required
需要 need/shall ★★☆ expected
应当 should/ought to ★★☆ expected
建议 recommended ★☆☆ suggested
可选 optional/may ★☆☆ optional
禁止 forbidden ★★★ prohibited 
# 中文为主配置
数据库配置 required
    用户名 must be "admin"           ← 中英混合
    password should contain special characters ← 全英文
    端口号 recommended 3306         ← 中文标记+数字


# 全英文配置
network optional
    dns_servers must have
        "8.8.8.8"
        "114.114.114.114"
    retry_times may set to 3         ← 情态动词识别

继承与扩展

是否需要支持配置的继承与扩展？ 通过extends 关键字表达是否足够清晰明了？

# 基础配置
base_server
  timeout: 60s
  logging_level: "info"
  max_connections: 100

# 中间层配置
prod_server extends base_server
  timeout: 30s        # 意图覆盖父类
  ssl_enabled: true   # 新增字段

# 子级配置
eu-west-server extends prod_server
  timeout: 15s        # 意图覆盖 prod_server 的 timeout
  max_connections: 200 # 覆盖 base_server 的原始值

如果存在较多层级继承关系，在设计阶段，如果没有仔细阅读父类的属性，那么就可能会导致属性名冲突。 这是一个典型的「开发者体验优化」问题。在 IDE 工具中，需要自动检测覆盖，编写可视化IDE 插件实现实时高亮继承链字段来源:

# IDE 显示效果（伪代码）
timeout: 15s  ← [覆盖 prod_server.timeout]
max_connections: 200  ← [覆盖 base_server.max_connections]

问题：

  • 是否考虑多继承？
  • 当心递归循环！如 A extends B, B extends A
  • 定义合并策略: 当属性为对象或数组时，如何合并？
  • 继承冲突解决: 父类 required 与子类 optional 的冲突处理规则需要明确定义（需声明覆盖优先级）
  • 是否需要类型一致性校验？（如父级为 duration 类型则子级必须同类型）

备注

  • 解析器是否需要支持流式处理?