如题，本贴是Claude辅助从《真・女神转生NINE》汉化项目中总结的技能；这还是属于AI汉化【术】的范畴，先抛个砖。
之后的帖子里我会再结合个人经验，介绍更通用的AI辅助汉化工程的思路，希望能够回答清楚为什么“别人家的AI能干活，我家的AI像个弱智”的问题😅。
对于以下内容，Claude Code、Codex，以及使用基于Claude Code的国内Agent，如Kimi K2.5、GLM-5、MiniMax-M2.5等，可以转换成SKILL.md格式，从而让AI从本汉化工程中汲取经验，实现复用到其他类似汉化项目之目的。
主机游戏汉化工程通用技能大纲
从 SMT NINE（OG Xbox）日→中汉化实战中提炼 | 适用于 Xbox / PS2 / GC / Wii / PSP 等平台
1 逆向
→
2 提取
→
3 翻译
→
4 后处理
→
5 字库
→
6 写回
→
7 部署
1.1 二进制格式逆向
核心能力
-
十六进制编辑器阅读raw二进制，识别 magic bytes、段偏移表、指针表
-
区分固定长度/变长记录，区分 bytecode 区（VM 指令流）与 data 区（文本池）
-
理解编码：SJIS / cp932 / EUC-JP / UTF-16，以及游戏自定义 TBL 映射
SMT NINE 实例
-
.mgs 有两种编译器变体（FF04 variant / pure bytecode variant），需逐文件识别
-
.mgp 场景包：嵌套结构含 bytecode 区 + text 区 + 5 个 section offset
-
XBE 可执行文件中 UI 字符串散布在
.rdata / .data 段内
-
RTS 脚本打包为 PACK 容器内的
.inf 脚本文件
1.2 字库格式逆向
核心能力
-
XPR / TIM2 / GIM / NFTR 等纹理格式解析；DXT1(BC1) / DXT5 编解码
-
TBL（码位→字形映射）结构解析；字形排列：页数、格子尺寸、block 对齐约束
SMT NINE 实例
-
sys_f24.xpr：12 页 512×512 BC1，24×24 格子（4×4 对齐，可无损替换）
-
sys_f18.xpr：18×18 格子（不对齐，需 block 级 pixel overlay）
-
原版 9 页扩展到 12 页，容纳 ~3200 个中文汉字
通用要点一款游戏可能有多种脚本格式（对话/菜单/战斗/教程），每种需独立分析。bytecode 中的文本引用指令决定了提取和回写逻辑。纹理 block 对齐约束决定了字库替换方案。
2.1 脚本文本提取
-
Python
struct 二进制解析，SJIS lead byte 范围判断定位文本
-
用 TBL 码表做 code→char 解码（游戏可能自定义码位，不能直接 cp932）
-
控制码提取时保留为标记（如
<FF><07>）
JSON 格式设计
{ "offset": 108596,
"text": "ねえ お兄ちゃん\nボクの いっしょ～の",
"raw_hex": "82cb82a6814082a88c5a...",
"parts": [
{"offset": 108596, "length": 16, "raw_hex": "..."},
{"offset": 108613, "length": 20, "raw_hex": "..."}
],
"chinese": "" }
2.2 合并策略（Smart Merge）
-
将同一文本框内多行合并为一个翻译单元——翻译更连贯
-
MGS FF04 variant：gap 中有
FF04=边界，无=合并
-
MGS bytecode variant：解析 VM 指令流判断分页边界
-
MGP：gap=1 合并（相邻 null 间文本属同一框）
2.3 多路线去重
-
按 offset + raw_hex 精确匹配，分类为 common / different / route-only
-
SMT NINE：Script（男主）与 Scriptf（女主）86% 文本一致，只翻译一次
2.4 辅助资源提取
-
XBE/可执行文件中的 UI 字符串（菜单、系统提示、格式化字符串）
-
RTS 战略模式脚本、角色名表等
3.1 LLM 翻译
-
设计翻译 prompt：角色表、术语表、语气要求、格式约束
-
上下文窗口：每条附带前后各 N 条上下文（SMT NINE 用 5 条）
-
速率控制：429 重试 + backoff + 配额等待自动 sleep
-
增量翻译：只翻未翻条目，翻译缓存（JP→CN 映射）避免重复调用
Prompt 设计要点
-
完整术语对照表（人名/地名/组织/道具）
-
翻译风格规则（如"不加句号"、"保留语气词表现力"）
-
格式要求（
\n 行数与原文一致、控制码原样保留）
3.2 术语对照表
-
收集全部专有名词，确定唯一标准翻译（参考官方中文版/系列惯例）
-
记录 LLM 常产生的错误变体，用于后处理替换
-
SMT NINE：
translation_glossary.md（7 章节）+ 恶魔名表（400+）+ 技能名表
3.3 翻译缓存管理
-
cache 是"单一真相源"——所有 translated JSON 都从 cache 同步生成
-
JP→CN 映射 + 来源引用（file + offset），去重/排序/标准化
-
特殊文件（如含 speaker_cn 的 EVE）需要专用 cache
4.1 术语统一替换
-
按术语表全局替换（长词优先，避免短词误伤）
-
恶魔名/技能名交叉比对（查 JP 原文确认实体再替换 CN）
4.2 标点修复
-
确定性规则优先（如"JP 无句号 → CN 也删句号"）
-
LLM 辅助处理复杂标点逻辑；保留控制码不动
4.3 假名残留清理
|
类型
|
示例
|
处理
|
|
完全未翻译
|
整条还是日文
|
重翻/人工翻译
|
|
夹带假名
|
ノイズ的出现
|
术语表替换：噪声的出现
|
|
括号注音
|
恶魔克星（デバッカー）
|
删除括号注音
|
4.4 字符长度检查
-
不同文件有不同行长上限（13 / 18 / 23 字符等）
-
超长条目：缩写 / 拆行 / 交给 LLM 精简
4.5 全角化
-
半角→全角映射（
!→！），保护 %s 等格式占位符和 <FF> 等控制码不被转换
4.6 质量检测
-
垃圾翻译（LLM 返回审核笔记）、符号不在字库中、空翻译、跨条目重叠
注意检测关键词不能过宽——"应该是"在 39 条正常对话中出现，不能作为垃圾检测词。
5.1 用字量统计
-
遍历翻译 JSON 统计实际使用的 CJK 字符集合（
0x4E00-0x9FFF 等）
-
与现有 TBL 交叉比对，输出频率表 + 缺失字符列表
5.2 字形渲染
-
Pillow / FreeType 渲染 TTF 字体到位图
-
描边/阴影效果；coverage-based 抗锯齿 + hysteresis 阈值
-
BC1/DXT1 编码：严格控制调色板索引（透明/描边/填充/AA 边缘）
-
block 不对齐时需 block 级 decode→overlay→re-encode
5.3 码表生成
|
输出物
|
用途
|
二进制 TBL（sysfont.tbl）
|
游戏运行时
|
文本 TBL（XXXX=字）
|
Python 写回工具编码
|
|
JSON 映射
|
多套字库间共享码位
|
绝不能混用二进制 TBL 和文本 TBL 用途不同。多套字库（大字/小字）必须共享同一套码位映射。
6.1 脚本写回
-
用中文 TBL 将 Unicode 编码为 SJIS 码字节
-
按
parts 数组将合并翻译拆回原始槽位
-
固定偏移格式：等长替换，超长报错
-
可变文本区格式：重建文本区，更新指针表和全部 section offset
-
空记录用全角空格（
0x8140）填充——b"" 会导致引擎挂起
-
角色名用内容匹配法独立翻译
6.2 XBE 写回
-
PE 段解析，只写
.rdata / .data 段
-
保护格式占位符（
%s/%02d）；打代码补丁（字库页数、SJIS 上限等）
6.3 RTS / 特殊脚本写回
-
PACK 容器解包→替换→重建
-
虚拟硬盘直接修补（qcow2 → FATX 文件系统定位 → 簇链写入）
7.1 部署链
字库: sys_f24_final_game.xpr → Media/SysFont/sys_f24.xpr
sys_f18_final_game.xpr → Media/SysFont/sys_f18.xpr
sysfont.tbl (二进制) → Media/SysFont/sysfont.tbl
脚本: output/Script/* → Media/Script/*
output/Scriptf/* → Media/Scriptf/*
XBE: output/default.xbe → 根目录 default.xbe
RTS: output/RTS/Scripts/* → Media/RTS/Scripts/*
7.2 易错清单
|
错误
|
后果
|
|
文本 TBL 当运行时 TBL 部署
|
游戏无法启动
|
|
提取时用中文 TBL
|
所有日文变乱码
|
|
多套字库码位不一致
|
小字体乱码
|
|
ISO 版 XBE 忘改路径标志
|
ISO 无法启动
|
|
从已污染的 Media/ 提取
|
得到半成品
|
空记录写入 b""
|
引擎挂起/崩溃
|
|
不更新 section offset
|
对话触发异常
|
|
更新 ISO 后忘更新 HDD 缓存
|
旧翻译残留
|
|
工具
|
职责
|
复用度
|
extract_scripts.py
|
二进制→JSON 提取（TBL 解码、smart merge、去重）
|
需定制
|
translate_context.py
|
LLM 逐条翻译（上下文窗口、缓存、速率控制）
|
高
|
fix_translations.py
|
术语替换 + 标点修复 + 假名清理 + 长度检查
|
高
|
apply_scripts_json.py
|
JSON→二进制写回（TBL 编码、slot 拆分、offset 更新）
|
需定制
|
apply_xbe.py
|
XBE UI 字符串写回 + 代码补丁
|
中
|
cache_paths.py / apply_cache_only.py
|
翻译缓存读写、同步、标准化
|
高
|
fullwidth_ascii.py
|
半角→全角转换（保护控制码/占位符）
|
高
|
count_hanzi.py + build_final_hanzi_table.py
|
用字量统计→字库字表生成
|
高
|
build_smt_nine_f24/f18.py
|
字形渲染→纹理写入
|
中
|
二进制安全
-
永远不要在没有备份的情况下修改原始文件
-
写回宁可报错也不要静默截断
-
空记录用安全填充，不要写 b""
TBL 管理
-
提取用原版 TBL，写回用中文 TBL，运行时用二进制 TBL——三者不能混
-
文本格式 TBL 可能将码位映射为空串→静默丢字
-
检测 TBL 格式看文件头字节，不要靠扩展名
LLM 翻译质量
-
同一术语多种译法是最大一致性问题——后处理必须全局替换
-
LLM 有时返回审核笔记而非翻译——需检测过滤（但关键词不能过宽）
-
假名残留需正则+术语表+人工三级处理
-
上下文对质量影响很大——逐条翻务必附带前后文
偏移与结构
-
改文本长度后 offset/pointer/section header 必须全部同步更新
-
section offset 可能有"非显而易见"含义——不能假设它指向末尾
-
合并条目的 parts 可能与其他条目重叠——需提取和写回层双重保护
部署一致性
-
同一游戏不同加载方式（目录/ISO/HDD）可能需要不同标志
-
有些游戏会缓存脚本到硬盘——更新 ISO 后必须同步清缓存
-
测试所有分支路径（男/女主角、不同选项）
字库容量
-
先统计实际用字量再决定方案——避免后期槽位不够
-
多套字库必须共享码位映射
-
保留原版符号/假名区原始字节
主机游戏汉化工程通用技能大纲 — 提炼自《真·女神转生 NINE》日→中汉化工程
上一篇：
最近准备重装房间，请教ps5pro 搭配多大尺寸得显示器比较合适。求指导下一篇：没了
