lyrics-translator

把日语歌词翻译为中文歌词。流程之所以分四步(通读定调 → 初译 → 子代理复核 → 修订交付),是因为歌词和普通文本不同:它是一个整体的艺术品,有统一的情感基调和风格。拿到歌词就逐行翻,每一行单看都对,拼起来却风格涣散、情感曲线断裂。所以先通读全曲、确定风格,再动笔;译完再让一双"没有参与翻译的眼睛"挑毛病,最后修订交付。

Step 0: 输入与输出约定

输入: 歌词文件,常见 .txt / .lrc。

• 用户给了路径 → 直接读
• 用户只是说"翻译这首歌"没给路径 → 在当前目录找歌词文件;找不到就问,不要瞎猜
• 用户直接在对话里粘贴了歌词 → 先存成 .txt 文件(用歌名或合理的名字命名),再走流程,这样最终交付物有处可放

输出: 与原文件同目录,纯中文译文:

• yozora.txt → yozora_zh.txt
• ハルカ_jpn.txt → ハルカ_zh.txt(已有语言后缀则替换)
• track01.lrc → track01_zh.lrc(.lrc 的时间标签 [mm:ss.xx] 原样保留,只翻译标签后的文本)

如果用户要日中对照版,在 _zh 文件之外另出 <主名>_对照.txt(一行日文、一行中文、段间空行)。默认不出。

Step 1: 通读与定调

先把整首歌词读完,再决定任何事。 这一步的产出是一段"风格定位"判断,它会贯穿初译、复核、修订三步,所以值得认真做。

通读时弄清楚:

1. 情感色彩: 全曲基调(哀伤/热血/温柔/愤怒/俏皮…),以及情感曲线——很多歌主歌压抑、副歌爆发,或结尾反转,译文要能跟住这条曲线
2. 思想主题: 这首歌到底在说什么?失恋、告别、自我和解、对世界的宣战……主题决定关键词的分量
3. 叙述视角: 谁在唱、对谁唱。日语歌词大量省略主语,人称(我/你/他)必须根据全曲叙事统一判断,不能逐句猜
4. 原文语体: 口语还是文语?有没有古语、方言、外来语轰炸?原文的语体是风格判断最硬的依据
5. 结构: 主歌/副歌/桥段划分,重复段在哪里(重复段必须用统一译法)

背景信息: 如果从文件名或歌词内容能认出具体歌曲(动画/游戏/偶像企划的歌往往和剧情强绑定,剧情会改变歌词的理解),可以快速 WebSearch 确认出处和创作背景。认不出就凭文本翻,不要编造背景。

选定风格: 用一两句话写下风格定位和理由,例如:"原文为口语体、主题是少年向世界证明自己,副歌情绪外放——采用直白有力的现代语,短句为主,避免文雅辞藻"。可选的风格方向(开放清单,仅供启发):诗化抒情、古风雅言、直白口语、热血少年、摇滚冷峻、民谣温暖、演歌沧桑、电波俏皮。风格服务于歌,不是炫技——判断依据永远是原文的语体和情感,而不是"哪种风格显得译者厉害"。

如果用户明确指定了风格,用户优先,跳过自动判断(但仍要写下风格定位,供复核环节对照)。

Step 2: 初译 — 信达雅怎么落地

逐行翻译全曲。三个准则在歌词语境下的具体含义:

信(忠实) — 忠实的对象是意象、情感和叙事,不是字面语序。

• 原文的意象(月、雨、车站、未送出的信)一个都不丢,也不擅自替换成"更美的"中文意象
• 不要"翻译升级":原文平实就译得平实,不要替作者抒情;同样不要降级,把浓烈的句子译淡
• 暧昧是日语歌词的核心手法。原文故意不说破的(那个人是死了还是走了?这是爱情还是友情?),译文同样保持开放,不要替听众解读
• 拿不准的多义句,选择与全曲主题一致的那个读法

达(通顺) — 译文要像中文歌词,不是翻译稿。

• 自检方法:遮住原文,单读中文。如果出现"的"字连串、欧化长定语、"虽然…但是"这类显式逻辑词(歌词的逻辑通常是隐含的),就是翻译腔,重写
• 中文比日语紧凑,译文行一般应比原文行短。凝练优先,一行歌词不要塞成一行散文
• 不强行押韵:顺手能押就押,为了韵脚牺牲信或达就是丢了西瓜捡芝麻

雅(风格) — 雅不等于堆辞藻,口语摇滚译成四字成语连发恰恰是不雅。雅 = 措辞精准、贴合 Step 1 选定的风格,并且全曲统一。另外,当原文有规整的音数律(如七五调、文语对句)时,译文宜用相对工整的句式呼应——不是机械对齐字数,而是让读者能感到原文的节奏感;原文本身松散口语的,不要强行工整。

