# AI 互相查错之后：如何把第二意见变成可追溯的工作制度

> 从 Cloudflare security-audit skill 与一次网站部署流程的来源核查，讨论如何保存证据、分离核查与授权，并让下一位协作者接得上工作。独立复核与格式验证各有边界，未解问题需要被明确留下。

- Author: Paul Kuo（郭曜郎）
- Date: 2026-10-03
- Pillar: 智能与秩序 / Intelligence & Order
- Tags: AI 治理, 第二意见, 可追溯性, 人机协作, Cloudflare, 安全审查
- Canonical: https://paulkuo.tw/zh-cn/articles/ai-evidence-review-workflow/
- Language: Simplified Chinese (简体中文)
- Translation: AI-translated from the zh-Hant (Traditional Chinese) original
- Original (zh-Hant): https://paulkuo.tw/articles/ai-evidence-review-workflow.md
- Site index for LLMs: https://paulkuo.tw/llms.txt

---

检查网站部署流程时，一段共用工具让人怀疑：数据缺失，防护就会跳过。往上追到正式入口，才看到调用方早已挡下这种情况。这个候选因此被推翻。

这次我请 Codex 先固定同一个代码版本，只读来源。若只留下最后的摘要，把反证省略，下一次审查就可能再追一次同一条线。

> 核查要留下结论的依据，也要留下推翻它的理由。尚未回答的问题，则需要有名字、来源与下一步。

## 第二意见之后，还有一段工作

