标签:#AI(21 篇)

重新整理了一遍博客自动化翻译流程。
现在大致的流程如下:
输入内容
-> 专有名词抽取
-> AI 知识库译名确认
-> 联网检索与译名校对
-> 内容翻译
-> 目标语言封面图生成
-> 审核预览生成
-> 最终交付

效果可以查看以下博文:
https://eeg1412.github.io/wikimoe-blog-archive/en-US/post/b-tet73zn0
https://eeg1412.github.io/wikimoe-blog-archive/ja-JP/post/b-tet73zn0
https://eeg1412.github.io/wikimoe-blog-archive/zh-HK/post/b-tet73zn0
https://eeg1412.github.io/wikimoe-blog-archive/ko-KR/post/b-tet73zn0
image-i4rbxhfe
您上个月欠费共计 1269 美元!
GitHub Copilot 将于下个月起推行 Token 计费制度。为帮助用户提前了解费用变化,本月已贴心提供用量统计,并预估在新计费模式下可能产生的额外支出。
这一统计吓了我一跳,这个金额居然高达 1269.51 美元!!??
原来在过去的这么长的时间里,我一直在用 10 - 39 美元,用着上千美元的 AI ??
好日子到头了,下个月可怎么办呀!
image-ygwl1t67
近两周一直在搭配 AI 创建 维基萌 的附属多语言翻译站的代码。
现在已经有一些成果了,有兴趣的话可以访问以下链接查看:
https://eeg1412.github.io/wikimoe-blog-archive/ja-JP
https://eeg1412.github.io/wikimoe-blog-archive/en-US
https://eeg1412.github.io/wikimoe-blog-archive/zh-HK

翻译站的核心理念是只读维基萌的数据,并创建副本和翻译版。
接入了最新的 DeepSeek v4 对内容进行翻译。
翻译一篇文章的成本大约在几分钱人民币,还是很划算的!
目前来看运转良好。就是还无法完全自动化,原因主要是以下2点:
1.专有名词的翻译。
2.封面图的文字。

现状需要我通过带有搜索功能的AI先整理一遍名词的翻译,然后再以此次任务的提示词的形式将数据注入完成的。
虽然这套流程也可以用AI完成,但是考虑到不稳定性,还是需要我来人工质检一遍。
封面图的文字问题,这个其实接入OpenAI的 API 可以解决,但是现状还需要评估一下。
试用了 GitHub Copilot 的 Opus 4.7,整体体验并不理想。
我拿一个从零开始的工具类项目做测试,前后尝试了 5 次,竟然有 3 次直接被拒绝。理由都是认为这个项目需要团队投入数周甚至数月,超出了 AI 能完成的范围。但实际上,这个项目代码量最多也就一万行左右,我一个人一个周末完全可以完成。
这种“直接拒绝”的处理方式确实有些过头,系统级提示词到底是如何设计的?类似情况在 4.6 版本中从未出现过。当初难度更高的项目(比如维基萌公会)都能被耐心完成。
在我不断调整提示词、强烈要求之后,有 2 次成功执行,但结果质量依然不尽如人意,问题包括但不限于:
功能缺失、逻辑遗漏
声称“已完成”,但实际并未完成
无视我提供的前端代码,自行重新实现
在一个表单中,将多个字段通过遍历逐个提交的低效做法
这些问题,本质上更像是思考深度不足导致的。相比之下,Github Copilot 版的 4.6 思考深度是高,而 4.7 是中。
总体来说,4.7 在价格提升数倍的情况下,却带来了明显下降的体验,难免让人失望。更何况还强制下架了 4.6,以“升级”为名降低成本,这种做法确实难以令人认同。
Github Copilot 停止了新用户注册,并且下架了opus4.6,还增加了用户的每周使用限制。
看来面向个人用户的AI好时代提前结束了?
让AI生成了一个记账网页应用。
完全按照我自己的需求定制的记账应用。当然也有一定的通用性。
支持响应式布局,所以手机也能用。
本人只贡献了需求和修改了一丢丢UI体验。
成品还是很满意的,看来AI时代,小工具根本不需要下什么APP了。
直接自己定制应用的好时代来了呀!
项目地址:https://github.com/eeg1412/wikimoeBookkeeping
※截图是测试数据,不是我发财了。
image-0cbzwb4limage-intxyvm4
用几乎纯 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生成封面图的样子。
1000038440100003844110000384421000038444Gemini_Generated_Image_a85e9ea85e9ea85e
AI挺能编造的呢!
虽然​日语中 聞香 确实可以读作 Mon-kou ,但是 聞香炉 却只有读作 Kiki-kou-ro。
一开始AI给了错误的发音之后让AI查字典,认错之后仍然编造 Mon-kou-ro 这种读法是内行人的说法……
10000375241000037525
做了个基于Gemini的日语翻译和学习的工具。
工具会把文字或者图片翻译成中文,并且对语法和单词做讲解。
最后还会自动总结归纳里面的单词加入生词本。
妈妈再也不用担心我看日文小说和漫画遇到生僻词啦!
项目地址:https://github.com/eeg1412/gemini-japanese-learn
100003751710000375181000037519
继续让AI生成了 Happy Sugar Life 的手办图。
其中生成效果最好的是万圣节这张,氛围和灯光都很喜欢,而且是一次过。
Gemini_Generated_Image_nlvd16nlvd16nlvdGemini_Generated_Image_937qnk937qnk937q-136c79406-61cb-4ed8-bd68-1bc12b8e63d1-1
将博客端的Nuxt版本从3升级到了4。
按照官方的升级教程走非常顺利的就升到了4。唯一的问题就是会报弃用警告,不知道是Nuxt UI导致的还是本体导致。跑了跑,发现没什么问题就上到维基萌上了。
中途想把Nuxt UI也从2升级4。但是一直没成功,按照官方教程走,结果Tailwindcss虽然安装了但是一直没生效,就退回到2的最新版了。
但是2的最新版也有点问题,就是编译时间加倍,这个问题4也有。如果继续用老版本的UI吧,提示不兼容当前Nuxt,进退两难。
昨天让 AI 以代理模式写代码。
当写到 tailwindcss ,AI用了@apply,但是一直出错。
于是 AI 觉得是 4.x 版本的问题,擅自把项目的 tailwindcss 版本降级了😂。
这个逻辑到底是跟谁学的啊?