### 三、元规则如何约束代码本身

技术版最容易犯的错误，是只要求普通参与者接受代码，却不要求**写代码的人、部署代码的人、升级代码的人**受约束。真正符合元规则的做法，恰恰相反：系统越自动化，规则定义者越要承担更重的责任。

尤其需要单独揪出来的，是`校准权`。很多失真并不来自公开改规则，而是来自悄悄调整评分口径、阈值、零点、权重和模型参数。条文没变，系统方向却已经被拨歪。因此，技术版不能只记录“规则有没有改”，还必须记录“刻度是谁调的、为什么调、影响了哪些人、何时回看、谁批准生效”。

如果想沿着“校准权、责任链、吹哨保护”这条技术治理线继续细读，可以结合[反腐与吹哨工具箱](toolbox/anti-corruption-and-whistleblowing.html)一起看。

因此，至少应有四项技术治理原则：

- **上线前审计。** 面向公众的关键合约、算法模型和规则参数，在上线前必须经过独立审查。
- **校准留痕。** 评分口径、阈值、权重、模型参数和例外白名单的任何调整，都必须留下版本号、责任人、依据、影响范围与回溯窗口。
- **升级可回溯。** 任何规则升级、参数调整、权限变更，都必须留下版本号、责任人、修改理由与生效范围。
- **错误可回滚。** 对高强度措施，系统必须支持限期复核、临时解除、争议冻结和条件回退，而不是“链上一写死，现实没后门”。
- **部署者担责。** 如果某套算法或合约导致大规模误伤，责任不能由抽象系统承担，而应落实到部署机构及其签字责任链。

元规则在数字时代的真正含义不是“大家都听代码的”，而是“写代码的人不能躲在代码后面”。