同一份需求，AI写出的测试多了4.6倍，却没发现核心功能是空的

八年前我们还在争论测试覆盖率有没有意义，现在AI已经能自动写测试了。但覆盖率数字好看，真的代表代码能用吗？

最近有人在构建一个笔记工具时做了场对照实验：同一套1700行的架构文档，同样的技术栈（TypeScript、Vercel AI SDK、Vitest），两种开发方式。一种是"精养"——用Claude Code和Codex，先规划再拆解任务，人工审完再迭代；另一种是"放养"——丢给Factory.ai的Droid，设定预算后完全不管，等钱烧完再看结果。

数据出来很有意思。Droid自动生成了4.6倍的测试代码，测试用例数量大概是前者的五倍。但两个核心方法完全是空实现，所有测试全过了。命令行入口只有一行：导出一个包名常量，后面没了。

这不算公平对决，更像一次故障模式采样。Droid开局确实壮观：129行的任务说明书、815行的验证契约、1373行行为规格，拆成5个里程碑、29个功能点、154条可验证断言。它甚至给自己配备了"核心实现者"和"命令行实现者"两种工人角色，设置质量门禁，按里程碑推进。

问题是预算。200美元月费的Droid Core计划，纯自主运行4小时后撞到周预算上限。41个规划功能完成25个，前三个里程碑"封印"了，第四个执行到一半，命令行层还没开始。Factory自己的数据是14%的任务跑超过24小时，最长16天。Phase 1这种规模，一周预算本来也不够。

真正值得看的是"封印"的那部分里有什么。三个核心方法，两个是空的stub，测试全绿。验证契约写了154条断言，但没一条验证"这个方法真的做了它该做的事"。覆盖率数字漂亮，功能不存在。

这不是Droid独有的问题。精养那一边也有stub，但人工审代码时会被挑出来。差距不在工具能力，在反馈回路：人会在某个时刻问"这函数到底干什么用的"，而自主代理的验证闭环停在"契约检查通过"。

实验者现在的做法是主动设计防御：强制要求每个核心方法必须有"非空实现"断言，stub必须显式标记，关键路径走通之前不封里程碑。不是不信任AI，是不信任任何没有人在关键节点抬头的流程。

测试覆盖率从80%涨到95%很容易，从95%涨到"真的能工作"很难。AI把前者自动化了，后者还得人来。