# CI 全绿，门禁却可能一次都没拦过：用变异测试给质量门禁做体检

## 先看一段真实输出

四个规则文件：三份 JSON Schema（`jsonschema`、`check-jsonschema`、`ajv`），一份 LLM 输出护栏（`guardrails-ai`）。每个都按时序改三次：

1. 规则文件原样 + 合法输入 → 应该放行
2. 规则文件原样 + 违规输入（`"timeout": "30"`，要求整数的地方给了字符串）→ 应该拒绝
3. 规则文件**删掉一行**（比如 `"type": "integer"`）+ 同一份违规输入 → ？

前两步所有工具都过。第三步：

```
[1] 原样 + 合法数据          exit 0
[2] 原样 + 违规数据          exit 1   30: '30' is not of type 'integer'
[3] 删一行 + 同一份违规数据   exit 0   (什么都没有)
```

`ajv` 是三个 JSON Schema 工具里唯一"知道"的——它在 stderr 上打了 `missing type "number" for keyword "maximum"`。那行警告没人看，退出码是 0。CI 只认退出码。

到 LLM 护栏那层，删掉一条规则（`no-competitor-mention;`）之后跑一句带竞品名的回答：

```
PASS (every rule in rail.xml accepted this answer)
    -> exit 0
```

另外四条规则照常生效，护栏没坏。**它只是窄了一条规则，从外面看不出来。**没有报错，没有警告，退出码没变——那条规则不是失效了，是停止了存在。

四个目标各跑 67～109 个变异，结果如下（全部在 2026-09-17 本机重跑复现）：

| 门禁 | 变异数 | 拦住 | 漏过 | 漏过里真正把门禁卸掉的 |
| --- | --- | --- | --- | --- |
| jsonschema | 67 | 47 | 20 | **2** |
| check-jsonschema | 68 | 52 | 16 | **2** |
| ajv | 68 | 52 | 16 | **2** |
| guardrails-ai | 109 | 83 | 26 | **3** |

## 为什么这件事比听起来严重

没有人会在被 review 的改动里偷偷删掉 schema 的一行。大家是在赶时间的时候删的，而这两种情况 CI 都是绿的。

绿灯的含义有两个，你分不出来是哪一个：代码是干净的，或者那条检查根本没跑。

这也解释了为什么"给项目加更多检查"不解决问题。检查越多，越没人知道哪一条还在工作。

## gatecheck：把体检变成一条命令

```bash
git clone https://github.com/simin-yuan/self-auditing-agent
cd self-auditing-agent

python gatecheck/gatecheck.py \
  --gate "python examples/gate.py {target}" \
  --target examples/service-config
```

它只要两样东西：

- 一条门禁命令——任何"非零退出 = 拒绝"的东西
- 一份合法输入——现在确实能通过这条门禁的基线

然后它把基线变异成 N 个变体，**每个变体单独再撞一次门禁**，报告哪些拦住了、哪些没反应。

本机真实输出：

```
baseline  : exit 0   ✅ passes
      ★  drop-line:schema.json:16:"type": "integer",
      ★  drop-line:schema.json:21:"minimum": 0,
      ...
结论：门禁对 19/56 个变异无反应 —— 它有可见盲区。
```

56 个变异拦住 37 个。其中被删掉的 `"type": "integer"`，就是前面演示里漏掉的那一条。

零依赖，只用 Python 标准库。理由很实在：一个需要你先装一堆东西的质量工具，进不了任何人的关键路径。

### 七个变异算子

| 算子 | 做什么 |
| --- | --- |
| `drop-file` | 删掉整个文件 |
| `empty-file` | 清空文件 |
| `drop-section` | 删掉一个 markdown 小节 / 配置块 |
| `drop-line` | 一次删一行 |
| `blank-value` | 保留 `key: value`，把值清空 |
| `break-reference` | 改标识符的一个字符，制造悬空引用 |
| `dup-id` | 复制一个 id，制造重复定义 |

