命名裁决 · 一名两物 (naming/decision-0.1)

本文件是跨仓库命名的唯一裁决源。各实现仓库的 TERMINOLOGY.md 与本文件冲突时，以本文件为准。 English

0. 这不是「名字不好听」，是同一个名字指着两个东西

NAMING-REVIEW.md 把命名问题分成三类：A 概念名（口味，不改）、B 名实不符（缺陷，该改）、 C 对外映射（补表即可）。本文处理的是那份分类没覆盖的第四类：一名两物。

判据很简单，且不涉及口味：

同一个词，在两个仓库里指着两个不同的部件，且两边的术语表互相矛盾。

实测的矛盾（不是推测）：

最后一行明令禁止的那个译法，正是前两行在用的那个意思。这不是翻译分歧， 是两个部件抢一个名字，而且已经硬化进了双方的规范文档。

成因：一个名字被同时用在「规范里的理想部件」和「实际造出来的部件」上

RFC-0006 §0 与 2origin-harness/README.md 都写着「唯一没装的部件是本象」。 但那句话说的是观察器没装。而架构表里的 Benxiang（world representation）并非没有实现—— 它实现在另一个仓库里，就是 本象协议/compiler/（87 条语言无关一致性向量 + Python 第二实现）。

所以真相是：这里一直有两个部件，只是共用了一个名字。 裁决要做的不是"给观察器换个名"，是把本来就存在的两个部件分别叫出来。

1. 裁决

已修订两次：v0.2 退休 本器、本境 归还环境层（§1.1）；v0.3 学历层定名 学籍，本历 作废（§1.1a）。

1.1 为什么 v0.1 的「本境＝学历」被推翻

v0.1 把本境判给学历层，并在同一节如实记下了那条不利证据：

「词源上『境』略偏向环境，这一条对本裁决不利，如实记下——但它抵不过前一条。」

那条不利证据后来被直接引用来推翻本裁决，这正是如实记录不利点的用处。「境」＝ 环境，字面就是 uenv 在管的东西，于是本境归还环境层；学历层另行定名，见 §1.1a。

• 本器 这个补丁随之退休——它当初的存在理由只是"本境被占了，环境层得另起一个"。 补丁消失是解法正确的信号：一个方案如果需要引入一个仅为绕开冲突而存在的名字，冲突多半没解对。

1.1a v0.2 的「本历」也被推翻了（一小时之内）

v0.2 给学历层起名 本历。同日被推翻，理由两条：

1. 「本历」是生造词，而「学历」不是。 「学历」是本体系传播力最强的一个词（"AI 的学历可以 继承"），旁边再摆一个需要解释的近音词，是在稀释它。
2. 正解已经在仓库里自发出现过：NAMING-REVIEW.md 第 37 行写着「跨会话继承的是学籍， 不是记忆」。中文里「学籍 / 学历」本来就是「登记系统 / 被登记的记录」，零解释成本。

于是层与实例各得其名，且与相邻部件同构：

副作用是整个词表变清楚了：「本」字部件从三个降到两个（本象 / 本境，恰是一对：表示 vs 环境）， 「学」字部件两个（学籍 / 学堂，也是一对：存学历 vs 产经验）。

这次推翻本身是 §5 的第一个用例。 本历 从提出到作废不到一小时，却已经被写进了命名冻结—— 那违反了同一份文件 §5.2 刚立的规矩：没有判据钉住的名字只能是 candidate。 一份裁决在自己发布的当天违反了自己第 5 节，这件事记在这里，不删。

1.2 为什么整机不叫「本象 AI 计算机」

曾认真考虑过，并为表示层准备好了替代名（立象，与取象构成《系辞》原文的动词对：观物取象 → 立象以尽意）。 否决，两条理由：

1. 本象协议是整个体系里唯一被外部契约钉死的部件——87 条语言无关一致性向量、Python 第二实现、 13 条变异检查。它是唯一一个「换个人另写一份实现就能当场自证合规」的东西。改它的真实代价不是 945 处文本替换，是那 87 条向量的语义连续性；向量的价值恰恰来自不动。
2. 整机名占用部件名 ＝ 部分冒充整体。 在本体系的语言里，那与"投影冒充本体"同型。 本源 / 2Origin 是中性的整体名，不与任何部件抢。

典源成对，不是硬凑

前三个全部出自《易传·系辞》同一篇，且原文里它们本来就有先后关系：

观物取象   → 取象（观察世界，得到象）  ← 输入端
立象以尽意 → 本象（用象承载意义）      ← 表示层
（曾据「形而下者谓之器」拟过 本器，随 §1.1a 一并退休——典源对得上不等于该存在）

