一、基本步骤：
一般来说，制作一个ai翻译补丁分为解包封包、翻译、修图、程序四个部分，其中修图和程序这两部分可以略过，尤其是修图。
解包封包：顾名思义，就是把包含脚本的文本提取出来翻译完后重新封回去，其中封包可以分为封包和免封包，具体看引擎。比如patch.xp3，update1.ypf这就是封包；根目录放ysbin文件夹，data文件夹或者直接放几十几百个脚本文件这种就是免封包。
翻译：利用大模型将人名和相关的日文文本翻译成中文，其中翻译的质量和你提取的文本以及模型以及字典以及翻译提示词有紧密关联。提取的文本尽量保持纯文本，像注音比如ruby的这些看你们的习惯删不删，但是因为注音封回去后出问题自己后果自负；模型这个怎么说好呢，如果是以前我会无脑推荐c35s，但是现在只能说看你们自己的财力，cluade和gemini都是不错的选择，但是cluade由于删了大量的瑟瑟词料，所以你们懂得都懂，我是推荐gemini就是了。
修图：最黑奴的一个，基本没几个人会想要修图，所以这个可有可无。
程序：这个就是涉及到了改编码和范围这些逆向工程，这方面往深了说就不是萌新能理解的东西，要用到x64dbg，Ollydbg，WinHex，010Editor这些相关东西。大家可以去看看dir-a或者芯晴的视频，可以初步接触一下相关知识。
二、码表映射：
首先我们要理清一个概念，大多数日文游戏使用Shift-JIS（简称sjis，或cp932，cp932其实是sjis的超集）编码，这种编码缺少很多汉化所需的简体中文字符，如果直接写入中文就会出现我们常说的乱码。
因为sjis是针对日文的一套编码规则，它的编码规则中存在一部分汉字，但是还有许多汉字是不存在的，给汉化带来了极其不友好的现象。
当然也有一些引擎除外，比如krkr、新版BGI、新版artemis、ty等等引擎，他们因为支持utf8、utf16这些编码，所以直接u8u16启动（），根本不用担心会出现乱码现象。所以啊，在补丁制作时编码处理是一个绕不开的问题。
故在汉化一部gal时就出现了两种主流解决方案：第一种是汉化主流，第二种是AI主流。
第一种就是我们传统的编码修改：它的核心思想就是将游戏的编码系统从日文的sjis修改为支持中文的gbk编码。gbk支持绝大部分中文、日文字符，但是也有严重的缺点，那就是gal中常用的♪、♡等符号在sjis编码中支持，但在gbk中不支持，只能删掉或者造字体映射过去。
但是修改游戏为gbk的情况较为复杂，难度较高，有时还会引入很多问题需要处理，很多人可能会止步于此。
实施步骤一般来说就是：
1.将翻译文本以gbk编码写入脚本。
2.通过调试工具或API Hook修改游戏渲染文本的函数，将字体字符集从日文（0x80）改为中文（0x86）。
3.修改游戏程序中判断字符是单字节还是双字节的范围逻辑，以适应gbk编码的范围。
我的天哪，你看看这个就知道对于大部分人来说非常困难，根本解决不了编码和边界问题。因此出现了第二种方案，也就是大部分AI翻译使用的一个方案——码表映射
既然编码修改这么复杂，那我们不改变游戏原有的sjis编码不就行了吗，我们知道，sjis编码里面有许许多多奇怪的字符，那些字符在中文显示时完全用不到，哎那我们是不是可以想到，既然在中文显示时完全用不到，那我们是不是可以以此来“欺骗”游戏建立一个新规则，将一个不支持的汉字“映射”到一个在sjis编码中存在但不常用的字符的码位上。
打个比方啊，比如“你”这个字符在sjis编码中是不存在，那么我们就找个sjis编码中存在但不常用的字符比如“凜”，让“你”这个字符占据“凜”的码位。
假如我们翻译了一个文本“你好”，如果直接sjis封回原游戏，只会显示“好”而不会显示“你好”，但是如果我们码表映射了后，再sjis封回后就会显示成“凜好”，哎是不是突然茅厕顿开了。
那么日繁又该怎么变成简体呢，就需要我们的日繁字体了，也就是你们经常看见的带有cnjp后缀的字体。既然“你”这个字符占据了“凜”的码位，那么我们再变回去啊，这就是一种很取巧的方式，游戏读取码位时以为要显示“凜”，但从我们提供的字体中找到了“你”的字形并显示出来。
这个例子是SE里面自带的映射表，我推荐大家造动态映射这些工具来生成对应的码表。
那么又该怎么让游戏去读取这个字体呢，就要用到我们的hook了，通过劫持原游戏的字体函数让其游戏读取我们的字体，进而让其显示简体。
三：制作前提
1.一定要先打好所有修正补丁和dlc补丁后再开始，修正补丁很有可能会影响文本。
2.一定要在解包后第一时间就测试能否封包（免封包），要尝试多修改下人名、文本再弄回去看看游戏能否照常运行；不要忽略这步直接开始翻译，别等你花个大几百元跑完了才发现封不了然后换工具发现解包的工具和封包的工具（甚至没有合适的封包工具）不互通你就等着气急败坏在站里发癫被封号最后咬打火机吧。
3.一定要确认把包括修正补丁和DLC补丁在内的所有文本全部提取出来；在提取文本后第一时间就检查自己的文本是否多提漏提！别到时跑完了发现提多了把控制符也翻译了或者提少了还要再提取翻译一遍（等翻译完后发现还要修几百处bug、几十段漏翻你就老实了）。
四、虚拟打包：
主要是针对免封包的游戏，可能会在游戏根目录里放几十几百个翻译后的文件，不仅丑而且非常占用地方，所以一般来说可以通过VFS来进行文件打包成一个chs文件这种的，不想自己写VFS也可以用Enigma Virtual Box进行虚拟打包，但是Enigma的适用性你们自己考虑一下后果吧。
五、hook函数：
hook的话，通过hook技术来使得游戏程序调用自己的字体，窗口标题，VFS，弹窗，转区，文件重定向等等功能，这个的话算补丁制作过程中非常重要的一点了，学会hook会让你的补丁制作起来更加便利尤其是在字体等方面。
六、日繁字体制作：
日繁字体的制作过程，找到一个你喜欢的字体，然后将其想办法变成伪日文字体，使得那些游戏可以读取到该字体（字体库的字符最好全一点），然后通过映射表的方式制作相关字体，一般来说，最通用的就是SExtractor的映射表subs_cn_jp.json，基本所有的日繁字体都是基于此制作的，除非你自己搞个动态映射。
七、补丁发布：
这个是重点，我们发布自己制作的补丁的时候，最好要规范下自己的补丁名称，不要使用“AI汉化”、“AI翻译”、“机翻补丁”、“汉化补丁”这种笼统或者错误的名称（倒狗倒卖资源的时候就喜欢收集起来全部改称精翻汉化，一看就和机翻有明显区别然后敛财）。
其实仔细观察就会发现，那些经常发补丁的大佬们并不喜欢用“ai补丁”、“机翻补丁”这种笼统的称呼，也不会说这是“汉化”，发布的补丁一般叫“XXX模型翻译补丁”，比如“千恋万花 gemini-3-pro-preview翻译补丁”。