从愿望清单到可执行约束：测试先行

你有了清晰的验收标准。下一步是让它变成可执行的。

在传统开发中，测试驱动开发（TDD）的主要动机是驱动设计：先写测试，让测试的需求塑造代码的接口和结构。Agent 时代，TDD 的动机发生了根本性的变化。编码成本趋近于零。Agent 可以在几分钟内生成一个模块的完整实现。当编码变得几乎免费，测试的相对价值趋向无穷。测试成为了你对 Agent 产出的唯一客观度量。

测试先行的具体做法是：在第一行业务代码落地之前，根据规约中的验收标准搭建测试框架。每一条验收标准对应一个或多个测试用例。暂时不存在的依赖使用 Mock 替代，构建与整体服务解耦的独立测试环境。

这样做的效果是：当 Agent 开始编码时，它面对的是一组已经存在的、红色的测试。它的任务是让这些测试变绿。测试定义了"完成"的含义，Agent 的每一次修改都能立即得到反馈。

测试是 spec 的可执行形式。规约中写的"支付成功后在账单页出现一条记录"，在测试中变成了一个具体的断言：调用支付接口，传入特定参数，验证数据库中新增了对应的记录，验证接口返回了预期的状态码。模糊的自然语言被转化为了精确的、可重复执行的检查。

这意味着规约和测试之间存在严格的映射关系。如果一条验收标准无法被转化为测试，这条标准本身就需要回到规约阶段继续明确。如果测试中存在没有对应验收标准的断言，这个断言要么是多余的，要么暴露了规约的遗漏。两者必须保持同步。