先取象，后立象——这正是 Observe → Think 的前两步。名字自己把数据流向说清楚了。

英文侧四个词彼此不撞

Origin IR / Sensor / State Layer / Machine Profile——英文读者不需要知道任何中文 或《易传》就能各就各位。这是本裁决的硬要求：中文名承担概念的成套性，英文名承担可理解性， 两者不必互译。 先例已有：影核的英文是描述性的 Action Kernel，不是音译。

为什么 Sensor 而不是 Observer

1. Observer 与 GoF 观察者模式（事件订阅）撞得太狠，英文读者第一反应是 pub/sub，完全不是一回事。
2. 这台机器整个是 PC 类比（CPU / RAM / SSD / GPU / Northbridge / Southbridge）。Sensor 是其中天然空着的一格：输入设备。
3. 最重要的：传感器不会因为你希望是 25 度就读出 25 度——那正是这个部件唯一的铁律 （observe() 收到第三个参数直接抛错）。名字自己就是判据。

为什么「本象」判给表示层而不是观察器

三条，按权重排：

1. 词源。「立象以尽意」说的是用象承载意义——那是表示，不是观察。观察在原文里是「取象」。
2. 规范已经这么写了。2origin-computer 架构表：Benxiang → GPU → world representation。 改规范比改一个目录贵得多。
3. 成本差一个数量级。本象协议 有 87 条一致性向量、4 个方言（CAD/法律/xlsx/memory）、 Python 第二实现、英文 README + MANIFESTO，已对外发布；ShadowOS 的观察器是一个目录、 5 个 .mjs。

为什么「本境」判给学历层而不是环境层

同样按权重：

1. 规范已定：2origin-computer 架构表 Benjing → SSD → everything the AI learned， 且 ShadowOS/TERMINOLOGY.md 写的是 state layer。论文正文亦在用。
2. 词源上「境」略偏向环境，这一条对本裁决不利，如实记下——但它抵不过前一条， 因为规范和论文的改动面更大。
3. 本器 对 uenv 反而更准：uenv 回答的是"这台机器是什么配置"，Machine Profile 比 Environment 精确（后者在英文里过泛，且与 env vars 混淆）。

2. 标价（实测计数，不是估计）

NAMING-REVIEW.md §2 立的规矩：改名前先量化爆炸半径，尤其是 facts[].source—— 那是证据指针，批量替换等于把「可复核」降级成「看起来像可复核」。 照办：

本象 → 取象（ShadowOS）

本境（本境协议 / uenv）：名字留在原地，含义收窄为环境层

一条别处没有的约束：历史不可改写，所以迁移必然是双语的

锚点快照和学历备份里的 benxiang 是当时的事实。改一个字节，.ots 立刻失效， 那批比特币时间锚全部作废。所以：

新旧名不是"过渡期共存"，是永久共存。 旧名在历史证据里永远是 benxiang， 新名只在今后的代码与文档里是 quxiang。

这不是妥协，是证据链的性质决定的。别名表因此不是迁移工具，是常设部件。

3. 现在做什么 / 不做什么

✅ 本轮做（零证据链风险）

• 出本裁决，中英双份
• 修 ShadowOS/TERMINOLOGY.md 第 18 / 77 行的自相矛盾，并指向本文件
• ShadowOS/CLAUDE.md 的命名冻结条款加入「取象」
• 2origin-computer/README.md 架构表补 Sensor 一行（它一直空着——输入设备那一格）

🛑 本轮不做（照 NAMING-REVIEW.md §2 的前置条件）

不执行 git mv benxiang/ quxiang/。 前置条件一条都还没就位：

1. dereferenceSource 需要先加路径别名表（benxiang/x.mjs → quxiang/x.mjs）， 让 35 条已验证事实的 source 在改名后仍能解引用——先保证证据不断链，再动文件；
2. 别名表必须是双向且永久的（见 §2 末），因为 16 份锚点快照永远指着旧名；
3. 改完每一批跑全量判据，用 B12 悬空报告逐条确认 35 处 source，不做全局 sed。

在别名表就位之前动手，等于让 35 条已验证事实的证据指针同时失效—— 而这正是 NAMING-REVIEW.md 为 southbridge/ 那笔债写下的、至今仍未偿还的结论。 一份裁决不该在落地时犯它自己引用的那个错误。

4. 给译者与论文作者

