写了一个翻译的 skill，开源，推荐试用，效果我测试下来还可以的。
使用方法很简单，安装后，只要说：
> 翻译 {文件路径}
或者快速翻译，速度最快，质量会差一些
> 快速翻译 {文件路径}
或者精翻，质量最好，时间长一些，token也会消耗更多
> 精翻 {文件路径}
如果配合 baoyu-danger-x-to-markdown skill 可以翻译 X 上的 Article，输入推文 url 就好，配合 baoyu-url-to-markdown 则可以根据 url 翻译文章内容
长文会自动分块，分块后能并行翻译，速度还可以，并且能保证分块后的翻译术语一致性。
可以定制化一些自己的术语表。
项目地址：github.com/JimLiu/baoyu-skills http://t.cn/AXGqimPJ
安装方式：http://t.cn/AXV2AHeh
---
我做 AI 翻译这件事，前前后后折腾了快两年。从最早手写提示词，到现在用 Agent 自动分块、并行翻译、审校润色，中间踩了不少坑，也攒了不少经验。最近把这些经验沉淀成了一个可复用的翻译 Skill。
先说说翻译这个场景为什么比看上去要复杂。提示词本身很简单，“把这段话翻译成中文”谁都会写。
但要做成一个通用的 Skill，你得考虑：输入千奇百怪，有人贴一句话，有人丢一篇万字长文，还有人给个 Markdown 文件；每个人常用的语言对不一样；有时候只想快速看个大意，有时候要求翻译质量必须高；太长的内容模型处理不了或者效果变差，需要分块，分块了又不好保证前后一致。
这些问题不是一次想清楚的，是一轮轮迭代踩出来的。
我用 AI 翻译的三个阶段
第一个阶段是推理模型出来之前。
那时候翻译质量全靠提示词，角色设定、语气要求、术语表，能塞的都塞进去。我应该是最早公开提出用“两步翻译”和“三步翻译”来提升翻译质量的。
两步翻译就是先直译再意译，原理类似推理链，让模型先老老实实把原文意思对上，再用更自然的方式重新表达。效果确实好，但费 Token。三步翻译多了一个中间的审校环节，先直译，再审校找问题，最后意译，效果更好，但上下文占用很大。
第二个阶段是推理模型出来之后。
有了推理能力，不需要我手动设计推理链了，模型自己会“想”。这时候翻译提示词的核心变成了一个词：“重写”。不是让模型“翻译”，而是让它用目标语言重写这段内容。“翻译”这个词会让模型惦记着原文的每个字，“重写”给了它更大的自由度去处理隐喻、重组句式。这个思路转变带来的质量提升很明显。
第三个阶段是 Agent。
到了 Agent 时代，翻译工作流可以做得更精细。
之前所有决策都是我做的：要不要分块、分多大、用什么术语表、翻译质量够不够好。现在很多决策可以交给 Agent，但关键节点由人来确认。
具体来说，我的 Agent 翻译工作流是这样的：
1. Agent 先分析要翻译的文章，找出专业术语、文化隐喻、读者可能不理解的背景知识，保存成分析文件
2. 根据分析结果和提示词模板，生成翻译提示词，也保存成文件
3. 如果文章太长，用脚本按 Markdown 结构分块
4. 多个 subagent 并行翻译，每个负责一块
5. 翻译完合并，再做整体校对
所有中间结果都保存成文件。分析报告、翻译提示词、每个分块的原文和译文、审校意见，全部保存成文件。
为什么要这么做？
因为翻译是个迭代过程。某一块翻得不好，可以单独重翻，不用从头来。提示词有问题，可以直接改文件，不用重新跑分析。
从串行到并行：一个关键转折
最开始分块翻译是串行的。一个 subagent 按顺序翻译所有块，上一块的结果带到下一块，保持上下文连贯。
问题很明显：慢。十个块要一个接一个翻，而且上下文越来越长，可能会爆。如果截断之前的内容，又没法用 prompt cache，成本反而更高。
改成并行翻译就面临另一个问题：术语不统一。前面翻成"强化学习"，后面变成"增强学习"，读者会懵。
解法是把一致性的保障从"运行时上下文"转移到"预先分析"。在翻译之前，Agent 已经分析好了全文的术语、翻译策略、风格要求，全部写在提示词文件里。每个 subagent 拿到的是同一份提示词文件，术语决策已经固化在里面了。
十个块十个 subagent 并行执行，速度提升好几倍，一致性由共享的提示词文件保证。
提示词文件的演进
提示词怎么传给 subagent，这件事改了好几版。
最开始是让 subagent 自己去读分析文件，自己理解。效果不稳定，每个 subagent 理解出来的东西不一样。
然后改成主 agent 读取分析文件，把所有上下文整合成一个完整的 prompt 传给 subagent。好了一些，但 prompt 里什么都有，包括分块列表，subagent 看到十个块的列表会困惑，因为它只需要翻一个块。
最后拆成两部分：共享上下文（术语表、翻译原则、背景信息）保存成文件，任务指令（翻译哪个文件、保存到哪里）作为调用参数传入。每个 subagent 读同一个提示词文件，但收到不同的任务指令。
把提示词保存成文件还有一个好处：它本身成了可追溯的中间产物。翻译完觉得风格不对，打开提示词文件一看，发现是分析阶段遗漏了某个术语，直接改文件重跑翻译就行。
当然还有一个重要原因是 Agent 很擅长读写处理文件。
整个 Skill 的创建和迭代过程是这样的：
1. 在 Claude Code 里用 skill-creator，直接把想法说出来，生成初始版本
2. 用生成的版本去翻译真实文章，不是测试用例，是真的要用的内容
3. 读翻译结果，找出不满意的地方
4. 把问题反馈给 Claude Code，让它改进 Skill
5. 再翻译，再检查，循环往复
这个过程中，人的角色是质量判官和方向指挥。你要能判断翻译好不好，要能说清楚哪里不好，但不需要自己去写提示词细节。比如我发现串行翻译太慢，不是我去改并行逻辑，而是告诉 Agent"改成并行"，然后它自己去处理并行带来的一致性问题。
比如我发现隐喻翻译生硬，不是我去写"遇到隐喻请意译"这样的规则，而是给它两版翻译让它自己总结规律。它总结出来的规则比我写的更系统、更全面。
