从我毕业第一年开始，我就始终在思考一个问题：为什么我值这些钱？
希望你也思考一下。

AI 写用例这一套目前有很大的问题：

1. 上下文理解问题。单纯一篇 PRD，一些内部共识的信息很大概率会在脑子里自动补全而不体现在文档中，这部分不告诉 AI 就会生成的很差，轻则用例缺漏，重者驴唇不对马嘴。尝试过接入历史需求、历史用例和历史缺陷，但是又碰到信息过时、场景描述上的省略等等问题，花了很多时间去学习 RAG 相关的知识，然后又花了很多时间去优化，最终效果都很差，反而小伙伴怨声载道。从最开始的积极配合到疑虑重重再到最后消极怠工。
2. 二次评审问题。既然 AI 一次性生成的效果总是难以做到非常好，那我们后面暂行了一个评审 AI 用例的流程。现在事后看来，效果也很差。阅读 AI 写的用例，总会有一种坐副驾驶位上的昏睡感，会导致自己看 AI 生成的用例时难以投入，一些细节错误没发现、该增加的用例没评审到等等问题。甚至本来还算顺畅的用例评审都遭到了各个开发的投诉，说的结结巴巴，甚至要临时调整，完全没有评审自己写的用例时流畅。
3. 维护问题。这个问题我们没有实际经历过，但是在做的时候就有预想。每个迭代都会产生新的历史需求、历史用例、历史缺陷，而这三者的处理逻辑各不相同，尝试过完全让 GPT3.5 去按照预设逻辑处理，但是效果并不好，完全能用的数据只有 30% 左右（可能还高估了），剩下的都要人工处理，即便是人工处理也不能完全保证可用性。而用 GPT4 处理，效果会好很多，但是成本也没办法承受。

上面这些问题，或许交由更专业、更专心的团队去处理，还有机会处理好，但是内中的细节问题、效果问题上应该还会有一大堆又一大堆要进行处理。
在做之前，我其实也已经跟领导说过这些问题了，但是一句试一试吧，让我没办法反驳。只能当做一次技术上的实践去做了。

小米的同学都喜欢说话直截了当，不喜欢去绕弯子，讨厌卖关子吗？

直接生成用例效果会不好，但是帮你检查用例效果可以很好

不懂代码的这批人，日子已经很难过了，他们中的绝大部分也不在这个社区里，还要被人这样嘲讽。
发这个帖子有什么现实意义呢？

不确定我们做的算不算。
目前有一套检测增量代码系统，可以检测到两个 commit 之间的差值，进而找到对应影响的接口。
拿到这批接口后，我们会重跑 jvm-sandbox-repeater 录制到的接口请求。
目前这套已经接到持续集成中了，每次开发部署代码之后都会和线上版本进行对比，跑一遍涉及到的旧接口。
但是局限性还是比较大，只能说有点帮助，但是不多。

今年是过去十年来最难的一年，今年也是未来十年里最好的一年。
来，干了这碗毒鸡汤。

因果倒置了。
最初之所以有测试，其实就是因为你说的这种完美的情况无法普及。
如果真的这么好普及，测试也不会出现并发展成行业很重要的一环。

以前打 dota 的时候有一句话很经典：看了等于会了，玩了一把等于精通，赢了一把等于绝活。
好好的词，就被绝活哥们搞臭了。