广树管理员
2026-08-16 14:15
@Zrzzz：ヾ(≧∇≦*)ゝ
导航
萌即是正义！时不时分享一些ACG活动记录与有趣代码的小站！
侧边栏
热门文章
1推文
在六本木 《药屋少女的呢喃》 联动 东京城市观景台。
巨大的猫猫好可爱呀！
热度
562
2推文
江之岛也在和《青春猪头》联动，推出了联动灯笼。
大家都是来江之岛欣赏美丽的灯笼夜景，就我们是来找联动灯笼的🤭。
热度
265
3推文
让 GPT5.6 生成高尔夫游戏，结果给了我这个？
披着高尔夫皮的台球？
不过好像还蛮好玩的...
试玩地址：
https://www.wikimoe.com/web_demo/ai_game/gpt5.6_sol_golf.html
热度
135
4博文
面码找到你了！探寻超平和Busters的秘密基地——《我们仍未知道那天所看见的花的名字》秩父圣地巡礼
热度
104
5博文
《上伊那牡丹，酒醉身姿似百合花般》圣地巡礼之杂司谷旧传教士馆
热度
91
6推文
《凉宫春日》20周年展
热度
90
7推文
为宣传剧场版，藤泽的 BIC CAMERA 在联动《青春猪头》。
布置非常用心，顺带还通过动画内容，宣传了一波电视机。
那么哪台电视更加适合看《青春猪头》呢？此处需要广告商。
热度
90
8博文
探访原作中被大海淹没的城市：动画《亚托莉 -我挚爱的时光-》圣地巡礼之铫子
热度
78
9博文
那些评测软文不会告诉你的 文石BOOX Leaf3C 细节体验报告
热度
78
10博文
【RPG Maker MV】插件脚本指令文档 | Script Calls
热度
65
攻略中
Steam空之轨迹 the 1st
2026年8月02日 12时 ~ 攻略中
已累计游玩2周
因父亲卡西乌斯失踪而踏上旅程的艾丝蒂尔与约书亚，
在巡游利贝尔王国的过程中，
经历了无数与未知同伴的相遇与别离，
而在旅途终点等待着两人的，究竟会是什么……？
NS节奏天国 奇迹之星
2026年7月08日 20时 ~ 攻略中
已累计游玩1个月9天
《节奏天国：奇迹之星》是一款轻松又充满创意的音乐节奏游戏，玩家只需跟随音乐节拍按下按键，就能完成跳跃、敲击空罐、制作料理等各种有趣的小挑战。游戏延续了《节奏天国》系列简单易上手、节奏感强、画风幽默的特点，让玩家在一个个短小精巧的关卡中感受音乐与反应力结合的乐趣，适合喜欢节奏游戏和轻松休闲玩法的玩家体验。
Steam告别回忆 -无垢少女- 致最爱的你
2026年6月24日 20时 ~ 攻略中
已累计游玩1个月23天
系列作发售至今经历了19年，做为其系列最终作的《告别回忆 ～无垢少女～》（以下略称为本篇）在2018年3月发售。本次的FanDisc和至今的系列作相同，带给玩家在各结局后的短篇故事。请充分享受和各个女主角们在欢乐结局后的幸福时光。
Steamfault - StP - LIGHTKRAVTE
2025年5月29日 20时 ~ 攻略中
已累计游玩1年2个月
全球累计销量超过50万份的“fault”系列最新作！故事的舞台是一个融合了奇幻与科幻的超前世界——卢森海德王国。本作讲述了生活在此地的一个平凡又平庸的究极普通市民——名为果子的少年的故事。
PSN奖杯卡
#AI
让 GPT5.6 生成高尔夫游戏，结果给了我这个？
披着高尔夫皮的台球？
不过好像还蛮好玩的...
试玩地址：
https://www.wikimoe.com/web_demo/ai_game/gpt5.6_sol_golf.html
让 GPT5.6 生成高尔夫游戏，结果给了我这个？
披着高尔夫皮的台球？
不过好像还蛮好玩的...
试玩地址：
https://www.wikimoe.com/web_demo/ai_game/gpt5.6_sol_golf.html
尝试让新出的GPT 5.6制作了一个图片压缩的小工具。
使用了electron构筑。
可以在windows电脑上直接打开使用。
恭喜你的电脑又多了一个chrome。
地址：https://github.com/eeg1412/blog-image-compression-tool
尝试让新出的GPT 5.6制作了一个图片压缩的小工具。
使用了electron构筑。
可以在windows电脑上直接打开使用。
恭喜你的电脑又多了一个chrome。
地址：https://github.com/eeg1412/blog-image-compression-tool
让AI写了个将三星手机拍摄的JPG Gain Map格式的照片转成压缩率更高的AVIF Gain Map格式的NPM包。
地址为：https://www.npmjs.com/package/libavif-with-gainmap
这样一定程度上能更快捷的管理HDR照片。
不过问题也是有的，比如服务器贫瘠的性能处理大尺寸的AVIF照片还是有点吃力的。
大照片一张大概需要30秒的样子...不知道还有没有优化的空间。
如果设备支持的话，示例图点击就能看到HDR效果啦！
让AI写了个将三星手机拍摄的JPG Gain Map格式的照片转成压缩率更高的AVIF Gain Map格式的NPM包。
地址为：https://www.npmjs.com/package/libavif-with-gainmap
这样一定程度上能更快捷的管理HDR照片。
不过问题也是有的，比如服务器贫瘠的性能处理大尺寸的AVIF照片还是有点吃力的。
大照片一张大概需要30秒的样子...不知道还有没有优化的空间。
如果设备支持的话，示例图点击就能看到HDR效果啦！
包含HDR
今日AI趣事
我说：源文章有 2 个 label，你只显示了 1 个。
Claude 说：那你一定选择的是当前文章。
我说：不是。
Claude 问：你来源选择的是源文章还是当前文章？
我说：源文章。
Claude 说：好的，那我改成不管你选哪个来源，我都显示源文章。
我说：不对，应该按照选择的来源显示。
Claude 说：不应该擅自修改，我还原代码。
我说：你还原代码，那不就 bug 还在？
Claude 又说：那你一定选择的是当前文章。
我说：不是。
Claude 又问：你来源选择的是源文章还是当前文章？
我说：源文章。
Claude 又说：好的，那我改成不管你选哪个来源，我都显示源文章。
我沉默了……
今日AI趣事
我说：源文章有 2 个 label，你只显示了 1 个。
Claude 说：那你一定选择的是当前文章。
我说：不是。
Claude 问：你来源选择的是源文章还是当前文章？
我说：源文章。
Claude 说：好的，那我改成不管你选哪个来源，我都显示源文章。
我说：不对，应该按照选择的来源显示。
Claude 说：不应该擅自修改，我还原代码。
我说：你还原代码，那不就 bug 还在？
Claude 又说：那你一定选择的是当前文章。
我说：不是。
Claude 又问：你来源选择的是源文章还是当前文章？
我说：源文章。
Claude 又说：好的，那我改成不管你选哪个来源，我都显示源文章。
我沉默了……
之前因为太忙停更了活动页面。
现在用AI半自动收集整理活动，再也不怕没时间更新啦！
而且量大管饱，唯一的缺点是暂时还不知道怎么安全整理图文。
AI整理的活动：https://www.wikimoe.com/page/event?year=2026&month=6
之前因为太忙停更了活动页面。
现在用AI半自动收集整理活动，再也不怕没时间更新啦！
而且量大管饱，唯一的缺点是暂时还不知道怎么安全整理图文。
AI整理的活动：https://www.wikimoe.com/page/event?year=2026&month=6
Deepseek v4 pro 在翻译成日语和韩语的时候总是会出现几个乱码。仅限pro，flash没有这个问题，非常奇怪。但是英语和繁体中文目前没有发现这个问题。难道是其它语言语料不足，训练不到位导致的吗？
Deepseek v4 pro 在翻译成日语和韩语的时候总是会出现几个乱码。仅限pro，flash没有这个问题，非常奇怪。但是英语和繁体中文目前没有发现这个问题。难道是其它语言语料不足，训练不到位导致的吗？
AI趣事分享。
最近让AI写代码的时候，由于接口文档遗漏了一个字段。但是功能上需要这条数据。又因为我在提示词中禁止兜底。
于是AI在一个不起眼的角落里写了一个猜字段工厂函数。根据命名习惯，排列组合几十种可能的字段名。硬是猜对了，能正常运行。
真的服了😅
AI趣事分享。
最近让AI写代码的时候，由于接口文档遗漏了一个字段。但是功能上需要这条数据。又因为我在提示词中禁止兜底。
于是AI在一个不起眼的角落里写了一个猜字段工厂函数。根据命名习惯，排列组合几十种可能的字段名。硬是猜对了，能正常运行。
真的服了😅
重新整理了一遍博客自动化翻译流程。
现在大致的流程如下：
输入内容
-> 专有名词抽取
-> 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
重新整理了一遍博客自动化翻译流程。
现在大致的流程如下：
输入内容
-> 专有名词抽取
-> 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 ？？
好日子到头了，下个月可怎么办呀！
您上个月欠费共计 1269 美元！
GitHub Copilot 将于下个月起推行 Token 计费制度。为帮助用户提前了解费用变化，本月已贴心提供用量统计，并预估在新计费模式下可能产生的额外支出。
这一统计吓了我一跳，这个金额居然高达 1269.51 美元！！？？
原来在过去的这么长的时间里，我一直在用 10 - 39 美元，用着上千美元的 AI ？？
好日子到头了，下个月可怎么办呀！
近两周一直在搭配 AI 创建 维基萌 的附属多语言翻译站的代码。
现在已经有一些成果了，有兴趣的话可以访问以下链接查看：
https://www.wikimoe.com/ja-JP
https://www.wikimoe.com/en-US
https://www.wikimoe.com/zh-HK
翻译站的核心理念是只读维基萌的数据，并创建副本和翻译版。
接入了最新的 DeepSeek v4 对内容进行翻译。
翻译一篇文章的成本大约在几分钱人民币，还是很划算的！
目前来看运转良好。就是还无法完全自动化，原因主要是以下2点：
1.专有名词的翻译。
2.封面图的文字。
现状需要我通过带有搜索功能的AI先整理一遍名词的翻译，然后再以此次任务的提示词的形式将数据注入完成的。
虽然这套流程也可以用AI完成，但是考虑到不稳定性，还是需要我来人工质检一遍。
封面图的文字问题，这个其实接入OpenAI的 API 可以解决，但是现状还需要评估一下。
近两周一直在搭配 AI 创建 维基萌 的附属多语言翻译站的代码。
现在已经有一些成果了，有兴趣的话可以访问以下链接查看：
https://www.wikimoe.com/ja-JP
https://www.wikimoe.com/en-US
https://www.wikimoe.com/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 的 Opus 4.7，整体体验并不理想。
我拿一个从零开始的工具类项目做测试，前后尝试了 5 次，竟然有 3 次直接被拒绝。理由都是认为这个项目需要团队投入数周甚至数月，超出了 AI 能完成的范围。但实际上，这个项目代码量最多也就一万行左右，我一个人一个周末完全可以完成。
这种“直接拒绝”的处理方式确实有些过头，系统级提示词到底是如何设计的？类似情况在 4.6 版本中从未出现过。当初难度更高的项目（比如维基萌公会）都能被耐心完成。
在我不断调整提示词、强烈要求之后，有 2 次成功执行，但结果质量依然不尽如人意，问题包括但不限于：
功能缺失、逻辑遗漏
声称“已完成”，但实际并未完成
无视我提供的前端代码，自行重新实现
在一个表单中，将多个字段通过遍历逐个提交的低效做法
这些问题，本质上更像是思考深度不足导致的。相比之下，Github Copilot 版的 4.6 思考深度是高，而 4.7 是中。
总体来说，4.7 在价格提升数倍的情况下，却带来了明显下降的体验，难免让人失望。更何况还强制下架了 4.6，以“升级”为名降低成本，这种做法确实难以令人认同。
Github Copilot 停止了新用户注册，并且下架了opus4.6，还增加了用户的每周使用限制。
看来面向个人用户的AI好时代提前结束了？
Github Copilot 停止了新用户注册，并且下架了opus4.6，还增加了用户的每周使用限制。
看来面向个人用户的AI好时代提前结束了？
1/2