第 3 章信任壁垒：为什么 AI 生成的代码不可直接信任

本章你将学到

工程师面对 AI 生成代码时那种"不敢直接合并"的本能，其实由三重结构性障碍构成------它们不是心理作用，而是模型工作机制的必然产物；

一份可操作的编码代理失败模式目录：AI 会犯哪些类型的错，以及每一类错"能不能被自动抓住、由什么来抓"；

为什么"Agent 产出越快，人反而越累"------监督成本悖论如何让"信任"从软性话题变成硬性瓶颈；

"信任"到底要建立到什么程度，才能真正把人从审查中解放出来（而不是虚假的安心）；

人类开发者身上那套看不见的"隐性 Harness"到底包含什么------正是它的缺失，定义了我们要为 Agent 显式补建的东西。

从"能干"到"敢用"之间，隔着一道墙

第 2 章我们拆开了 Agent 的引擎盖，看清它能力很强、边界也很清楚。但一个绕不过去的现实是：能力强，不等于可以直接信任。

几乎每个用过编码代理的工程师都有过同一种体验------Agent 飞快地生成了一大段代码，看起来像模像样，但你的手在"合并"按钮上停住了："它真的对吗？我得逐行看一遍。" 这一瞬间的迟疑，就是本章要解剖的对象。

这道"信任壁垒"（trust barrier）不是保守，也不是偏见。Birgitta Böckeler 在其框架文开篇就一针见血地指出了它的三个来源：

作为软件工程师，我们对 AI 生成的代码有一种天然的信任壁垒------LLM 是非确定性的，它们不了解我们的上下文，而且它们并不真正理解代码，它们是以 token 在思考。

理解这道墙由什么砌成，是理解"为什么需要 Harness"的前提。因为 Harness Engineering 的终极目标，正是系统性地降低这道墙的高度------让 Agent 在更少监督下工作，同时我们还能对结果保持信心。

本章源级：本章为 A 级为主。三重信任障碍（非确定性、无上下文、以 token 思考）、失败模式目录的核心条目、监督成本矛盾均出自 Böckeler 框架文的一手记载（A 级）；失败模式的三分类（结构/语义/意图）与"隐性 Harness"的展开讲法为本书在源文基础上的框架化整理（B 级）。

3.1 三重信任障碍

Böckeler 点出的三个来源，恰好对应第 2 章讲过的三个机制。它们层层递进，共同构成了这道墙。

障碍一：非确定性------"同样的输入，不保证同样的输出"

第 2 章 §2.1 讲过，模型输出来自对概率分布的采样，只要温度不为 0，同样的提示就可能走向不同的结果。

这对信任的打击是根本性的：你无法通过"这次它做对了"推断"下次它也会做对"。 传统软件里，一个函数测试通过了，你就可以信任它------因为它是确定的。但 Agent 这次生成了完美的代码，不构成对下一次的任何保证。信任无法在非确定的对象上简单累积。

回扣 Harness ：这解释了为什么 Harness 必须是系统而非技巧。你不能靠"这次调教好了"一劳永逸，只能靠一套每次都运行的前馈引导 + 反馈传感器，把非确定性的输出，收敛到确定性的质量闸门内。

障碍二：无上下文------"它不知道我们团队的约定与业务背景"

请注意，这里的"上下文"和第 2 章 §2.3 的"上下文窗口"是两个不同层面的概念，切勿混淆：

§2.3 的上下文窗口，指模型单次能"看到"的 token 容量（技术容器）；
这里的"无上下文"，指模型缺乏团队约定、业务背景、历史决策这类背景知识（知识内容）。

模型是在公共数据上训练的，它不知道"我们这个团队为什么规定所有金额必须用整数分存储""这个看似多余的校验其实是三年前一次线上事故的教训""这块代码虽然丑但绝对不能动"。这些信息从来没进过它的训练数据，也不在它的上下文里。

回扣 Harness ：这道障碍的解法贯穿全书第三篇------把散落在人脑、会议、聊天记录里的隐性知识，持续沉淀进仓库，让它对 Agent 可见。这正是第 15 章"仓库即唯一事实来源"和"新员工测试"要解决的问题：Agent 运行时拿不到的信息，等同于不存在。

