AI研发机检三闸与证据语料库方法论
> 编制：万有AI产品团队
> 定位：万有AI通用方法论系列 | 工程治理的执行层——规范负责说，门禁负责拦
> 依据：万有AI HARNESS 工程专项方案（A案三闸+B案证据语料库）与线上部署门禁的实际运行记录
> 一句话：不能自动判定的规范是倡议，能自动拦截的规范才是制度
一、三个必然失效的环节
任何研发团队都会在这三个地方失守，区别只在有没有防线：
| 失效环节 | 典型场景 | 后果 |
|---|---|---|
| 提交时 | 密钥、危险删除命令、违规用语随手写进文件 | 一提交就进历史，删不干净 |
| 发布时 | 脚本漏跑一步、旧版本镜像没换 | 线上半个新半个旧 |
| 上线后 | 静态文件被绕过部署链单独改动 | 声明与实际不一致 |
机检三闸的本质，就是把这三处从「靠人记得」改成「机器不让过」。
二、四道闸的分工
| 闸位 | 名称 | 触发时机 | 判据来源 | 失败处理 |
|---|---|---|---|---|
| 闸1 | 提交快扫 | 每次提交前 | 受控词表（敏感信息/合规用语/受保护技术词/危险删除形态） | 拒绝提交 |
| 闸2 | 发布门禁 | 部署脚本第一步 | 清单制机检项（环境/版本/资产/配置一致性） | 未通过则退出，不进入部署 |
| 闸2.5 | 入库快照断言 | 部署前 | 暂存区内容扫描 + 历史提交检索双断言 | 命中则逐处定性 |
| 闸3 | 公网断言 | 部署末步 | 三通道实测响应 + 关键内容比对 | 重试三次后转人工，不自动回滚 |
设计要点：闸越靠前越便宜。同一个问题在提交时拦下，成本是一次改文件；到了公网才发现，成本是一次事故复盘加一次返工。
三、闸1：提交快扫的四条硬约束
| 约束 | 要求 | 为什么 |
|---|---|---|
| 只看暂存区 | 只扫本次要提交的文件 | 全量扫描会拖慢提交，最终没人愿意用 |
| 时限 | 单次十秒内 | 慢的门禁等于没有门禁 |
| 词表单点 | 全团队共享一份受控词表 | 多份词表必然漂移，漂移就没法追责 |
| 留痕克制 | 日志只记时间、结果、文件名 | 记内容片段等于二次泄露 |
词表定位要能跨仓工作：钩子放在代码仓，词表放在治理仓，钩子必须能自动回退到治理仓取词表——否则「钩子在、词表不在」，检查会悄悄变成空转。缺词表时必须显式告警（禁止静默跳过），并把告警写进日志供日报汇总。
四、闸2与闸3：部署的两道保险
4.1 闸2 清单制发布门禁
| 要素 | 做法 |
|---|---|
| 脚本清单 | 活跃部署脚本逐条登记，清单外脚本迁出活动目录 |
| 首步检查 | 任何部署脚本第一步先过门禁，未通过即退出 |
| 属主分流 | 站点自带资产直接部署；系统属主资产必须显式声明提权理由 |
| 备份先行 | 覆盖前先备份，并做校验和比对 |
| 路径守卫 | 显式拒绝路径穿越形态 |
属主分流这一条尤其重要：部署脚本不能「一刀切提权」。凡是需要更高权限的写入，必须在部署输出里逐件打出原因，让审计者一眼看清哪件资产、为什么、动了什么。
4.2 闸2.5 入库快照断言
它补的是一个容易漏的盲区：首提交不走常规提交路径，钩子根本没机会触发；同时门禁只扫活跃面。所以要在部署前做双断言：扫暂存区内容 + 检索历史提交记录。命中后逐处定性——真实泄露则脱敏重建，误报则登记豁免。
4.3 闸3 公网断言
| 检查 | 判据 |
|---|---|
| 三通道可达 | 页面/接口/静态文件各自实测状态码与体积 |
| 内容比对 | 关键字符串必须与源件一致 |
| 假阴性防护 | 断言不能自证：期望值写死字面量，实际值取自真实测量 |
| 失败策略 | 重试三次仍失败转人工，不自动回滚 |
最后一条「不自动回滚」是故意保守的选择：自动回滚在多数真实事故里会掩盖根因，把一个可诊断的故障变成两个不可诊断的故障。
五、证据语料库：让每次事故只交一次学费
门禁解决「不再犯同一个形态」，语料库解决「不再犯同一类判断」。它由四段组成：
| 段 | 内容 | 纪律 |
|---|---|---|
| 语料 schema | 单事故单文件 + 索引：事故锚点、关联条款号、陷阱编号、证据链接、脱敏标记、推翻标记 | 脱敏是开工前置，不是收尾动作 |
| 存量回灌 | 历史报告与事故记录批量入册 | 被推翻的结论保留不删除，标推翻标记当反面教材 |
| 蒸馏 | 脚本产候选 → 条款责任方批准 → 机检模板 → 独立复跑 → 入住 | 优先扩充既有条款；新增须论证既有条款为何覆盖不了 |
| 按需检索 | 按任务类型注入相关条款，单次限量，只出脱敏后内容 | 注入过量会污染上下文，反而不如不给 |
「推翻标记保留」是这个语料库最反直觉、也最有价值的设计：工程知识里最有用的往往不是结论，而是「当初我们以为是那样，后来发现不是」的过程。
六、权责分离：谁能批准、谁能验收
| 角色 | 防线建设 | 验收权 | 批准权 |
|---|---|---|---|
| 研发执行方 | 开发与自测 | 无（不得自验） | 无 |
| 安全方 | 独立复跑与护栏验收 | 有 | 条款内容批准 |
| 产品方 | 交叉验收机检模板实现 | 有（非批准人自验） | 无 |
| 管理层 | 里程碑审批 | 终裁 | 里程碑节点 |
核心一句话：发现方不复验己方，实现方不批准内容。这是唯一能防住「自出题自判满分」的结构设计。
七、实施路径
| 阶段 | 交付 | 验收标志 |
|---|---|---|
| 一期 | 闸1上线 + 词表就位 + 清单制闸2 | 故意植入违例文件必被拦；日志可查；无门禁段脚本拒绝启动 |
| 二期 | 闸2.5快照断言 + 闸3公网断言 | 回滚演练通过；既有流程无回归 |
| 三期 | 语料库schema + 存量回灌 | 回灌率≥90%并抽样比对 |
| 四期 | 蒸馏流程 + 按需检索 | 蒸馏演示走通、检索命中、权责留痕 |
八、避坑指南
| 坑 | 表现 | 解法 |
|---|---|---|
| 门禁空膛 | 缺词表时静默通过 | 缺料必须告警并留痕 |
| 门禁变慢 | 全量扫描导致提交等待 | 只扫暂存区，时限十秒 |
| 词表分裂 | 各仓各维护一份 | 单点词表 + 跨仓回退定位 |
| 断言自证 | 期望值与实际值同源 | 期望写死，实际实测 |
| 自动回滚掩盖根因 | 一出错就回滚 | 重试后转人工诊断 |
| 验收自己 | 开发方复跑自己的门禁 | 独立复跑，发现方不复验己方 |
> 一句话收口：机检体系的成功标志不是「拦住了多少」，而是「每一次失败都有人看得见」。看不见的拦截，和没有拦截，对治理效果是等价的。
万有AI | 依据HARNESS工程专项方案与线上门禁运行记录萃取