交件審稿與品質檢核

🎯 這條流程解決什麼

翻譯社交件前的審稿，是最吃審稿師心力、卻又塞滿機械性勞動的一道關。審稿師打開一份譯稿，要做的不只是讀通順——他得一手拿著客戶的詞彙表（glossary）和風格指南，逐段核對術語有沒有照客戶要求譯（同一個產品名、法律名詞,全篇有沒有用法不一致）、有沒有整段或整句漏譯、數字有沒有抄錯一個零、標點與全半形有沒有跑掉、排版標籤（尤其是有 tag 的本地化檔案）有沒有對齊原文。

這些比對工作高度機械，卻偏偏最花時間。一份上萬字的稿子,光是逐段對齊原文找漏譯、查術語一致性，就可能吃掉審稿師兩三個小時，真正需要「人的語感」去判斷的潤飾、語氣、在地化反而被擠到最後、草草帶過。趕件時更危險：審稿師為了趕交期跳著看，漏掉一個術語不一致或一處漏譯，交到客戶手上才被抓出來，輕則重做、重則賠上客戶信任，法律或醫療這類文件甚至可能造成實質損害。問題的本質是：審稿師把太多時間花在「機器其實做得比人更穩」的比對上，而把最該由專業判斷的部分壓縮掉了。

導入後的改變

導入前，審稿是「審稿師從頭逐字掃」：所有比對、找漏、查格式都靠人眼,效率受限於人的注意力與耐心，趕件時錯漏率上升。導入後，分工重新切割——機械比對交給自動化，審稿師只面對「被標出來的疑點」並專注在語感判斷上。

效益相當直接。以一份萬字稿估算，原本審稿師約需 2 到 3 小時逐段比對加潤飾，導入後系統幾分鐘跑完術語、漏譯、格式三項檢核並產出待審清單，審稿師針對清單上被標記的可疑點逐項確認、再做整體語感把關，整份審稿時間通常能壓到 1 小時上下，等於審稿工時省下約五到六成。更關鍵的是品質穩定度：機械性的術語不一致、漏譯、數字錯、格式跑掉這類「最不該交出去卻最常被趕件漏看」的錯誤，靠系統地毯式掃描幾乎都能在交付前被攔下，客戶端被抓錯而重做、客訴的比率明顯下降，審稿師也不必再為趕件而提心吊膽。

流程怎麼運作

這條流程由「譯者標記初稿完成」觸發，對應 frontmatter 五個節點：

1. 交稿接收（📄）：接收譯者上傳到 Google Drive 的稿件,讀取原文與譯文,對齊兩者的段落與句子結構，建立比對基礎。
2. 術語比對（🔤）：依該客戶的詞彙表與風格指南，用 OpenAI API 檢查術語譯法是否一致、是否照客戶指定用詞，並標出疑似漏譯的段落（原文有、譯文對應位置卻空缺或明顯過短）。
3. 格式檢核（📐）：檢查數字、日期、貨幣、標點全半形、排版與標籤是否與原文一一對應，揪出抄錯數字、漏標點、標籤錯位等問題。
4. 待審清單（📝）：把以上所有可疑點彙整成一份結構化的待審清單（標明位置、類型、原文與譯文對照），透過 Slack 推給審稿師逐項人工確認。
5. 打包交付（📦）：審稿師確認通過後，系統把終稿打包，透過 Gmail 交付客戶，並把對應版本歸檔到 Google Drive。

需要的工具與串接重點

平台用 n8n 或 Make。Google Drive是稿件進出與版本歸檔的中樞，建議用「客戶／案件／版本」的資料夾結構，並對機密稿件設分權限。Google Sheets維護各客戶的詞彙表與風格指南，這是術語檢核的判斷依據，必須持續更新、版本明確——詞彙表過期，檢核就會誤判。OpenAI API負責語意層的比對（術語一致性、漏譯偵測），重點是把任務框成「找出疑點並標註理由」而非「自動改稿」，並要求它對不確定的標低信心、丟給人判斷。Slack把待審清單轉成審稿師的待辦通知，Gmail負責最終交付。串接最大的注意點是「檢核只標記、不自動修改」——任何自動改寫都可能把對的改錯。整體閘門與防呆設計原則可參考 /automation。

常見錯誤與注意事項

⚠️ 品質與專業提醒：自動檢核只負責「找出疑點」，不判斷對錯，最終譯文品質務必由審稿師逐項人工確認，系統不取代專業審稿與潤飾。法律合約、醫療、財報等高風險文件，建議加一道領域專家複核，避免機器誤判造成實質損害。客戶稿件含機密內容，版本歸檔須分權限並設保存期限。

最常見的三個錯誤：一是把自動檢核當定稿，以為系統跑過就沒問題、跳過審稿師人工確認，但 AI 會漏判也會誤判，這一步不能省；二是讓 AI 直接改稿，自動修正看似省事，卻可能把客戶刻意指定的特殊用詞、語氣「改回常規」，反而出錯——所以系統只標記、修改一律由人決定；三是詞彙表沒維護，拿過期的術語表去檢核，把對的標成錯、把錯的放過。高風險文件（法律合約、醫療、財報）即使過了自動檢核與審稿，也建議再加一道領域專家複核，機器誤判在這類文件上的代價是實質的法律與安全風險。客戶稿件多含機密與營業祕密，Drive 權限要分級、歸檔版本要設保存期限，離職或結案後須回收存取權，不可外流。

台灣中小企業情境案例

桃園一家專做技術與法律文件的翻譯社，常接機械手冊、專利與合約案，客戶對術語一致性要求極嚴。導入前，兩位審稿師長期被「逐段對齊找漏譯、翻詞彙表查術語」的機械工作綁住，旺季趕件時還是出過幾次包——一份手冊把某個關鍵零件名前後譯成兩種說法，被客戶退回重做，賠上時間也賠了信任。導入這條流程後，譯者一標初稿完成，系統就依客戶詞彙表掃出術語不一致、標出疑似漏譯與數字格式落差，產出待審清單推到審稿師的 Slack。審稿師不再從頭逐字掃，直接攻清單上的疑點，再把省下的時間放在語氣與在地化潤飾。三個月後，審稿師估算單件審稿時間少了一半，因術語不一致或漏譯被客戶退件的情況幾乎絕跡，連客戶都回饋「最近交來的稿子穩定很多」。

延伸應用

這條流程往後可直接接 /workflows 的翻譯社客戶經營流程，交付完成即啟動滿意度調查與回購追蹤，把品質與客戶經營串成一條線。也能把每次的檢核結果與退件原因累積成資料，分析「哪些譯者、哪類案件最常出現某種錯誤」，回頭做譯者培訓與派案優化。詞彙表本身也能半自動維護——把審稿師確認過的正確術語回寫進詞彙表，讓檢核越用越準。對需要嚴格留痕的客戶，還能在交付時自動產出一份品質檢核報告（檢了哪些項、發現幾處、如何處置），提升專業信任感。詞彙表與風格指南的維護、譯者品質追蹤的設計範例，可參考 /recipes。

流程圖

用到的工具

更多「專業服務」工作流

瀏覽全部工作流藍圖 → 自動化工作流中心 → AI Skills 食譜庫 →