我折腾 AI 翻译差不多两年了。
最早的思路很直接：把提示词写得足够详细，告诉模型怎么直译、怎么意译、哪些术语不能乱动。后来推理模型越来越强，很多过去必须手把手写进 Prompt 的步骤，可以交给模型自己判断。
再往后，我发现问题已经不只是“提示词怎么写”。
文章太长怎么办？术语怎么保持一致？多个章节能不能并行翻译？某一段翻坏了是不是必须全部重来？审校、润色和最终定稿怎么衔接？
当这些问题放到一起，翻译就开始从“一次模型调用”，变成一套完整工作流。
最近我把这套方法整理成了一个可重复使用的翻译 Skill。回头看，它的变化基本可以分成三个阶段：提示词时代、推理模型时代，以及现在的 Agent 时代。
AI 翻译的三个阶段
第一阶段：靠提示词把模型一步步带过去
早期大模型的翻译能力已经不错，但遇到长句、隐喻、专业术语和复杂语气时，很容易出现两种极端。
一种是太直。
原文什么结构，它就尽量保留什么结构，最后得到的是“每个词都认识，合起来不像中文”的译文。
另一种是太自由。
读起来舒服了，但原文的一些限定条件、语气甚至事实细节也跟着被改掉了。
所以那时候我会把翻译过程拆开。
最常用的是两步：
- 先忠实翻译，确保意思没有跑偏；
- 再根据中文表达习惯重新整理。
后来又加了一层审校，变成：
初译 → 检查问题 → 润色定稿。
这样做确实能改善结果，因为模型不用一次同时解决“理解原文”和“写出自然中文”两个问题。
代价也很明显。
Prompt 越来越长，中间结果越来越多，同一篇文章会被反复塞进上下文，Token 消耗也跟着上去。
当时优化 AI 翻译，很大一部分精力其实都花在了：
怎么写一条更好的提示词？
第二阶段：推理模型出现后，Prompt 不用再写得那么碎
模型推理能力提升以后，我逐渐减少了那种非常机械的步骤：
第一步分析句子。
第二步逐字翻译。
第三步找出问题。
第四步重新组织……
不是因为 Prompt 不重要了，而是没有必要把模型每一步应该怎么思考都规定死。
现在更重要的是把几个东西说清楚：
- 最终目标是什么；
- 哪些信息绝对不能丢；
- 目标读者是谁；
- 哪些术语必须统一；
- 允许多大程度的语言重组；
- 什么情况算翻译失败。
这时候我也开始改变对“翻译”这个词的理解。
以前更像：
把这段英文转换成中文。
后来更接近：
在不改变事实、观点和语气的前提下，用自然中文重新表达作者真正想说的内容。
这里的“重写”不是让模型自由发挥，更不是改写原意。
它只是允许模型在句式、语序、隐喻处理和表达习惯上拥有更大的空间。
英文喜欢用长定语、从句和抽象名词，中文未必需要照搬。英文里非常自然的隐喻，逐字搬过来可能反而让人摸不着头脑。
好的翻译要忠于原意，但不需要忠于原来的句子形状。
推理模型让我少写了很多“模型应该怎么想”，但有一件事一直没变：
目标、边界和质量标准仍然必须讲清楚。
第三阶段：从翻译提示词变成 Agent 翻译工作流
真正变化最大的，是 Agent。
以前我会问：
怎么让模型把这篇文章翻译好？
现在我更关心：
怎么让 Agent 把整个翻译任务管理好？
例如收到一篇长文章后，Agent 可以先判断内容类型和长度，然后决定：
要不要分析术语？
要不要拆分？
哪些内容不能切断？
是否适合并行？
翻完以后需不需要统一审校？
某些高难度段落是不是应该单独重做？
于是我现在的精细翻译流程大致变成：
- 保存原文；
- 分析内容、术语、人名、隐喻和写作风格；
- 生成本次任务使用的翻译规则；
- 长文章按结构安全地分块；
- 多个子 Agent 分别处理不同部分；
- 合并结果；
- 从全文角度检查一致性和遗漏；
- 根据审校结果修订；
- 最后做一次中文表达层面的润色。
从这里开始，翻译已经不是一条 Prompt 了。
它变成了一套可以暂停、重跑、检查和修改的系统。
Agent 翻译和普通 Prompt 翻译，差别在哪里？
如果只是翻一句话，Agent 没什么优势。
比如：
Please translate this sentence into Chinese.
直接让模型翻就行了。
为了十几个单词启动一整套分析、分块、审校工作流，只是在制造额外开销。
Agent 真正有优势的是长内容和复杂任务。
一次调用，变成可调整的工作流
普通 Prompt 翻译通常是：
输入 → 模型 → 输出。
结果不好，再重新 Prompt 一次。
Agent 工作流则可以根据输入调整。
一篇 800 字的小文章，没必要拆分。
一篇几万字的 Markdown 文档，就可以先检查标题、列表、代码块、表格等结构，再寻找合适的切分位置。
技术文章先统一术语。
人物很多的文章先统一姓名。
文化背景比较复杂的文章，先找出哪些地方可能需要译注。
这里最重要的不是“Agent 会自己做所有决定”，而是它可以按照既定规则处理大量机械判断，把少数真正影响质量的决定留给人。
文件系统变成了工作区
普通对话里，最重要的东西都在上下文中。
Agent 工作流则可以把很多中间结果写进文件：
source.md
analysis.md
prompt.md
draft.md
critique.md
revision.md
translation.md
模型当前只需要处理其中几份，就读取几份。
这并不意味着上下文窗口不重要。
现在模型能够处理的上下文已经比早期大很多，但“能放进去”和“值得全部放进去”是两回事。
一篇很长的文章即使能够完整塞入上下文，也仍然要考虑成本、局部信息关注度、术语一致性，以及后续修改是否方便。
文件的价值就在这里。
某一章翻坏了，只改那一章。
术语规则有问题，只改术语配置。
Prompt 生成得不好，可以直接检查 prompt.md。
审校发现问题，也不必从最开始重新跑一遍。
上下文适合当前思考，文件更适合保存过程。
可以把独立任务并行处理
长文章最明显的瓶颈之一就是时间。
假设一篇文章被拆成十块，串行翻译就是：
第一块完成 → 第二块 → 第三块 → …… → 第十块。
如果这些块彼此依赖很弱，就没有必要全部排队。
Agent 可以把其中一部分任务交给多个子 Agent 分别处理。
不过并行有一个非常现实的问题：
快是快了，全文可能不像一个人翻的。
同一个词，第一个 Agent 翻成“竞争壁垒”，第二个翻成“护城河”；一个章节把某产品名称保留英文，另一个章节却用了中文译名。
所以并行翻译真正麻烦的不是怎么启动多个 Agent，而是：
怎么让它们在互相看不到完整译文的情况下，仍然遵守同一套规则？
这后来成了整个 Skill 里最重要的一次调整。
从串行改成并行后，我先解决一致性
最初的设计其实很简单。
一个 Agent 从第一块翻到最后一块。
前面翻过什么，后面都能看到，因此术语和语气比较容易延续。
问题是慢，而且上下文越来越重。
后来我改成并行翻译，马上遇到一致性问题。
解决办法不是让所有子 Agent 互相读取彼此的结果，而是把一致性工作提前。
翻译之前，主 Agent 先完整分析一次文章。
例如确定：
AI Wrapper → AI 套壳
Moat → 护城河
Hallucination → 幻觉
同时确定：
- 人名怎么处理；
- 产品名是否翻译；
- 数字格式；
- 标点习惯；
- 中文语气；
- 哪些英文缩写保留；
- 哪些背景信息需要解释；
- 隐喻应该直译还是转换表达。
这些规则写成共享文件。
接下来每一个子 Agent 拿到的东西基本相同：
统一翻译规则 + 自己负责的正文。
这样一致性的来源就不再是：
“我记得前一章怎么翻。”
而变成：
“所有人一开始就拿到了同一份规则。”
这对并行任务尤其重要。
把一致性问题从运行阶段往前挪，很多冲突会直接消失。
当然，最后仍然要做一次全文审校。
预先统一规则解决的是大部分确定性问题，全文审校解决的是那些只有把文章合在一起以后才能发现的问题。
Skill 是怎么一步步做出来的
我没有一开始就坐下来写一份非常复杂的 SKILL.md。
第一版的要求其实很简单：
- 普通翻译和精细翻译两种模式；
- 可以配置默认目标语言；
- 支持自己的术语表；
- 长文章自动分块；
- 精细模式加入分析、翻译、review 和润色；
- 分块之前先统一人名和术语。
然后用 Skill Creator 生成第一版。
真正重要的工作反而从这里才开始。
我没有专门编一批“标准测试文本”，而是直接拿平时真的需要翻译的文章去跑。
过程基本是：
使用 → 看结果 → 找问题 → 修改 Skill → 再使用。
例如发现串行速度太慢，就重新设计并行流程。
发现多个子 Agent 术语不一致，就增加全文预分析。
发现英文隐喻翻译得太机械，就加强隐喻识别和审校。
发现 Prompt 太复杂，就重新拆文件。
Skill 最终不是“写出来”的，更像是被真实任务一点点磨出来的。
最后变成了三种翻译模式
第一版只有普通和精细两种。
用了一段时间后，我发现还缺一种情况：
我只是看到一篇外文内容，想花一分钟知道它大概在讲什么。
这种时候根本不需要分析报告、术语整理和全文审校。
于是最后变成三种模式。
快速模式
直接翻译。
适合聊天消息、短文，或者只是想快速理解大意。
普通模式
先做必要的内容分析，再翻译。
长内容需要时进行分块，最后合并检查。大多数日常正式翻译，我会优先用这一档。
精细模式
在普通模式基础上，再增加系统审校、修订和最终润色。
适合真正准备发布的文章，或者对表达质量要求比较高的内容。
这样有一个好处：
不需要一开始就把每个任务都当成最高规格处理。
普通模式完成以后，如果觉得质量已经够了，到这里结束。
如果觉得：
这篇文章我要正式发布，再打磨一下。
直接从现有结果继续审校，不需要重新分析和翻译。
这也是保存中间文件带来的好处。
Prompt 本身也经历了几次重构
整个 Skill 里，我改得最多的其实不是翻译原则，而是怎么把上下文交给子 Agent。
第一版，让子 Agent 自己读取分析文件。
结果是每个 Agent 都要先找文件、理解文件，再决定哪些信息重要。
自由度太高。
第二版，主 Agent 先读完所有分析结果，再把内容组合成一大段 Prompt 传给子 Agent。
稳定了一些，但又出现新问题：
这份真正决定翻译质量的 Prompt，只存在于一次任务调用里。
翻完以后很难检查。
第三版，我开始把最终 Prompt 保存成文件：
02-prompt.md
一下就舒服多了。
Prompt 不再是隐藏在调用过程里的临时变量，而变成了可以打开、检查、修改和版本管理的中间产物。
后来继续测试又发现一个问题。
共享 Prompt 里如果包含所有分块任务：
chunk-01.md
chunk-02.md
chunk-03.md
...
负责 chunk-03.md 的子 Agent 有时候也会关注其他文件，反而增加干扰。
所以后来又拆了一层。
共享上下文放文件：
- 文章背景；
- 术语表；
- 人名表；
- 风格；
- 翻译原则；
- 特殊处理要求。
当前任务放调用参数：
翻译 chunk-03.md
输出到 chunk-03-translated.md
这样每个子 Agent 都知道整篇文章应该怎么翻，但只知道自己当前具体应该干什么。
这个结构后来也让我意识到一个问题：
给 Agent 的上下文不是越多越好，关键是给它当前任务真正需要的信息。
所有中间结果都保存下来
现在我的翻译目录大致会保留这些文件：
01-analysis.md
02-prompt.md
03-draft.md
04-critique.md
05-revision.md
translation.md
长文章还会多出：
chunks/
├── chunk-01.md
├── chunk-02.md
├── chunk-03.md
└── ...
以及对应的译文。
这么做表面上看文件变多了，实际反而更容易管理。
例如最终发现第二章翻译有问题，不用重新跑全文。
重新处理第二块，然后合并即可。
觉得某个术语不对，可以先检查：
01-analysis.md
看看是不是分析阶段就判断错了。
如果分析没错，再去检查：
02-prompt.md
看看规则有没有正确传递下去。
这比只看到一个最终译文，然后猜：
到底是模型理解错了，还是 Prompt 写错了？
容易排查得多。
以前 Prompt 更像一次性指令。
现在我更愿意把它看成代码。
能看到，能改，能复用，出了问题还能追踪。
与其自己猜怎么改 Prompt，不如让 Agent 分析失败案例
有一次测试里，原文是：
“The Swiss had been watching the Japanese in the rear view mirror all through the 1960s, and they’d been improving at an alarming rate.”
模型给出的译文大意是：
整个 1960 年代，瑞士人一直从后视镜里看着日本人以惊人的速度追赶上来。
单看没有明显语法错误。
但读起来很翻译腔。
“从后视镜里看着日本人”保留了英文的画面，却没有很好地传达这里真正的关系：日本人正在快速追赶，而瑞士人已经开始感到压力。
alarming 也不仅仅是“惊人的”。
它还有“快到让人不安”的意味。
我后来整理了一版更符合预期的表达，大意是：
整个六十年代，瑞士人一直把日本人看作身后的追赶者，而对方进步的速度已经开始让他们感到不安。
然后我没有马上自己往 Prompt 里增加：
不要直译 rear view mirror。
alarming 应译成让人不安。
这种规则只能修当前这一句话。
我把原译文和理想版本一起交给 Agent，让它分析：
为什么第一版不好？这种问题以后怎么识别？
最后得到的不是针对这一句话的补丁，而是几条更通用的规律：
- 隐喻先判断作者想表达的关系，再决定是否保留原意象；
- 不要为了对应单词而牺牲目标语言自然度；
- 情绪词除了字典含义，还要保留说话者态度；
- 审校时专门检查“字面正确但目标语言不自然”的表达。
然后这些规则分别进入：
分析阶段、翻译规则和审校阶段。
这比不断往总 Prompt 里追加一句句特殊规定有效得多。
我在这个过程中越来越确定一件事：
人最重要的作用不是替 Agent 写所有规则，而是提供质量判断。
你要能说清楚：
这里不好。
为什么不好。
什么样算好。
至于怎么把这个问题抽象成一套可复用规则，可以让 Agent 参与完成。
个性化配置和术语表，最后都做了减法
翻译工作流不可能所有人用同一套配置。
有人主要英文转中文，有人是日文转中文。
有人翻技术文档，有人翻商业文章。
同一个英文词面对不同读者，处理方式也可能不同。
所以 Skill 里我保留了一个类似 EXTEND.md 的用户配置文件，用来覆盖默认设置，例如：
- 默认目标语言；
- 常用语言方向；
- 目标读者；
- 翻译风格；
- 自定义术语；
- 特殊写作习惯。
其中我越来越重视“目标读者”。
同一个技术概念，写给工程师，很多术语可以直接保留。
写给普通读者，就可能需要多解释半句话。
不是翻译准确度发生变化，而是：
什么叫“足够清楚”发生了变化。
术语表也一样。
我最初喜欢往里面塞很多词，后来发现越做越长，最后有六十多条。
再后来反而砍到了十几条。
像：
Machine Learning → 机器学习
Artificial Intelligence → 人工智能
这种模型基本不会出错的内容，没必要反复提醒。
真正值得写进去的是：
- 容易出现多个译法的；
- 行业内有固定习惯的；
- 本项目必须统一的；
- 模型经常翻错的；
- 作者有明确偏好的。
例如：
AI Wrapper → AI 套壳
Hallucination → 幻觉
Moat → 护城河
术语表不是一本英汉词典。
它更像一份：
这些地方请特别注意。
条目越多，不一定越专业。
真正关键的那十几条反而更容易被模型遵守。
回头看，真正留下来的不是某条神奇 Prompt
折腾到现在，我已经不太相信存在一条“万能翻译提示词”。
短句、长文、技术文章、人物访谈、文学内容，本来就不应该走完全相同的处理方式。
真正稳定下来的，反而是几条工作流原则。
第一，重要中间产物尽量保存。
分析、翻译规则、初稿、审校意见和终稿都可以追溯。出问题以后知道从哪一步重新开始，而不是整篇重跑。
第二，把不同任务拆开。
分析负责理解。
翻译负责生成初稿。
审校负责找问题。
润色负责处理最终表达。
每个阶段目标越明确，越容易判断结果到底好不好。
第三，不要所有任务一上来就最高规格。
短内容直接翻。
正式文章正常翻。
真正要发布的内容再进入完整审校。
质量应该可以逐级提高，而不是只有“随便翻”和“全流程跑一遍”两个选项。
第四，并行之前先解决共享规则。
并行很容易，真正困难的是多个 Agent 怎么像同一个译者。
先统一术语、风格和命名，再并行，最后全文审校，比单纯把十块内容扔给十个 Agent 稳得多。
第五，Prompt 也应该可检查。
只存在于一次模型调用里的 Prompt 很难调试。
保存成文件以后，它就从一句临时指令变成了工作流的一部分。
第六，人的判断仍然很重要。
Agent 可以找问题、总结规律、改 Skill、重新翻译。
但你仍然要知道：
什么样的中文才是真的好读。
这件事至少目前还很难完全外包。
回头看这两年的变化，最明显的并不是模型把某个单词翻得更准了。
真正的变化是工作方式。
提示词时代，我在研究：
怎么告诉模型翻译。
推理模型时代，我开始研究：
怎么把目标和边界说清楚，让模型自己解决中间步骤。
到了 Agent 时代，我考虑的已经是：
怎么设计一套可以分析、分块、并行、审校、返工和持续改进的翻译系统。
这也是我现在理解 Agent Skills 的方式。
Skill 最有价值的地方，并不是把一大段 Prompt 换个地方保存。
而是把过去靠人脑记住的经验——什么时候分析、什么时候拆分、怎么保证术语一致、出了问题从哪里重来——真正变成一套可以重复执行的流程。
当翻译走到这一步，优化的对象就不再只是模型了。
而是整个工作流。
参考资料
- Anthropic《The Complete Guide to Building Skills for Claude》：介绍 Agent Skills 的创建、迭代、Skill Creator 以及在 Claude Code 中使用 Skills 的方式。
Anthropic Agent Skills 构建指南 - Anthropic Claude Code 官方资料：当前 Claude Code 支持 Skills、subagents、MCP 等能力，可用于构建多步骤 Agent 工作流。
Claude Code Foundations - Anthropic Agent Skills 介绍：Skills 用于把针对特定任务的流程和经验编码成可重复使用的能力。
Agent Skills 介绍 - Anthropic Claude 模型资料：当前部分 Claude 模型已经提供百万 Token 级上下文，但长上下文并不能替代合理的上下文管理和任务拆分。
Claude Opus 4.6 - Anthropic Prompt Caching 文档：Prompt Cache 可以降低重复上下文调用的成本，但缓存策略与工作流结构仍会影响实际费用。