假設一家美國維修店把訂單通知交給 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 合成測試，沒有接入客戶系統或傳送通知。