AI 生成的代码，凭什么说它"可靠"？｜5 个陷阱 + 一张自检清单

TL;DR（结论先行）

复制代码

可靠 ≠ 看起来对
「跳过 / 未接线 / 待复核 / 前置缺失」 一律不得计为 「通过」
数字必注取值时点（转引须复取）
引用用「内容锚」，不用「行号锚」
新写的检查，必须先用反例打穿一次

一句话 ：一段代码"可靠"的程度 = 关于它的每一条说法能被独立核验的程度。

下面 5 个陷阱是我们实打实踩过的，每个都附可落地的改法。

陷阱 1 · 全打勾的自检清单

现象：AI 交付附清单，六项全打勾 ⇒ 看着最有据。

问题：这份清单是谁写的？------ 它写的，也是它勾的。

自己给自己打勾的清单不是检查，是陈述。

改法（可落地） ：清单每一项必须落到一个别人能照着跑的动作。

yaml 复制代码

# ❌ 不合格
- 已核对数据格式

# ✅ 合格：每项都是可复跑的动作
- id: check-schema
  cmd: python3 -c "import yaml;yaml.safe_load(open('schemas/x.yaml'))"
  expect_rc: 0

判据：不能落地的项，不该出现在清单里。

陷阱 2 · 假通过：把「跳过」算成「通过」⭐ 最要命

现象：检查跑起来是绿的。

问题：绿灯可能来自三种完全不同的原因：

复制代码

① 检查了，通过
② 检查了，不通过
③ 没检查（跳过 / 未接线 / 前置缺失）  ← 被算成了 ①

我们真实遇到两次：

一条应该检查 5 项 的断言，说明文字写着"5 项"，但第 5 项的检查代码因一个标识没对上，根本没执行 ⇒ 嘴上 5 项、实际 4 项、结果是"通过"。
另一个脚本在前置条件缺失 时返回了一个"看起来是 0"的码，被上层当作通过记下。

改法（可落地） ：判定必须三态 ，且跳过不得收敛为通过。

bash 复制代码

# 三态判定（示意）
if [ "$PRE" != "ok" ]; then
  echo "SKIP: 前置缺失 ⇒ 不计为 PASS"; exit 3   # 3 = 显式跳过（≠0）
fi
... || { echo "FAIL"; exit 1; }
echo "PASS"; exit 0

ini 复制代码

# 门禁默认语义（铁律）：这些一律不得计为 PASS
SKIP / 未接线 / UNDER_REVIEW / rc=3

一个只会报假通过的检查，比没有检查更糟 ------ 它让人开始信任一个不该信任的东西。

陷阱 3 · 过期的数字 & 漂移的锚

现象 A（过期数字） ：报告写"某清单 169 项 "，复核重取 ⇒ 现盘 177 项 。出处是三个月前 的文档，转引未复取。

现象 B（漂移的锚） ：报告写"某文件第 38 行 有问题"，复核时该文件已升版，第 38 行现在是另一段注释。

关键区别：

锚类型	位置变了	内容变了
行号锚	❌ 静默指错	❌ 静默指错
内容锚	✅ 仍能定位	✅ 找不到（可发现）

改法（可落地） ：

引用写成 内容锚＋行号（仅参考） ；
所有数字注取值时点 ，格式：值（时点）；
转引他人材料 ⇒ 重取一次 ，不重取就标 转引（源时点）。

xml 复制代码

<!-- ❌ --> 某件第 38 行有 bug
<!-- ✅ --> 某件「空产物直接返回 0」（参考 :38 · 时点 2026-10-13）有 bug

陷阱 4 · 不可回访的出处

现象：出处栏写「标题 · 日期 · 权威级别」------看着挺全，但打不开、对不上、验不了。

它长得像证据，实际上是转述。

改法（可落地） ：每条出处必须带四件（缺一不可）：

json 复制代码

