Yalnızca Yapay Zeka ve Microsoft Araçlarını Kullanarak 13 Dilli E-posta İş Akışını Nasıl Otomatikleştirdim

跨多個地區本地化電子郵件活動曾經是一項緩慢、重複且需要許多手動步驟的任務。多位審核人員在不同版本上工作，相同內容被重寫多次，而且管理多達13種語言的一致性需要大量協調。

我沒有引入新平台或外部工具，而是進行了一項內部實驗：\n 是否可以僅使用標準企業Microsoft環境中已有的工具來實現本地化自動化？

該原型主要依賴SharePoint、Power Automate和Teams，還有一個額外組件 - 通過Azure OpenAI訪問的GPT-4.1 mini - 嚴格用於受控的QA步驟。這使流程能夠受益於基於LLM的推理，同時將所有數據保留在相同的企業環境中。

為支持此工作流程，我設置了一個名為Email translations的結構化SharePoint庫，其中包含代表本地化生命週期各階段的文件夾：

| 文件夾 | 用途 | |----|----| | 01IncomingEN | 英文源文件；Power Automate觸發器 | | 02AIDrafts | 來自Copilot + GPT的自動翻譯草稿 | | 03InReview | 等待區域審核的文件 | | 04Approved | 最終批准的翻譯 | | 99Archive | 已歸檔或被拒絕的版本 |

文件根據其狀態在這些文件夾之間自動移動。

目標不是建立一個完美的本地化系統 - 只是看看使用內部工具能將原型推進到什麼程度。

結果它消除了大量重複工作，並創建了一個更加結構化的審核流程。

問題：流程，而非語言

在許多地區手動本地化內容會產生幾個一致的問題：

• 每個地區編輯自己的文件，因此同時存在多個不同版本。
• 當源文本更改時，並非所有地區都更新其版本，這導致內容不匹配。
• 文件保存在不同位置並使用不同名稱，難以識別哪個版本是當前版本。
• 審核需要時間，特別是當團隊處於不同時區時。
• 在多個文件中重複相同的編輯增加了小錯誤的風險

嘗試1：僅使用Copilot翻譯

雖然Copilot現在運行在較新的GPT-5系列模型上，但此原型是基於早期版本構建的，翻譯行為反映了那些早期功能。

工作流程的第一個版本很簡單：

1. 文件上傳到01IncomingEN。
2. Power Automate自動觸發。
3. Copilot為每個地區生成翻譯。

由於SharePoint觸發器可能在文件完成上傳前觸發，流程包含了文件大小完成檢查（等待大小 > 0後再繼續）。

然而，主要問題很快變得明顯：Copilot的翻譯對於端到端本地化來說不夠可靠。

常見問題包括：

• CTA翻譯過於字面
• 不同語言間的語調和風格差異
• 佔位符被移除或更改
• 列表、間距和結構的格式差異

這使Copilot僅適用於生成初稿。\n 需要第二層質量檢查。

嘗試2：添加GPT-4.1 Mini進行QA

下一個版本添加了審核步驟：

1. Copilot → 初始翻譯
2. GPT-4.1 mini (Azure) → QA和一致性檢查

GPT-4.1 mini改進了：

• 語調一致性
• 佔位符保留
• 格式穩定性
• 與源意義的對齊

提示需要調整以避免不必要的重寫，但經過調整後，輸出變得足夠一致，可用於工作流程。

工程工作：使工作流程可靠

架構很簡單，但在實際使用中出現了幾個問題需要修復。

平台行為：

• SharePoint觸發器並不總是立即啟動，因此添加了檢查和重試。
• 當頻道重命名時Teams路由失敗，因此必須更新映射。

設計問題：

• 一些並行步驟在首次運行時失敗，因此引入了重試邏輯。
• JSON響應有時缺少預期字段，因此添加了驗證。
• 文件名不一致，因此定義了單一命名格式。

經過這些調整後，工作流程在正常條件下可靠運行。

最終原型架構

以下是系統的完整工作結構。

1. SharePoint上傳與接收

當文件上傳到Email translations / 01IncomingEN時，流程開始

然後Power Automate：

• 檢查文件是否完全上傳（零字節保護）
• 檢索元數據
• 提取文本
• 識別目標區域

SharePoint作為所有階段的單一真實來源。

2. Power Automate編排

Power Automate控制工作流程的每個部分：

• 讀取英文源文件
• 調用Copilot進行草稿翻譯
• 將草稿發送給GPT-4.1 mini進行QA
• 為每個區域創建分支
• 將輸出通過電子郵件發送給本地團隊
• 發布Teams批准卡片
• 捕獲"批准"或"請求更改"
• 將批准的文件保存在04_Approved中
• 將更新的版本保存在03InReview中
• 將舊版本歸檔到99_Archive中

所有路由、重試和狀態轉換都由Power Automate處理。

3. Copilot翻譯通道

Copilot翻譯提取的內容並保留了大部分電子郵件結構 - 列表、間距和格式 - 比單獨使用GPT更好。

4. GPT-4.1 Mini QA通道

GPT-4.1 mini檢查：

• 語調一致性
• 意義對齊
• 格式穩定性
• 佔位符完整性

這為區域審核創建了更可靠的草稿。

5. 區域審核（電子郵件 + Teams）

對於每個區域，Power Automate：

• 通過電子郵件發送翻譯文件
• 發布帶有批准 / 請求更改的Teams自適應卡片

如果提交了更改，更新的文件返回到03InReview並重新進入工作流程。

6. 最終存儲

批准的翻譯使用一致的命名格式存儲在04_Approved中。

被拒絕或過時的版本被移至99_Archive。這確保了完整且清晰的審計跟踪。

結果

在實際工作流程中測試原型後：

• 翻譯時間從數天縮短到數分鐘
• 版本衝突減少
• 最少的手動重寫
• 更快的審核週期
• 所有數據在Microsoft環境內處理

這並未取代專用本地化系統，但它消除了大量重複的手動工作。

局限性

• 某些語言仍需要風格調整
• Teams批准取決於審核者的響應時間
• 流程需要針對暫時性錯誤的重試邏輯
• 長篇或複雜電子郵件的語調一致性有所不同

這些對於原型來說是可接受的。

下一步：術語記憶庫

計劃的下一個改進是基於向量的術語庫，包含：

• 詞彙表
• 產品名稱
• 受限術語
• 區域特定表述
• 同義詞組
• 語調規則

兩個模型在生成或檢查翻譯前都會使用此庫。

最終思考

這個項目是一個內部實驗，旨在了解使用僅標準Microsoft工具和一個Azure託管的LLM可以自動化多少本地化工作流程。該原型顯著減少了手動工作並改善了跨區域的一致性，而無需添加新軟件。

它不是一個完整的本地化平台 - 但它展示了在現有企業堆棧內使用簡單、結構良好的工作流程可以實現什麼。

\