Coming Heart 资源分析（七）
我的一位读者朋友说用 codex，汉化了 pc98 的 desire，于是我也尝试了一下。
目录
tldr
这篇以我的经历为主，所以我觉得先总结一下比较好，节约读者时间， 方便朋友们判断是否有必要读。
首先我的模型不是原装模型，是量大管饱的深度求索，也没有中间商赚差价。 所以我眼中的 codex 和 claude，跟原厂一定是有差距的，那为什么不用原厂， 一个是贫穷，另一个是怕封号，据了解，首先新账户容易被封，然后老账号封了更麻烦， 所以我也就没去用原厂。
有了前提我就可以将结论了：目前 codex/claude 比较擅长执行明确的指令，不擅长分析未知问题。
这似乎和本体并没有关系，是使用过程中得到的一个推论，本体相关结论请参照总结。
听我解释
我一开始写的结论是这样：目前 codex/claude 比较擅长执行明确的指令，不擅长分析问题。
可能有读者会觉得这两句有矛盾：我让它分析一个具体问题，所有东西都具体说明， 那其实不就是一个明确的指令？两者的差异在于，前者其实有一个明确的结果， 我也可以办得到，只是我知识储备不够，干的时候要边查资料边操作。而后者， 我不知道答案，或者结果是什么样子，这个时候把这个东西交给 cc， 那就有点赌命的意思了，它给你的答案有可能是对的，有可能是错的，所以我修正了一下结论。
还有一种情况，它分析得太复杂了，或者题目太大了，超过了它得处理能力，这个不重要， 可以忽略。
详情
看了看我的用量统计，我大概是用了十天的时间，前两天先用 codex，感觉确实能成事， 但是想想还没用过 claude，就又用了一天 claude，claude 是真烧钱工具， 一天下来就烧掉了我一百块钱，算了一下有点心疼现在的孩子，房租估计得一两千， 还得付模型商一两千，这得挣多少才能回本。于是放弃 claude 退守 codex。
Claude 使用时有一个实时的 token 使用提醒，这个很有迷惑性。看着也就几千， 感觉会比 codex 还要省，但是用得绝对不含糊，一天下来将近三亿（2.7）， 虽然 90% 的用量命中了缓存，但是数量级在那里。 这要是用原厂，不晓得得花多少， 当然了，也许原厂一下子就解决了呢。
Codex 对 token 的消耗就温柔了很多，高的时候一天也就十几块， 还是在我检讨了一次模型配置之后，因为我发现它默认是用 flash 模型， 不像 claude 大大咧咧就给我直接用 pro 模型。所以我后来把 codex 调到 pro 模型， 就是前面说的一天十几块钱的水平。
对比 claude 和 codex，我的感觉是 claude 效果略好，但是绝对不值这个价钱， 因为我从这两个工具里获得的有价值的信息，仅仅比我之前自己研究得来的信息多了那么一点点。 当然它们俩确实节约了大把的研究时间，我以前花在调试、看 log 上的时间可不止这十天。
问题
这几天我折腾了点什么呢，终于回到标题上了，对了，我在「指导」AI 帮我汉化游戏， 把原本我想退休后干的事情提前了。
这个游戏前面我们做过点研究了，图像部分我们已经解开了，这部分和汉化不涉及。 脚本部分，我们已经定位到了文本，那么其实汉化要做的部分， 就是把文本换成中文就结束了，这是个精细体力活。不过我并没有把我的研究成果告诉 AI， 我想看看它自己有没有这么神。
我的做法是：告诉它我想要什么，剩下只根据它的需求，或者测试结果做出反馈， 比如它需要装什么包，我给它装好，替换游戏文件后运行出现哪些问题，我告诉它。
都有些插曲，但是两个工具都做到了一个正常的标题画面：
但是我们知道，标题画面是最简单的，要通过复杂文字场景的考验，才说明方案可行， 而 claude 和 codex 都栽倒在了第一个场景 ch1。
栽倒的现象差不多，都是流程或是文字显示错误，但是几天试错我意识到， 把这些现象告诉 AI，基本上它是解决不了了。因为看上去， 它基本也是推测什么样的情况会出现我遇到的错误，先推测，再修复推测的问题， 推测层层叠加，就变得时好时坏，或者一时东墙好了，一时西墙又坏了。
现在看来，其实都是一个问题：译文长度跟原文长度不同。
译文跟原文长度不同，这个其实是很难避免的，日文八个字，一定要求中文也八个字，
我想大部分翻译都会崩溃。AI 想了两个「好办法」，一个是用全角空格补上，
一个是用 \0 补上。
这两个其实都是馊主意，补全角空格，会让画面上的翻页提示变得很怪。
补 \0 则是完全摧毁了字符区的布局。这两个其实都在回避一个问题，
程序是如何定位该用哪个字符串的。
AI 装模做样检查了老半天，信誓旦旦跟我说，它没有保存字符串的定位， 就是一个一个按顺序用的。如果是这个样子，那确实，空格补全理论上可以解决这个问题， 只要我们保证译文不长于原文。但是这样太奇怪了，我不想接受这个方案。
所以在这个进度点上，我卡了几天时间。尝试让 AI 找出字符串的定位方式， 但是它就是不能，我意识到，我可能要调试程序去看它到底是怎么走的， 才能知道如何定位字符串。因为懒，我也不想弄这个，但是这几天我确信了我的观点： 文件中一定有字符串的定位。因为对于 startup.mpx 的脚本文本：
（Ｃ）１９９５，９６ Ｍａｙ－Ｂｅ ＳＯＦＴ
ゲーム開始
おまけ
ＣＧ鑑賞
回想モード
如果我翻译为：
（Ｃ）１９９５，９６ Ｍａｙ－Ｂｅ ＳＯＦＴ
游戏开始
特典
ＣＧ欣赏
不重要
相较于原文，「游戏开始」比「ゲーム開始」少了一个字，而接下来， 「特典」就只显示了「典」，「ＣＧ欣赏」也会跟着变成「欣赏」。每少一个字， 下一串字就会跳掉一个字，还会累计，那我想一定是有个字符串定位表没跑了。
但是 AI 对这个事情的态度依然是：
给我扯说可能还有哪里有问题了，我想得了，我自己解决吧。
不过我也没打算自己去跟字符串的定位，我打算出个简化方案：译文不得超过原文，
少于原文的部分用 \0 补齐。后面基本我都是这个思路，让 AI 写脚本，
我来分析解码编码中的问题。很快我找到了AI 补齐方案的问题，比如：
字符串以 \0 结尾，但是切割时还要考虑脚本（%K），像这句，
是两串文本组成的一个字符串，那么这就会出现我们要在哪里对齐的问题，
如果用 \0 对齐，那么程序读到 \0 就认为字符串结束了，
然后去查表执行下一段脚本，那么就丢失了一部分脚本。
所以这两段要统一对齐在最后一个 \0 的地方，这个就是 AI 百思不得其解的问题，
要么强制接受难看的全角空格，要么就错给你看。
看，我也回避了程序如何定位字符串这个问题，但是我的解决方案要比 AI 高明一点点。
解决了这个问题，那我其实只差一个好翻译了，不过我其实不太敢用深度求索来翻译游戏脚本， 基本还是靠可以勉强应付的匿名模型来翻译，说来好笑，多数时候我甚至得不到翻译， 模型经常原样返给我，点名批评 grok 和 gemini，匿名用户也是用户，要么就不给用呗。
说来之前总结到的经验，比如建个翻译对照表啊什么的，用是用上了，但是感觉用处不大， 每次都是卡在其他没遇过的事情上了。这可能也是跟前面对照上了， AI 擅长解决已知明确有解的问题，不明确的问题，它还是相当于一个占星术。
总结
我最近有点理解为啥从今年起，常有机器人流量来访问我的站，很容易分辨， 访问了很多地址，但是停留时间是零，我的文章对于模型来说一点也不复杂吧。 这可能是有人在把我炼成 skill？
大模型像是新一轮的圈地运动，我写的文章虽然乱七八糟，不过知识和经验我想是有的， 但是不够拿去卖，而大模型想了一个办法，把一群我这样人的知识打包在了一起， 然后用 token 的形式卖出去。其实还是在卖知识，别人的知识。
我是不是有点过于自我陶醉了，这甚至不是个总结，赶紧回到正题：
- MPX 中包含脚本字符串（这个是之前的内容）。
- MPX 中一定以某种形式保存了字符串表，虽然我还没找到。
- 全部文本都是双字节 sjis，可以通过替换的方式进行汉化。
- 单字节字符是脚本命令，这也是为啥公司名要写全角的 Ｍａｙ－Ｂｅ ＳＯＦＴ，程序很粗暴地把单字节当脚本命令，双字节当文本。而两者又混在一起放入字符串。
- 油管 Demo
- Chandice 也有一部分文本，加密方式大致相同，参考 PS
不会有人催更这个吧……这只是我年轻时偶然遇到的一个游戏。
PS
后续还是遇到了一些脚本中的乱码，还挺好玩的，但不值得写一篇，放在这里再凑点字。
界面上的乱码，基本上我都选择忽略了，因为也不耽误玩，改 exe 文件又挺痛苦， 但是大概怎么改我们也知道，所以就先放一放。
原本我以为，解开 mpx 以后，游戏内容应该没什么乱码了，不过既然我在写字， 那说明事实并不是这样。
根据上下文，我们可以很快定位到，是 %v 这个脚本指令：
【雪 绪】%v0……可是……%v0……好舒服嘛……%v1！%k
【 享 】唔唔……。%k
【雪 绪】%v1……%v0……%v0……%v0……。%v1。%k
很显然 %v 被换成了什么其他文字，有意思的是长度还不固定。那这个就引起我的警觉了，
看来还有未知部分，我不晓得其他人会往哪个方向猜，我的第一想法是：这游戏里有音效？
因为 v 我猜了 voice，于是去翻游戏里的 wave 文件，就那么几个，很快我否定了这个想法： 我对上下文的理解产生了幻觉。
用 ghidra 简单翻了一下对应脚本处理的代码，%v 后一定是一个数字，
然后根据这个数字结合一个随机效果，把一段数据复制到某个地方。
这个我想 AI 可能搞不定了，硬着头皮打开 ollydbg 调试，因为很容易复现， 很快就找到数据的源头，再去看谁写进去的，结果发现是 chandice：
这个是解码后的数据，因为文件很小，看名字 chan 可能是 chance，再加上 dice。 推测是做随机效果功能的一些数据，就没去管它，没想到是干这个的…… 一共有四组 chandice，脚本开头指定一个 chandice，然后根据 v0、v1、v2， 随机出一个语气词，放进对话中，来让玩家每次回想场景都有所不同， 那么我们也很容易估计，不同的 chandice 代表不同的人，v0、v1、v2， 代表三个不同的阶段……
这个创意真是一言难尽，不晓得游戏策划想出这个构思时，觉得自己的想法到底如何。