Concise Summary简洁概述
Translation quality moved through three eras — hand-crafted two/three-step prompts, then reasoning models where the key trick became telling the model to 'rewrite' instead of 'translate', then agentic workflows with file-based memory and parallel sub-agents.
The deeper shift is architectural: a prompt treats the context window as the entire workspace, while an agent treats the filesystem as persistent memory and the context as just a workbench — enabling traceable intermediate artifacts, resumable workflows, and parallel sub-agents that stay consistent via a shared, pre-generated prompt file.
翻译质量的提升经历了三个阶段：先是靠人工设计两步/三步翻译提示词，再到推理模型时代把核心指令从「翻译」换成「重写」，最后进入 Agent 时代，靠文件系统做外部记忆、多个子 Agent 并行处理。
更根本的变化是架构上的：提示词把上下文窗口当成全部工作空间，Agent 把文件系统当成主记忆、上下文只是工作台——这带来了可追溯的中间产物、可恢复的流程，以及靠共享提示词文件保持一致的并行子 Agent。
Infographic信息图
Translate → Rewrite
「翻译」变成「重写」
The single-word prompt shift from 'translate' to 'rewrite' unlocked reasoning models' capacity to handle metaphor and sentence restructuring, because 'translate' anchors the model to every original word while 'rewrite' grants freedom to re-express intent.
把指令从「翻译」换成「重写」，是一个词的改动却带来质变：「翻译」让模型惦记原文每个字，「重写」则给了它处理隐喻、重组句式的自由度，推理模型的能力因此被真正释放出来。
Filesystem as memory
文件系统即外部记忆
Every intermediate artifact — analysis, prompt, drafts, critique, revision — is persisted as a numbered file (01-analysis.md … translation.md), turning the context window from a disposable scratchpad into a lean workbench that reads only what's needed.
分析报告、翻译提示词、初稿、审校意见、修订版全部按数字前缀存成文件，上下文窗口不再是用完即弃的全部空间，而是一个只按需读取的干净工作台，任何一步都能单独重跑或手动修改。
Parallel via shared prompt
靠共享提示词实现并行
Serial chunk translation was slow and blew up context; parallelizing broke terminology consistency until consistency was moved from runtime context into a pre-computed shared prompt file that every sub-agent reads identically.
串行分块翻译太慢且容易撑爆上下文；改成并行后又丢失了术语一致性，直到把一致性保障从「运行时上下文」搬到「预先分析生成的共享提示词文件」，每个子 Agent 读同一份文件，术语和风格自然统一。
Human judges, agent optimizes
人做判官，Agent 做优化
When a metaphor translated too literally ('watching in the rear view mirror'), the author didn't hand-edit the prompt — he gave the agent a better reference translation and let it derive the underlying rules (translate intent, preserve emotional tone), which produced more systematic rules than manual editing would.
发现隐喻翻译生硬（如「从后视镜里看」的直译腔）后，作者没有自己改提示词，而是给出一份人工润色的对比译文，让 Agent 自己分析两版差异、总结出「译意图不译字面」「保留情感色彩」等规则——比人工写的更系统。
Detailed Summary详细解读
The article's core claim isn't about prompt-writing technique but about what architecture a reusable translation system actually needs. Two years of experience compress into three stages: hand-designed reasoning chains (two-step, three-step translation) in the prompt era; the single-word shift from 'translate' to 'rewrite' in the reasoning-model era; and, in the agent era, offloading chunking, terminology consistency, and quality tiers to the agent while the human judges quality and sets direction. The value of this arc is showing where the bottleneck moves — from writing a good prompt to designing a good workflow.
The three-step translation method (literal → review → free) isn't itself novel — it's essentially chain-of-thought applied to translation — but the article flags an easily overlooked cost: context consumption grows linearly with steps, and long articles quickly blow the window. This explains why 'rewrite' replacing 'translate' became the better lever once reasoning models arrived: not because the reasoning chain stopped working, but because the model internalized that reasoning, freeing the human from manually scaffolding it and freeing context budget for longer inputs.
The most concrete, transferable insight is the relocation of the consistency problem: serial translation preserves consistency but is slow and context-heavy; parallel translation is fast but lets terminology drift. Rather than trading off between the two, the fix moves consistency enforcement from runtime to a pre-processing step — one upfront analysis pass produces a shared terminology and style spec, saved as a prompt file that every parallel sub-agent reads identically. This generalizes to any multi-agent scenario where parallelization threatens consistency: amortize coordination cost into pre-processing instead of paying it at runtime.
The principle of persisting every artifact as a file runs through the whole piece and is its most underrated design decision. It delivers more than debuggability — it means mode upgrades (normal → refined) skip re-running earlier steps, since analysis and drafts already exist as files. This effectively turns the translation pipeline into a resumable state machine rather than a one-shot black-box call. The prompt-passing mechanism's four rewrites confirm this: from sub-agents fetching their own files, to splitting shared context from per-task instructions, each iteration solved a traceability or responsibility-boundary problem.
The metaphor-translation case is the article's most persuasive evidence, but it also exposes a limitation: the author relies on providing one manually-curated comparison sample from which the agent 'derives' systematic rules — a process that only works if the human's own translation judgment is sharp enough to supply a useful signal. The piece never addresses what happens when the human's judgment isn't good enough; the 'you test, you direct, it executes' model quietly assumes competent human oversight, a boundary condition readers need to supply themselves.
The detail of trimming the terminology glossary from 60+ entries to 15 seems minor but names an often-overlooked principle: supplementary knowledge given to a model should cover only what it doesn't already know or tends to get wrong — redundant entries dilute the ones that actually matter. The same principle governs configuration management, where scattered parameters like chunk thresholds get consolidated into one Defaults table to cut maintenance cost. Together these details point to a larger judgment: good agent-system design is largely an art of subtraction, not rule accumulation.
文章的核心论点不是「翻译提示词怎么写」，而是「一个可复用的翻译系统需要什么架构」。作者把两年经验压缩成三个阶段：提示词时代靠人工设计推理链（两步、三步翻译），推理模型时代把核心指令简化为「重写」而非「翻译」，Agent 时代则把分块、术语一致性、质量分级这些决策外包给 Agent，人只负责判断质量和指方向。这个演进路径的价值在于揭示了瓶颈的转移——从「怎么写好提示词」变成「怎么设计好工作流」。
三步翻译（直译→审校→意译）这个方法论本身并不新鲜，类似 Chain-of-Thought 的应用，但作者指出了一个容易被忽视的代价：上下文占用随步骤线性增长，长文章很快就会撑爆窗口。这也解释了为什么推理模型出现后，「重写」替代「翻译」成为更优解——不是因为推理链本身失效，而是因为模型内化了推理能力，人不再需要手动搭建脚手架，省下的上下文可以用于处理更长的输入。
文章最具体、最可迁移的部分是「一致性问题的转移」：串行翻译能保一致性但慢且吃上下文，并行翻译快但术语会打架。作者的解法不是在两者之间取舍，而是把一致性检查从运行时移到预处理阶段——先做一次全文分析，生成术语表和风格规范，写成一份提示词文件，所有子 Agent 共享这份文件再各自并行工作。这个思路可以推广到任何「并行化会破坏一致性」的多 Agent 场景，本质是把协调成本从运行时摊销到预处理阶段。
「把产物全部持久化成文件」这条原则贯穿全文，也是最容易被低估的设计决策。它带来的不只是可调试性，还有一个更微妙的收益：模式升级（普通→精细）不需要重跑前面的步骤，因为分析、初稿都已经是文件。这本质上是把翻译流程变成了一个可断点续传的状态机，而不是一次性执行的黑盒调用。文中提示词文件的四次重构也印证了这一点——从「让子 Agent 自己找文件」到「拆分共享上下文与任务指令」，每一次重构都是在解决可追溯性和职责边界的问题。
隐喻翻译的案例是全文最有说服力的证据，但也暴露了方法论的局限：作者靠一次人工对比样例，让 Agent「悟」出了系统性规则，这个过程本质上依赖人的翻译判断力足够高，才能提供有效的对比信号。如果人自己判断不出好坏，这套「你测试、你指挥、它执行」的模式就会失效——文章对此没有讨论，也没有给出当人的判断力不够时该怎么办。这是一个需要读者自行补足的边界条件。
术语表从 60 条精简到 15 条这个细节，看似小事，实则点出了一个常被忽视的原则：给模型的补充知识应该只覆盖模型「不知道」或「容易出错」的部分，重复模型已经掌握的内容反而会稀释真正需要注意的条目。这个原则同样适用于配置管理——分块阈值等参数统一放进一张 Defaults 表，避免散落各处导致的维护成本。这些细节共同指向一个更大的判断：好的 Agent 系统设计，很大程度上是「做减法」的艺术，而不是不断堆砌规则。
FAQ常见问答
Does the 'rewrite instead of translate' trick work in the pre-reasoning-model prompt era?「重写」替代「翻译」这个技巧，在提示词时代能用吗？
Less effective. The trick relies on the model having strong reasoning and intent-parsing ability; before reasoning models, giving it more freedom via 'rewrite' risked omissions or over-liberal output, which is why the earlier era needed hand-designed two/three-step chains to constrain the process.
效果会打折扣。这个技巧依赖模型自身有较强的推理和意图理解能力，在推理模型出现前，模型更容易被「重写」的自由度带偏，出现漏译或过度发挥，所以那个阶段作者才需要手工设计两步、三步翻译链来约束过程。
Doesn't using the filesystem as external memory add engineering complexity?文件系统当外部记忆，会不会带来额外的工程复杂度？
It adds some complexity — file management, naming conventions, multi-agent read/write coordination — but buys traceability and resumability: a poorly translated chunk can be redone alone instead of restarting everything, a worthwhile trade for long-document workflows.
会增加一定复杂度（文件管理、命名规范、多 Agent 读写协调），但换来的是可追溯性和断点续传能力——某一块翻译不好可以单独重翻，不用整体重来，这个收益对长文章场景是划算的。
With only 15 glossary entries, is it sufficient for less common language pairs?术语表精简到 15 条，会不会在切换到冷门语言对时不够用？
The article doesn't validate this directly. The 15-entry set is tuned for the author's common pair (English–Chinese); for less common pairs where the model's own knowledge is weaker, the glossary likely needs re-expanding — this shouldn't be copied uncritically.
文章没有直接验证这一点。15 条是针对作者常用语言对（英中）优化的结果，冷门语言对模型本身知识较弱，可能需要重新扩充术语表，这条经验不能不加验证地照搬。
If parallel sub-agents rely on a shared pre-analysis prompt for consistency, what happens when the pre-analysis itself is wrong?并行子 Agent 靠共享提示词文件保一致性，如果预分析本身出错怎么办？
This is a single point of failure in the architecture: consistency depends entirely on pre-analysis quality, and a terminology or style misjudgment there gets synchronously amplified across every sub-agent, unlike serial translation where later chunks might self-correct. The article doesn't address how to detect or repair this.
这是这套架构的单点风险：一致性完全依赖预分析质量，分析阶段的术语误判或风格误判会被所有子 Agent 同步放大，而不是像串行翻译那样可能在后续块中被逐步修正。文章未讨论如何检测或修复这种错误。
Can these lessons transfer directly to agentic workflows beyond translation?这套经验能直接迁移到翻译之外的其他 Agent 工作流吗？
The design principles — persist artifacts, separate concerns, progressive experience, parallelize when possible, treat prompts as code — generalize well, but the specific mechanisms (chunking strategy, glossary) are translation-specific and need re-deriving for a new domain, not copy-pasting.
设计原则（产物持久化、关注点分离、渐进式体验、并行优先、提示词即代码）具有较高的通用性，但具体机制（分块策略、术语表）是翻译特有的，迁移时需要按新场景重新设计对应机制，而不是照搬。
In-depth Analysis · Pros & Cons深入解读 · 优缺点
This piece traces two years of iterating on an AI translation tool through three architectural eras, showing how the real difficulty of translation lies not in prompt phrasing but in system design — chunking, consistency, quality tiers, and personalization.
这篇文章记录了两年打磨 AI 翻译工具的历程，横跨三个架构阶段，说明翻译真正的难点不在提示词措辞，而在系统设计——分块、一致性、质量分级与个性化配置。
- Real iteration log真实迭代记录The four rewrites of the prompt-passing mechanism and the glossary trim from 60 to 15 entries are concrete fail-then-fix cases, not generic best-practice lists — this lends real credibility.提示词传递机制的四次重构、术语表从 60 条精简到 15 条，都是具体的失败-修正案例，而非空泛的最佳实践罗列，可信度高。
- Generalizable consistency fix一致性问题的解法具通用性Moving consistency enforcement from runtime context to a shared pre-analysis file is a pattern that transfers to any multi-agent scenario where parallelization threatens consistency.把一致性保障从运行时上下文转移到预分析阶段生成的共享文件，这个思路可以迁移到任何「并行化威胁一致性」的多 Agent 场景。
- Clear human/agent division人机分工清晰The 'human as quality judge and direction-setter, agent as rule-refiner' division runs throughout and is demonstrated concretely via the metaphor-translation case, not just stated as a slogan.「人做质量判官和方向指挥，Agent 做规则细化」这条分工原则贯穿全文，并用隐喻翻译案例具体展示了如何执行，而不只是口号。
- Sound progressive UX design渐进式体验设计合理Defaulting to normal mode and allowing on-demand upgrade to refined mode without re-running prior steps balances 'users shouldn't need to pre-judge quality needs' against 'don't waste existing artifacts'.默认普通模式、按需升级精细模式且不重跑前置步骤，这个设计权衡了「用户不需要提前判断」和「不浪费已有产物」两个诉求。
- Assumes strong human judgment, no failure case依赖人工判断力，未讨论失效场景The 'you test, you direct, it executes' model assumes the human can reliably judge translation quality; the piece never discusses what happens when that judgment itself is weak.「你测试、你指挥、它执行」的模式默认人能准确判断翻译好坏，文章没有讨论人自己判断力不足时这套方法会如何失效。
- Pre-analysis is a single point of failure, no correction loop预分析成为单点风险，缺乏纠错机制Consistency depends entirely on pre-analysis quality; errors there get synchronously amplified across all parallel sub-agents, and no detection or repair mechanism is proposed.一致性完全依赖预分析质量，分析阶段的错误会被所有并行子 Agent 同步放大，文章未提出检测或修复机制。
- Narrow sample: limited language pairs and domains经验样本单一，语言对和场景有限Cases center on English-to-Chinese technical/narrative text; whether the glossary-trimming and chunking conclusions hold for less common language pairs or highly specialized domains (legal, medical) is untested.案例集中在英译中的技术/叙事类文本，术语表精简、分块策略等结论是否适用于小语种或高度专业化领域（如法律、医学文本）未经验证。
- No quantified cost or failure-rate comparison缺少成本与失败率的量化对比The piece repeatedly claims things like 'several times faster' or 'costs more instead,' but offers no concrete token-usage, latency, or quality-score comparisons, leaving readers unable to independently verify the magnitude of these gains.文章多次提到「速度提升好几倍」「成本反而更高」，但没有给出具体的 Token 消耗、耗时或翻译质量评分对比，读者难以独立验证这些收益的量级。
Worth reading for anyone building an agentic tool beyond a single prompt call — the value is in the concrete architectural lessons (file-as-memory, pre-computed consistency, four prompt-passing rewrites), not in translation technique itself. Caveat: treat it as one practitioner's iteration log with an unquantified track record, not a benchmarked methodology.
适合任何想把单次提示词调用升级成 Agent 系统的人读，价值在于具体的架构经验（文件即记忆、预先计算一致性、提示词传递的四次重构），而不在翻译技巧本身。但要注意，这是一份缺乏量化数据的个人实践记录，不是经过基准测试的方法论，采用前需自行验证。
Original Text原文
The English text on this side is an AI translation provided for convenience; the authoritative version is the source in the other language.
I've been tinkering with AI translation for almost two years now. From hand-writing prompts at the start, to now using an Agent to automatically chunk, translate in parallel, and review/polish, I've hit plenty of pitfalls along the way and accumulated plenty of experience. Recently I organized this experience into a reusable translation Skill, and this article is about how that Skill was iterated on step by step.
Translation as a scenario is more complicated than it looks. The prompt itself is simple — anyone can write "translate this passage into Chinese." But to turn it into a general-purpose Skill, you have to consider: inputs come in all shapes, some people paste a single sentence, some dump a ten-thousand-word article, some hand you a Markdown file; everyone has different habitual language pairs; sometimes you just want a quick gist, sometimes you need the translation quality to be top-notch.
Content that's too long either can't be handled by the model or the results degrade, so it needs to be chunked — but once chunked, consistency across chunks is hard to guarantee. These problems weren't solved by thinking them through once; they were worked out through round after round of iteration.
The three stages of my AI translation journey
The first stage was before reasoning models existed.
Back then, translation quality depended entirely on the prompt — role setup, tone requirements, glossary, whatever could be stuffed in got stuffed in. I was probably among the first to publicly propose using "two-step translation" and "three-step translation" to improve translation quality.
Two-step translation means translating literally first, then translating for meaning — the principle is similar to a reasoning chain, letting the model first honestly match the meaning of the original, then re-express it in a more natural way. It works well, but it costs tokens. Three-step translation adds a middle review step: literal translation first, then review to find problems, then free translation last — better results, but it eats up a lot of context.
The second stage was after reasoning models appeared.
With reasoning capability, I no longer needed to manually design the reasoning chain — the model could "think" on its own. At this point the core of the translation prompt became a single word: "rewrite." Not asking the model to "translate," but to "rewrite" the content in the target language. The word "translate" makes the model fixate on every word of the original; "rewrite" gives it more freedom to handle metaphors and restructure sentences. This shift in thinking brought a clear improvement in quality.
The third stage is the Agent stage.
In the Agent era, the translation workflow can be made much more refined. Previously, every decision was made by me: whether to chunk, how big to chunk, which glossary to use, whether the translation quality was good enough. Now many of those decisions can be handed off to the Agent, with a human confirming at key checkpoints.
Specifically, my Agent translation workflow looks like this:
The Agent first analyzes the article to be translated, identifies technical terms, cultural metaphors, and background knowledge readers might not understand, and saves this as an analysis file
Based on the analysis results and a prompt template, it generates a translation prompt, which is also saved as a file
If the article is too long, a script splits it into chunks based on Markdown structure
Multiple sub-agents translate in parallel, each handling one chunk
Once translation is done, the chunks are merged and an overall proofread is done
All intermediate outputs — the analysis report, the translation prompt, the original text and translation of each chunk, the review comments — are all saved as files. Translation is an iterative process; if one chunk is translated poorly, it can be retranslated on its own without starting over. If there's a problem with the prompt, you can edit the file directly without rerunning the analysis.
At this stage, it was only natural to want to turn the whole process into a Skill for reuse.
What's the difference between Agent translation and prompt translation
With prompt-based translation, you stuff the original text, instructions, and glossary into the context, the model executes once, and the output is the result. The context window is your entire workspace — everything has to be crammed in there. Once an article gets long, you either truncate it or force it in, and quality and cost both become hard to control.
Agent translation is different, in three main ways.
First, the Agent has a workflow, not a one-shot execution. It follows the process the Skill was designed with, but not rigidly step by step. For short articles it skips chunking; for long articles it analyzes the Markdown structure itself to find safe split points; it uses different chunking strategies for plain text versus Markdown. The target language, translation style, and quality requirements can all be flexibly adjusted based on user needs. When it hits a problem, it writes its own script to handle it — for example, writing code to do AST parsing so it doesn't cut a table or code block in half. None of this is achievable with a single prompt.
Second, the Agent can use the file system as external memory. Analysis results are saved as files, the translation prompt is saved as a file, and the translation of each chunk is also saved as a file. The Agent doesn't need to hold everything in context — it reads what it needs when it needs it, keeping the context clean at all times. With traditional prompt translation, the context is your everything, used once and discarded; with Agent translation, the file system is the main memory, and the context is just a workbench.
Third, the Agent can spawn sub-agents to work in parallel. With traditional prompt translation, one model translates from start to finish. An Agent can spin up ten sub-agents, each given only the shared prompt file plus the chunk it's responsible for, translating independently. Speed improves several times over, and each sub-agent's context load is lower too, since it only needs to focus on its own chunk.
Combining these three capabilities turns translation from "write one good prompt" into "design a translation system." What follows is how this system was iterated on step by step.
How the Skill was created and iterated on
Creating the Skill itself wasn't complicated. In Claude Code, using skill-creator, once you clearly state the idea, it can generate an initial version.
My very first instruction laid out the core requirements clearly:
Help me create a new translation skill for the current project:
Two modes: normal translation, and fine-grained translation
An EXTEND.md file that lets you customize the default target language, language-to-language glossaries, etc.
For normal translation, just translate directly
For fine-grained translation, make it a workflow: first analyze the article content → initial translation → review → polish, etc.
If the content is too long, it needs to be chunked for translation, but terms and names should be identified first to ensure consistency across the whole text
I also directly attached a sample reference translation prompt and a sample glossary, so Claude wouldn't need to guess my translation style preferences.
The whole process of creating and iterating on the Skill went like this:
In Claude Code, use skill-creator, state the idea directly, and generate an initial version
Use the generated version to translate a real article — not a test case, but content that actually needed translating
Read the translation output and identify what's unsatisfactory
Feed the problems back to Claude Code and have it improve the Skill
Translate again, check again, repeat the cycle
In this process, the human's role is quality judge and direction commander. You need to be able to judge whether a translation is good, and be able to clearly articulate what's wrong with it, but you don't need to write the prompt details yourself. For example, when I found serial translation too slow, I just told the Agent "switch to parallel," and it handled the resulting consistency issues on its own. Another example: when metaphor translations felt stiff, I gave it two versions of a translation and had it summarize the pattern itself — the rules it came up with were more systematic than anything I would have written.
Where the three translation modes came from
Originally only two modes were designed: normal and fine-grained. Later I found that often I just wanted a quick gist, and the analysis step in normal mode was overkill, so I added a quick mode, making it three:
Quick mode — no analysis, no chunking, translates directly, suited for when you just want a quick gist
Normal mode — first analyzes the article content, extracts terminology, identifies difficult points, then translates. Long content is automatically chunked and merged after translation. When done, it asks you: want to continue polishing?
Fine-grained mode — same as normal mode up front, but afterward it continues to review the translation result, revises based on the review comments, and finally polishes it into a final version
There's a UX consideration here: the default is normal mode. You don't need to decide in advance what level of translation quality you need. Most of the time normal mode is enough; if after reading it you feel it needs to be better, replying "continue polishing" seamlessly upgrades it to fine-grained mode. All intermediate results are saved as files, so upgrading modes doesn't require rerunning earlier steps.
From serial to parallel: solving the consistency problem
Originally, chunked translation was done serially. One sub-agent translated all the chunks in order, with the previous chunk's result placed into the next chunk's context to ensure continuity.
But it was too slow — ten chunks had to be translated one after another. Worse, the context could blow up, and if you truncated earlier content you couldn't use Prompt Cache, which actually made costs higher.
What about switching to parallel? Multiple sub-agents translating different chunks at the same time made it faster, but consistency couldn't be guaranteed. The same term might be translated as "moat" by the first sub-agent and "competitive barrier" by the third.
The solution was to shift the guarantee of consistency from "runtime context" to "upfront analysis." Before translation, an analysis pass is done first, nailing down the glossary, translation style, and naming conventions, and writing them into an analysis report. Then, based on the analysis report and a prompt template, a complete translation prompt is generated.
Each sub-agent receives the same prompt plus the chunk of content it's responsible for, so how terms are translated and what tone the style should have is fully unified. Ten chunks, ten sub-agents running in parallel — speed improves several times over, and consistency is guaranteed by the shared prompt file.
Chunking itself takes some care too. Initially it split on blank lines, which would cut tables, code blocks, and lists in half, causing a lot of trouble downstream. Later this was changed to use a library for Markdown AST parsing, splitting only at structurally safe points, such as paragraph boundaries or right after headings.
Four rounds of refactoring how the prompt is passed
This part went through the most iterations.
Version one had the sub-agent read the analysis file itself. The sub-agent had to find the file and interpret the analysis results on its own, which added uncertainty.
Version two had the main Agent read the analysis file, assemble all the context into one complete prompt, and pass it directly to the sub-agent. This was somewhat better, but the prompt only existed within the call parameters — it couldn't be traced or manually inspected.
Version three saved the assembled prompt as a file. The sub-agent just reads this file. The prompt itself became a traceable intermediate artifact — you could open it up to check whether the generated prompt was correct, or even edit it by hand.
Version four: during actual testing, a problem surfaced — the prompt file included the list of all chunks, and seeing information about every chunk confused the sub-agent, since it was only responsible for translating one chunk. So the prompt was split into two parts: the shared context (background, glossary, translation principles) is saved as a file, and the task instruction (which file to translate, where to save it) is passed separately as a call parameter.
All artifacts are saved as files
Regardless of whether the input is a file, a URL, or pasted text, the first step is always to save it as a file. Then the analysis report, translation prompt, first draft, review comments, revision, and final translation are all saved in the same directory, with numeric prefixes marking the step order:
01-analysis.md — content analysis
02-prompt.md — translation prompt
03-draft.md — first draft
04-critique.md — review comments
05-revision.md — revised version
translation.md — final translation
One chunk translated poorly? Retranslate just that chunk. Want to check whether the analysis report missed anything? Just open 01-analysis.md. Want to manually adjust the translation prompt? Just edit 02-prompt.md. Finished a normal-mode translation and want to upgrade to fine-grained mode? The earlier files are all there — just start from the review step.
Parallel translation is possible for the same reason: the prompt is already a file, and multiple sub-agents sharing the same file are naturally consistent.
Letting the Agent discover problems on its own
A typical problem turned up during translation testing. The original text was:
"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."
The model translated it as:
"整个 1960 年代，瑞士人一直从后视镜里看着日本人以惊人的速度追赶上来。" ("Throughout the 1960s, the Swiss kept watching the Japanese catch up at an astonishing speed in their rearview mirror.")
Whereas the translation I expected was:
"整个六十年代，瑞士人一直把日本人看作身后的追赶者，而且对方进步的速度已经让他们感到不安。" ("Throughout the sixties, the Swiss had regarded the Japanese as pursuers on their tail, and the pace of the Japanese's progress had already begun to unsettle them.")
"Watching in the rearview mirror" is a literal translation of an English metaphor, and it reads awkwardly to a Chinese reader. "Alarming" was translated as "astonishing," which loses the original's sense of the Swiss feeling unsettled.
My approach wasn't to go edit the prompt myself. I manually put together a high-quality reference translation, then had the Agent compare the two versions itself and analyze what was better and how the translation could be improved.
The Agent identified several core patterns on its own: metaphors should be interpreted for intent rather than translated literally by image; convey the author's meaning rather than translating word for word; preserve the emotional coloring of word choice — "alarming" isn't just "astonishing," it also carries a sense of unease; use Chinese emphatic structures rather than copying the English word order.
The Agent then made optimizations at three levels. In the analysis stage, it added metaphor mapping, requiring an analysis of the author's intent, the risk of literal translation, and the target-language handling strategy for every metaphor. In the translation principles, it added "translate intent, not the literal wording" and "preserve emotional coloring." In the review stage, it specifically checks for literally-translated metaphors and flattened emotional tone.
Throughout this whole process, what I did was: identify the problem, provide a comparison example, and point out the direction. How exactly to change the Skill was left to the Agent itself.
The Agent understands how to write a good prompt better than you do, but you need to tell it the direction. You don't need to write the Skill's specific rules yourself — what you need to do is find the problems, provide a standard for good versus bad, and then let the Agent analyze and optimize on its own. You test, you direct, it executes.
Personalization settings
Everyone's translation needs are different. Some people mainly translate English to Chinese, some translate Japanese to English. Some target technical readers, some target general readers.
The Skill has an EXTEND.md file designed into it, where users can set their own default target language, translation style, target readership, and glossary. The first time you use it, it walks you through a setup, and after that every translation reads your configuration.
Target readership isn't just a configuration item — it affects the entire translation strategy. For general readers, add more translator's notes; for technical readers, you can omit explanations of common terms. Academic readers get formal register, general readers get a narrative style.
The gloss itself takes care. Rather than simply tagging the original English term, it explains the meaning in plain language. For instance, the "comb-over effect" (a series of individually small changes that eventually take you from slightly off to absurdly broken) lets readers unfamiliar with the concept keep reading smoothly.
Trimming the glossary
The glossary started with 60-plus entries and was later trimmed down to 15. Terms the model already knows on its own — like translating "Machine Learning" as 机器学习 — were removed, keeping only the ones prone to mistranslation or dispute, such as "AI Wrapper" as AI 套壳, "Hallucination" as 幻觉, and "Moat" as 护城河.
The glossary is supplementary knowledge for the model, not the whole of it. No need to repeat what the model already knows — too much repetition dilutes the entries that actually need attention.
A similar approach was applied to configuration management. The Skill had parameters like the chunking threshold and max words per chunk scattered across various places, so changing one meant hunting through several spots. These were later consolidated into a single Defaults table, with settings in EXTEND.md able to override the defaults — so each specific number appears only once.
Looking back, a few principles kept recurring
First, persist every artifact. Source files, analysis, prompts, drafts, reviews, and final versions are all saved as files — traceable, debuggable, recoverable.
Second, separation of concerns. Analysis is analysis, translation is translation, review is review. Sub-agents handle only the draft translation; review and polishing require a global view and are handed back to the main agent.
Third, a progressive experience. Default to normal mode, and prompt for an upgrade once done — the user doesn't need to anticipate anything in advance.
Fourth, parallelism first. Parallelize as much as possible while preserving quality, letting multiple sub-agents work independently via a shared prompt file.
Fifth, prompts as code. Translation prompts are saved as files — inspectable, editable, reusable.
The distance from "translate this passage into Chinese" to a complete translation Skill turned out to be bigger than I expected. The translation prompt itself is indeed simple, but a genuinely usable translation tool has to handle far more than translation alone: input format, chunking strategy, terminology consistency, quality tiers, intermediate artifact management, personalized configuration. None of these problems can be solved by a single prompt, yet none of them requires you to write code from scratch either. Your value lies in judging quality, spotting problems, and pointing the direction. Let the agent handle the specifics of optimization.
Project link: https://github.com/JimLiu/baoyu-skills
Installation:
npx skills add https://github.com/jimliu/baoyu-skills --skill baoyu-translate
Works with both crawfish 🦞 and Claude Code.
我做 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