退出码：`0` = 全部拦住；`1` = 有漏过的，全部写进 `--report`。可以直接进 CI。

## 更有信息量的用法：拿它撞自己

工具是通用件。真正值得看的是拿它去撞**写它的那套门禁**——25 类规则校验器，175 个变异：

```bash
python gatecheck/gatecheck.py \
  --gate "python repro/validate_meta_model.py {target} --source repro/fixtures/valid-source" \
  --target repro/fixtures/valid-meta-model \
  --report gatecheck-self-report.json
```

本机重跑：

```
结论：门禁对 78/175 个变异无反应 —— 它有可见盲区。
```

175 个变异漏过 78 个（44%）。这个数字工具会给，再往下就没人能替你了：78 个漏过里多数在语义上是合法的——删掉 `- 略` 这种占位内容、复制一个 H1 标题（标题本来就不是 ID，不构成冲突）。逐条复查后，**真的该拦而没拦的有 4 类**。

### 第一类：触发条件由被检方自己提供

原规则是条件式的：

> **如果**一个功能声明自己是 `non-interactive` / `hybrid`，**那么**它必须登记进非菜单功能索引。

绕过它最省事的办法，不是去补登记——是把 `non-interactive` 这四个字删掉。前件不成立，后件自然不被要求，门禁全程绿灯。

> 一个只在你自认有罪时才生效的检查，等于没有检查。

现实里的形态是：一个后台定时任务，只要在功能清单里不写交互类型，就能体面地不进任何登记册。修法方向是把"每个功能必须声明交互类型"变成无条件规则——**判据不应该由被检方决定自己适不适用**。

### 第二类：存在性检查冒充完整性检查

门禁检查 8 个小节标题在不在，不检查小节里有没有内容。标题底下全空，照样放行。

磁盘上有文件 ≠ 文件里有东西；有个字段 ≠ 字段被填了。这类缺陷在任何"按结构校验"的系统里都会出现。

### 第三类：单向引用检查

门禁查"被引用的 ID 有没有定义"，不查"定义的 ID 有没有人引用"。于是那些没有引用者的定义，改名、删除、写错，门禁都没有反应。

这一条有意思的地方在于：同一个项目里**有**一条针对行为的反向引用检查（`reference_index.py`），主校验器却没有。**同类规则的成熟度在不同文件里不一致**，而这类不一致靠人工 review 是查不出来的。

### 第四类：重复标题不可检测

标题不是 ID，所以"同一个标题出现两次"没有任何规则覆盖。这一轮无害，但任何靠标题做锚点的下游工具都会指错段。

## 它不给你判决，它给你清单

工具跑完会打印一句：并非每个漏过都等于缺陷。

上面四份规则文件的例子里，工具报的漏过是 20 / 16 / 16 / 26，逐条复查后真正把门禁卸掉的只有 2 / 2 / 2 / 3。**直接发一句"发现 20 个盲区"，就高估了大约 9 倍。**而一个会撒谎的工具，你第二次就不会再信它。

所以默认行为是"只报告"：CI 里 `min-rejected-pct` 留空，跑完只写报告、不拦流水线。要不要因为漏过而失败，是你的判断。

同一份文档里还记了一个反例，因为它在反对整齐的故事：把 RAIL 里的 `on-fail-<rule>="exception"` 删掉，在 guardrails-ai 0.11.0 里**不会**静默降级——四条规则仍然照常触发并拒绝，门禁会回落到 abort。26 个漏过里有 4 个看起来触目惊心，实际代价为零。

## 顺手撞出来的两个坑

**一、schema 里的拼写错误是静默的。** 把 `required` 拼成 `requird`，`check-jsonschema` 对一份缺必填字段的数据返回 exit 0，还打印 `ok -- validation done`。它什么都没验，并告诉你验完了。`ajv` 在 strict 模式下会拒绝（`unknown keyword: "requird"`），这是正确的行为。

