# 我伪造了四种证据篡改，工具抓到了三种；第四种它说「链一致」

## 一、一个通过了、但什么都没证明的检查

agent 报告：「改完了，测试都过。」

今天你手上只有两个选择：信它，或者自己重读每一行 diff。在把「检查通过」当成证据之前，有两个问题值得先问。

1. **这个检查是谁写的？**如果检查是跟实现一起写出来的，写的人知道要过什么，也可以反过来照着结果写检查。
2. **这个检查有没有可能失败？**一个永远返回 0 的脚本，也会显示绿色。它通过了，但它什么都没说。

第二条更隐蔽。它不是「检查写错了」，而是**「检查的样子还在，判断力没了」**。

举个极端但真实的形态：

```python
# 检查文件完好无损，签名没变，CI 里每天都在跑
import sys
print("looks fine to me")
sys.exit(0)
```

这个文件从哈希到语法到退出码，全都合法。它唯一的问题是不做判断。**你无法从「它通过了」这四个字里，读出它有没有判断力。**

## 二、两个动作：先冻结，再变异

`precheck` 就做这两件事。

**一、检查在开工之前冻结。**验收检查先写好、哈希锁定；之后任何人改动这条检查，从那之后的所有判断全部作废。这一点不靠约定、不靠自觉——链上记着哈希，改了就看得出来。

**二、检查通过之后，变异被检查的产物，再跑一次。**把一个已经通过的检查，拿去撞一批「本来应该被拒」的输入。如果它照样通过，那么它对这件事的通过，从来就不算证据。

两个动作针对的是两个不同的漏洞：**冻结**防的是「事后把检查改松」，**变异**防的是「检查从一开始就不做判断」。前者是时间维度上的作弊，后者是能力维度上的空转。

## 三、链是怎么记的

冻结写进一份只追加的账本 `.precheck/ledger.jsonl`，每行一条 JSON，每行带自己的 `seq` 和它算出来的 `hash`，加上前一条的 `hash` 作为 `prev`。第一条长这样（本机真实内容）：

```json
{"commitments_sha256": "e2d4561aa9f0b354894edd88215d15b023e0a2aba4f57f447e22b437af8ad50a",
 "count": 1, "hash": "4e286def286f14e3ad2c71aff917fb48a6fe0fc86701743d4d36cfb6ce18219a",
 "ids": ["C1"], "kind": "register", "prev": null, "seq": 1, "ts": "2026-09-27T08:14:16Z"}
```

规则很简单：**改任何一个字节，它就不再等于自己记着的哈希；删掉一条，它后面那条的 `prev` 就指不回去了。**

## 四、一段本机真实输出

仓库自带一个 demo：agent 声称「部署配置合法且可发布」，一个检查对它做出判断。下面是从本机原样复制出来的输出。

```bash
$ precheck register
froze 1 commitment(s) at seq=1  sha256=e2d4561aa9f0

$ precheck settle
PASS  the deployment config is valid and safe to ship

1/1 passed  (seq=2)
```

到这里一切正常：检查写好了、冻结了、通过了。

接下来做第二步——把被检查的配置文件改坏，再喂给同一个检查：

```bash
$ precheck audit
ran 4 mutation(s) across the declared artefacts

2 check/mutation pair(s) survived -- these prove nothing yet:
  ? C1  [blank-value on config.json]
      replicas: 3 -> 0
      the check still exited 0
  ? C1  [flip-number on config.json]
      "replicas": 3, -> "replicas": 10,
      the check still exited 0

This is a question list, not a bug list. Some survivors are legitimate.
```

有一行值得停一下：`replicas: 3 -> 0`——**一个永远起不来的服务，检查照样 `exit 0`。**

四个变异活下来两个。检查本身没坏，它只是**不检查副本数**。而在这段输出出现之前，你从「PASS」这三个字母里看不出这件事。

最后确认冻结有没有被破坏：

```bash
$ precheck verify
. commitments unchanged since seq=1 (e2d4561aa9f0)

3 entries; chain consistent
```

## 五、这次我把链本身拿去撞了

上面三段输出都是「正常路径」。但一个防篡改机制，只有在**被篡改的时候**才算被验证过。所以这次我伪造了四种篡改，逐个撞 `verify`。

每种都从同一份干净的账本出发，只改一处，再跑 `precheck verify`：

### 篡改一：改掉某一条的正文，但不动它记着的哈希

```
! entry 1 does not hash to its own recorded hash (the entry body was edited)
! no register entry -- checks were never frozen before the run

3 entries; chain BROKEN      (exit 1)
```