技术性约定:

• 行数对应: 一行对一行,不合并、不拆分,空行(段落分隔)原样保留——用户可能拿译文去做字幕或对照排版
• 重复段一致: 副歌每次出现用同一译法;但若原文重复段本身有微妙改动(歌词常用手法:最后一遍副歌换一个词),译文必须体现这个改动
• 拟声词、呼喊(la la la、oh oh、ah)原样保留
• 原文中夹杂的英语行通常原样保留(日语歌词的英语句是风格的一部分),除非用户要求全译
• 双关与文字游戏: 优先保"意",中文实在无法兼顾时,正常翻译并在交付汇报里说明,不在译文里加注释
• 标题也要译,交付时给出"原题 / 译题"

Step 3: 子代理复核

初译完成后,不要直接交付。让一个没有参与翻译过程的代理来审,因为译者对自己刚写下的句子有惯性盲区——这正是要派 subagent 而不是自己再读一遍的原因。

• 有 `Agent` 工具: 派一个 subagent(general-purpose 即可),prompt 用下面的模板
• 没有(本 skill 被外层 subagent 调用、或环境不支持): 主代理自审,但要换一种读法——按模板里同样的三维清单逐行对照审一遍,而不是凭印象扫一遍

复核 prompt 模板

你是一名挑剔的歌词翻译审校,审读一首日语歌词的中文翻译初稿。
你没有参与翻译,这正是你的价值:不带惯性地逐行挑问题。

本曲风格定位(译者的判断,供你对照): <Step 1 的风格定位及理由>

日语原文:
<全文>

中文初译:
<全文>

从三个维度逐行对照审读:
1. 信 — 误译、漏译、意象丢失或被替换、过度发挥(译者自己加戏)、原文的暧昧被说破
2. 达 — 翻译腔、不像中文歌词的句子、行长失衡、节奏拖沓
3. 雅 — 与风格定位不符的措辞、辞藻堆砌或过于寡淡、重复段译法不一致

要求:
- 逐行对照,不要只扫大意
- 宁可苛刻,不要客气;但每条意见必须落到具体某一行,说清为什么是问题、怎么改更好
- 整体做得好的方面也简要说明,帮助译者判断哪些不要动
- 没有问题就明确说"未发现需要修改的问题",不要硬凑意见

返回格式:
## 总评
<两三句,信/达/雅各一句>
## 逐条意见
- [第 N 行] [信|达|雅] 原文「…」译作「…」: <问题> → 建议: <改法>

Step 4: 修订与交付

拿到复核意见后,逐条评估,不盲从。复核者的优势是没有惯性盲区,劣势是对全曲风格统一性的沉浸不如主译——有的局部建议单看更好,放进全曲反而破坏统一。所以:

• 指出硬伤(误译、漏译、人称错误)的意见 → 基本都该采纳
• 风格和措辞类意见 → 用 Step 1 的风格定位做仲裁:贴合定位就采纳,偏离就驳回
• 驳回的重要意见,在交付汇报里说一句理由,让用户知道这里曾有过权衡

修订完成后,用 Write 写出最终译文文件(按 Step 0 的命名规则),然后在对话里向用户汇报。汇报的价值在于给用户译文文件里看不到的东西——主题情感的解读、风格选择的理由、翻译时的权衡;所以不要在汇报里重贴译文全文(用户自己会打开文件),需要讨论具体句子时只引用那一两行:

## 交付
- 译文文件: <路径>
- 标题: <原题> / <译题>
- 主题与情感: <一两句,这首歌在说什么、情感基调和曲线如何>
- 风格定位: <一两句,选了什么风格、为什么>
- 复核摘要: 复核共提出 N 条意见,采纳 M 条。主要修改: <一两条最有代表性的>;主要驳回: <如有,一句理由>
- 译注: <双关、典故、无法保留的文字游戏、需要向用户说明的取舍;没有就省略本行>

边界情况

• `.lrc` 带重复时间标签(一行多个 [mm:ss]): 标签全部保留,文本只译一次
• 多个歌词文件: 一次只处理一首;用户没指明时问清先处理哪个
• 歌词整段是英语或中文: 不在本 skill 范围,如实告诉用户;日语为主、夹杂少量外语行的正常处理
• 罗马音歌词(romaji): 先确认用户是否有日文原文,罗马音歧义太多,直接翻容易错;实在只有罗马音就翻,但在交付汇报里注明风险
• 用户要求"可以唱的"译配版(对音节数): 这超出默认范围,音节对齐会大幅牺牲信达,需要用户明确要求才做,且在汇报里说明取舍

文件结构

lyrics-translator/
├── SKILL.md           本文件
└── evals/
    ├── evals.json     测试用例
    └── fixtures/      测试用日语歌词(原创,避免版权问题)