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

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

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

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

我在〈我让 codex 挑 Claude 的错，但不照它说了算〉写过如何保护第二意见的独立性：提问保持中性，原始报告留下来，审查者只指出问题，由掌握完整上下文的人决定是否采用。

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

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

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

Cloudflare 如何保存未解问题

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

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

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

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

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

机器检查能证明到哪里

Cloudflare 的验证规则明确限定：验证器成功，证明的是格式与台账一致性。它无法代替对漏洞事实的判断。

换一个新的代理复核，可以降低沿着原作者思路走的偏误，但不同代理仍可能有共同的盲点。多跑几轮，也不能直接换算成「找到了全部漏洞的多少比例」。Cloudflare 在介绍其 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 或账单。来源阅读与后续本机运行各自记录范围，才能回头判断增加一个代理解决了什么问题。

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

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

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

原始来源

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