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

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

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

文章目录

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

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

先设想一个场景。

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

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

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

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

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

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

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

二、第一层实现：条款映射完整性（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,
}
}

两个关键设计：

三、第二层实现：五向一致性链（宪法→手册→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 代码的解读——"任一断链即红"是怎么成立的——放在《（中）》篇。）

诚实边界

公开声明

本文所披露的技术方案（裁决台账与条款映射表双向互校的定义与两个方向判据、"卷宗级 + 条款级"双层校验的 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 判定的实现原文。

系列目录（持续更新中）

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