我在[〈我让 codex 挑 Claude 的错，但不照它说了算〉](https://paulkuo.tw/zh-cn/articles/ai-second-opinion-independence/)写过如何保护第二意见的独立性：提问保持中性，原始报告留下来，审查者只指出问题，由掌握完整上下文的人决定是否采用。

那次经验也有一个限制。机器可以挡住完全空白的审查输出，但一段有字的报告，是否真的完成了实质审查，仍需要人判断。

工作一多，这个问题会延伸到交接。几天后换一个窗口，接手的人知道哪个结论已经核对过吗？代码改版之后，旧证据还适用吗？一条被推翻的意见，有没有留下理由，还是只从最后摘要里消失了？

我希望第二意见能被下一次工作接续使用。这需要比聊天摘要更明确的记录。

## Cloudflare 如何保存未解问题

Cloudflare 公开的 [security-audit skill](https://github.com/cloudflare/security-audit-skill) 提供了一个参照。它安排不同代理发现与复核候选，要求验证者寻找反证，并把结果分成已确认、需要验证与已推翻。核查范围另有台账，不让一份结果报告代替整体覆盖情况。

本文参照 Cloudflare 官方文章 [Build your own vulnerability harness](https://blog.cloudflare.com/build-your-own-vulnerability-harness/)、公开的 security-audit skill 及其验证规则，把证据、反证与待查事实的划分方式，用在作者自己的工作记录上。

我想借用的是它对「需要验证」的处理。这个状态要指出尚未解决的确切事实，不给漏洞严重度，也不能因为线索看起来有说服力，就被写成已确认。

例如，有些判断需要知道实际部署配置，有些需要在受限环境中运行最小测试。只读代码时看不到的事实，应该在记录里保持可见。

同一套分法也能用在我的日常工作：线索、待查事实与已被推翻的判断，分开记录。会议中提过合作方向，仍要回到原始消息，确认谁有权承诺；文件中有一个数字，仍要核对版本与适用日期。AI 可以先整理线索，再把需要人的地方写清楚。

## 机器检查能证明到哪里

Cloudflare 的[验证规则](https://github.com/cloudflare/security-audit-skill/blob/main/skills/security-audit/VALIDATION-AND-REPORTING.md)明确限定：验证器成功，证明的是格式与台账一致性。它无法代替对漏洞事实的判断。

换一个新的代理复核，可以降低沿着原作者思路走的偏误，但不同代理仍可能有共同的盲点。多跑几轮，也不能直接换算成「找到了全部漏洞的多少比例」。Cloudflare 在[介绍其 harness 做法的文章](https://blog.cloudflare.com/build-your-own-vulnerability-harness/)里指出，没有涵盖所有真实漏洞的完整标注集，不能据此宣称召回率。

第一轮先保存固定版本与来源指纹，另一个代理回到同一份来源找反证。自制检查器核对记录之间的关联、行号范围与来源身份；这一轮没有运行目标程序。

能重查一份来源，与已经观察到程序行为，是不同层次的证据。报告必须让读者分得出来。

## 一条部署线索，如何走到修补验证

第二轮才进入受控本机重现。我们保留实际的部署入口、防护与基本功能检查（smoke）脚本，让 Git 使用真实的版本关系，将服务、网页响应与构建换成离线替身。由操作系统强制限制的沙箱，先通过拒绝网络与越界写入的测试，再运行案例。

这个部署流程一次更新两个部分：网站页面（Pages）与后端服务（Worker）。旧的联合部署入口，只从混合台账取最后一笔成功来源。若台账后面是 Pages 的旧来源记录，它就可能忽略 Worker 已使用的较新来源。

在隔离的离线环境里，我们让服务与构建都使用替身，重现了联合部署将模拟 Worker 换回旧来源，整个入口却仍记成功的情况。同一个旧来源单独部署 Worker，则被挡下。核查期间代码已有更新；固定更新后的来源重跑，仍得到同样结果。

这里的「台账后面」指文件中的排列位置，不能拿来代替真实部署的时间顺序。

这个结果支持修正版本比对逻辑，还不能支持「正式环境已出过事故」。本次只验证这条版本回退路径，没有完成安全漏洞判定，也未评定严重度。假服务没有运行真正的 Worker，实际功能有没有受影响、过去台账是否真的出现这种排列，仍是另外两个问题。

第三轮由我同意后，Codex 才在隔离副本修补部署入口。联合部署改为分别核查 Pages 与 Worker 的上次成功来源，共用防护检查保持原样。新增的测试先在旧代码上抓到问题，再确认修补后会挡下；六个完整入口案例中，四个回退情境都在任何服务部署调用前被拦下，两个正常更新则完成检查与成功记账。

独立复核代理接受这个限定范围的修补，也指出错误消息没有随部署目标切换，我们补上修正与对照测试。这次交付到可审查的补丁和本机验证。在 2026-10-03 这次隔离验证结束时，补丁留在隔离副本，尚未合并与正式部署；本文保留当时的验证边界，不追踪后续部署状态。「核查通过」「修补验证通过」与「正式环境已更新」，需要分开记录。

## 把证据与行动授权分开

对我这种跨项目使用 AI 的工作方式，我把下一次交接希望能查回的内容，整理成六栏：

| 栏位 | 要回答的问题 |
|---|---|
| 主张 | 这次究竟在判断什么？ |
| 来源与版本 | 根据哪份代码、文件或原始消息？ |
| 证据状态与理由 | 已核对、待查，还是被推翻？依据或反证是什么？ |
| 未解事实 | 现在还缺哪个具体答案？ |
| 责任人与下一步 | 谁能补上证据，怎么补？ |
| 行动授权 | 谁同意哪些操作？授权的原始记录在哪里？ |

用这次的部署线索填进去，大致会是这样。这是 2026-10-03 隔离验证结束时的记录，不代表现在的进度：

| 栏位 | 本次部署案例（2026-10-03 当时记录） |
|---|---|
| 主张 | 联合部署可能漏掉 Worker 已使用的较新来源，让后端回到旧版本。 |
| 来源与版本 | 固定版本的部署入口、对应的离线测试记录，以及另外保存的隔离补丁。 |
| 证据状态与理由 | 离线路径已重现。联合部署回退且记成功，同条件单独部署被挡；修补后六个入口案例得到预期结果。 |
| 未解事实 | 正式环境是否曾出现相同台账排列与来源条件，真实 Worker 功能是否受影响，均未验证。 |
| 责任人与下一步 | 当时的下一步：我决定后续范围与承办者，再核对主分支版本，评估补丁是否合并及正式部署。 |
| 行动授权 | 当时已同意隔离修补与本机验证，授权可回查原始对话；补丁的合并及正式部署当时另行决定。 |

最后一栏尤其需要独立。查证一项事实，并不会同时取得修改、发送或发布的权限。几个模型一致，也不会替合作对象做出承诺。

部署核查同样如此。发现一个问题后，修补方案、代码变更与正式部署，各有不同的验收与责任。把它们全部包进「已完成」，下一位接手的人就得重新猜一次。

这份记录也适合接到会议与邮件整理。重要期限附上原始消息，合作承诺留下确认者，部分读取失败则如实标记。数据获取失败与没有符合条件的消息，不能共用同一句「没有事项」。

## 从能维护的范围开始

我先选网站部署流程做试行，没有把每份日常摘要都送进多轮审查。第一轮先把本机子代理调用的规划上限定为三次；这限制的是调用次数，并非 token 或账单。来源阅读与后续本机运行各自记录范围，才能回头判断增加一个代理解决了什么问题。

被推翻的候选需要留存，让下一次核查能先读过反证，再判断是否值得重查。尚未验证的线索也要留下，指出工作还欠哪一步。这些记录提供安排测试的依据；是否让人更省时，仍需要后续比较。

下一轮，我会看这套记录是否让复核更省时、交接是否少了重复查找。第一次试行还没有可比基线，不能先写下节省比例。

我想保留下来的判断位置，很具体：下一次看到「已完成」，能沿着证据查回去，也知道还有哪一步没有完成。

## 原始来源

- [Build your own vulnerability harness](https://blog.cloudflare.com/build-your-own-vulnerability-harness/)，Dan Jones、Alexandra Godoi、Grant Bourzikas，2026-06-18：说明从 skill 发展到跨 repo 内部 harness 的设计与局限。
- [cloudflare/security-audit-skill](https://github.com/cloudflare/security-audit-skill)：支持六阶段单 repo 起点、独立证伪、confirmed／needs_validation／rejected 三种状态与 coverage ledger。
- [VALIDATION-AND-REPORTING.md](https://github.com/cloudflare/security-audit-skill/blob/main/skills/security-audit/VALIDATION-AND-REPORTING.md)：支持格式与记录一致，不等于漏洞事实成立。

本文的部署案例来自作者 2026-10-03 的固定来源核查、离线复现与隔离修补记录，只支持文中限定的本机结果。