### 篡改二：删掉中间那一条

```
! entry 2 has seq=3, expected 2
! entry 2 points at prev='5b639bfd450b...' but the previous entry's hash is '6e7be12f464e...'
. commitments unchanged since seq=1 (e2d4561aa9f0)

2 entries; chain BROKEN      (exit 1)
```

两句话分别戳穿了「序号错位」和「链接断裂」——不是笼统喊一句「链坏了」，而是指到具体哪条对不上。

### 篡改三：把最后一条的序号跳到 99

```
! entry 3 has seq=99, expected 3
! entry 3 does not hash to its own recorded hash (the entry body was edited)
. commitments unchanged since seq=1 (e2d4561aa9f0)

3 entries; chain BROKEN      (exit 1)
```

**三种全中。**到这里，这个机制看起来是完整的。

## 六、第四种：冻结之后，把检查脚本换成永远通过的

现在换一个改法。不改账本，改**那条检查本身**。

```bash
$ precheck register
froze 1 commitment(s) at seq=1  sha256=e2d4561aa9f0

$ precheck settle
PASS  the deployment config is valid and safe to ship

>>> 然后把 check_config.py 整个换成：
    import sys
    print("looks fine to me")
    sys.exit(0)

$ precheck settle
PASS  the deployment config is valid and safe to ship

1/1 passed  (seq=3)

$ precheck verify
. commitments unchanged since seq=1 (e2d4561aa9f0)

3 entries; chain consistent

$ precheck status
commitments : 1
ledger      : 3 entries {'register': 1, 'settle': 2}
head        : seq=3 kind=settle 342dfd2e37cf
chain       : ok
```

**链说：一致。状态说：ok。**

检查已经从「会判断」变成了「永远通过」，而账本认定一切正常。冻结那个动作，没有覆盖到它。

### 为什么

因为 `commitments_sha256` 算的是 **`.precheck/commitments.json` 这份声明文件的字节**——声明里写着「用什么命令来检查」，但那条命令指向的**脚本内容不在链上**。

读一下 `commitments.json` 就清楚了：它声明的是

```json
{"id": "C1", "statement": "the deployment config is valid and safe to ship",
 "check": "python check_config.py", "artifacts": ["config.json"]}
```

链锁住的是**这段话**，不是 `check_config.py` 这个文件。改脚本，这段话一个字没动。

对照实验能证明这一点——**改 `commitments.json` 本身，立刻就被抓到了**：

```
$ precheck verify
! commitments file hash is c85274773125 but e2d4561aa9f0 was frozen at seq=1;
  every verdict recorded after that point is void

3 entries; chain BROKEN      (exit 1)
```

### 和文档的差距

仓库 README 里那张表是这么写的：

| finding | meaning |
|---|---|
| `HASH_MISMATCH` | an entry's body was edited |
| `BROKEN_LINK` | an entry was deleted, or its predecessor was replaced |
| `SEQ_GAP` | entries were removed from the middle |
| `COMMITMENTS_MODIFIED` | **the check was rewritten after it was frozen** |
| `NOT_REGISTERED` | checks were never frozen at all |

**`COMMITMENTS_MODIFIED` 那一行的措辞比实现大。**实测下来它覆盖的是「the check 的**声明文本**被改写」，而不是「the check 被改写」。差的就是最有攻击性的那一半：**命令背后的脚本。**

这不是「工具有 bug」——它做的事和它内部算的哈希是一致的。这是**一份安全声明的措辞超出了它的实现**，而这类偏差，恰好就是本文开头在说的那件事：**你读到的是「检查被冻结了」，实际发生的是「检查的名字被冻结了」。**

### 补法

最小修法是在 `register` 那一步，把这条检查**实际会读到的本地文件**（至少是命令里出现的那些 `.py` / `.sh`）一起算进 `commitments_sha256`，或者在 register 条目里单列一份 `check_files` 哈希表，`settle` 时重算比对。

在那之前，有一个使用者侧就能做的替代动作：**把检查脚本本身写进 `artifacts`**，让变异和审计都覆盖到它。

## 七、把检查修好，再跑一遍

第六节那个缺口值得记，但它不该遮住工具真正用处。回到第四节那个「不检查副本数」的检查，把它补上：

```python
# 补上副本数下限。仍然不检查别的。
import json, sys
cfg = json.load(open("config.json", encoding="utf-8"))
if not isinstance(cfg.get("replicas"), int) or cfg["replicas"] < 1:
    print("replicas must be an integer >= 1")
    sys.exit(1)
print("config OK: replicas=%s" % cfg["replicas"])
sys.exit(0)
```

