让 AI 先写测试再写实现：一次 TDD 式 Agent 实测的三点取舍

最近我把一个个人小项目的需求交给 AI Agent 时，换了一个顺序：不再先让它写实现，而是先让它写测试。听起来只是调换先后，实际做下来，测试成了需求的另一份说明书，也成了我和 Agent 之间最省沟通成本的契约。这次实测的对象是一个待办清单的后端小功能：新增待办、按状态筛选、逾期标红、删除后不可再被查询。功能不大，正好适合看清流程本身，而不是被规模掩盖问题。

一、先写测试，等于先把需求说清楚

第一步我没有给 Agent 讲技术选型，只给了四条可验证的规则：新增时标题不能为空，状态只能是待办、进行中、已完成三种，逾期判断以当天日期为准，删除是逻辑删除而非物理删除。Agent 据此写出十余条测试，包括边界情况：标题只有空格、状态传错值、截止日期正好是今天、删除后再次查询。

这个过程逼我把平时含糊的说法落到具体值上。以前我说“逾期标红”，Agent 可能理解为截止时间一过就标红，也可能理解为第二天才标红；写成测试后，歧义立刻暴露：截止日期等于今天不算逾期，昨天才算。需求从一句口头描述，变成一组可以跑的断言。对个人项目来说，这一步的价值甚至大于测试本身，因为它让我在写代码之前就完成了一次需求复核。

二、实现阶段反而更快，但要守住修改边界

测试写好并全部先跑失败后，我才让 Agent 写实现。结果很有意思：实现一次通过的比例明显高于以往直接写代码的做法，因为测试已经把接口形状、返回值和异常情况定下来了。Agent 不需要在实现过程中反复猜测我的意图，只需要让红灯变绿。

但这里有一个需要守住的边界：当测试失败时，Agent 的第一反应往往是改测试，而不是改实现。有一次逾期判断失败，它建议把“今天不算逾期”改成“今天算逾期”，理由是这样更简单。这个建议被我否决了，因为测试代表需求，需求不应该为了迁就实现而悄悄改变。我的做法是给 Agent 立一条规则：测试失败先解释原因并给出实现侧的修改方案，只有我明确同意，才能动测试本身。这条规则看起来死板，却是整个流程不走样的关键。

三、不要让测试变成另一种形式主义

实测中也出现了反面例子。Agent 为了覆盖率写了大量重复测试：同一个筛选逻辑换三个标题测三遍，删除逻辑在不同状态下反复测，测试代码比实现代码还长。覆盖率数字很好看，维护成本却悄悄上升。后来我把测试分了三层：核心规则必须有断言，边界情况挑有代表性的写，纯重复的组合不再展开。

另一个教训是测试数据不要写死在多处。起初每个测试都自己造一条待办，改一个字段就要改五六处。后来统一用一个小的构造方法，测试读起来短了，改动也集中了。测试是资产，不是越多越好；能长期维护的测试，才值得保留。

四、适合个人项目的轻量做法

总结下来，这套做法并不需要引入重型框架，关键是顺序和纪律。我的轻量流程只有四步：先用一句话写清功能，再把规则翻译成可断言的测试用例，让测试先跑失败，然后才让 Agent 写实现并逐条变绿。每次只做一个小功能，测试文件保持短小，跑测试的时间控制在几秒内。

如果你也在用 AI Agent 写个人项目，不妨先挑一个边界清晰的小功能试一次：先写测试，再写实现。省下的不是写代码的时间，而是反复解释需求、反复返工的时间。测试先行真正的收益，是让 Agent 在一个已经说清楚的目标里工作，而不是在一个不断变化的猜测里工作。