**二、`--check-metaschema` 与 `--schemafile` 互斥。** 所以唯一能抓到上面那个拼写错误的开关，没法跟它要保护的那步校验放进同一个 CI 步骤里。

## 放进 CI

```yaml
- uses: simin-yuan/self-auditing-agent@main
  with:
    gate: "python validate.py {target}"
    target: ./my-data
    report: gatecheck-report.json
    # min-rejected-pct: 90   # 留空 = 只报告；填了才会因为盲区而失败
```

这个 action 会先检查基线输入确实能通过门禁。基线都不通过的话，这一次跑什么都证明不了，直接报错退出。剩下的漏过只出 warning，不拦你。

## 另一半：门禁得会说是，也得会说不

只报错从不放行的检查，和只放行从不报错的检查一样没用。仓库里另有一个脚本专门验这个：

```
[1/2] 故意违规的输入 —— 门禁必须说不
      退出码=1  ERROR=76  WARNING=0  命中规则类别=19      ✅
[2/2] 合法的最小输入 —— 门禁必须说是（不误杀）
      退出码=0  ERROR=0  WARNING=0                      ✅

门禁能说不、也能说是 —— 两条对称证据都在，主张成立。
（注意：这仍不等于"门禁正确"。它只等于"在这两组输入下行为正确"。）
```

那个括号比结论更重要：两条对称证据只证明它在这两组输入下行为正确，不证明门禁正确。

## 最后：这 4 类缺陷一个都还没修

仓库里那份体检报告写明了自己是**诊断**，不是**修复记录**。修完要单独出一卷，并且必须附上"重跑 gatecheck，漏过从 78 降到多少"的对比。同时列出的欠账还有两条：这一轮基线是构造出来的最小合法输入，只证明门禁不误杀最小输入，**不能证明门禁能验收真实项目**；变异算子只有 7 个，没做值级别、类型级别、跨文件语义变异。

把欠账写成欠账、而不是免责声明，这一点我觉得比工具本身更值得抄。

---

**仓库**：`github.com/simin-yuan/self-auditing-agent`（MIT，零依赖）

**复现**：文中每个数字都在 2026-09-17 于本机重跑过，命令原样贴在文中；`docs/USAGE-EXAMPLES.md` 与 `docs/BLIND-SPOTS.md` 是完整的原始输出与逐条复查结论。

**说明**：项目与本文由 AI 协作者（时晴）完成，人类账号发布并审计——那份体检报告查的就是它自己的门禁。


四个规则文件：三份 JSON Schema（jsonschema、check-jsonschema、ajv），一份 LLM 输出护栏（guardrails-ai）。每个都按时序改三次：

CI 全绿，门禁却可能一次都没拦过：用变异测试给质量门禁做体检

给质量门禁做一次变异测试：把合法输入变异成上百个变体逐个撞门禁，看它拦不拦。四个真实规则文件的实测结果，加上一次「拿工具撞自己门禁」的体检报告——175 个变异漏过 78 个，其中 4 类是真缺陷，最狠的一条是「删掉四个字就能绕过全部检查」。零依赖，可进 CI。

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

测试

运维

开发工具

CI全绿可能只是假象：变异测试揭示质量门禁存在44%盲区，即使规则文件被删改仍返回退出码0。gatecheck工具用零依赖Python实现，通过7种变异算子自动检测门禁失效，发现四类隐藏缺陷：条件触发可被绕过、存在性检查冒充完整性、单向引用漏洞、重复标题不可检测。工具默认只报告不拦截，附完整复现数据与门禁自检案例。

代码解释

Python

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

CI 全绿，门禁却可能一次都没拦过：用变异测试给质量门禁做体检-腾讯云开发者社区-腾讯云

CI 全绿，门禁却可能一次都没拦过：用变异测试给质量门禁做体检

CI 全绿，门禁却可能一次都没拦过：用变异测试给质量门禁做体检

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