背景

Phase 3.2 设计文章修订链时，每个版本需要一个内容指纹。最“正统“的内容寻址 格式是 IPFS CIDv1（multibase + multicodec 前缀的 sha256），路线图 §2 也把 “内容寻址（git/IPFS 同源于 Merkle DAG）“列为要引进的原语。但格式选型必须 回答一个现实问题：这个指纹此刻要和谁互操作？

选项

• IPFS CIDv1。 生态标准，但本机与服务器都没有 IPFS 节点，Phase 4 的 公共网关只读末层明确“触发条件不满足不动工“；现在打 CID 没有任何系统会按 CID 路由它，只剩格式上的仪式感。
• 裸 64 位 hex。 最短，但无法自描述算法；将来若升 sha3 或引入真 CID， 旧值无法机械区分。
• 自描述 sha256-<64hex>（采纳）。 一眼可知算法，短码取 hex 前 12 位 做 URL（GitHub commit 风格）；前缀为将来升级到 CIDv1 或其他算法留口， 迁移时可机械识别。

证据

• 无 IPFS 节点、互操作价值为零（经验判断，写于 3.2 设计文档 §1 决策表）； 固定向量 sha256-d9084… 由 Rust 与 C++ 双端独立实现并三向漂移锁锁定。
• 自描述前缀的成本几乎为零，却消灭了“这串 hex 是什么算法“的长期歧义， 符合单一事实来源：算法身份写在值里，不靠旁注。

拍板

拍板者 zj：版本指纹采用自描述 sha256-<hex>，不追 IPFS CIDv1 的形式； 等 Phase 4 真有内容路由需求时再评估映射。AI 协作者给出格式对比与迁移口分析。 日期：2026-09-23（2026-09-24 补录）。