翻译场景为什么比看上去复杂
提示词本身很简单，但要做成通用工具，问题一个接一个：输入格式千差万别，有人贴一句话，有人丢一篇万字长文，还有人给个 Markdown 文件；每个人的语言对不同；有时候只想看个大意，有时候要求高质量输出。长内容还得分块，分块又带来一致性问题。这些不是一次想清楚的，全靠一轮轮迭代踩出来。
三个阶段的演进
提示词时代，翻译质量全靠手工堆叠——角色设定、语气要求、术语表，能塞的都塞进去。核心技巧是"两步翻译"（先直译再意译）和"三步翻译"（直译→审校→意译），本质是手动构造推理链，让模型先对齐原文意思再自然表达。效果好，但费 Token，上下文占用大。
推理模型时代，模型自带推理能力，不需要手动设计思维链。这时候提示词的关键变成一个词："重写"。不是让模型"翻译"，而是用目标语言"重写"内容。"翻译"会让模型执着于原文的每个字，"重写"给了它更大的自由度去处理隐喻、重组句式。这个思路转变带来的质量提升非常明显。
Agent 时代，翻译从单次调用变成了一套工作流。之前所有决策——要不要分块、分多大、用什么术语表——都靠人来做。现在大部分决策交给 Agent，人只在关键节点确认。
Agent 翻译工作流的具体设计
整套流程分五步：
- Agent 先分析文章，找出专业术语、文化隐喻、读者可能不理解的背景知识，保存成分析文件
- 根据分析结果和提示词模板，生成翻译提示词，也保存成文件
- 如果文章太长，用脚本按 Markdown 结构分块
- 多个子 Agent 并行翻译，每个负责一块
- 翻译完合并，再做整体校对
所有中间产物——分析报告、翻译提示词、每个分块的原文和译文、审校意见——全部保存成文件。某一块翻得不好可以单独重翻，提示词有问题可以直接改文件，不用从头来。
Agent 翻译和提示词翻译的本质差异
Agent 有工作流，不是一次性执行。 碰到短文章跳过分块，碰到长文章自动分析 Markdown 结构找安全切分点，碰到纯文本和 Markdown 用不同策略。遇到问题它会自己写脚本处理，比如写代码做 AST 解析，避免把表格或代码块切断。
Agent 用文件系统当外部记忆。 不需要把所有东西都装在上下文里，需要什么读什么，上下文始终保持干净。传统提示词翻译的上下文用完即弃；Agent 翻译中，文件系统才是主记忆，上下文只是工作台。
Agent 可以启动子 Agent 并行工作。 传统方式一个模型从头翻到尾，Agent 可以起十个子 Agent，每个只拿共享的提示词文件加自己负责的那一块，独立翻译。速度提升好几倍，每个子 Agent 的上下文负载还更低。
从串行到并行：一致性怎么保证
最初分块翻译是串行的，一个子 Agent 按顺序翻所有块，上一块结果放到下一块上下文里，保证前后连贯。但速度太慢，上下文还可能爆。
改成并行后速度快了，但同一个术语可能被不同子 Agent 翻成不同的词。解决方案是把一致性的保障从"运行时上下文"转移到"预先分析"——翻译之前先做一次内容分析，把术语表、翻译风格、命名约定写成分析报告，再据此生成统一的翻译提示词。每个子 Agent 拿到的是同一份提示词，术语怎么翻、风格什么调性，全部统一。
分块策略也有讲究。最开始按空行分段，会把表格、代码块、列表切断。后来改成用库做 Markdown AST 解析，只在结构安全的地方切割——段落边界、标题之后。
提示词传递的四次重构
这部分迭代次数最多，值得细说：
- 第一版：让子 Agent 自己去读分析文件，但子 Agent 还得自己找文件、理解分析结果，不确定性太大
- 第二版：主 Agent 读取分析文件后整合成完整提示词，直接传给子 Agent。好了一些，但提示词只存在于调用参数里，没法追溯
- 第三版：把组装好的提示词保存成文件，子 Agent 读文件就行。提示词本身成了可追溯的中间产物，可以打开检查甚至手动改
- 第四版：发现提示词文件里包含分块列表，子 Agent 看到所有块的信息会混淆。于是拆成两部分——共享上下文（背景、术语表、翻译原则）保存为文件，任务指令（翻译哪个文件、保存到哪里）作为调用参数单独传入
这个迭代过程体现了一个普遍规律：Agent 工作流中信息怎么传递，往往比信息本身更重要。
让 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."
模型翻译成了"从后视镜里看着日本人以惊人的速度追赶上来"，而期望的翻译是"一直把日本人看作身后的追赶者，而且对方进步的速度已经让他们感到不安"。
问题在于："从后视镜里看"是英文隐喻的直译，中文读者读着别扭；"alarming"被翻译成"惊人的"，丢失了原文中瑞士人感到不安的主观情绪。
做法不是自己去改提示词，而是手动整理一份高质量翻译版本，让 Agent 自己比较两版，分析差异。Agent 总结出了几个核心模式：隐喻要解读意图而不是直译字面意象；保留用词的情感色彩；用中文的表达结构而不是照搬英文语序。然后 Agent 在分析阶段新增了隐喻映射，在翻译原则里加了"翻译意图不翻译字面"，在审校阶段专门检查直译隐喻和情感扁平化问题。
这里的经验很关键：Agent 比你更懂怎么写好提示词，但你要告诉它方向。 你的角色是发现问题、提供好坏的标准，让 Agent 自己分析和优化。
三种翻译模式
最初只设计了两种模式，后来发现很多时候只是想快速看个大意，于是加了快速模式：
- 快速模式：不分析不分块，直接翻译，适合快速了解大意
- 普通模式：先分析文章内容，提取术语、识别难点，再翻译。长内容自动分块。结束后会问一句：要不要继续润色？
- 精细模式：在普通模式基础上继续审校、修订、润色定稿
默认是普通模式，用户不需要提前判断需要什么级别。看完觉得需要更好，回复"继续润色"就能无缝升级到精细模式——因为所有中间结果都保存成了文件，升级时不用重跑前面的步骤。
个性化和术语表的精简
Skill 里设计了 EXTEND.md 文件，用户可以设置默认目标语言、翻译风格、目标读者、术语表。目标读者这个维度会影响整个翻译策略——给普通读者要多加译注，给技术读者可以省略常见术语解释，学术读者用正式语体，普通读者用叙事风格。
术语表从最初的 60 多条精简到 15 条。删掉了"Machine Learning → 机器学习"这类模型本身就知道的，只保留容易翻错或有争议的，比如"AI Wrapper → AI 套壳"、"Hallucination → 幻觉"、"Moat → 护城河"。术语表是给模型的补充知识，不是全部知识，重复太多反而稀释了真正需要注意的条目。
文件即工作流
所有产物都用数字前缀标识步骤顺序：
01-analysis.md —— 内容分析
02-prompt.md —— 翻译提示词
03-draft.md —— 初稿
04-critique.md —— 审校意见
05-revision.md —— 修订版
translation.md —— 最终翻译
这个设计让每一步都可追溯、可调试、可单独重跑。并行翻译也因此自然可行——提示词已经是文件了，多个子 Agent 共享同一个文件，天然一致。
反复出现的设计原则
回头看整个迭代过程，几个原则贯穿始终：
- 所有产物持久化：源文件、分析、提示词、初稿、审校、终稿都保存为文件
- 关注点分离：分析归分析，翻译归翻译，审校归审校。子 Agent 只负责初稿，审校和润色需要全局视角，交回主 Agent
- 渐进式体验：默认普通模式，完成后提示可以升级，用户不需要提前预判
- 并行优先：在保证质量的前提下尽量并行，通过共享提示词文件保证一致性
- 提示词即代码：翻译提示词保存成文件，可检查、可修改、可复用
这些原则不只适用于翻译场景。任何想用 Agent 构建复杂工作流的人，都可以从"文件系统即记忆"和"预先分析保证一致性"这两个思路入手。一个好用的 Agent Skill，本质上不是一条好提示词，而是一套设计合理的系统——而这套系统的迭代，本身也可以交给 Agent 来完成。