Harness Engineering 到 Trust Engineering

当 AI 写代码的速度超过你审核的速度

上一篇文章我们聊了 vibe coding——那种对着 AI 说出需求、看着代码如流水般涌出的畅快感。Claude Code、Cursor、Windsurf 这些工具已经把编程的"手速"提升到了前所未有的高度。但快感过后，一个实际问题浮现出来：AI 一天能产出过去一周的代码量，你真的能逐行看完吗？

这不是杞人忧天。传统的"逐行 code review"模式在 AI 时代客观上已经失效。不是你不认真，是人的阅读速度追不上生成速度。而比 review 更底层的困境是：当 AI 代理（Agent）开始自主调用工具、读写文件、执行命令时，你如何确保它的行为始终在你的意图边界之内？这正是 Harness（ Harness 指的是 AI 代理的运行时框架与约束机制，包括权限控制、工具调用审计、沙箱隔离、轨迹记录等）要解决的问题——它管的是"AI 能做什么"，但 Harness 本身并不回答"你怎么知道它做对了"。

问题于是变成：在无法看完每一行代码、也无法实时监督每一次工具调用的前提下，你如何确信系统是可靠的？

我已经是时不时开启bypass permissions的人了，但是测试的职业特性对我写的东西依旧无法信任。

信任工程：从"看代码"到"审证据"

这个问题有一个系统性的答案，叫做信任工程（Trust Engineering）。

但在讲它的架构之前，我们需要先回答一个更基础的问题：信任到底是怎么被建立的？

在日常协作中，你对同事的信任通常不是来自"我检查过他写的每一行代码"，而是来自几个更高效的信号：他过去交付的质量记录、他是否提供了清晰的变更说明、他的改动是否有测试覆盖、以及当出现问题时他是否能快速定位和修复。换句话说，信任建立在可验证的历史行为和可追溯的证据上，而不是实时的显微镜式审查。

这个原理放到 AI 身上同样成立。当你面对一个无法逐行审核的代码库时，真正让你安心的不是"我看过"，而是"有一套机制能持续生成有效数据来证明它是对的"。这里的"有效数据"指的是：独立于代码生成过程的测试报告、来自不同视角的验证结果、以及在故障注入下依然能报警的监控信号。审证据之所以有效，正是因为证据是多源、可复现、可审计的——它把"我相信"变成了"我可以验证"。

它的核心洞察很直接：AI 时代，建立信任的方式不该是"更努力地看代码"，而应该是"构建一套不需要看所有代码也能知道系统可靠的工程体系"。

信任工程把开发流程从"任务 -> 代码"升级为"声明 -> 证据"。具体来说，它通过六层架构来建立对 AI 产出物的信任：

第一层是承诺层。在写任何代码之前，先写一份 Change Contract（变更契约），明确三个东西：要做什么（intent）、哪些业务规则必须保持为真（invariants）、以及明确不在本次范围内的东西（non_goals）。这份契约不是给项目经理看的文档，而是后续所有验证的判定基准。

第二层是执行层。给 AI 设定清晰的权限边界：能读哪些目录、能改哪些文件、最多改多少文件、哪些操作绝对禁止。这让"即使 AI 犯了错，破坏也被限制在可控范围内"成为可能。

第三层是验证层。这是最关键的一层：测试不能只有一种来源。最大的风险是"自证闭环"——同一个 AI 按同一个理解写代码、写测试、判通过，全部绿灯，但需求理解本身错了。验证必须多源独立：从契约生成的业务测试、从代码结构生成的单元测试、主动寻找反例的对抗测试、以及来自历史故障的回归测试。

第四层是挑战层。测试全部通过只是弱证据。你还要证明：如果代码真的错了，这套测试有能力发现。手段包括变异测试（故意改坏代码看测试是否报错）、边界注入（空值、并发、权限中途变化等）、以及反复追问：如果这里有一个严重 bug，哪个测试会发现？

第五层是判定层。完成条件应该是确定性的规则，而不是问 AI"你完成了吗"。契约测试通过、回归测试通过、变异杀死率达到阈值、安全扫描无严重发现——这些条件满足，门才开。

