裁决台账双向互校（上）：名册与实物的第一道对账

裁决台账双向互校（上）：名册与实物的第一道对账

系列：《宪法即代码》第 31 篇（上）｜ 标签建议：AI编程、Rust、架构治理、CI、可追溯性

文章目录

• 裁决台账双向互校（上）：名册与实物的第一道对账
• • 一个治理体系的"暗伤"：名册与实物对不上
  • 一、双向互校的定义：两个方向都要走通
  • 二、第一层实现：条款映射完整性（460/460）
  • 三、第二层实现：五向一致性链（宪法→手册→ROOT→代码→程序→宪法）
  • • [3.1 第②向（手册→ROOT）：这就是"双向互校"的主角](#3.1 第②向（手册→ROOT）：这就是"双向互校"的主角)
  • 诚实边界
  • 公开声明
  • 可证伪
  • 快问快答
  • 下一篇
  • 系列目录（持续更新中）

一个治理体系的"暗伤"：名册与实物对不上

先设想一个场景。

你有一套"规则清单"（比如 460 条团队规约），每一条都声称"已经实现"。你去查，每条都能在清单里查到，都有编号，都很整齐。

但问题是：清单里写着"第 200 条已实现"，而代码里那个实现根本不存在。或者反过来------代码里有个实现，却没有对应条款。

这就是治理体系最常见的暗伤：名册（台账）与实物（代码）失配 。而且它极其隐蔽 ------因为清单自己看起来完全自洽。你查清单，清单说"全实现了"；你查代码，代码也挺多。只有"清单 ↔ 代码"对起来看，才会发现两边对不上。

本文公开我们的对账机制：双向互校。

一、双向互校的定义：两个方向都要走通

单向对账是"我数了数清单，齐了"。双向对账是两个方向都要过：

方向	问题	判据
正向	清单里有 460 条，代码里有没有对应的实现？	登记位 → 验证函数存在性
反向	代码里的实现，清单里有没有登记？	实现 → 登记位磁盘存在性

只有两个方向同时走通，才算"一致"。任一向断，就是"失配"，就要报障。

二、第一层实现：条款映射完整性（460/460）

最直接的实现，在 阴_木火_0001/阴_金_0007/阴_水_0065/mod.rs（原文）：

/// 验证460条宪法条款映射完整性（13卷连续覆盖1-460）
///
/// 返回 Ok(已映射条款数) 表示460条全覆盖；Err(缺失条款列表) 表示存在缺口。
/// 校验维度：
/// 1. 条款级：每一条1-460都能映射到所属卷宗（verify_clause_mapping）；
/// 2. 卷宗级：13卷无间隙、无重叠、条款总数恰为460（verify_volume_infos_consistency）。
pub fn verify_mapping_completeness() -> Result<u32, Vec<u32>> {
    // 卷宗级一致性校验（间隙/重叠/总数≠460 均视为不完整）
    if clause_map::verify_volume_infos_consistency().is_err() {
        return Err(vec![0]); // 0 编码卷宗级一致性错误
    }
    // 条款级映射校验（1-460 每条均有卷宗归属）
    clause_map::verify_clause_mapping()
}

/// 获取460条宪法覆盖率（已映射条款数/460×100）
pub fn mapping_coverage_percent() -> f64 {
    match verify_mapping_completeness() {
        Ok(n) => n as f64 / clause_map::TOTAL_MAPPED_CLAUSES as f64 * 100.0,
        Err(_) => 0.0,
    }
}

两个关键设计：

1. "卷宗级 + 条款级"双层校验 。卷宗级查"13 卷有没有间隙/重叠/总数是否为 460"（这是结构 层的对账）；条款级查"每条有没有归属"（这是内容 层的对账）。结构先过，内容再过------结构错了，内容对得再齐也没意义。
2. TOTAL_MAPPED_CLAUSES 是一个常量 （值 460），代码里声明"我映射了 460 条"。这个常量就是"名"------后文的②向会讲它怎么被用来和"实"对账。

三、第二层实现：五向一致性链（宪法→手册→ROOT→代码→程序→宪法）

460 覆盖只是"条款 ↔ 卷宗"。更完整的对账是一条五向链，把"宪法文本、工程手册、根文件（ROOT）、代码、程序运行"串成一个闭环：

① 宪法 → 手册      （k23_a3_wood_charter）   ← 立宪条款数 + 手册缺锚点清单
② 手册 → ROOT      （k23_a3_fire_map_root）   ← MD ↔ 代码双向互验
③ ROOT → 代码      （k23_a3_earth_root_src）  ← 五文件组 B2 判定
④ 代码 → 程序      （k23_a3_metal_src_run）   ← 桩扫描
⑤ 程序 → 宪法      （k23_a3_water_run_charter）← 覆盖缺口

元_L3_00030_dimension.rs 里的入口函数，原文：

pub fn k23_a3_run(root: &std::path::Path, mode: &str) -> (i32, String) {
    match mode {
        "facts"        => (0, k23_facts_text(root)),
        "charter-map"  => { /* ① 宪法→手册：立宪条款数 + 手册缺锚点清单 */ }
        "map-root"     => { /* ② 手册→ROOT：MD↔代码双向互验 */ }
        "root-src"     => { /* ③ ROOT→代码：B2 判定 */ }
        "src-run"      => { /* ④ 代码→程序：桩扫描 */ }
        "run-charter"  => { /* ⑤ 程序→宪法：verify_clause_N 缺口 */ }
        _ => (2, String::new()),
    }
}

一条链走完 = 一整圈对账。 逐向讲最关键的两向（本篇先讲②向的核心；"机器可读"细节与③向放在《（中）》篇）。

3.1 第②向（手册→ROOT）：这就是"双向互校"的主角

这是"台账 ↔ 映射表"互校的核心，原文（map-root 分支）：

"map-root" => {
    if !root.join("CLAUSE_MAPPING.md").is_file() { return (1, String::from("❌A3-② | CLAUSE_MAPPING.md 缺失\n")); }
    let (reg_n, claim) = k23_a3_fire_map_root(root);
    let mut o = format!("ℹA2注册表（CLAUSE_MAPPING.md）机器可读区块登记条款数={reg_n}\n");
    if reg_n < 460 {
        o.push_str(&format!("❌A3-②·手册→ROOT | 注册表仅登记{reg_n}条<460（须逐条登记·第459条双向追溯）\n")); (1, o)
    } else if claim == Some(460) {
        o.push_str(&format!("✅A3-②·MD↔代码双向互验绿（CLAUSE_MAPPING登记{reg_n}条 ↔ 元_L4_05219_clause.rs TOTAL_MAPPED_CLAUSES=460·任一断链即红）\n")); (0, o)
    } else {
        o.push_str(&format!("❌A3-②·MD↔代码双向互验 | 注册表{reg_n}条 vs 代码{}\n", claim.map(|c| c.to_string()).unwrap_or_else(|| "无".to_string()))); (1, o)
    }
}

（这段 map-root 代码的解读------"任一断链即红"是怎么成立的------放在《（中）》篇。）

诚实边界

1. 本篇与后续（中）（下）两篇公开的是对账机制与真实代码 （verify_mapping_completeness、五向链、A2 机器可读区、B2 五判据、三向对账）。这些都已实装。
2. 一处口径说明 ：专利池文档 D-3 引用的是"第 024 号修正案"（H256 双向验证）。本系列披露的 CLAUSE_MAPPING ↔ 代码常量 双向互验属于同一族机制在"条款映射"这一侧的实现，两者是同一设计思想在不同对象上的应用，不必强行合并为一个编号。

公开声明

本文所披露的技术方案（裁决台账与条款映射表双向互校的定义与两个方向判据、"卷宗级 + 条款级"双层校验的 460/460 映射完整性、五向一致性链的总览与②向"MD↔代码互验"的判定代码原文），均为本项目作者原创，特此公开发表，以期其成为公共知识。我们认为：成为时代标准远比收取授权费更有价值。

可证伪

三步：① 打开 阴_木火_0001/阴_金_0007/阴_水_0065/mod.rs，核对 verify_mapping_completeness 的"卷宗级 + 条款级"双层校验；② grep TOTAL_MAPPED_CLAUSES，核对常量值 460；③ 打开 元_L3_00030_dimension.rs，核对 k23_a3_run 的六个 mode 分支与 map-root 分支原文。代码可查，常量可数，回来验我。

快问快答

Q1：为什么不能只做单向对账？

单向会漏。只做"清单→代码"，会漏掉"代码有实现但清单没登记"（野实现）；只做"代码→清单"，会漏掉"清单有名字但代码没实现"（幽灵条目）。幽灵条目是失配里最危险的一种------它让治理体系以为自己覆盖了某能力，其实没有。

Q3：TOTAL_MAPPED_CLAUSES = 460 这种"自己声明自己是 460"的常量，不是可以随便改吗？

可以改，但改了要过两道：① 万文件内容锁（第 4 篇）要求变更走评审；② 真正的对账是"清单登记数 == 常量 "，改常量而不改清单，门禁立刻红。常量不是"真理"，是"待验证的声明"------它的价值恰好在于"可被对面的实物否证"。

下一篇

第 31 篇（中）：《裁决台账双向互校（中）：五向一致性链------②向解读与③向实现》------先解读上篇那段 map-root 代码（"任一断链即红"是怎么成立的），再补"机器可读区"细节，最后进入③向 B2 判定的实现原文。

系列目录（持续更新中）

1. 《覆盖率 100% 但全是重言式，等于 0%》
2. 《460 条"宪法"管理 AI 写代码：45 天、172 万行 Rust 的实战复盘》
3. 《五行生克是调度算法不是玄学：320 个闭环的图论解释》
4. 《SHA-256 万文件锁定：怎么防止 AI"顺手重构"你的架构》
5. 《45 天修宪 43 次：同步立法制》
6. 《AI 写的代码出 bug 算谁的？》
7. 《我写了一个"越用越聪明"的 CI 门禁：322 组判例清偿实战》
8. 《写在宪法里的"打脸"清单：6 维确定性，我们只有 1 个是世界级》
9. 《385-4 兑现实录：宇宙模型的五行闭环，今天开始接线》
10. 《新猎手上岗：dead_code 与 det_pattern 门禁接线记》
11. 《十二正经经脉网络：金行验证的容错路由》
12. 《执行AI虚报"全部通过"：审查AI的43个编译错误打脸实录》
13. 《无正本缺口清零战：族14缺口补建与439金标准》
14. 《十二层记忆体系：道录守不眠，一个数字生命的记忆怎么分层》
15. 《六根守护：眼耳鼻舌身意怎么写进代码》
16. 《防逃逸：AI 不能修改考核自己的规则》
17. 《三元进化闭环：让 AI 变好这件事，本身要可回滚》
18. 《五行生克防线：相克不是内耗，是五道关卡》
19. 《错误分类：四类错误与处置梯度》
20. 《母体与分身：一个数字生命物种的基因编码》
21. 《火·永恒动力之源：一个数字物种的能量经济学》
22. 《土·永恒记忆之载：集体记忆、交叉验证与遗忘权》
23. 《金·不朽秩序之规：健康裁决、群体决策与不可伪造的审计链》
24. 《水·无穷适应之变：降级、免疫、休眠与方向告警》
25. 《宇宙级永恒法则：使命、三元和谐、跨文明共存与归道》
26. 《确定性双跑断言：同一种子跑两遍，必须逐字节一致》
27. 《末弧回起：闭环为什么必须回到原点》
28. 《R 边异实现复算：为什么第二遍不能复用第一遍的代码路径》
29. 《闭环挂名检测：怎么识别走过场的闭环》
30. 《审计链自愈六步：默克尔树加哈希链的十分钟自动恢复》
31. 本文（上）《裁决台账双向互校：四百六十条映射怎么才不失配》
    番外 《智能时代的母体机座：从汽车平台到数字生命》

（本文为《宪法即代码》系列第 31 篇（上），数据口径：宪法版本 XF58.19.0、代码实测 2026-09-23）