--- layout: post.njk source: https://baoyu.io/blog/2026-03-05/i-built-a-translator-skill speaker: baoyu.io title: 我用 AI 翻译的三个阶段：提示词时代 → 推理模型时代 → Agent 时代 | 宝玉的分享 date: '2026-03-05' summary: 本文作者宝玉分享了其两年间迭代 AI 翻译 Skill 的历程，梳理了从提示词时代、推理模型时代到 Agent 时代的技术演进。文章详述了在处理长文本、保证术语一致性、优化翻译质量等方面的挑战，以及如何通过工作流设计、文件持久化、并行处理和 Agent 驱动的优化来解决这些问题。作者强调了从写提示词到设计系统的转变，并指出人的价值在于发现问题和指明方向，具体实现由 Agent 完成。 area: tech-engineering category: ai-application tags: - ai-translation - prompt-engineering - agent-based-systems - skill-creation - workflow-automation people: - 宝玉 companies_orgs: [] products_models: - Agent - Claude Code - Gemini CLI media_books: [] draft: true status: evergreen --- 宝玉的分享 Menu See all posts Published on 2026-03-05 # 我用 AI 翻译的三个阶段：提示词时代 → 推理模型时代 → Agent 时代 作者： 宝玉 我做 AI 翻译这件事，前前后后折腾了快两年。从最早手写提示词，到现在用 Agent 自动分块、并行翻译、审校润色，中间踩了不少坑，也攒了不少经验。最近把这些经验整理成了一个可复用的翻译 Skill，这篇文章聊聊这个 Skill 是怎么一步步迭代出来的。 翻译这个场景比看上去复杂。提示词本身很简单，“把这段话翻译成中文”谁都会写。但要做成一个通用的 Skill，你得考虑：输入千奇百怪，有人贴一句话，有人丢一篇万字长文，还有人给个 Markdown 文件；每个人常用的语言对不一样；有时候只想快速看个大意，有时候要求翻译质量必须高。 太长的内容模型处理不了或者效果变差，需要分块，分块了又不好保证前后一致。这些问题不是一次想清楚的，是一轮轮迭代踩出来的。 ## 我用 AI 翻译的三个阶段 第一个阶段是推理模型出来之前。 那时候翻译质量全靠提示词，角色设定、语气要求、术语表，能塞的都塞进去。我应该是最早公开提出用“两步翻译”和“三步翻译”来提升翻译质量的。 两步翻译就是先直译再意译，原理类似推理链，让模型先老老实实把原文意思对上，再用更自然的方式重新表达。效果确实好，但费 Token。三步翻译多了一个中间的审校环节，先直译，再审校找问题，最后意译，效果更好，但上下文占用很大。 第二个阶段是推理模型出来之后。 有了推理能力，不需要我手动设计推理链了，模型自己会“想”。这时候翻译提示词的核心变成了一个词：“重写”。不是让模型“翻译”，而是让它用目标语言“重写”这段内容。“翻译”这个词会让模型惦记着原文的每个字，“重写”给了它更大的自由度去处理隐喻、重组句式。这个思路转变带来的质量提升很明显。 第三个阶段是 Agent。 到了 Agent 时代，翻译工作流可以做得更精细。之前所有决策都是我做的：要不要分块、分多大、用什么术语表、翻译质量够不够好。现在很多决策可以交给 Agent，但关键节点由人来确认。 具体来说，我的 Agent 翻译工作流是这样的： Agent 先分析要翻译的文章，找出专业术语、文化隐喻、读者可能不理解的背景知识，保存成分析文件 根据分析结果和提示词模板，生成翻译提示词，也保存成文件 如果文章太长，用脚本按 Markdown 结构分块 多个子 Agent 并行翻译，每个负责一块 翻译完合并，再做整体校对 所有中间结果，分析报告、翻译提示词、每个分块的原文和译文、审校意见，全部保存成文件。翻译是个迭代过程，某一块翻得不好可以单独重翻，不用从头来。提示词有问题可以直接改文件，不用重新跑分析。 到了这个阶段，自然就想把整套流程做成 Skill 方便重用。 ## Agent 翻译和提示词翻译有什么不同 用提示词翻译，你把原文、指令、术语表塞进上下文，模型执行一次，输出就是结果。上下文窗口是你的全部工作空间，所有东西都得挤在里面。文章一长，要么截断要么硬塞，质量和成本都不好控制。 Agent 翻译不一样，差别在三个地方。 第一，Agent 有工作流，不是一次性执行。 它会按 Skill 设计的流程走，但不是死板地按步骤走。碰到短文章跳过分块，碰到长文章自己分析 Markdown 结构找安全的切分点，碰到纯文本和 Markdown 用不同的分块策略。目标语言、翻译风格、质量要求，都可以根据用户需求灵活调整。遇到问题它会自己写脚本来处理，比如写一段代码做 AST 解析，避免把表格或代码块切断。这些靠一条提示词做不到。 第二，Agent 能用文件系统当外部记忆。 分析结果存成文件，翻译提示词存成文件，每一块的译文也存成文件。Agent 不需要把所有东西都装在上下文里，需要什么读什么，上下文始终保持干净。传统提示词翻译，上下文就是你的全部，用完即弃；Agent 翻译，文件系统才是主记忆，上下文只是工作台。 第三，Agent 可以启动子 Agent 并行工作。 传统提示词翻译，一个模型从头翻到尾。Agent 可以起十个子 Agent，每个只拿共享的提示词文件加自己负责的那一块，独立翻译。速度提升好几倍，每个子 Agent 的上下文负载还更低，因为它只需要关注自己的那一块。 这三个能力组合在一起，让翻译从”写一条好提示词”变成了”设计一套翻译系统”。后面的内容就是这套系统怎么一步步迭代出来的。 ## Skill 怎么创建和迭代 创建 Skill 的过程本身不复杂。在 Claude Code 里用 skill-creator，把想法说清楚，它就能生成一个初步版本。 我的第一条指令就把核心需求说清楚了： > 帮我为当前项目创建一个新的翻译的 skill： > 两种模式：正常翻译，和精细翻译 > 有一个 EXTEND.md 可以定制默认的 target 语言、语言到语言的术语表等 > 如果是普通翻译，直接翻译即可 > 如果是精细翻译，做成一个工作流：先分析文章内容→初步翻译→review→润色等 > 如果是内容太长，需要分块翻译，但是要先把术语、人名先找出来，确保全文一致 同时我直接附上了参考翻译提示词和术语表样例，这样 Claude 不需要猜测我的翻译风格偏好。 整个 Skill 的创建和迭代过程是这样的： 在 Claude Code 里用 skill-creator，直接把想法说出来，生成初始版本 用生成的版本去翻译真实文章，不是测试用例，是真的要用的内容 读翻译结果，找出不满意的地方 把问题反馈给 Claude Code，让它改进 Skill 再翻译，再检查，循环往复 这个过程中，人的角色是质量判官和方向指挥。你要能判断翻译好不好，要能说清楚哪里不好，但不需要自己去写提示词细节。比如我发现串行翻译太慢，直接告诉 Agent“改成并行”，它自己去处理并行带来的一致性问题。再比如隐喻翻译生硬，我给它两版翻译让它自己总结规律，它总结出来的规则比我写的更系统。 ## 三种翻译模式的由来 最初只设计了两种模式：普通和精细。后来发现很多时候只是想快速看个大意，普通模式的分析步骤多余了，于是加了快速模式，变成三种： 快速模式——不分析不分块，直接翻译，适合只想快速看个大意 普通模式——先分析文章内容，提取术语、识别难点，再翻译。长内容会自动分块，翻译完合并。结束后会问你一句：要不要继续润色？ 精细模式——前面和普通模式一样，但后面会继续审校翻译结果，根据审校意见修订，最后润色定稿 这里有个用户体验的考虑：默认是普通模式。你不需要提前判断自己需要什么级别的翻译质量。大多数时候普通模式就够了，看完觉得需要更好，回复”继续润色”就能无缝升级到精细模式。所有中间结果都保存成文件，升级模式时不用重跑前面的步骤。 ## 从串行到并行，解决一致性问题 最初分块翻译是串行的。一个子 Agent 按顺序翻译所有块，上一块的结果放到下一块的上下文里，保证前后连贯。 但速度太慢，十个块要一个接一个翻译。更麻烦的是上下文可能会爆，如果截断之前的内容又没法用 Prompt Cache，成本反而更高。 改成并行呢？多个子 Agent 同时翻译不同的块，速度快了，但一致性没法保证。同一个术语，第一个子 Agent 翻译成“护城河”，第三个可能翻译成“竞争壁垒”。 解决方案是把一致性的保障从“运行时上下文”转移到“预先分析”。翻译之前先做一次内容分析，把术语表、翻译风格、命名约定都确定下来，写成一份分析报告。然后根据分析报告和提示词模板，生成一份完整的翻译提示词。 每个子 Agent 拿到的是同一份提示词加上各自负责的分块内容，术语怎么翻、风格什么调性，全部统一。十个块、十个子 Agent 并行执行，速度提升好几倍，一致性靠共享的提示词文件保证。 分块本身也有讲究。最开始按空行分段，会把表格、代码块、列表切断，后续处理很麻烦。后来改成用库做 Markdown AST 解析，只在结构安全的地方切割，比如段落边界、标题之后。 ## 提示词传递的四次重构 这部分是迭代次数最多的。 第一版，让子 Agent 自己去读分析文件。子 Agent 还得自己找文件、理解分析结果，增加了不确定性。 第二版，主 Agent 读取分析文件后，把所有上下文整合成一个完整的提示词，直接传给子 Agent。好了一些，但提示词只存在于调用参数里，没法追溯、没法手动检查。 第三版，把组装好的提示词保存成文件。子 Agent 读这个文件就行。提示词本身成了一个可追溯的中间产物，你可以打开看看生成的提示词对不对，甚至手动改。 第四版，实际测试时发现一个问题：提示词文件里包含了分块列表，子 Agent 看到所有块的信息会混淆，因为它只负责翻译一个块。于是把提示词拆成两部分，共享上下文（背景、术语表、翻译原则）保存为文件，任务指令（翻译哪个文件、保存到哪里）作为调用参数单独传入。 ## 所有产物都保存成文件 无论输入是文件、URL 还是粘贴的文本，第一步都是保存成文件。然后分析报告、翻译提示词、初稿、审校意见、修订版、最终翻译，全部保存在同一个目录里，用数字前缀标识步骤顺序： 01-analysis.md —— 内容分析 02-prompt.md —— 翻译提示词 03-draft.md —— 初稿 04-critique.md —— 审校意见 05-revision.md —— 修订版 translation.md —— 最终翻译 某个块翻译质量不好？单独重翻那一块。想看看分析报告有没有遗漏？直接打开 01-analysis.md。想手动调整翻译提示词？改 02-prompt.md 就行。普通模式翻译完想升级到精细模式？前面的文件都在，直接从审校步骤开始。 并行翻译也因此可行，提示词已经是文件了，多个子 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.” 模型翻译成了： > “整个 1960 年代，瑞士人一直从后视镜里看着日本人以惊人的速度追赶上来。” 而我期望的翻译是： > “整个六十年代，瑞士人一直把日本人看作身后的追赶者，而且对方进步的速度已经让他们感到不安。” “从后视镜里看”是英文隐喻的直译，中文读者读起来别扭。“alarming”被翻译成“惊人的”，丢失了原文中瑞士人感到不安的主观情绪。 我的做法不是自己去改提示词。我手动整理了一份高质量翻译版本，然后让 Agent 自己去比较两版翻译，分析哪里好、怎么才能翻译得更好。 Agent 分析出了几个核心模式：隐喻要解读意图而不是直译字面意象；传达作者的意思而不是逐词翻译；保留用词的情感色彩，“alarming”不只是“惊人的”，还有“不安”的意味；用中文的强调结构而不是照搬英文语序。 然后 Agent 在三个层面做了优化。分析阶段新增了隐喻映射，要求对每个隐喻分析作者意图、直译风险、目标语言处理策略。翻译原则里加了“翻译意图不翻译字面”、“保留情感色彩”。审校阶段专门检查直译隐喻和情感扁平化问题。 整个过程我做的就是：发现问题、提供对比样例、指明方向。具体怎么改 Skill，让 Agent 自己来。 Agent 比你更懂怎么写好提示词，但你要告诉它方向。 你不需要去写 Skill 的具体规则，你需要做的是发现问题、提供好坏的标准，然后让 Agent 自己分析和优化。你测试，你指挥，它执行。 ## 个性化设置 每个人翻译的需求不一样。有人主要翻英文到中文，有人翻日文到英文。有人面向技术读者，有人面向普通读者。 Skill 里设计了一个 EXTEND.md 文件，用户可以设置自己的默认目标语言、翻译风格、目标读者、术语表。第一次使用时会引导你做一次设置，之后每次翻译都会读取你的配置。 目标读者这个维度不只是一个配置项，它影响整个翻译策略。给普通读者要多加译注，给技术读者可以省略常见术语的解释。学术读者用正式语体，普通读者用叙事风格。 译注本身也有讲究。不是简单标个英文原词，而是用通俗语言解释含义。比如“遮秃效应”（comb-over effect，指一系列单独看来微小的变化，最终将你从略有偏差带入荒诞失常的境地），让不了解这个概念的读者也能顺畅读下去。 ## 术语表的精简 一开始术语表有 60 多条，后来精简到 15 条。删掉了 Machine Learning 翻译成机器学习这类模型本身就知道的，只保留容易翻错或有争议的，比如 AI Wrapper 翻译成 AI 套壳、Hallucination 翻译成幻觉、Moat 翻译成护城河。 术语表是给模型的补充知识，不是全部知识。 模型知道的就别重复了，重复太多反而稀释了真正需要注意的条目。 类似的思路也用在了配置管理上。Skill 里有分块阈值、每块最大词数这些参数，最开始散落在各处，改一个要找好几个地方。后来统一放到一个 Defaults 表里，EXTEND.md 里的设置可以覆盖默认值，具体数字只出现一次。 ## 回头看，几个反复出现的原则 第一，所有产物持久化。 源文件、分析、提示词、初稿、审校、终稿都保存为文件，可追溯、可调试、可恢复。 第二，关注点分离。 分析归分析，翻译归翻译，审校归审校。子 Agent 只负责初稿翻译，审校和润色需要全局视角，交回主 Agent。 第三，渐进式体验。 默认普通模式，完成后提示可以升级，用户不需要提前预判。 第四，并行优先。 在保证质量的前提下尽量并行，通过共享提示词文件让多个子 Agent 独立工作。 第五，提示词即代码。 翻译提示词保存成文件，可检查、可修改、可复用。 从“把这段话翻译成中文”到一个完整的翻译 Skill，这中间的距离比我预想的大。翻译提示词确实简单，但一个好用的翻译工具要处理的问题远不止翻译本身：输入格式、分块策略、术语一致性、质量分级、中间产物管理、个性化配置。这些问题没有一个能靠一条提示词解决，但也没有一个需要你自己从零写代码。你的价值在于判断质量好坏、发现问题、指明方向。具体怎么优化，让 Agent 来。 项目地址：https://github.com/JimLiu/baoyu-skills 安装方法： > npx skills add https://github.com/jimliu/baoyu-skills --skill baoyu-translate 小龙虾🦞和 Claude code 都可以用。 See all posts Built by 宝玉. RSS . 本站原创内容，独家授权赛博禅心公众号发布。 Toggle theme