我如何仅使用人工智能和微软工具实现13种语言的电子邮件工作流程自动化

跨多个地区本地化电子邮件活动曾经是一项缓慢、重复且需要许多手动步骤的任务。多个审核员在不同版本上工作，相同内容被重写多次，而且管理多达13种语言的一致性需要大量协调。

我没有引入新平台或外部工具，而是进行了一项内部实验：\n 是否可以仅使用标准企业Microsoft环境中已有的工具实现本地化自动化？

该原型主要依靠SharePoint、Power Automate和Teams，还有一个额外组件 - 通过Azure OpenAI访问的GPT-4.1 mini - 严格用于受控的质量检查步骤。这使流程能够受益于基于LLM的推理，同时将所有数据保留在同一企业环境中。

为支持此工作流程，我设置了一个名为电子邮件翻译的结构化SharePoint库，其中包含代表本地化生命周期每个阶段的文件夹：

| 文件夹 | 用途 | |----|----| | 01传入EN | 英文源文件；Power Automate触发器 | | 02AI草稿 | 来自Copilot + GPT的自动翻译草稿 | | 03审核中 | 等待区域审核的文件 | | 04已批准 | 最终批准的翻译 | | 99存档 | 已存档或被拒绝的版本 |

文件根据其状态在这些文件夹之间自动移动。

目标不是构建一个完美的本地化系统 - 只是看看使用内部工具能将原型推进到什么程度。

结果它消除了大部分重复性工作，并创建了一个更加结构化的审核流程。

问题：流程，而非语言

在多个地区手动本地化内容产生了几个一致的问题：

• 每个地区编辑自己的文件，因此同时存在多个不同版本。
• 当源文本更改时，并非所有地区都更新其版本，这导致内容不匹配。
• 文件保存在不同位置并使用不同名称，使识别当前版本变得困难。
• 审核需要时间，特别是当团队处于不同时区时。
• 在多个文件中重复相同的编辑增加了小错误的风险

尝试1：仅Copilot翻译

虽然Copilot现在运行在较新的GPT-5系列模型上，但此原型是基于早期版本构建的，翻译行为反映了那些早期功能。

工作流程的第一个版本很简单：

1. 文件上传到01传入EN。
2. Power Automate自动触发。
3. Copilot为每个地区生成翻译。

由于SharePoint触发器可能在文件完成上传前触发，流程包含了文件大小完成检查（等待大小 > 0后再继续）。

然而，主要问题很快变得明显：Copilot的翻译对于端到端本地化而言不够可靠。

常见问题包括：

• CTA翻译过于字面
• 不同语言之间的语气和风格各异
• 占位符被删除或更改
• 列表、间距和结构的格式差异

这使Copilot仅适用于生成初稿。\n 需要第二层质量检查。

尝试2：添加GPT-4.1 Mini进行质量检查

下一个版本添加了审核步骤：

1. Copilot → 初始翻译
2. GPT-4.1 mini (Azure) → 质量检查和一致性检查

GPT-4.1 mini改进了：

• 语气一致性
• 占位符保留
• 格式稳定性
• 与源意义的对齐

提示需要调整以避免不必要的重写，但经过调整后，输出变得足够一致，可用于工作流程。

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

架构很简单，但在实际使用中出现了几个问题，需要修复。

平台行为：

• SharePoint触发器并不总是立即启动，因此添加了检查和重试。
• 当频道重命名时Teams路由失败，因此必须更新映射。

设计问题：

• 一些并行步骤在首次运行时失败，因此引入了重试逻辑。
• JSON响应有时缺少预期字段，因此添加了验证。
• 文件名不一致，因此定义了单一命名格式。

经过这些调整后，工作流程在正常条件下可靠运行。

最终原型架构

以下是系统的完整工作结构。

1. SharePoint上传与接收

流程始于文件上传到电子邮件翻译 / 01传入EN

然后Power Automate：

• 检查文件是否完全上传（零字节保护）
• 检索元数据
• 提取文本
• 识别目标区域

SharePoint作为所有阶段的单一真实来源。

2. Power Automate编排

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

• 读取英文源文件
• 调用Copilot进行草稿翻译
• 将草稿发送给GPT-4.1 mini进行质量检查
• 为每个区域创建分支
• 将输出通过电子邮件发送给本地团队
• 发布Teams批准卡片
• 捕获"批准"或"请求更改"
• 将批准的文件保存在04_已批准
• 将更新的版本保存在03审核中
• 将旧版本存档在99_存档

所有路由、重试和状态转换均由Power Automate处理。

3. Copilot翻译通道

Copilot翻译提取的内容并保留了大部分电子邮件结构 - 列表、间距和格式 - 比单独使用GPT更好。

4. GPT-4.1 Mini质量检查通道

GPT-4.1 mini检查：

• 语气一致性
• 意义对齐
• 格式稳定性
• 占位符完整性

这为区域审核创建了更可靠的草稿。

5. 区域审核（电子邮件 + Teams）

对于每个区域，Power Automate：

• 通过电子邮件发送翻译文件
• 发布带有批准 / 请求更改的Teams自适应卡片

如果提交了更改，更新的文件返回到03审核中并重新进入工作流程。

6. 最终存储

已批准的翻译使用一致的命名格式存储在04_已批准中。

被拒绝或过时的版本被移至99_存档。这确保了完整且清晰的审计跟踪。

结果

在实际工作流程中测试原型后：

• 翻译时间从数天缩短至数分钟
• 版本冲突减少
• 手动重写最小化
• 审核周期更快
• 所有数据在Microsoft环境内处理

这并未取代专用本地化系统，但它消除了大量重复性手动工作。

局限性

• 某些语言仍需要风格调整
• Teams批准取决于审核者响应时间
• 流程需要针对暂时性错误的重试逻辑
• 长篇或复杂电子邮件的语气一致性各异

这些对于原型来说是可接受的。

下一步：术语记忆

计划的下一个改进是基于向量的术语库，包含：

• 词汇表
• 产品名称
• 受限术语
• 区域特定表述
• 同义词组
• 语气规则

两个模型在生成或检查翻译前都将使用此库。

最终思考

这个项目是一项内部实验，旨在了解使用仅标准Microsoft工具和一个Azure托管的LLM可以自动化多少本地化工作流程。该原型显著减少了手动工作并改善了跨区域的一致性，而无需添加新软件。

它不是一个完整的本地化平台 - 但它展示了在现有企业堆栈内使用简单、结构良好的工作流程可以实现什么。

\