障碍三：无理解------"它以 token 思考，而非以语义理解"

第 2 章 §2.1 的核心结论在这里再次发挥作用：模型捕捉的是统计规律 而非语义真理。它能生成"看起来对"的 token 序列，但"看起来对"不等于"逻辑对"。

这是三重障碍里最隐蔽、也最危险的一重。前两重障碍（不稳定、缺背景）你还能有所警觉，而"无理解"制造的错误往往表面完美------命名地道、结构工整、注释齐全，唯独逻辑是错的。它甚至会自信地调用一个不存在的 API。这种"言之凿凿的错误"，恰恰最能骗过快速的人工扫视。

回扣 Harness ：正因为错误会伪装成"看起来对"，我们绝不能依赖人工肉眼扫视 来把关，而必须依赖能穿透表象的确定性验证------测试是否真的通过、类型是否真的自洽、契约是否真的满足。这是第二篇整个反馈体系存在的根本理由。

三重障碍的合流

把三者叠加起来，就能理解那道墙为什么如此顽固：

markdown 复制代码

  非确定性  →  这次对，不代表下次对（信任无法累积）
     +
  无上下文  →  它不知道我们的约定和业务背景（会违反不成文规则）
     +
  无理解    →  错误会伪装成"看起来对"（骗过肉眼扫视）
     ↓
  结论：不能凭"看一眼觉得没问题"就信任 AI 生成的代码

这个结论听起来令人沮丧，但它恰恰是 Harness Engineering 的起点：既然三道障碍都源于模型的固有机制、无法靠"换个更强的模型"根除，那么唯一的出路，就是在模型外部建一套系统去补偿它们。而要建这套系统，我们首先得知道：Agent 到底会犯哪些错？

3.2 编码代理失败模式目录

要对症下药，先得把"病"列清楚。Böckeler 基于实践整理了一份编码代理的失败模式清单，并给出了一个极其关键的判断：这些失败模式，能被自动抓住的能力天差地别。 按"能否被可靠捕获"，可以清晰地分为三类。

这份目录是全书的一条主线。 它是第 26 章"失败模式覆盖矩阵"的原型，也是附录 E 完整版的雏形。现在先建立整体认知，后面章节会逐条给出对应的传感器方案。

结构类失败：计算型手段可靠捕获

这类问题是形式层面 的偏差，有客观、确定的判定标准，因此廉价、成熟、确定性的计算型工具就能可靠抓住：

失败模式	说明
重复代码（duplicate code）	复制粘贴而非抽象复用
圈复杂度过高（cyclomatic complexity）	分支嵌套过深、函数过于复杂
测试覆盖缺失（missing coverage）	关键路径没有测试保护
架构漂移（architectural drift）	依赖方向、模块边界被悄悄破坏
风格违规（style violations）	不符合既定编码规范

回扣 Harness ：这一类是 Harness 最容易见效的地方------用第 11 章的计算型传感器（linter、静态分析、结构性测试）就能覆盖，快到可以在 Agent 每次编辑后都运行。花小钱，办实事。

语义类失败：推理型手段可部分捕获（昂贵、概率性）

这类问题需要语义判断 ，没有简单的形式规则可套，计算型工具无能为力。只能靠推理型手段（AI 评审）部分识别，而且昂贵、结果概率性、不能每次提交都跑：

失败模式	说明
语义重复（semantically duplicate code）	代码长得不一样，但做的是同一件事
冗余测试（redundant tests）	大量测试其实在重复验证同一逻辑
暴力修复（brute-force fix）	用蛮力绕过问题，而非解决根因
过度设计（over-engineered solutions）	为简单需求引入不必要的抽象与复杂度

回扣 Harness ：这一类对应第 12 章的推理型传感器（评审 Agent、LLM-as-Judge）。关键认知是：它们能帮忙，但不能兜底------非确定、成本高，只适合抽样或在关键节点触发（第 12、24 章会讲成本控制）。

意图类失败：两类手段都无法可靠捕获

