真源要按维度显式指定

更新于 2026-09-21

真源要按维度显式指定

# 真源要按维度显式指定

同一份东西出现在两处时，「谁是对的」没有全局答案。你踩过的每一次「以哪边为准」的坑，根因都是默认了一个不成立的伪规则：「谁新用谁」「谁全用谁」「谁在代码里用谁」「谁看起来像就用谁」。正确的动作是：先按维度把真源写死，再谈同步。

出处	被默认的伪规则	显式指定后
多源更新按维度取真源	「整体取更新的那个源」	skill 正文 → 上游；协议字段 → 本地；以上游为基线再叠本地改造
作者是AI时协议要唯一规范答案	「同一个名字在哪层出现都能对上」	一个概念只留一个规范写法，其余一律 deprecated；校验器可自动拦
Agent读语义文件App读结构化存储	「数据库和文件都是真源」	Markdown 是唯一真源，SQLite 是可重建的派生层
导入要保留来源类型以选对渲染链	「落库了就是一条内容」	来源类型（`kind`）本身也是真源的一部分，决定后续走哪条渲染链
多源更新按维度取真源（协议侧）	「文档说了就等于运行时是那样」	每个字段的真源要能被校验发现「还没同步的层」

「谁新 / 谁全 / 谁像」都不是判据，只有「哪个维度归哪一层」是。 新旧是逐维度判定的：上游 skill 正文更新 ≠ 本地协议改造过时。一旦把两个维度绑成一次「整体选择」，必然丢东西 —— 丢掉的那部分不会报错。
真源不显式，就会退化成「最后写入者胜」。 这和更新时序要由本地最新状态决定是同一件事的两面：一个是「谁最后返回就算谁新」，一个是「谁最后改就算谁对」。两者都发生在没有显式记录的地方。
派生层必须是可重建的，否则它就偷偷变成了第二个真源。 「Markdown 为真源、SQLite 可重建」之所以成立，前提是允许丢掉 SQLite 重建。任何「两边都不能丢」的设计，实际上就是两个真源。
可迁移的动作：拿到任何一份有多处副本的产物，先答三句 —— 「这个字段的真源在哪？」「另一处是派生还是独立？」「派生层能不能重建？」 三句里有一句答不上来，这次同步就只是在制造不一致。

单看每一页，都是某个项目的局部约定（skill 从哪拉、库存在哪、导入留哪个字段）。并排之后才看得出它们共享同一个缺口：没有把「谁说了算」写成显式规则。而这个缺口独立于任何项目，只要存在多处副本就会复现。