第六层是证据层。最终交付的不是"代码 + 测试"，而是一个 Evidence Package（证据包）：声明了什么、变更了什么、每条不变量由什么证据支撑、哪些 mutation 被杀死、还有哪些残余风险未覆盖。人类审核的对象从代码变成了这份证据包。

BDD：让"承诺"成为可执行的代码

信任工程的承诺层听起来很好，但有一个实操问题：怎么确保契约不会被遗忘在文档里，而是真正驱动开发和验证？

行为驱动开发（BDD） 恰好回答了这个问题。

BDD 的核心理念是用自然语言描述业务行为，然后把这些描述转化为可执行的测试。它通常遵循这样的格式：

Feature: 订单取消
  作为已下单用户
  我想要取消尚未发货的订单
  以便在改变主意时挽回损失

  Scenario: 成功取消未发货订单
    Given 用户 A 有一个状态为"待发货"的订单
    When 用户 A 请求取消该订单
    Then 订单状态变为"已取消"
    And 库存恢复且只恢复一次

  Scenario: 已发货订单不可取消
    Given 用户 A 有一个状态为"已发货"的订单
    When 用户 A 请求取消该订单
    Then 系统返回错误"已发货订单无法取消"
    And 订单状态保持不变

这段自然语言描述，通过 BDD 框架（如 Cucumber、Behave、pytest-bdd）可以直接映射为自动化测试。这意味着：业务人员写的"承诺"，本身就是测试工程师运行的"用例"。

当信任工程的 Change Contract 遇上 BDD，契约就不再是静态文档，而是一套活的、可执行的验证体系。invariants 变成 Scenario，non_goals 变成明确的边界条件，intent 变成 Feature 描述。业务方、开发、测试三方在同一个语言体系里工作，误解的空间被大幅压缩。

两者结合：一个最小可行的工作流

你不需要一次性搭建完整的六层架构。从一个最小 Trust Loop 开始，效果已经很明显：

第一步：写 Change Contract（5 分钟） 用 BDD 的 Feature/Scenario 格式，把需求翻译成 3-5 条可验证的业务规则。不要多，要精。

第二步：AI 实现 + AI 生成契约测试 让 AI 在权限边界内实现功能，同时要求它从 Contract 生成对应的 BDD 测试。注意：写测试和写代码的 prompt 要分开，明确切换角色——“刚才你是实现者，现在你是测试者，你的任务是证明这段代码是错的。”

第三步：运行测试 + 变异挑战 测试通过后，做一轮简单的变异测试：故意删掉一行权限判断、交换一个边界符号、注释掉一段库存恢复逻辑。如果测试仍然通过，说明测试不可信，回去补强。

第四步：生成 Evidence Package 一页纸的证据包：声明了什么、改了什么、每条不变量的证据状态、被杀死的关键 mutation、诚实列出的未覆盖风险。

第五步：人类审查证据 + UAT 你不再需要知道每一行代码写了什么，但你清楚地知道系统声称保证什么、每项保证由什么独立证据支撑、哪些地方仍未被证明。把审核精力投入到最值得的地方。

风险分层：不是所有代码都值得同等审查

信任工程不是让你对每一行 AI 生成的代码都如临大敌。合理的做法是风险分层：

低风险（文档、UI 文案、代码格式化）：自动完成，事后抽查。
中风险（API 修改、业务逻辑调整）：Change Contract + 测试证据 + Diff review。
高风险（权限、支付、数据库结构、安全）：完整六层 + 人工审批 Gate。

信任不是不信任 AI，而是把人的判断力用在最关键的地方。

写在最后

AI 辅助开发的时代已经来了，而且不会回去。与其焦虑代码量爆炸，不如升级我们的工作方式。信任工程和 BDD 的结合，本质上是在回答一个问题：当机器的生产力远超人的审核力时，人应该做什么？

答案不是更努力地看代码，而是更聪明地设计验证体系。让机器负责生成，让人类负责定义"什么必须为真"和"什么风险不可接受"。代码可以自动生成，但价值的判断、风险的权衡、边界的划定——这些仍然是人的领地。

把重复的认知劳动交给 AI，把高阶的判断力留给自己。这才是 vibe coding 应该有的样子。

本文由 AI 辅助生成，经人工审校后发布。观点来自对当前 AI 工程实践的持续观察与思考，如有偏颇，欢迎指正。