用几乎纯 AI 写维基萌公会联盟这款游戏也有段时间了，可以分享一些 AI 写项目的心得了。
先说结果，现阶段面向个人的几大 AI 模型用来开发个人小项目，实现个人的一些想法是够用的。但是用在商业项目还有待商榷。
目前用下来的问题包括但不仅限于：
· 不会总结需求功能中哪些函数或者组件应该共通化，同样的功能写的到处都是。
· 由于上面的问题，修改BUG的时候经常只会改一处就觉得自己解决问题了。
· AI 有时候倾向掩盖问题而不是解决问题。比如有几次指挥解决日志中的错误，结果 AI 选择遇到此类问题不输出日志。
· 受到上下文最大输入限制，现在的 AI 是以总结交接的形式将前面的信息传递到下一任 AI ，这就导致了一旦发生交接，这段代码质量会急剧下降。
· 不约束代码习惯的时候，AI 更倾向写可读性很差的语法糖。
· UI交互设计不加详细描述就会写的一团糟。
· 游戏玩法设计幻觉严重。
当然优点也有很多。最大的优点就是减少了我自己的心智负担。并且用自己的描述成功让 AI 完美实现时的成功感。我现在算是明白为什么那么多人喜欢玩抽卡游戏了。

用 AI 写了一个放置类的网页游戏
游戏地址：https://guild.wikimoe.com/game/home
总成本大约40美元。
我提供了框架选用、游戏玩法、数值设定。从结果来看，属于能跑，但是基于幻觉的BUG应该还有不少。
因为是测试阶段，未来可能会删库重构。
游戏本身其实是当年维基萌抽卡时期构思的玩法，后来因为种种原因鸽了好几年。
不过现在有了 AI 可以实现当年的玩法了。

试了下让 AI Nano Banana Pro 自动生成文章封面图。
很意外的是，AI仅凭标题中提到的作品名绘制出了作品角色。甚至还仿造了作品Logo的风格绘制标题。
但是也少不了出现完全不认识的角色。而且对于较新的作品，比如《mono》就绘制了完全缝合的角色。AI似乎知道《mono》和《摇曳露营》的关系，出现了和扶子造型相似的角色，以及强行加塞了原标题没有的文字，说是《摇曳露营》的城市。
其它大大小小的幻觉还有很多，现阶段还是不能借助AI生成封面图的样子。

AI挺能编造的呢！
虽然​日语中 聞香 确实可以读作 Mon-kou ，但是 聞香炉 却只有读作 Kiki-kou-ro。
一开始AI给了错误的发音之后让AI查字典，认错之后仍然编造 Mon-kou-ro 这种读法是内行人的说法……

做了个基于Gemini的日语翻译和学习的工具。
工具会把文字或者图片翻译成中文，并且对语法和单词做讲解。
最后还会自动总结归纳里面的单词加入生词本。
妈妈再也不用担心我看日文小说和漫画遇到生僻词啦！
项目地址：https://github.com/eeg1412/gemini-japanese-learn

使用AI绘制的砂糖与盐的过年图。
被治愈到了。

继续让AI生成了 Happy Sugar Life 的手办图。
其中生成效果最好的是万圣节这张，氛围和灯光都很喜欢，而且是一次过。

让AI生成了一张 Happy Sugar Life 的手办图。
效果出乎意料的好，太尊啦！

将博客端的Nuxt版本从3升级到了4。
按照官方的升级教程走非常顺利的就升到了4。唯一的问题就是会报弃用警告，不知道是Nuxt UI导致的还是本体导致。跑了跑，发现没什么问题就上到维基萌上了。
中途想把Nuxt UI也从2升级4。但是一直没成功，按照官方教程走，结果Tailwindcss虽然安装了但是一直没生效，就退回到2的最新版了。
但是2的最新版也有点问题，就是编译时间加倍，这个问题4也有。如果继续用老版本的UI吧，提示不兼容当前Nuxt，进退两难。

昨天让 AI 以代理模式写代码。
当写到 tailwindcss ，AI用了@apply，但是一直出错。
于是 AI 觉得是 4.x 版本的问题，擅自把项目的 tailwindcss 版本降级了😂。
这个逻辑到底是跟谁学的啊？