Deepseek v4 pro 在翻译成日语和韩语的时候总是会出现几个乱码。仅限pro，flash没有这个问题，非常奇怪。但是英语和繁体中文目前没有发现这个问题。难道是其它语言语料不足，训练不到位导致的吗？

重新整理了一遍博客自动化翻译流程。 现在大致的流程如下： 输入内容 -> 专有名词抽取 -> AI 知识库译名确认 -> 联网检索与译名校对 -> 内容翻译 -> 目标语言封面图生成 -> 审核预览生成 -> 最终交付 效果可以查看以下博文： https://www.wikimoe.com/en-US/post/b-tet73zn0 https://www.wikimoe.com/ja-JP/post/b-tet73zn0 https://www.wikimoe.com/zh-HK/post/b-tet73zn0 https://www.wikimoe.com/ko-KR/post/b-tet73zn0

您上个月欠费共计 1269 美元！ GitHub Copilot 将于下个月起推行 Token 计费制度。为帮助用户提前了解费用变化，本月已贴心提供用量统计，并预估在新计费模式下可能产生的额外支出。 这一统计吓了我一跳，这个金额居然高达 1269.51 美元！！？？ 原来在过去的这么长的时间里，我一直在用 10 - 39 美元，用着上千美元的 AI ？？ 好日子到头了，下个月可怎么办呀！

让AI生成了头像的表情包，都好可爱呀！

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

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

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

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