AI写代码时代：如何防止Agent在测试里自导自演

如果 AI Agent 已经能独立编写业务代码，人类工程师的阵地就只剩下流水线的两端：说清楚要做什么，以及验证它是否真的做对了。

但这套流水线的下游验证环节，正在遭遇新的挑战。

自动化测试的两大死穴：死板与脑补

让 Agent 直接从验收标准（Acceptance Criteria）生成测试用例，通常会走向两种极端，且都会导致验证失效：

1. 字面直译（Literal Translation）：Agent 将需求里的每个具体场景机械转换为测试脚本。这种做法很安全，但极其单薄。需求给三个示例，它就生成三个断言。如果业务规则包含复杂的非单调边界，这种测试几乎没有覆盖率可言。
2. 盲目泛化（Generalisation）：Agent 试图自行推断出底层规则，并生成更多测试用例。这立刻撞上了测试领域的“先知难题（Oracle Problem）”——每个新增的测试输入都需要一个预期的正确输出，但需求文档本身并没有提供。于是 Agent 开始胡乱脑补规则。例如看到“机器内有足够的钱”，Agent 几乎必然会自行推导为 现金存量 ≥ 取款金额。生成的测试全部亮绿灯，逻辑自洽，却在实际面额找零逻辑上全盘皆错。没人会察觉异常，因为代码和测试看起来都“完美符合预期”。

扩展后的需求格式改变了这一现状，它将不同的语义直接映射到对应的测试层级：

• 具体示例（Examples）→ 示例测试：验证文档中写明的具体 Case，同时覆盖条件成立与不成立的两侧。
• 前提守卫（Provided）+ 关系型结果 → 基于属性的测试（Property-based Tests）：针对任意输入金额，只要满足面额组合条件就必须吐钞，且吐出的钞票总额严格等于请求金额。
• 兜底处置（Otherwise）+ 副作用隔离 → 框架测试（Frame Tests）：在系统拒绝交易后，账户余额与机器内钞票库存必须保持原样，不得产生未声明的状态变更。
• 术语词汇表（Glossary）→ 条件本身的单元测试：确保业务概念（如 可组合找零）完全符合定义者声明的逻辑。

规则不再需要 Agent 去猜。它被明确写在 Provided 守卫中，其术语在词汇表里有据可查。如果某个概念未被定义，Agent 会立刻停下来报告缺口，而不是悄悄替人类做决定。

隔离验证：让两套上下文互相博弈

比语法格式更重要的，是一条架构原则：测试代码与业务代码绝不能来自同一个上下文。

如果同一个 Agent 基于它对需求文档的同一次理解，既写了业务代码又写了测试用例，它犯下的逻辑错误就会在两端完美同步。测试变成了给代码背书，而不是检验代码。只有当两种解读完全独立时，验证才有实际意义。

更合理的工作流应当引入双 Agent 机制：

• 测试 Agent 与 编码 Agent 各自独立阅读需求规范；
• 在双方全部完工之前，谁也看不到对方的产出；
• 此时，测试失败不再是一张判决书，而是一个信号：必然有一方理解错了需求，而需求规范本身就是裁决的唯一依据。

一种更为激进的做法是：让编码 Agent 只能看到测试用例，完全接触不到原始需求。测试本身构成了全部的交付契约。测试 Agent 没能转译出来的逻辑，编码 Agent 就绝不会去实现。这种模式能强迫所有隐性假设浮出水面，但也伴随着三大风险：

• 应试编码（Teaching to the test）：只看测试的 Agent 极易写出特例硬编码逻辑（如 if amount == 80: return false）。基于属性的测试能遏制这种投机，但单纯的用例测试防不住。
• 业务语汇丢失：测试代码说明了“做什么”，却往往丢失了“用什么术语表达”。折中方案是把领域词汇表同步给编码 Agent，但不给它具体规则。
• 单点故障转移：一旦测试 Agent 读偏了需求，业务代码就会一丝不苟地把错误实现到底。

为了规避这些问题，可以借用机器学习中的**留出集（Hold-out set）**机制：无论允许编码 Agent 查看多少测试，都必须保留一部分隐藏的测试用例（最好是基于属性的测试）专门用于最终验收。如果在可见测试上全绿、在隐藏测试上报错，就说明代码出现了过拟合。

这种思路并不新鲜。早在 20 世纪 80 年代，IBM 联邦系统部门推行的洁净室软件工程（Cleanroom Software Engineering）就规定：测试必须由完全不了解内部实现的独立认证团队负责。开发人员在交工前甚至不允许自行运行代码。在过去，由于人力成本高昂，洁净室工程只能局限在极少数要求严苛的工程团队中；但在多 Agent 协作体系下，双重隔离的边际成本几乎归零。

跨规则分析：用约束求解器消灭死角

人工肉眼审阅单条业务规则并不难，但一个运行多年的中大型系统往往堆积了成百上千条规则。显式的守卫条件（Guard）让整套系统具备了形式化分析的可能，使三类冲突无所遁形：

1. 重叠（Overlaps）：针对同一事件，两条规则的触发条件同时满足，却给出了互相矛盾的结果。
2. 死角（Gaps）：存在某种特定的条件组合，没有任何一条规则予以覆盖，形成未定义行为。
3. 兜底冲突（Otherwise Collisions）：在同一异常场景下，一条规则要求“静默拒绝，不产生任何变更”，另一条规则却要求“记录失败流水”。

只要词汇表对业务条件的定义足够精准，Agent 就能将守卫逻辑转化为形式化表达式，直接交给 Z3 等约束求解器（Constraint Solver）。Agent 负责翻译，求解器负责计算裁决。判断两个守卫是否存在逻辑冲突，不再依赖工程师对自然语言文字游戏的推敲。而在传统的自然语言需求里，这些冲突通常被掩埋在字里行间，直到线上出故障才被发现。

同时，规则集本身必须动态维护。它应当是当前系统行为的活文档，而不是历史用例的垃圾堆。过期的废弃规则必须剔除，否则相互矛盾的陈旧示例会让系统维护成本呈指数级上升。增量检测应该发生在变更的瞬间：每次新增或修改规则时，只校验该规则及其邻近依赖，而非全局无休止全量重跑。

现实中总有一些盲区只能在线上暴露：客诉工单、线上故障、用户意想不到的操作习惯。这些反馈必须快速回流到规则集与词汇表中。失去这层闭环，所谓的“前置精确规范”无非是预算更高的瀑布模型。

形式化的真实边界：暴露不确定性

这一套方案并不能打造出在数学上绝对正确的完美软件。形式化验证只能证明“代码是否忠实于需求规范”，却永远无法自证明“需求规范本身是否正确”。检验者本身也需要被检验。

在项目初期，验收标准本质上只是团队关于“什么功能有用”的猜想。将其当作既定真理并固化为绿灯测试，只会用确定的假象掩盖真实的不确定性。规范语法的价值不在于消除不确定性，而在于将其显性化：未定义的术语、缺失的兜底逻辑、未从正反两面校验的边界守卫，都会被摆上台面。

务实的目标不是零缺陷，而是尽早且低成本地暴露错误。Guarded Gherkin 所做的，就是给条件守卫一个专属位置，让负向场景成为必填项，让模糊地带作为未定义术语直接报错，阻断下游 Agent 自作主张替人类做决策的漏洞。