Subtitle Me

故事起点：当大模型把“蛇皮走位”翻译成“之字形”

做这个工具，是因为我自己玩 Bungie 的新游戏《失落星船：马拉松》（Marathon）。

国内社区小、官方中文出得慢。为了让少数同好第一时间能看懂海外的开发者访谈和高玩教学，我经常自己扒下英文视频和 SRT 字幕做翻译。

直接丢给通用大模型，翻出来的东西根本没法用：

1. 游戏黑话翻得让人哭笑不得：海外主播嘴里大喊的 "Do a zigzag across the lane!"，玩射击游戏的人都知道是“蛇一下！”（蛇皮走位避开枪线），AI 却死板地翻成“进行之字形行进”；世界观里的核心怪物 "Compiler"，圈内约定俗成是“编译体”，AI 聊着聊着就退化成了“代码编译器”；
2. 眼球根本看不过来：大模型不会按视频画面的阅读节奏切分句子。经常是原声英文讲了一长串，模型直接吐出一整句 40 多个汉字，打在 27 寸的显示器上从屏幕最左边拉到最右边。看视频的人眼睛像看网球比赛一样左右甩，极度疲劳；
3. 为了压字数乱删台词：在提示词里严厉限制“单行不要太长”，模型就会自作聪明地把后半句的修饰成分和冷幽默直接删掉。

翻译工科的规矩：先锁术语，代码守门

我本科学英语，做过笔译实习，用过 memoQ 等专业工具。所有干过翻译工程的人都知道一条铁律：稳定质量的第一步永远是先抽术语库，把名词定死再动笔。

我把这套规矩做进了工具里：

1. 前置术语抽取：在翻译前，让 Agent 先扫描全片英文，把出现的高频特殊名词单独拎出来，生成 glossary.json。我确认好“Compiler = 编译体”、“zigzag = 蛇一下”之后，后面的翻译必须死死咬住这个词表，谁改动谁失效；
2. 两套字幕彻底解耦：系统强制输出两套文件。一份是用来对标原声的 semantic.srt，行数时间戳 1:1 锁死，不删一个字；另一份是实际压片用的 readable.srt，用本地 Node.js 脚本按照人眼舒适宽度（建议 16 字符，上限 24 字符）在原句时间跨度内自动切行，绝不让字幕在屏幕上拉通跑火车；
3. 确定性代码卡死：大模型本质是概率推断，靠写长 Prompt 求它“千万别超时超长”是靠不住的。格式解析、行宽测量和时间轴比对全部交给本地纯脚本。只要有一行字超宽或者时间戳对不上，直接拦截报错，逼模型重新修。

审校与恢复也属于工作流

生成可读字幕后，Agent 会重新对照英文和当前中文逐条审校，记录已检查的范围与修复的问题。未解决的术语选择不能通过最终 QA；脚本错误阻断交付，警告需要逐项检查并说明。

任务状态保存在项目目录。继续工作前先查看状态，输入字幕变化后重新初始化并重置受影响的后续阶段。修改译文或术语后重新生成相关产物、再跑 QA，避免旧的通过记录掩盖新改动。

零依赖与开源交付

工具基于 Node.js 原生标准库编写，不依赖任何第三方 npm 包，开箱即用。目前已在 GitHub 开源发布，支持通过 npx skills add 快速集成至现代 Agent 客户端。