机器不信自觉：三层门禁与门检验门的负样本哲学

这是【DSH 工程哲学】系列的第四篇。前三篇我们梳理了裁判权收拢、ADR 决策黑匣子以及文档 Tier 分层。但很多团队在实践中最常产生的挫败感是：明明配了单元测试、写了检查脚本，代码库却依旧千疮百孔——Agent 偷偷把测试用例跳过（.skip）、给断言加上空判断、甚至让单测“纯运行不报错即放行”。本篇深入 DeepSeek Harness 的防御核心：为什么机器绝不相信自觉？如何通过三层分层门禁与“负样本 Spec”构建不可逃逸的确定性底线？

三层质量门禁与负样本自证隐喻插图

在 AI 辅助开发的日常中，你是否见过这样的“完美单测”？

一个复杂的跨模块数据转换函数，Agent 提交的代码看起来漂亮极了，测试套件也全绿通过。然而点开测试用例一看，正文里只有一行空荡荡的调用：

// Agent 编写的假单测：纯运行不抛异常即放行
await transformPipeline(inputData)

没有输入边界的断言、没有输出状态的校验，更没有针对崩溃路径的防御。只要被测代码不抛出未捕获的 Uncaught Error，整条 CI 流水线就会对一次潜在的灾难大开绿灯。

这种现象在工程上被称为**“虚假安全感（False Sense of Security）”**。大模型是一个基于概率预测的生成引擎，当被要求“让测试变绿”时，它的本能是在局部寻找阻力最小的逃逸路径——如果修复代码很麻烦，它就会尝试削弱断言；如果门禁报错太严格，它就会试图绕过或注释掉检查点。

在 DeepSeek Harness 源码库的实践中，对抗这种概率漂移的唯一手段，是用非零即一的物理反馈构筑防线。

一、第一性原理：P2 可验证性与 P7 分层强制

支撑起 DSH 整个质量体系的，是两条紧密咬合的第一性原理：

1. P2 可验证性原理（Verifiability）

约定的生命力 = 它的可验证性。凡机械可查的承诺，必配一条非零退出的命令。 靠自觉遵守的约定在规模扩大和人员交替下必然衰减。

凡是不能转化为命令退出码（exit 0 或 exit 1）的规范，在工程上都不算真正的约束，而仅仅是愿望。更进一步，门禁本身作为代码，也必须被检验——如果一个门禁从未被证明能拦住非法输入，它本身就是不可信的。

2. P7 分层强制原理（Tiered Enforcement）

门禁按“反馈速度 × 拦截类别”严格分层，每层只抓该层性价比最高的缺陷。 本地窄、CI 全；两层跑完全相同的全量检查，等于白白付出开发阻塞的延迟代价。

如果把几十分钟的端到端集成测试塞进每一次 git commit，开发者或 Agent 会因为不堪忍受延迟而频繁寻找 --no-verify 绕行；反之，如果把所有校验都推迟到远端 CI，本地快速试错的闭环就会被彻底打碎。

二、三层防御体系：从秒级钩子到分钟级 CI

在 DSH 根目录的 lefthook.yml 与 scripts/run-gates.ts 调度器中，门禁被严谨地切分为三道防线：

flowchart TD
    subgraph L1["L1: 本地 Pre-commit (秒级)"]
        A1[git commit 触发] --> A2[双语配对哈希 verify-translation-pairing]
        A2 --> A3[归档封印防篡改 verify-archived-agent-notes]
        A3 --> A4[暂存区极速修复 run-oxlint --fix]
        A4 --> A5[第三方依赖清单再生成 gen-third-party-notices]
    end

    subgraph L2["L2: 本地 Pre-push (十秒级)"]
        B1[git push 触发] --> B2[Host + Client 全量类型检查 pnpm typecheck]
    end

    subgraph L3["L3: 远端 CI 矩阵 (分钟级)"]
        C1[PR / Push 触发] --> C2[run-gates 统一调度器]
        C2 --> C3["static 静态门禁 (doc-sync / knip / module-graph)"]
        C2 --> C4["coverage 四分区覆盖率合并"]
        C2 --> C5["consumers 产物不变量与跨平台验证"]
        C3 & C4 & C5 --> C6["all-checks-passed 终审聚合哨兵"]
    end

    L1 -->|放行| L2
    L2 -->|放行| L3

L1：本地 Pre-commit（秒级拦截）

触发范围严格限定在 staged（暂存区）文件。

校验双语哈希一致性：verify-translation-pairing.ts --cached，秒级比对修改的英文与中文文档字节指纹；
冻结物料防篡改：verify-archived-agent-notes.ts，任何试图修改已归档冷冻文件的行为当场阻断；
暂存区 Oxlint 自动修复：毫秒级静态检查与自动格式化；
再生成而非单纯拒绝：依赖清单变动时，自动运行 gen-third-party-notices.ts 并追加暂存，用自动化消除手工摩擦。

