TL;DR： loop engineering 系列第二篇。上一篇講完官方的委派階梯結構，這篇用我自己做的翻譯品質系統 TQEF 當例子，說明兩種東西不同的壽命：harness，也就是讓事情跑起來的機制，會不斷被替換；criteria，也就是判斷成果是否合格的標準，則能在一次次重建中累積下來。文章裡有幾個真的踩過的坑，也誠實交代這套系統還有哪些部分沒做完。

上一篇文章的最後一句話留了一筆債：「我自己這幾個月怎麼一輪一輪撞出同樣的結構、踩過哪些坑，留到下一篇細談。」這篇來還。

先講結論，再講我是怎麼撞出來的。

在一套持續運作的 AI 系統裡，有些東西很快就會過期，例如 prompt、工具、資料庫和排程。這些讓系統跑起來的機制，我把它統稱為 harness。一次意外、一次升級，甚至一次架構調整，都可能讓它必須重做。

但判斷輸出好不好的標準不一樣。我把這一層稱為 criteria。只要定義得夠具體，它就能撐過一次次重建，還會隨著每次出錯，變得更完整。

我做的系統長什麼樣子

TQEF 是我做的一套翻譯品質評分框架，全名 Translation Quality Evaluation Framework，服務對象是阿哥拉廣場，我自己開發的即時會議翻譯工具。

這套系統由四層迴圈組成。

最裡面的一層負責翻譯：模型接收四路語音辨識結果，逐段產生譯文。第二層負責檢查：TQEF 依照五個維度評分，沒有過關，就把問題交回去重新翻譯。第三層以每場會議為單位運作，會議結束後，譯文會進入語料庫，成為後續改善的材料。最外層則定期檢查多輪結果，找出反覆出現的問題，再回頭調整 prompt 和辭典。

阿哥拉的四層迴圈堆疊：代理迴圈、驗證迴圈、事件驅動迴圈、爬山迴圈，套在一起運作

TQEF 用五個維度評分。

第一是術語準確度，權重最高。因為「半導體」如果被翻成別的東西，其他句子再流暢也沒有意義。第二是忠實度，檢查譯文有沒有偏離原意。第三是關鍵資訊保留，確認數字和專有名詞有沒有遺漏或錯譯。第四是自然度，也就是譯文讀起來像不像人話。最後是嚴重錯誤，只要出現一次，就直接判定不合格。

這五個維度是 criteria 這層。前面提到的翻譯、檢查、事件觸發這三層具體運作，都是 harness 這層。接下來的坑，全部發生在 harness 這層。

harness 怎麼過期的：三個實際踩過的坑

第一個坑最戲劇化。有一次我在協作 session 裡用 osascript 寫檔案，引號嵌套出了錯，226 行的核心評估腳本 eval_runner.py 被截斷成只剩一行，#!/usr/bin/env python3，整支腳本毀了。這不只是「重寫就好」的小事，更像一個系統性的警告：當同一個工作階段同時負責策略、寫程式和部署，任何一步出錯，都可能一路影響到後面的工作。那次之後我把整個協作流程拆成三軌：一軌只負責偵察跟策略，不碰程式碼；一軌負責批量檔案操作；一軌負責精準的單檔修改跟部署。三軌不能同時修改同一個檔案；每個階段結束前，也必須確認變更已經保存、提交，並留下可以回復的版本。這個分工是那次事故逼出來的，不是我事先設計好的，事後看是整段開發歷程裡報酬率最高的一個決定，因為後面再也沒有發生過類似的版本混亂。

第二個坑比較安靜。系統擴充時，我依照文件猜測資料庫欄位的名稱，實際查詢後才發現，資料結構和文件寫的不一樣。類似情況發生過兩次，幸好都在前期檢查時被攔下，沒有造成實際損害。從此我多了一條硬規矩：資料庫欄位一律以實際查詢結果為準，不能依靠文件或記憶猜測。

第三個坑是評分紀錄重複入庫。同一輪、同一句話的評分結果，被寫進資料庫兩次，原因是當初沒有設定唯一性約束。修法很直接：補上約束，再清掉重複資料。