这是最高影响、也最棘手的一类。它们既不是形式问题，也不是纯语义问题，而是"做的事情根本不是人真正想要的"：

失败模式	说明
问题误诊（misdiagnosis of issues）	修错了地方------症状缓解了，根因还在
多余功能（unnecessary features）	做了一堆没人要的东西
误解指令（misunderstood instructions）	从一开始就理解偏了需求

Böckeler 对这一类给出了本章、乃至全书最冷静的一句断言：

正确性不在任何传感器的职权范围内------如果人类一开始就没说清楚想要什么。

这句话必须被反复咀嚼。它意味着：再完善的 Harness 也无法弥补"意图输入"本身的缺失。如果人没说清楚要什么，任何传感器都无从判断对错------因为"对错"的标准根本还不存在。

回扣 Harness ：这一类不是靠加传感器能解决的，它指向了两个方向------第一，第 17 章的"规格工程"，把模糊意图转化为清晰、可验证的验收标准（把问题往前馈端解决）；第二，第 33 章工程师的新职责"明确意图"。这也正是第 2 章 §2.6"第三档能力"和第 26 章反复强调的边界：Harness 兜住不确定性，但兜不住人类没想清楚的需求。

目录的战略意义：Harness 投资的地图

把三类合起来看，这份目录立刻变成一张投资地图------它诚实地告诉你，花钱建 Harness 能买到什么、买不到什么：

复制代码

结构类  → 计算型可靠捕获   → 必建，且廉价，优先做
语义类  → 推理型部分捕获   → 该建，但要控成本、管好非确定性
意图类  → 都无法可靠捕获   → 别指望传感器，投资规格工程与人类判断

这张地图会在第 26 章被细化为完整的"覆盖矩阵"。现在你只需记住一个反直觉的结论：Harness 最擅长解决的，恰恰是那些看起来最琐碎的结构问题；而最影响成败的意图问题，反而最需要人类亲自兜底。

3.3 监督成本悖论：Agent 越快，人越成为瓶颈

前面说清楚了 Agent 会犯错、且很多错抓不住。一个自然的应对是："那我就人工审查每一份产出好了。"

这恰恰掉进了 Harness Engineering 要解决的核心矛盾------监督成本悖论。

逻辑链条是这样的：

引入 Agent 的初衷，是大幅提高代码产出的速度（第 1 章 OpenAI 案例：人均每天约 3.5 个 PR）；
但由于三重信任障碍，每一份产出原则上都需要人工审查才能放心合并；
于是，产出越快，等待人工审查的队列就越长------瓶颈从"写代码"平移到了"审代码"；
人的审查速度是基本恒定的，它无法随 Agent 产量线性扩张。

结果就是这个悖论：Agent 把生产环节加速了 10 倍，却让审查环节成了新的天花板。 如果监督方式不变，Agent 带来的速度收益会在审查队列里被大量抵消。这也预告了第 21 章的"瓶颈转移定律"------代码吞吐上去之后，卡点会转移到人工 QA。

回扣 Harness ：悖论的出路只有一条------不是让人审得更快，而是让绝大多数问题在到达人眼之前就被自动纠正 。这正是 Böckeler 对"好 Harness"的定义：一套外层 Harness 应当"提供反馈回路，在问题到达人类眼前之前，就自动纠正掉尽可能多的问题，最终降低审查负担"。换句话说，Harness 的价值不只是提质，更是把人从线性增长的审查负担里解放出来。

3.4 信任的经济学：多高的信任才算"够"

既然目标是减少监督，那就要追问一个精确的问题：信任要建立到什么程度，才能真正减少监督？

这里有一个容易被忽视的"信任的经济学"陷阱：部分信任，往往等于零信任。

设想你对 Agent 的产出有 90% 的把握。听起来很高了？但只要那 10% 的不确定足以造成严重后果，你就仍然必须审查 100% 的产出 ------因为你事先并不知道这一份恰好落在可靠的 90% 还是危险的 10% 里。在这种情况下，那 90% 的信任在"减少监督"这个目标上没有产生任何价值：你付出的审查成本一分没省。

这就是信任的经济学核心：

