假設一間美國維修店，將訂單通知交畀 AI 翻譯。原句係「Order {order_id} is ready.」，譯稿變成「訂單 {订单号} 已準備好。」中文好順，但可能填唔到系統提供嘅 order_id。呢度嘅括號唔係畀顧客睇嘅文字，而係程式同文案之間嘅介面。本文用虛構通知做一次編輯演練。

喺本文採用嘅 Python str.format 語法入面，花括號包住替換欄位，名稱一定要同傳入資料相符。 我哋用合成編號 A-104 做咗本地測試：保留 {order_id} 嘅譯稿，正確填入編號；改成 {订单号} 就出現 KeyError。唔可以將呢個結果推廣成所有範本引擎嘅行為，但已經足以說明，讀起嚟順唔順，唔係程式驗收。

另一份譯稿淨係寫「訂單已準備好」。佢冇語法錯誤，但漏咗顧客分辨訂單需要嘅編號。本地測試確認，佢仍然可以產生文字，所以淨係檢查程式有冇回報錯誤係唔夠嘅。呢類簡單通知，要先列出一定要保留嘅欄位，再對照解析結果同實際輸出。欄位存在，都唔保證放喺正確位置，仍然要由人手檢查意思。

保留欄位名，唔等於要求譯文照搬英文語序。ICU 文件建議，將訊息當成完整單元翻譯，等變數位置可以按目標語言調整；佢嘅 MessageFormat 亦支援按語言規則揀複數分支。 畀 AI 完整句子、欄位意思同示例值，比逐段翻譯碎片更有用。Python 同 ICU 嘅語法唔可以混用，驗收一定要用產品實際採用嘅解析器。

將「訂單 {order_id} 已準備好。」連同示例資料交畀審核人，輸出應該包括 A-104，意思仍然係訂單已經準備好。之後再測試冇提供資料、較長編號，同產品支援嘅語言分支。我哋建議，將欄位規格約定檢查同語言審核分開記錄；任何一項失敗，都保留草稿。本文只執行咗簡單嘅 Python 合成測試，冇接入客戶系統，亦冇傳送通知。