還有一個反覆出現、比較不戲劇化但更常見的模式：程式碼寫好了，但沒接通。功能看起來寫完了，但 import 沒加、路由沒接、部署沒跑，或前端根本沒有渲染。各個零件可能都在，整條流程卻從來沒有真正走通。這個教訓養成了一個習慣：任何改動完成後，一定要做一次完整的端到端驗證，從頭走一遍，確認東西真的活著，而不是相信「應該有動」。

criteria 怎麼複利的：一次可以說清楚原因的提升

跟前面那幾個坑對照最鮮明的一輪，發生在辭典上線那天。基線評分是 4.69（滿分 5），還有一個嚴重錯誤。那一輪我把三個產業辭典和一套商業用語規則同時上線，一次補齊半導體、循環經濟、再生醫學與常用商業詞彙的翻譯校正。下一輪結果：整體評分跳到 4.97，嚴重錯誤歸零。

這次提升可以清楚追溯到辭典上線。分數提高能對應到一項具體的工程改動，不只是主觀感覺。這正是 criteria 這層的價值：即使 harness 一再重建，它仍讓前後幾輪的結果可以用同一套標準比較。不管底層腳本是不是被 osascript 炸過、資料庫欄位名是不是查對過、有沒有重複入庫的 bug，五個評分維度雖然持續補充細節，但從第一輪到現在，核心判斷邏輯都沒有改變。每一次工程改動的效果，都可以疊加在同一把尺上比較。這把尺沒有被任何一次 harness 重建打掉重練，這就是複利的意思。

後續幾輪分數在 4.78 到 4.90 之間浮動，這種波動是正常的，29 句語料的樣本量不大，評分模型本身也有隨機性。但整體趨勢仍然向上，也可以回頭比對每一輪做過哪些工程改動，以及它們可能帶來的影響。這件事跟上一篇提過的原則呼應：迴圈可以幫你把生成跟評估拆開，但「怎樣算一句翻譯過關」這件事，永遠得是你自己先講清楚，講到能拿去打分。

誠實講還沒做完的部分

TQEF 目前完成的是 Phase 1：單一評分引擎、29 句測試語料、跑過七輪評估。Phase 2 設計了五個自動收集語料的通道，目前只完成兩個，其餘還在規劃。我另外規劃了一個 Stage B，專門驗證評分器本身是否可靠。除了調整評分 prompt，還要用另一套指標交叉比對、請真人專家評分校準，並重複測試同一批資料，確認結果是否穩定。這個階段到現在都還沒真正推進，卡在其他優先順序後面，是誠實留著的一個坑，不是隨口說說。

這部分不能省略。既然我主張 criteria 比 harness 更持久、更值得投資，就也必須說清楚：criteria 也不是寫完一次就能定案。它仍然需要交叉比對、真人校準和穩定性測試。不同的是，這些工作通常是在修正同一把尺，而不是每次都換掉整套判斷方式。這個驗證我自己都還沒做完。

這兩篇合起來想說的事

上一篇講完 loop engineering 的官方結構之後，留了一句話：Loop engineering 可以自動化「流程怎麼跑」，卻不能替你決定「怎樣才算跑對」。這一篇用自己踩過的坑，把這句話落到實處。harness 這一層，我炸過、修過、重建過，三軌分工是被那次事故逼出來的。criteria 這一層，從第一天定義清楚之後，撐過了每一次重建，還隨著每一次踩坑補得更完整。

如果你手上沒有 TQEF 這種現成系統，這個對比一樣用得上。任何持續運作的 AI 系統，讓它跑起來的機制遲早會被打掉重練，這幾乎是必然。真正值得先花力氣想清楚的，是「怎樣才算做完」。把標準寫得夠具體，具體到不同的人或模型，都能拿它判斷成果是否過關。這件事很難完全外包給模型。但只要把標準建立起來，它通常會比任何一版 prompt、工具或工作流程都活得更久。

參考資料

同系列前一篇

TQEF 相關素材

  • 本文所有評分數據、事故紀錄、開發時程均為 Paul 自建系統的第一手紀錄，非第三方報告轉述