只有当信任高到"可以据此跳过审查"时，它才开始真正减少监督成本；停留在"还是得看一眼"的信任，经济价值约等于零。

那么怎样才能跨过"可以跳过审查"这道门槛？答案不是"祈祷模型更强"，而是用 Harness 把"信任"从对模型的主观期望，转化为对系统的客观保证：

你信任的不再是"这个 Agent 这次应该没问题"（主观、不可累积）；
而是"任何未通过全套传感器的产出，都无法被合并"（客观、确定、可累积）。

信任的锚点，从变幻莫测的模型 ，转移到了稳定可靠的 Harness 上。这正是 Böckeler 反复强调的目标------建立"足以减少监督和手工测试的信心（confidence）"。而这种信心的高低，本身也是分维度、分场景的：核心业务路径需要极高的信任门槛，外围功能则可以容忍更高的自主性（这是第 28 章"分级信任"策略的伏笔）。

回扣 Harness ：这一节点明了 Harness Engineering 的经济学本质------它不是质量工具，而是信任的生产系统。它把"能不能少看一点"这个模糊的心理问题，变成了"传感器覆盖到什么程度、就能安全地跳过哪一层人工审查"这个可计算、可投资的工程问题。

3.5 人类开发者的"隐性 Harness"

读到这里，一个更深的问题浮现了：为什么人类资深工程师写的代码，我们就敢相对放心地信任？

答案揭示了本章最重要的洞察：人类开发者本身，就自带一套看不见的 Harness。 Böckeler 称之为"隐性 Harness"（implicit harness）------我们把自己的技能和经验，作为一套隐性的约束，带进了每一个代码库。它至少包含四样东西：

一、内化的约定（Absorbed Conventions）

资深工程师在长期工作中，把大量"好实践"和团队约定内化成了肌肉记忆。他不需要每次都查规范，因为规范已经长进了他的直觉里。而 Agent 没有肌肉记忆------它每一次都是"新来的"，除非你把约定显式喂给它。

二、复杂度的痛感（Cognitive Pain of Complexity）

人类工程师面对一个 300 行的巨型函数，会产生一种生理性的不适 ------Böckeler 直白地称之为"审美上的厌恶"（aesthetic disgust）。正是这种痛感，驱使他停下来重构。而 Agent 对复杂度毫无痛感：它可以心平气和地生成、维护一个丑陋到人类无法忍受的结构，因为它感受不到"丑"。

人类工程师知道------这次提交上，署的是我的名字。 代码出了事，要负责的是我，同事的目光、团队的信任都系于此。这种社会问责构成了一种强大的、无需明说的质量约束。而 Agent 没有名誉可失：它不会因为写了烂代码而感到羞愧，也不担心明天被同事追问。

四、组织记忆（Organisational Memory）

资深工程师携带着大量组织层面的对齐信息 ：团队正在追求什么目标、哪些技术债是出于业务原因被有意容忍的、在这个特定语境下"好"到底长什么样。而 Agent 没有组织记忆：它不知道团队的来龙去脉，也感受不到那些"心照不宣"的共识。

关键差异：分不清"承重墙"和"习惯"

这四样东西汇成一个最致命的差距，Böckeler 一语道破：

Agent 分不清哪一条约定是"承重墙"（load-bearing），哪一条只是"习惯"（habit）；也判断不了那个"技术上正确"的方案，是否契合团队真正想做的事。

人类工程师凭经验知道：有些规则动了会塌方（承重墙），有些规则只是历史习惯（可以商量）。而 Agent 眼里所有规则一样重------它可能小心翼翼地遵守一条无关紧要的格式习惯，却大刀阔斧地推倒一堵真正的承重墙，浑然不觉。

这一切如何定义了 Harness 的使命

现在，我们可以给出 Harness Engineering 一个最本质的定义了。Böckeler 的原话是：

Harness 是一种尝试------把人类开发者经验中那些隐性的东西，外化（externalise）并显式化（make explicit）。

也就是说，我们要为 Agent 显式补建的那套系统，本质上就是人类工程师头脑里那套隐性 Harness 的"外化版本"：