我用 AI 翻譯的三個階段：提示詞時代 → 推理模型時代 → Agent 時代

我用 AI 翻譯的三個階段：提示詞時代 → 推理模型時代 → Agent 時代

我做 AI 翻譯這件事，前前后后折騰了快兩年。從最早手寫提示詞，到現在用 Agent 自動分塊、并行翻譯、審校潤色，中間踩了不少坑，也攢了不少經驗。最近把這些經驗整理成了一個可復用的翻譯 Skill，這篇文章聊聊這個 Skill 是怎么一步步迭代出來的。

翻譯這個場景比看上去復雜。提示詞本身很簡單，"把這段話翻譯成中文"誰都會寫。但要做成一個通用的 Skill，你得考慮：輸入千奇百怪，有人貼一句話，有人丟一篇萬字長文，還有人給個 Markdown 文件；每個人常用的語言對不一樣；有時候只想快速看個大意，有時候要求翻譯質量必須高。

太長的內容模型處理不了或者效果變差，需要分塊，分塊了又不好保證前后一致。這些問題不是一次想清楚的，是一輪輪迭代踩出來的。

我用 AI 翻譯的三個階段
第一個階段是推理模型出來之前。

那時候翻譯質量全靠提示詞，角色設定、語氣要求、術語表，能塞的都塞進去。我應該是最早公開提出用"兩步翻譯"和"三步翻譯"來提升翻譯質量的。

兩步翻譯就是先直譯再意譯，原理類似推理鏈，讓模型先老老實實把原文意思對上，再用更自然的方式重新表達。效果確實好，但費 Token。三步翻譯多了一個中間的審校環節，先直譯，再審校找問題，最后意譯，效果更好，但上下文占用很大。第二個階段是推理模型出來之后。

有了推理能力，不需要我手動設計推理鏈了，模型自己會"想"。這時候翻譯提示詞的核心變成了一個詞："重寫"。不是讓模型"翻譯"，而是讓它用目標語言"重寫"這段內容。"翻譯"這個詞會讓模型惦記著原文的每個字，"重寫"給了它更大的自由度去處理隱喻、重組句式。這個思路轉變帶來的質量提升很明顯。

第三個階段是 Agent。

到了 Agent 時代，翻譯工作流可以做得更精細。之前所有決策都是我做的：要不要分塊、分多大、用什么術語表、翻譯質量夠不夠好?，F在很多決策可以交給 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 都可以用。

*來源：X @dotey（寶玉）*