{
  "source_url": "https://...",     // ① 能打开的原始链接
  "fetched_at": "2026-10-15T00:13:13Z",  // ② 抓取时间（ISO 8601）
  "sha256":   "ec23fb58...",         // ③ 落盘文件指纹（改写即断链）
  "authority": "L1"                // ④ L1/L2/L3 分级；低级别不得单独支撑结论
}

顺带一个我们自己的翻车记录（很值得引以为戒）：

加了链接后我们宣称"24/24 可回访 "，结果抽验 6 条报了 2 条连不上。人工回访的结论是：

1 条是我们的探针方法错了 ------ 用了 HEAD 请求，而那站点拒绝 HEAD；
1 条 URL 真实存在 ------ 只是站点 TLS 实现过时 （不支持安全重协商，现代客户端一律握不上手），不是编造，是客户端受限。

⇒ 可达性探针规范（可直接抄） ：

perl 复制代码

# ✅ 必须用 GET，禁用 HEAD（部分站点拒 HEAD ⇒ 会把可达误判为不可达）
curl -sLk -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" \
     --max-time 15 -o /dev/null -w "%{http_code}" "$URL"

# 判定分档：
#   200 / 301 / 302                    ⇒ 可达
#   403 / 404                          ⇒ 站点拒绝 / 路径不存在（须区分记明）
#   TLS 握手失败（如 unsafe legacy renegotiation disabled）
#                                      ⇒ 单列「真实存在 · 客户端受限」
#                                        不计为「不可达」、不计为「编造」
#   000 且 DNS/TCP 均通                 ⇒ 落上档

口径纪律 ： "形式可回访"（每条有 URL＋时间＋指纹）与"实测可达"（实发请求）必须分开陈述，且失败样本摆在明面上。

陷阱 5 · 检查自己没被验证过

这条最反直觉 ：我们用检查去保证别人可靠，那检查自己可靠吗？

我们后来定了一个动作 ------ 新写的检查，必须先用反例打穿一次。

举例：写了一条静态检查，用来发现「代码里用了没导入的名字」这类错误（编译期查不出，只在运行到那行时才爆）。

python 复制代码

# 怎么证明这条检查有用？故意塞一个不存在的名字：
def some_func(argv):
    _zz_never_imported.name      # ← 反例注入

bash 复制代码

$ python3 scripts/chk-py-names.py
FAIL ① bin/v8:203 未可见名 `_zz_never_imported`（NameError 风险）

它当场报出来了 ⇒ 我们才敢把它挂到流程上。

不做这一步的检查，就只是"自认为在检查"。

另一个反向教训 ：同一条检查的第一版误报了 3 处假失败 （名字匹配规则写得太严）------ 同样得靠人去核对才发现。 一个只会报假错的检查，会让人开始忽略它，比没有更糟。

归纳：把"可靠"工程化的三层

层	做什么	落到什么
证据	说法要能锚定	哈希指纹 · 链接＋抓取时间 · 数字注时点 · 内容锚
判据	约束要能机器判，且能被打穿	三态判定（跳过≠通过）· 反例验证
责任	放行要人拍，且留理由	批准带理由，不填不算

三样缺一，"可靠"都会退化成形容词。

附 · 可靠性自检 8 问（可复制到你的 checklist）

css 复制代码

- [ ] 1. 这个说法从哪来？
- [ ] 2. 能打开验证吗？
- [ ] 3. 是什么时候的事实？（数字注时点）
- [ ] 4. 引用靠位置还是靠内容？
- [ ] 5. "检查通过"真跑了吗？
- [ ] 6. 有没有"跳过被算成通过"？
- [ ] 7. 这条检查自己被打穿过吗？
- [ ] 8. 谁拍的板？理由在哪？

8 问里有 2 条答不上 ⇒ 这段产出不该被当作"已核实"。

结论

AI 生成的代码，不因为"看起来对"而可靠，也不因为"模型很强"而可靠。 它因为"关于它的每一条说法，你都还能独立核验一遍"而可靠。

AI 让"产出"变得极其便宜，于是"核验"成了唯一的瓶颈。