源文本里出现一个错别字，真正该修的时机只有一次——就是在它扩散之前。异步任务会把同一份源载荷分发到每个目标语言区域，而每个语言区域都会翻译自己拿到的文本。所以，源文本里的拼写错误、漏词或病句，不会只停留在一个地方。它会变成德语里的一个问题、法语里的同一个问题，以及任务涉及的其他每个语言区域里的同一个问题——最后每个版本都得在事后各自修一遍。
本地化前 AI 预编辑（preEdit）就是在源头补上这个缺口。它是 异步本地化流水线 的第一阶段：在核心翻译步骤开始前，AI 智能体会先检查源载荷，修正错别字、语法错误和拼写问题。随后被翻译的，就是这份清理过的源文本——也就是说，你只需要在它分发出去之前修一次，而不是等到十几个输出结果里反复处理同一个错误。
这是 异步流水线 的一个阶段，因此只会在通过 Async Localization API 创建的任务中运行。同步的 /localize endpoint 只执行核心翻译步骤，不会理会流水线设置。
这个阶段会做什么#
preEdit 处理的是源文本，不是译文。AI 智能体会读取你的源载荷，改写其中内容以消除表层错误——比如错别字、语法问题和拼写错误——然后再把修正后的文本交给核心本地化步骤。每个目标语言区域都会基于这份清理过的源文本进行翻译。
它的范围被刻意控制得很窄，而这正是重点所在。这是一次文案清理，不是重写：它针对的是那些会让翻译模型对源文本产生歧义的表层噪声，让模型把注意力放在翻译上，而不是去猜一句残缺不清的话原本想表达什么。源文本越干净，各语言区域的翻译就越一致——因为所有语言区域都从同一份修正后的文本出发，而不是让每个模型各自去揣摩同一个错误。
如果你想要的是更地道、更像母语写作者写出来的输出——也就是重写译文本身，让它读起来像出自母语文案之手——那是另一个阶段。请参阅 为自然文案进行改写。preEdit 清理输入；rephrase 打磨输出。
它不会把任务变得更糟#
谨慎的工程师看到一个会在翻译前编辑内容的 AI 步骤时，首先会问一个非常正确的问题：如果这个步骤出错了，或者根本没跑，会发生什么？
preEdit 是一个非关键阶段。如果预编辑调用失败或超时，系统会原样传递原始源文本，任务继续进入翻译步骤，就像这个阶段从未开启一样。这里的失败，损失的只是这次清理——不是整个任务。翻译仍会照常交付。
如果预编辑失败或超时，会怎样？
任务不会失败。非关键阶段会回退到其输入：当 preEdit 失败时，未经编辑的源文本会按原样翻译，任务也会继续执行直到完成。任务状态会变为 completed_with_warnings，preEdit 步骤会被记录为 failed，原因则会写入任务的 warnings 数组——这样你既能看到问题确实发生过，又不会因此阻塞交付。关于如何读取这些步骤记录，请参阅 观察流水线运行情况。
所以，最坦率的说法是：启用 preEdit 不可能让一个原本会成功的任务变成失败。最坏的情况，也只是它在某个任务上没有帮上忙，然后安静地退到一边。
它不是什么#
有必要把这一点说清楚，尤其是在你最希望它更强大的时候：preEdit 是一种尽力而为的表层文案清理，不是懂你业务领域的校对员，也不是会核实你说法是否属实的事实核查器。它会修正错别字、语法和拼写问题；但不会验证价格是否正确、产品名称是否仍然是最新的，或一句话是否准确表达了你的本意。如果你的源文本在事实层面就是错的，preEdit 只会忠实地把这句错误的话在语法上清理干净，然后再干净地翻译到每个语言区域。
对于那些无论经过任何 AI 处理都必须保持原样的术语——例如产品名称、商标、代码标识符——请在源头把它们钉住。你可以在引擎的 glossary 中将其标记为不可翻译，或者针对特定载荷中的结构化字段，使用 lockedKeys 将其排除。这些是对数据本身的硬性保障；preEdit 则是在这些保障之外进行的尽力清理。
何时启用#
当你的源文本很可能带有噪声时，preEdit 值得多跑这一步；而当源文本本身已经很干净时，它就是多余的。
- 建议启用：当源内容来自用户生成、机器提取、网页抓取、OCR，或以其他方式产生于正式编辑流程之外时——这些场景里表层错误很常见，而且错误扩散到多个语言区域的代价也确实存在。
- 可以跳过：对于已经过编辑或人工审阅的内容。如果源文本已经足够干净，这个阶段就没有什么可修正的，你等于是在为一次无事可做的 AI 处理付费。每启用一个阶段，任务就会多跑一个步骤，成本里也会多一项——在源质量不确定时值得，在源质量明确可靠时就是浪费。
这就是全部权衡：在源质量不确定的任务上，先多花一次处理，在它分发出去之前修一次——而不是等到交付之后，再在每个语言区域里重复修正同一个错误。
你可以在引擎的 Pipeline 选项卡中开启或关闭 preEdit，让它应用到路由到该引擎的所有异步任务；也可以在 create-jobs 请求中通过 pipelineConfig 仅对单次提交覆盖它。这两层配置，以及当某个阶段被省略时如何继承引擎默认值，都在 配置流水线 中有说明。
