配置 Pipeline

你可以分两层控制要运行哪些 Pipeline 阶段：一层是引擎默认配置，另一层是单次请求的可选覆盖。

你已经决定好要在核心翻译步骤前后加入哪些阶段。接下来要回答两个问题：这个决定应该配置在哪里？如果某个任务需要和其他任务不同，又该怎么处理？答案就是两层配置。引擎承载的是所有异步任务都会继承的默认值；单次提交中的 pipelineConfig 对象，则只会覆盖这一次提交的设置。覆盖中未写出的阶段会继续继承引擎配置，因此请求里只需要说明差异。

如果你刚接触 Pipeline，建议先阅读 Pipeline 概览，了解各阶段分别做什么。本页讲的是如何启用这些阶段，以及如何覆盖它们——不展开介绍它们启用后的具体行为。

引擎级默认配置#

在控制台中打开该引擎的 Pipeline 标签页，然后分别切换各个阶段。这里的配置就是该引擎的默认值：所有路由到这个引擎的异步任务都会按这些阶段运行，除非某个请求显式覆盖。设置一次之后，你就不需要在每次调用时重复声明整套 Pipeline。

每个阶段都有独立开关。你可以自由组合——全部关闭、全部开启，或介于两者之间的任意搭配：

• 翻译前 AI 编辑——在翻译前先清理源文本。
• 翻译后人工审核——将内容路由到 Internal 或 External 审核。你可以在同一面板中选择模式、层级和超时时间。
• 翻译后 AI 审核——在启用人工审核之前会一直保持关闭；它会根据你的引擎规则，协调人工修改后的结果。
• 润色为自然表达——重写文案，让表达更自然、更像母语写作。它独立于其他阶段。
• 回译检查——验证内容在往返翻译后是否仍保留原意。它独立于其他阶段。

核心本地化 不是可选开关——它始终都会运行。其他阶段都是围绕它展开的。

默认配置会被每个任务继承，因此引擎配置就是 pipelineConfig 覆盖项要合并进去的基础结构。每个阶段对应一个键：

{
  "preEdit": { "enabled": true },
  "humanEdit": {
    "enabled": true,
    "provider": "internal",
    "tier": "standard",
    "timeoutHours": 48
  },
  "postEdit": { "enabled": false },
  "rephrase": { "enabled": false },
  "backTranslation": { "enabled": true }
}

至于每个字段具体控制什么——比如使用哪个审核服务商、哪个层级、等待多久——会在对应阶段自己的页面中说明。本页关注的是配置放在哪里，以及这两层如何组合生效。

按请求覆盖#

大多数任务都应该直接使用引擎默认配置。例外是某次提交需要不同的 Pipeline：比如一批一次性的营销文案，希望启用引擎平时默认关闭的润色阶段；或者一份法务内容，反而应该跳过这一步。如果为了这一批任务去改引擎配置，就会连带影响其他所有任务。

所以，应该把差异直接写在请求里。在 POST /jobs/localization 请求体中添加一个 pipelineConfig 对象，它只会覆盖这一次提交的引擎默认配置。引擎本身不会被改动；下一个没有覆盖项的任务，仍然会回到默认配置。

{
  "sourceLocale": "en",
  "targetLocales": ["de", "fr"],
  "data": { "headline": "Ship in every language." },
  "pipelineConfig": {
    "rephrase": { "enabled": true },
    "backTranslation": { "enabled": false }
  }
}

这就是继承规则，也是覆盖配置能够保持精简的关键：写出来的阶段会被覆盖；省略的阶段会继承引擎默认配置。 上面的请求只会为这一个任务开启 rephrase，并关闭 backTranslation。preEdit、humanEdit 和 postEdit 没有出现在请求中，因此它们会完全按照引擎上的配置运行。你只需要声明不同的部分。

还有两点需要说清楚，因为这部分最容易让人误以为“什么都能改”：

• 它只影响这一次提交。它不会回写到引擎，所以不能用来做长期配置调整——真正的持久化修改应当在 Pipeline 标签页里完成。一次性需求用覆盖；新的常态配置用标签页。
• 它不会放宽某个阶段自身的运行规则。翻译后 AI 审核 只有在人工审核产生输出时才会运行，因此如果某个任务根本没有人工审核阶段可供协调，那么启用 postEdit 也不会产生效果——无论你是在哪一层启用它。

确认实际运行了哪些阶段#

配置决定的是哪些阶段应该运行；而任务本身的记录，才会告诉你哪些阶段真正运行了。任务会携带一个 steps[] 数组，你应该通过这个数组来确认按请求覆盖是否确实生效——而不只是确认你把它发出去了。

至于如何读取这些记录——比如每个阶段的 stepId、skipped 步骤代表什么、以及非关键失败会显示在哪里——这些内容会在单独的页面中说明。

后续步骤#

现在你已经可以在引擎上设置默认值，也可以在请求中按需覆盖。接下来，你可以提交一个带覆盖项的任务，或者回读步骤记录，确认到底运行了哪些阶段。