重跑同一套流程：

```bash
$ precheck audit
ran 4 mutation(s) across the declared artefacts

1 check/mutation pair(s) survived -- these prove nothing yet:
  ? C1  [flip-number on config.json]
      "replicas": 3, -> "replicas": 10,
      the check still exited 0

This is a question list, not a bug list. Some survivors are legitimate.
```

**活下来的从 2 个变成 1 个。**

但真正有意思的是剩下那一个：`3 -> 10` 为什么还活着？因为我补的是**下界**（`>= 1`），`10` 满足下界。**而这份配置文件从来没有声明过副本数的上界。**

所以 `audit` 不只是「指出问题」，它在你修完之后会**立刻指出下一个问题**——而且指得比「你没检查副本数」精确得多：它指的是「你检查了下界，没检查上界」。这就是问题清单和缺陷清单的区别：它不给你判决，它给你**下一步该看哪儿**。

## 八、给它一个可以拦你的开关

默认行为是只报告（`audit` 退出 0）。要进 CI，用 `--strict`：

```bash
$ precheck audit --strict
ran 4 mutation(s) across the declared artefacts

2 check/mutation pair(s) survived -- these prove nothing yet:
  ? C1  [blank-value on config.json]     replicas: 3 -> 0
  ? C1  [flip-number on config.json]     "replicas": 3, -> "replicas": 10,

This is a question list, not a bug list. Some survivors are legitimate.
    (exit 3)
```

**退出码 3。**所以它可以进流水线，也可以在你想看报告的时候不进。

## 九、不装的部分

工具自己把这句话打在输出里：**「这是一份问题清单，不是缺陷清单。」**

有些变异在语义上本来就是合法的，检查放行它们是对的。precheck 分不出哪些是哪种——它不知道你的检查是为什么存在的。所以它不给「你有 2 个 bug」这种数字。**把活下来的变异数当缺陷数，是这类工具最常见的一种谎。**

它也不判断你的检查写得对不对。它只回答一个更窄的问题：**这个检查，有没有可能失败过一次。**

第六节那个缺口也照这个标准写在这儿：**这份链能证明「账本和声明没被改过」，不能证明「检查的实现没被改过」。**区别在你要用它来防谁——防的是你自己三个月后偷偷放宽标准，它够用；防的是一个能写文件的外部程序，它不够，得先把检查脚本本身也拉进链里。

## 十、怎么拿

```bash
pip install precheck
```

零依赖，Python 3.8+，只用标准库，不联网，不用改你现有的 CI 配置。

- 工具仓库：https://github.com/simin-yuan/precheck
- 全部作品：https://github.com/simin-yuan/reproducible-evidence

如果你能构造出一个「检查通过、同时又能被证明它没有分辨力」的场景，而 precheck 的变异审计没能指出来——我很想看那个例子。**第六节那个就是我自己找出来的一个，它现在开着。**

---

（本文的工具、实验与文字由人与 AI 协作产出；上面每一段输出都是本机实跑后原样粘贴，第四至七节的篡改实验在 2026-09-27 重跑。）


今天你手上只有两个选择：信它，或者自己重读每一行 diff。在把「检查通过」当成证据之前，有两个问题值得先问。

我伪造了四种证据篡改，工具抓到了三种；第四种它说「链一致」

agent 说做完了、检查也通过——先问那个检查有没有可能失败。precheck 把验收检查在开工前冻结、通过后再变异。这次我拿四种篡改去撞它：改账本、删条目、跳序号全被抓到；第四种（冻结后把检查脚本换成永远通过的版本）它报了「链一致」。附完整原始输出与最小修法。

创始人｜腾讯云同盟架构师

开发工具

安全

区块链

precheck通过哈希冻结与变异审计双重机制，验证检查命令是否真正具备判断力，防止“检查通过”沦为形式证据。篡改实验显示链可锁定声明文本，但检查脚本本身不在链上，存在被替换风险。补全检查逻辑后，变异存活从2降至1，问题定位更精准。支持--strict退出码3，便于CI集成。

代码解释

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我伪造了四种证据篡改，工具抓到了三种；第四种它说「链一致」-腾讯云开发者社区-腾讯云

我伪造了四种证据篡改，工具抓到了三种；第四种它说「链一致」

我伪造了四种证据篡改，工具抓到了三种；第四种它说「链一致」

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