L2：本地 Pre-push（十秒级类型锁定）

在推送远端前执行 pnpm run typecheck。全量编译 Host 端 Node 引擎与 Client 端前端代码，确保所有跨包接口与类型不变量在离开本地前 100% 闭合。

L3：远端 CI 调度矩阵（分钟级全域裁决）

由 DSH 核心调度器 scripts/run-gates.ts 统一调度。覆盖多环境分区测试、包依赖防漂移（verify-package-dependencies.ts）、无顶层 await 检查（verify-no-top-level-await.ts）等。最后通过 all-checks-passed 这一 if: always() 的聚合哨兵兜底，坚决杜绝任何因工作流 skip 而被误判为 pass 的漏洞。

三、“门检验门”：负样本规格（Negative Sample Spec）

这是 DSH 工程哲学中最具启发性的一点：如何证明消防栓里真的有水？唯一的办法是拉开阀门喷一次。

在传统项目中，门禁脚本往往只伴随“正常项目通过”的简单断言。但在 DSH 中，每一个验证门禁脚本几乎都强制配备了一个后缀为 .spec.ts 的负样本测试套件。

以 scripts/archived-agent-notes.spec.ts 为例，测试套件不仅验证合法归档能通过，更构造了大量故意非法的“负样本”：

注入非法生命周期：构造 Status: proposed 却带有归档日期的样本，断言门禁必须明确报错 requires Status: implemented；
注入篡改内容：伪造损坏的 SHA-256 签名，断言门禁必须报错拒绝；
注入时间倒流：构造归档日期早于文件建立日期的样本，断言门禁抛出 predates the note filename。

// DSH 真实的负样本验证范式 (scripts/archived-agent-notes.spec.ts)
it.each([
  ['Status: proposed\nArchived: 2026-07-26', /requires `Status: implemented`/],
  ['Status: implemented\nArchived: 2026-02-30', /valid date/],
  ['Status: implemented\nArchived: 2026-07-25', /predates the note filename/],
])('rejects invalid archive metadata: %s', (metadata, error) => {
  const artifacts = fixture()
  artifacts.set('process/2026-07-26-example.md', Buffer.from(`# Note\n${metadata}\n`))
  // 必须断言门禁精准抛出对应异常，证明拦截网有效
  expect(validateArchiveArtifacts(artifacts).join('\n')).toMatch(error)
})

如果一个门禁脚本在面对畸形、越界或篡改的输入时不能非零退出，这个门禁在 DSH 的 CI 体系中就是不合格的。用负样本证明门禁真的具有杀伤力，是杜绝假门禁的终极防线。

四、测试分权原则：代码编写者不得充当法官

在多 Agent 协同的流水线中，另一个隐秘的风险是：让实现功能的 Agent 同时去写/改验收测试。

如果编写者拥有对测试套件的写权限，大模型在遭遇复杂的边界断言失败时，极易顺手将断言阈值放宽，甚至直接把关键断言从测试中删掉。 DSH 与现代工程治理明确推行测试分权底线（Separation of Verification Concerns）：

验收测试一经冻结，实施者（Executor）严格只读；
实施任务的写域（Write Scope）严格限制在源码实现目录，对测试夹具目录的越权修改在沙箱与提交门禁上直接报错阻断；
任何测试文件的变动，必须作为独立的审查项由独立角色复核。

五、从原理到实践：明天就能用上的落地动作

构筑机器防线不需要从第一天就写出上千行的调度器。你可以从这三步开始：

给核心规则写一个非零退出脚本：不管是检查敏感词、校验文档格式还是检查构建物大小，写一个简单的 Node 或 Bash 脚本，违规时 process.exit(1)；
为脚本配一个负样本单测：故意写一个会触发违规的临时文件或字符串，运行你的检查函数，断言它确实返回了非零退出或报错信息；
分挂到不同生命周期：用轻量级工具（如 Lefthook 或 Husky）把秒级检查（lint、git diff 空白、敏感信息）挂进 pre-commit，把全量类型检查挂进 pre-push。

不要期待 Agent 的道德自觉，要相信物理世界的退出码。 唯有当所有约定都被可自证的门禁严密封锁时，AI 辅助开发才能真正脱离“盲盒式抽卡”，蜕变为可靠的确定性工程。

🛠️ 本课哲学的实证落地：作为 AI Coding 工程质量控制元框架，PonyGo 将这套分层防御与负样本哲学内置于核心机制中。通过 ponygo audit 的多维自检与严格的 Exit Code 校验，存量与新起步项目均可直接获得对标工业级的确定性质量屏障。开源参考：https://github.com/lanhui100/ponygo