我们写代码以前最头疼写单元测试。写业务逻辑半小时，写测试代码可能也要半小时。后来用AI自动生成测试，说帮你省时间。用了几个月说点结果。

AI写测试快是快。

你把函数丢给它，它几十秒给你一套测试用例。正常情况、边界情况、异常情况，它都帮你想到了。跑一遍全绿。

看起来完美。

但你仔细看它写的测试，就发现问题了。

它写的测试都是"按代码逻辑写"的——代码里怎么写，它就怎么测。代码走if分支，它测一下if；代码走else分支，它测一下else。

但它不测"逻辑对不对"。代码写错了，它测试也跟着错。因为它是照着代码写测试，不是照着需求写测试。

有次我们代码里有个判断写反了，AI写的测试也跟着写反了。测试全过，但功能是错的。后来用户报bug我们才发现。

这就是AI写测试的根本问题。

它能帮你覆盖代码，但它不知道业务对不对。它不知道这个函数应该在什么情况下返回什么——它只看代码现在返回什么，然后写个测试断言"它就应该返回这个"。

那这测试有什么意义？代码错了测试也跟着错，测试通过不代表功能对。

那AI写测试还能用吗？

能用，但它是个起点。它帮你把测试框架搭起来，把基本情况覆盖了。你得自己补：根据业务需求写测试用例，测那些代码可能写错的地方。

AI帮你省了搭框架的时间，但真正关键的测试，还得人来写。

做自动化测试这个事，工具帮你提速。

但测试的目的是发现问题。AI写的测试太"相信代码"了，它发现不了逻辑错误。你得带着怀疑去写测试。

说个更真实的坑。有次AI帮我们生成了一套测试，跑起来全绿，覆盖率还90%以上。我们特别高兴，觉得测试做得很到位。

结果上线后，一个用户报了个bug。我们查了半天，发现那个分支代码有问题。但AI生成的测试里，这个分支根本没测到。为什么？因为AI是根据现有代码生成测试，那个分支是新加的，AI生成的时候没看到。

我们以为覆盖率90%就安全了。但覆盖率这个数字是AI算出来的——它测了它写的那些用例，跑通了，就说覆盖率高。它不测的地方，它不算。

后来我们定了个规矩：AI生成的测试，我们必须人工review。不是看它跑不跑得通，是看它测的场景对不对、有没有漏掉关键情况。

这样虽然多花点时间，但比上线后修bug强多了。

测试这个事，别光看数字。

你得知道它测的是什么。

别被覆盖率骗了。

真的。

别光看数字。

看内容。

真的。

听我的。

就这样。

嗯。