對於承接 B2B 翻譯案、遊戲文本在地化（Game Localization）、或是醫學與法律手冊的自由譯者來說，有一個字絕對是惡夢：「名詞不一致」。
在三十萬字的角色扮演遊戲（RPG）文本中，一個魔法道具可能昨天被翻成「破壞之劍」，大後天又被翻作「毀滅戰刃」。當玩家在遊戲中看到任務面板與道具欄名字不一樣，這就是極度嚴重的翻譯事故。
傳統的解法是使用 SDL Trados 這類的 CAT（電腦輔助翻譯）工具。但在生成式 AI 時代，讓大語言模型（LLM）直接吃下整個你的術語庫（Glossary） 來強制翻譯，不僅速度極快，更是大勢所趨。
💡 本篇定位 這是翻譯 AI 技能樹的「術語管理」篇。建議搭配閱讀：MTPE 機器譯後編輯（初稿效率流程）與語氣在地化（確保翻譯不只正確，還有靈魂）。
傳統 CAT 工具 vs. LLM 術語管理：到底差在哪？
在深入實作之前，先釐清一個關鍵問題：既然 SDL Trados、MemoQ 這些 CAT 工具已經有術語庫功能，為什麼還要用 LLM？
兩種路線的差異比較
| 比較項目 | 傳統 CAT 工具（Trados / MemoQ） | LLM 術語庫（ChatGPT / Claude） |
|---|---|---|
| 術語匹配方式 | 精確字串比對，原文必須完全一致才觸發 | 語意理解，能辨識同義詞、縮寫、變體 |
| 上下文感知 | 幾乎沒有，只看單一句段 | 能根據前後文判斷同一個詞的不同譯法 |
| 建置成本 | 需購買授權（年費 USD 300–800+） | API 費用或訂閱制（月費 USD 20 起） |
| 學習曲線 | 介面複雜，需數週學習 | 會打字就能用，門檻極低 |
| 批量處理速度 | 快（本機運算） | 快（但受 API 速率限制） |
| 術語「強制力」 | 100% 精確，不會偏差 | 需透過 Prompt 設計提高服從度，偶有遺漏 |
| 適合場景 | 高度重複性的技術文件、軟體 UI | 遊戲劇情、行銷文案、創意型長文本 |
最佳解法：混合使用
實務上，頂級譯者不會只選一邊。最常見的工作流是：
- CAT 工具負責「已經有明確對應」的技術性術語（產品型號、法規條號）
- LLM負責需要語境判斷的翻譯（角色口吻、情境改寫）
- 最終由人工 MTPE 流程做品質把關
這種混合路線的效率，比單獨使用任何一種工具都高出 30% 以上。
建立你的「專屬翻譯記憶庫大腦」
步驟 1：整理標準化的術語庫（Glossary）
無論你要餵給 ChatGPT 還是 Claude，第一步永遠是將原本零散的 Excel 匯出為一個結構清晰的文字檔（如 Markdown、CSV 或 JSON）。
例如，準備好這樣的一份 Glossary.txt：
[角色名稱]
Vanguard -> 先鋒隊長（男）
Siren -> 賽壬（女，海妖）
King Arthur -> 亞瑟王
[道具與技能]
Healing Potion -> 治癒藥水
Meteor Strike -> 隕石風暴
Mana Shield -> 法力護盾（絕對不能翻譯成魔力盾）
[世界觀地名]
Frostfall -> 霜降城
The Abyss -> 萬丈深淵步驟 2：選擇最適合的檔案格式
不同格式各有優劣，選錯格式會直接影響 LLM 的術語服從度：
| 格式 | 優點 | 缺點 | 適用場景 |
|---|---|---|---|
| 純文字（TXT） | 最簡單，人類一眼看懂 | 結構較鬆散，大量術語時容易混亂 | 術語量 < 100 條 |
| CSV | 結構清晰，可直接從 Excel 匯出 | LLM 偶爾會誤讀逗號分隔 | 術語量 100–500 條 |
| JSON | 結構最嚴謹，支援巢狀分類 | 人類閱讀不直覺 | 術語量 > 500 條或需要 API 串接 |
| Markdown 表格 | 視覺清晰，LLM 理解度最高 | 手動維護較麻煩 | 需要附加備註或使用限制的術語 |
對於大多數自由譯者，Markdown 表格是最佳平衡點——LLM 的理解度高，人類維護也方便。
步驟 3：強制定錨的翻譯 Prompt（Glossary Enforcement）
大語言模型也是會「忘記」的。如果你一次丟給它 5 萬字，它到最後可能還是會把 “The Abyss” 翻成 “深淵”。
所以你必須在每次分批（Chunking）翻譯時，強力聲明術語的優先級別。
📌 實戰 Prompt：載入術語庫強制翻譯
你現在是一位資深的遊戲在地化翻譯專家。
我將請你翻譯一段西方奇幻角色扮演遊戲的台詞文本（從英文翻為繁體中文）。
【⚠️ 強制術語指令 ⚠️】
以下是我們本專案的「官方名詞翻譯對照表 (Glossary)」。
在進行翻譯時，若原文出現表內的英文單字，你【必須100%】使用我指定的對應繁體中文，絕對不可自行發明新的譯名：
--- 術語庫開始 ---
Vanguard -> 先鋒隊長
Siren -> 賽壬
Meteor Strike -> 隕石風暴
The Abyss -> 萬丈深淵
--- 術語庫結束 ---
【作業要求】
1. 除了需嚴守上述術語外，請保持遊戲台詞中世紀奇幻般史詩且略帶戲劇張力的對話語氣。
2. 請保留所有的遊戲代碼系統標籤（如 `<color=red>` 或 `\n`），不可以翻譯它們。
3. 若有任何你不確定的名詞，請附註於翻譯結果最下方的 `[譯者疑惑區]`，以供我人工審查。
請回覆「了解術語庫限制」，接著我將貼上第一段對話劇本。挑戰與進階心法：Prompt 記憶衰退
「如果你發現 AI 翻到第十頁時，又開始亂翻名詞了，該怎麼辦？」
這在大語言模型中被稱為「Context Window 遺忘現象」。你不需要重新發脾氣，只需要：
策略 1：分段重新注入術語庫
翻譯長文本時，不要把 30 萬字全部擠在同一個 ChatGPT 視窗。大約每 3–5 萬字，請開一個全新的對話，並把上面的「術語庫 Prompt」重新餵給它一次，重溫記憶。
策略 2：善用 System Prompt 提高服從度
如果你使用 API 或介面後台（如 Dify/Coze 或是 OpenAI 的 Playground），將術語表寫死在 System Message 中，能夠大幅增加模型對這些詞彙的服從度。這跟Prompt 工程中「系統層指令優先於使用者層指令」的原理完全一致。
策略 3：翻譯後自動校驗
最穩妥的做法是在翻譯完成後，跑一次自動化比對腳本：把術語庫中所有的原文詞彙拿去搜尋譯文，確認每一個出現的地方都使用了指定譯名。這步驟可以用簡單的 Python 腳本或 Excel VLOOKUP 完成，幾分鐘就能揪出所有漏網之魚。
醫學與法律術語庫的特殊挑戰
遊戲術語翻錯，最多被玩家罵；醫學和法律術語翻錯，後果可能是人命關天或官司纏身。這兩個領域的術語管理有幾個獨特的難點，值得單獨拉出來談。
醫學翻譯：一詞多義的地獄
醫學術語最棘手的地方不是「不知道怎麼翻」，而是同一個英文詞在不同科別有不同的標準譯法。
| 英文術語 | 心臟科翻法 | 神經科翻法 | 直接丟給 AI 的結果 |
|---|---|---|---|
| Stroke | 心搏（Stroke Volume） | 中風（腦中風） | 隨機二選一 |
| Discharge | 放電（心臟放電） | 出院（病患出院） | 看上下文猜，常猜錯 |
| Culture | — | — | 可能翻成「文化」而非「培養（細菌培養）」 |
解法是在術語庫中加入領域標籤：
[心臟科專用]
Stroke -> 心搏（非「中風」，心臟科語境）
Discharge -> 放電
[神經科專用]
Stroke -> 中風（腦血管意外）
Discharge -> 出院並在 Prompt 中明確指定：「本次翻譯屬於【心臟科】領域，遇到歧義詞彙請一律依照心臟科術語庫。」
法律翻譯：精確度就是一切
法律文件的術語容錯率是零。「shall」和「may」的差別，在合約中可能代表數百萬的賠償責任。法律術語庫需要額外加入：
- 法規出處：每個術語標註來源法條，例如「善良管理人注意義務（民法第 535 條）」
- 不可替代標記：某些術語絕對不能用近義詞替換，需在術語庫中標註「⚠ 不可改寫」
- 管轄區差異：台灣法律用語與中國大陸不同（例如「智慧財產權」vs.「知識產權」）
這類高風險翻譯完成後，務必搭配MTPE 譯後編輯流程做最終人工審查——AI 在這裡的角色是「高效初稿產生器」，絕對不是「最終定稿者」。
術語庫的長期維護：別讓它變成廢墟
很多譯者花了大力氣建好術語庫，卻從此再也不更新。三個月後，術語庫跟實際專案的用語早就脫節了。
維護的三個實務原則
- 每案更新：每完成一個翻譯案，花 15 分鐘把新增的術語回填到主術語庫。這 15 分鐘會在未來幫你省下數小時的名詞校對時間。
- 版本控制：術語庫也要有版本號。當客戶更改了某個產品名的官方譯法，你必須知道「從哪一版開始改的」，才能回溯修正舊文件。
- 客戶共管：理想的做法是邀請客戶一起維護術語庫——他們負責確認官方譯名，你負責執行。這樣出了問題，責任歸屬才清楚。
如果你同時在做在地化翻譯的案子，術語庫更需要區分「可在地化改寫的詞」和「絕對不能動的官方名詞」。這個區分沒做好，就會出現品牌名被創意改寫的災難。
從苦工到總規劃師：術語管理的職涯意義
這種從「逐字敲打的苦工」轉變為「管理 AI 與維護名詞手冊的總規劃師」，正是現代譯者產值翻倍的不二法門。
當你能向客戶展示一份結構完整、持續維護的術語庫，你賣的就不只是「翻譯服務」，而是「翻譯品質管理系統」。這正是翻譯 AI 轉型指南中所強調的——AI 時代的譯者核心價值，是流程設計與品質控管能力。
常見問題 FAQ
術語庫要多大才夠用？一個專案通常需要多少條術語？
視專案類型而定。一般企業文件大約 50–200 條就足夠；遊戲在地化專案通常需要 500–2,000 條（角色、道具、技能、地名全部加起來）；醫學或法律手冊可能需要 1,000 條以上。重點不是數量，而是涵蓋率——你的術語庫是否覆蓋了該專案中所有「翻錯會出事」的關鍵名詞。
ChatGPT 和 Claude 哪個比較適合做術語庫翻譯？
兩者都能勝任，但特性不同。Claude 的上下文視窗（Context Window）較大，適合一次載入大量術語庫加長文本；ChatGPT 的 GPT-4o 在指令遵從度上表現穩定。實務建議是兩個都測一輪，用同一段文本加同一份術語庫，看哪個的名詞一致性更好。最終選擇往往取決於你的具體專案類型和個人工作習慣。
術語庫可以用在 MTPE 流程中嗎？
不只「可以」，而是「必須」。MTPE（機器譯後編輯）的第一步就是確保 AI 初稿的名詞一致性。如果 AI 的初稿名詞就是亂的，後面的人工編輯等於要從頭修正，完全喪失 MTPE 的效率優勢。正確的流程是：先用術語庫約束 AI 產出初稿，再由人工專注處理語氣、流暢度和在地化調整。
客戶沒有提供術語庫怎麼辦？要自己建嗎？
這反而是你展現專業價值的機會。主動為客戶建立術語庫，在報價中加入「術語庫建置費」（通常是翻譯報價的 10%–20%），並在交付時一併提供完整的術語庫檔案。很多客戶從來沒想過這件事，當你主動提出，他們會對你的專業度刮目相看——而且這份術語庫會成為你們長期合作的黏著劑。