其实，说实话都大差不差，无论是价格，还是准确度，还是性能上，都没有质的差距。所以为了避免打广告嫌疑，我就不具体说明用的哪几家AI了。
正文：
【现象描述】
如果你让gpt ，给一段功能的描述，生成判定表用例。它会给你生成不少用例，看起来还都不错的。
但是如果你让gpt不生成最终用例，而是生成该功能描述的条件桩、动作桩。那多半它会生成的一塌糊涂。也就是中间过程的数据是非常糟糕的。
这样的结果，经过大量方法和例子论证，确实存在这个现象。
【总结影响】
gpt生成的中间层面数据非常糟糕，如果作为一些下游算法函数的入参是没啥好结果的。意味着在用例生产过程中的大部分节点内使用gpt和固定算法结合都不是一个好办法。
【原因猜测】
gpt的数据来源基本都是学习，无论是从互联网上，还是从哪里，进行不断的学习。但是他们学习的都是最终答案，而非中间过程。之前有个科学家就说过：说你问gpt 10*10 等于多少？gpt回答你100。但是这计算过程并不是和我们人类一样去列竖式子去按部就班的计算。而是gpt从庞大的经验库中找到了10*10的答案，就是100 。可能gpt自己也不明白为什么是100，只是因为互联网找到的无数个10*10的问答中，100都是正确答案，仅此而已。
就好像考试的时候，一个差生抄了选择题的答案，之后老师让他上讲台讲一下这选择题，差生傻了，他只知道选，但是不知道为什么要选。只是因为之前抄的尖子生的答案罢了。
而gpt，大体就是这么回事。当然10*10的问题还是太简单了。而那些真正用例功能描述生成用例这样的实际应用题，gpt则没有按照我们人类的思维去写用例，更没有所谓的中间数据，什么条件桩，什么动作桩，什么排列组合的都没有，只不过之前有人问过类似的问题，恰好有人回答过正确的最终用例而已。再略微扩展和润色，就呈现在了你的眼前。
【拯救办法】
虽然，让gpt和算法深度结合来生成用例的这条路不太好走，但是我仍然不准备放弃这个路线。只是做成一个可持续进化的方案比较好。一开始，用手工+算法的方式来生成测试用例，和gpt直接生成的用例做互补。这个过程中，再本地训练一个封闭式AI，让其学习功能原始描述和手动整理出的中间数据的关系，一点点渐进式的投入使用。其中自然语言处理上让gpt帮忙一下也没啥问题。若一切顺利，大概在一般规模公司部署后，个把月就可以让手工休息了。当然，这个过程中要额外增加成本，比如结果收集和AI训练等等，而且也不太可能一帆风顺，中间还会有很多意外问题需要解决。总体来说，这一段路不是那么好走的。
但我相信，技术是没有穷尽的，总有一天，我们会解决所有的难题。哪怕到时候会遇到更多更难的问题！