• 「本象 / Benxiang」在论文中一律指 Origin IR（表示层）。若上下文说的是观察，写 Sensor。
• 不要把取象译成 Observer（撞 GoF 模式），也不要译成 Watcher（暗示持续监听，它是一次性调用）。
• 不要把学籍译成 Environment——那是本境（Machine Profile）。学籍是 State Layer。
• 不要把「学籍」和「学历」混用：学籍是层（登记系统），学历是实例（一份 task state）。
• 命名冻结（一个季度内不改）现在覆盖：2Origin / 本象 / 取象 / 学籍 / 本境 / 影核 / 北桥 / 南桥 / 学堂。
• 英文技术名：Origin IR / Sensor / State Layer / Machine Profile / Action Kernel / Northbridge。 商标（ActionParity、OriginBus 等）是品牌名，不在技术文档里当部件名用。

4b. 第二轮清查：一物两名

§0 处理的是一名两物。反向的毛病同样存在，而且藏得更深——同一个部件有两个名字， 读者无从判断它们是不是一回事：

学堂那条最值得记：一名两物就发生在那张专门用来消除一名两物的表里，而且它在本裁决 落地当天被改过两次都没被发现。清单查得出的东西，通读查不出——这正是 §5 要给命名层 配考试的理由。

为什么 ActionParity 必须让位

parity 指的是「CLI 与 MCP 两条通道判决一致」——那是我们测过它的一个性质，不是它是什么。

用验证属性给部件命名，等于用「我们测过它」当名字。 哪天加了第三条通道，或 parity 判据被重构，名字就开始说谎；而它描述的那个东西 （风险判级 / 批准模型 / 审计 / 幂等 / 写后回读）一点没变。

商标与技术名分开不是妥协：ActionParity 继续作为商标持有，品牌名与技术描述名本就可以不同 （Apple Silicon / ARM SoC）。只要分工被写下来，一物两名就不再是缺陷；不写下来才是。

一个标价后没改的：影核的「影」

CLAUDE.md 铁律说「聊天记录是影，本象是对象本身」——影＝派生、次等、不可信。 而影核是全体系最可信的部件之一（动作的判决者）。同一个字承担了两个相反的价值判断。

放弃改名的理由是价钱：代码 19 / 文档 161 / 学历证据指针 20 / spec id shadowcore/0.2 30 处。 最后一项决定性——spec id 是协议标识符，改它等于协议版本变更，会波及所有声称符合该协议的 实现与记录。曾考虑 行核（与「北桥知、南桥行」咬合，且摆脱这个冲突），代价不值。 冲突记录在 ShadowOS/TERMINOLOGY.md §3，不掩饰。

5. 名字也要走 candidate → verified

5.1 病

数一遍这个体系已经在用的名字：本象、本境、学籍、学历、取象、影核、南桥、北桥、学堂、学历、经验、 判据、带外、锚定、叠象、影域、舟舱、本源计算机、Origin IR、bugscope、ShadowBench……

再按本体系自己的标准数一遍能被外部核验的（"一份实现自己跑通自己的测试，证明不了协议存在"， 本象协议/spec/conformance/README.md）：一个。其余全部是自家实现跑自家判据。

命名的密度已经远超验证的密度。名字是免费的，判据是贵的。 每多一个名字，就多一个「看起来已经存在的部件」。

这与学堂盘点出的那句是同一个病——58 条经验、49 条自称 verified、0 条能被任何人重跑—— 只是复发在命名层，而命名层至今没有考试。

5.2 判据（与学堂的经验生命周期同构）

定义一个名字 ＝ 做出一个尚未被验证的存在性主张。 「我们有 X 这一层」与 bugscope A1「标记存在＝崩溃」同型：起了名字，等于宣布它存在。

与学堂的规矩对称：verified 只由判据给，手写会被压回 candidate。

5.3 当前缺口：一律 candidate，不发正式名

对着主板点完之后，以下几格是空的。按 §5.2，它们不获得正式名字，只登记为 candidate：

5.4 一条被撤回的缺口，以及它撤回的理由

初版按主板清单列了 DMA（"大块数据绕过模型直传"）。撤回。

DMA 的价值是"绕过 CPU"；在 LLM 系统里，绕过模型的数据搬运本来就是普通函数调用，不需要一个部件名。 它之所以出现在清单上，只因为主板上有它。

隐喻在生产问题，也在遮蔽问题。 主板是冯·诺依曼架构的物理实现，而冯·诺依曼的前提是 「指令与数据可分、控制流可预测、状态可精确复制」——大模型三条都不满足。 按主板清单补部件，会补出一批在本架构下没有意义的东西。

因此判据不是「主板上有没有对应物」，是「它对不对应一个实测发生过的病」。 内存保护站得住（学历被吃过），DMA 站不住。

这一节是本体系第一次转身检查自己的名字——此前它审视过事实、经验、动作与时间，唯独没审视过命名。