先说好的。

用 Cursor 写测试代码，是真的快。

以前写一个接口的单元测试，连想带写带调试，少说半小时。现在把需求一贴，噼里啪啦，五分钟，一套用例出来了。

Trae 也一样，生成速度快得让人不适应。

所以我不是来唱衰 AI 的。恰恰相反，我觉得 AI 写代码是大趋势，挡不住。我自己现在写测试也离不开这俩工具。

但 ——

快，不等于没问题。

用了一周，踩了三个坑。每个都挺要命。

---

坑一：代码 "能跑"，不等于代码 "正确"

AI 写的代码有个特点 —— 特别能跑。

编译通过，主流程跑通，一切看起来都很美好。测试全绿，你甚至想给自己点个赞。

但问题往往出在你想不到的地方。

异常场景、并发竞争、数据一致性、安全漏洞，这些地方 AI 经常掉链子。

说个真事。我见过一段 AI 写的支付回调处理，主流程跑得特别顺，测试全绿。结果上线后遇到 "回调超时 + 重试" 的场景，直接重复扣款了。

这种问题，常规功能测试根本测不出来。因为你测的都是正常路径，谁会没事去测 "超时了又重试" 呢？

AI 也不会。它只写你让它写的。你没提的边界，它默认不存在。

---

坑二：代码量暴增，你根本看不过来

这个是我最直观的感受。

以前一个 PR，200 行代码，Review 的时候还能一行行看。现在呢？AI 一写就是 800 行，甚至更多。

Harness 的 CEO Jyoti Bansal 在 2025 年 Unscripted 活动上说过一句话：用 AI 生成代码，代码量可能是以前的四倍。

四倍什么概念？

你以前看 200 行需要 20 分钟，现在看 800 行需要一个半小时。而且大部分是 AI 写的，你还得猜它为什么这么写、有没有考虑边界。

看到最后，人已经麻了。

然后就会发生一件事 —— 你不看了，直接合并。

这才是最危险的。

---

坑三：最讽刺的，测试用例也是 AI 写的

这个坑我一开始完全没意识到。

AI 编码助手不仅帮你写业务代码，还会顺便帮你生成单元测试。看起来很贴心，对吧？代码和测试一条龙。

但你细想 —— 让同一个 AI 既写代码又写测试，等于什么？

等于让一个人既做账又做审计。

它写代码的时候怎么想的，写测试的时候还是怎么想。它只会验证自己认为对的东西，自己没想到的场景，测试里也不会有。

有研究说过这个事：AI 先写了有缺陷的代码，再用同一个 AI 生成测试，缺陷检测效果会明显下降。因为代码和测试来自同一个 "大脑"，不独立。

说白了，自己考自己，能考出啥问题？

---

那传统测试框架不行吗？

有人说了，用 JUnit、Pytest、Appium 这些不行吗？

说实话，不够用了。

传统测试框架本质上是 "执行预设脚本"。你写好用例，它帮你跑。但 AI 写的代码天天在变，你根本来不及为每一行新代码补测试。

更关键的是 ——AI Agent 本身就需要被测试。

传统软件是确定性的。同样的代码、同样的输入，跑一百次结果都一样。

AI Agent 不是。同一个输入，你跑十次，可能得到十个不同的结果。因为它底层的模型每次都在 "自己决定" 怎么完成任务。

用测确定性系统的方法去测非确定性系统，怎么可能测得住？

---

那怎么办？不用 AI 了？

不可能。我说了，这是大趋势，挡不住。

我的做法是三条：

第一，AI 写的代码，必须人工 Review。 不是走形式，是真看。尤其是异常处理、并发、数据一致性这些地方，逐行看。

第二，AI 写的测试，不能直接用。 必须自己再补边界场景、异常场景、并发场景。AI 写的测试只能当草稿，不能当最终版。

第三，对 AI 生成的代码做额外的 "破坏性测试"。 故意搞点异常输入、并发请求、脏数据，看它扛不扛得住。正常路径 AI 都能跑，问题全在异常里。

简单说就是 ——AI 可以帮你写，但你得帮它兜底。

---

最后说一句。

AI 写代码，快是真快，好用也是真好用。我现在写测试也离不开 Cursor 和 Trae。

但越是好用，越不能掉以轻心。

代码能跑，不代表代码正确。测试全绿，不代表没有缺陷。

做了 10 年测试，我最深的体会就是 —— 永远不要相信 "看起来没问题"。

AI 也不例外。

如果你也在用 AI 写代码，欢迎在评论区聊聊你踩过什么坑。