摘要

  • draft-feng-netmod-naim-01 把 Canonical JSON 定为唯一权威表示；Markdown View 是面向人工审阅的可再生视图，LLM Context View 则是为节省 token 而有意删减的信息包。
  • JSON Schema、往返测试、重试成功与 YANG 验证各自只能证明特定输入、规则、工具版本和 schema context 下的有限检查，不能单独证明需求已消歧、操作获授权、服务器已实现、配置已生效或网络结果正确。

设想一句常见要求：“主链路失效后才允许备用路径接管，但受监管流量永远不能走备用路径。”AI 建模助手追问了列表键和可写性，生成 NAIM JSON；工具验证通过，Markdown 能再生，YANG 也被解析器接受。此时最重要的问题却可能仍然空白：谁判定“失效”，怎样识别“受监管流量”，“允许”究竟是可以配置、已获授权，还是立即执行？输入里没有的事实，不会因为序列化稳定而自动出现。

NAIM revision 01 正是为自然语言直接转 YANG 的猜测风险提出中间表示。草案列出的缺口包括配置与状态混淆、列表键不清、约束表达式缺失、操作前置条件含糊，以及跨模块关系未交代。它没有把“更好的提示词”当成唯一答案，而是设计了一组各司其职的表示和处理层。

先把文件身份说清。Datatracker 将 Chong Feng 的文件列为 2026 年 7 月 18 日更新的 active individual Internet-Draft，stream 为空，intended RFC status 为空，状态是 I-D Exists。草案页眉另写着 Intended status: Standards Track，那是作者在草案中标注的目标，不等于 NETMOD 工作组采纳、IETF 背书或 RFC 地位。修订历史 证明文件发生过什么变化，不证明任何网络已经采用它。

一个主记录，两个不同目的的派生视图

草案要求互操作工具以 Canonical JSON 为权威。Markdown View 必须从 JSON 确定性生成，服务于人工审阅、版本控制和编辑讨论。如果系统允许用 Markdown 反向更新 JSON，Markdown 已表达的字段要保持语义等价，只存在于 JSON 的字段不得被悄悄丢弃；冲突必须显式解决。

这条规则不是简单的格式偏好。它为“方便阅读的文本”和“机器认定的记录”划出主从关系，也暴露了编辑路径中的真实风险：人改了一个可见字段，系统却覆盖了一个未展示字段；或者两个视图同时修改同一事实，最后由未记录的优先级决定结果。合格的证据应包含具体转换器版本、输入输出哈希、字段丢失清单和冲突处理记录，而不只是一句“往返成功”。

LLM Context View 的任务完全不同。它面向模型、追求 token 效率，必须保留名称、语义类型、必填性、约束、可写性、可见条件、支持的操作、前置条件和副作用；同时必须省略传输报文构造细节、内部元数据、原始 JSON Schema、deviation 声明和 extension 定义。草案明确禁止用它重建 Canonical JSON。

“有意省略”并不等于“对任何任务都不重要”。目标服务器的 deviation、feature 或外部 augment 可能改变有效 schema；某个 transport 细节也可能决定操作是否安全。模型基于上下文作出忠实回答，仍可能不适用于现场。操作者要证明的不是提示变短，而是每类省略信息都经过任务相关性判断，并在后续步骤重新接回完整环境。

三层架构把责任拆开

Specification 层定义 JSON 结构、JSON Schema 以及视图生成规则；Skill 层承担会话建模、摘要、YANG 生成和逆向提取等 AI 过程；Tool 层是确定性软件，负责结构验证、视图转换、上下文生成以及从确认的材料生成或解析 YANG。格式可以稳定，Skill 可以替换，是这套设计最可取的治理特征之一：模型不是永久权威，验证器也不需要理解组织意图。

Validation-Reflection-Retry 进一步处理机器可定位的错误。Tool 生成带路径和预期条件的结构化错误，系统把它注入 Skill 上下文后重试；超过上限就应停止，把剩余问题转换成针对用户的具体问题，并保留修正历史。

然而“第二次通过”只证明第二次输出避开了第一次触发的检查。模型可能删除难处理的可选字段、选择一个看似合理的 key，或把无法转换的运行条件塞进 description。若最终记录只剩绿色结果，重试反而会洗掉最有价值的不确定性。审计必须保留最初需求、澄清问题、默认值、删除或改写字段、每次诊断以及精确的 Skill、Tool 与 schema 版本。

生成 YANG 后，证据边界依然存在。RFC 7950 定义 must、when、leafref、augment、feature 和配置/状态等语义。拿到完整模块闭包、feature、deviation 与测试实例时，验证器能够给出强证据；它却无法判断一句自然语言 when 是否被翻成了原意的 XPath，也不能证明目标服务器存在那个 augment、某个账号获准操作，或操作后的转发表符合预期。RFC 8407 提供成熟的 YANG 设计指导，但同样不是生成结果的采纳证书。

RFC 8525 的 YANG Library 能记录服务器声称使用的模块集、feature 和 deviation。它很重要，却仍是声明层证据，需要与源码字节、客户端解析轨迹和有效 schema 指纹配对。RFC 8342 又把 intended 与 operational datastore 区分开：配置被接受，不等于设备已经完成应用，更不等于网络目标实现。

NAIM 草案自己强调它不是 YANG 的 JSON 编码，也不取代 YANG；运行时操作意图另由 NAIM-OP 草案 讨论。revision 01 不规定具体模型、提示词、置信度算法、内部工作流和运行执行。它的结构性控制值得重视，也必须按这个范围使用。

生产环境的最低证据链应至少保留：原始需求和未决假设；Canonical JSON 精确字节、来源、schema 版本与哈希；两个派生视图、转换器和省略/冲突清单；生成的 YANG、完整依赖闭包、feature、deviation、验证器和正反测试；服务器 YANG Library、客户端解析与授权记录；最后才是 intended/operational 状态、遥测、回滚与网络结果。RFC 8259 对 JSON 的定义本来就很克制，后续每一个绿色状态也应保持同样克制。

这与 Lu Heng 所说的最小确定性公共层相呼应：公共规则应可在本地验证，而实际采用要由运行代码的参与者完成。他关于运行代码优先和现实层次的笔记帮助 BTW 区分文档、记录与可执行结果；这里引用的是分析框架，并不表示 Lu Heng 审阅过 NAIM。

来源