大模型没那么完美

现在的工作，越来越依赖AI 大模型了。

开发人员以前做件事情，一部分时间是在编写代码，一部分时间在做测试，剩下绝大部分时间。。。

在干嘛？

当然是无休止的找bug，找bug。。。终于好不容易找出bug，经常时候会发现是个非常低级的错误，激动的心情，一拍大腿，剩下一点时间用来修复这个bug。。。

而现在呢，需求提出来之后，交给大模型，大模型虽说也需要thinking，但是时间很短呀，通常都是以秒来计算，最长也不过个把分钟而已。

之后呢就开始输出，把它的思路完整的打印给你，确认没理解错，接下来就开始正式编码啦！

至于编码，相比以前手动操作，效率那是提高了不知道多少倍。。。当然，这期间也得些过程，比如简单的工作任务几分钟，复杂的话可能几十分钟不等，这中间的时间呢，对于人来说自然就是空闲啦。

一旦大模型开始工作，人就可以闲下来了，摸摸鱼，喝喝咖啡，逛会网站，甚至偶尔还能趁机玩一把游戏，真可谓是身心俱愉快。

但是，这世上没有完美的东西，大模型也是如此。它没有我们想的那么完美，比如做一件复杂的事情，它也会偷懒，先抛给你个解决方案和实现，等你测试过之后发现不行，它又会给你建议更好的实现，如果还不行，接着再来，给你更高级的实现方法。。。

反复多次，搞得人也很烦，我有时候在想，

“这家伙也太不厚道了，为何一开始不给出最佳的实现方法呢？非得浪费我那么多的token之后才慢吞吞给出解决方案。。。”

要知道，token就是算力，就是money，真金白银。如果把大模型比作一个全能的员工，你问他一个问题，他非得让你反复折腾多次失败后，才给出最后的解决方案，换作你，你说你烦不烦？囧

因此，我现在都养成了个习惯，每次大模型说它完成工作后，我都会让他自检下，看看是不是有遗漏或纰漏地方，比如刚才我让它自检，果不其然，它思考了一阵子之后，倒是很坦诚交代了它的失误，

深度审查发现了一个关键缺陷必须修复，否则可能导致测试彻底失败！
发现的问题：fast path 缺少 .catch() 安全降级
如果 IndexedDB 读出的 Module 在实例化时失败（例如 WASM 版本变更、模块损坏），当前代码会直接抛错给页面，没有任何降级到原生编译的逻辑。这意味着一旦 IDB 模块有问题，测试就彻底死了。

看吧！即便是目前最优秀的大模型，依旧没那么完美。

关键时刻，还是得人来把关。

PS：

我原本想着一个月200刀的预算，应该足够了，结果这个月发现远不够，明天就是3月最后一天，我们来看下我这个月用了多少刀Token，以及我用的最多的top 3大模型都有哪些？