配置 Pipeline
你可以分两层控制要运行哪些 Pipeline 阶段：一层是引擎默认配置，另一层是单次请求的可选覆盖。
你已经决定好要在核心翻译步骤前后加入哪些阶段。接下来要回答两个问题：这个决定应该配置在哪里？如果某个任务需要和其他任务不同，又该怎么处理？答案就是两层配置。引擎承载的是所有异步任务都会继承的默认值；单次提交中的 pipelineConfig 对象，则只会覆盖这一次提交的设置。覆盖中未写出的阶段会继续继承引擎配置，因此请求里只需要说明差异。
如果你刚接触 Pipeline，建议先阅读 Pipeline 概览，了解各阶段分别做什么。本页讲的是如何启用这些阶段，以及如何覆盖它们——不展开介绍它们启用后的具体行为。
仅适用于异步任务
Pipeline 配置只适用于通过 Async Localization API 创建的任务。同步的 /localize endpoint 只会运行核心翻译步骤，完全忽略两层中的所有 Pipeline 设置。
引擎级默认配置#
在控制台中打开该引擎的 Pipeline 标签页，然后分别切换各个阶段。这里的配置就是该引擎的默认值：所有路由到这个引擎的异步任务都会按这些阶段运行，除非某个请求显式覆盖。设置一次之后，你就不需要在每次调用时重复声明整套 Pipeline。
除 Localization 外，每个阶段都有独立开关，你一切换就会立即保存。你可以按需任意组合——全部关闭、全部开启，或介于两者之间的任意搭配。任务会按以下顺序运行这些阶段：
- 预编辑——在翻译前先清理源文。
- 本地化——核心翻译步骤。它标记为 始终开启，没有开关。
- 改写——重写内容，让表达更自然、更符合母语习惯。独立于其他阶段。
- 人工审核——将内容流转到内部或外部审核。该步骤的设置按钮会打开 提供方、超时时间 和 质量阈值。
- 后编辑——将人工修改与你的引擎规则进行协调。只有在 人工审核 开启后，它才能开启；关闭 人工审核 时，它也会随之关闭。
- 内容长度——让译文控制在宽度预算内，按显示列数而非字符数计算。该步骤的设置按钮会打开 预算：保持在固定上限内（配有 最大长度）、不超过原文长度，或 匹配原文长度（配有 允许差异，按百分比表示）。
- 回译——验证内容往返翻译后是否仍保留原意。独立于其他阶段。
未包含在你的套餐中的阶段会带有 Enterprise 标签，且无法开启。
默认配置会被每个任务继承，因此引擎配置就是 pipelineConfig 覆盖项要合并进去的基础结构。每个阶段对应一个键：
{
"preEdit": { "enabled": true },
"humanEdit": {
"enabled": true,
"provider": "internal",
"tier": "standard",
"timeoutHours": 48,
"qualityThreshold": 85
},
"postEdit": { "enabled": false },
"rephrase": { "enabled": false },
"contentLength": {
"enabled": true,
"mode": { "_tag": "fixedCap", "maxColumns": 40 }
},
"backTranslation": { "enabled": true }
}| 键 | 字段 | 在阶段页面中设置 |
|---|---|---|
preEdit | enabled | 翻译前 AI 编辑 |
rephrase | enabled | 润色为自然表达 |
humanEdit | enabled、provider（internal | external）、tier（可选；写入时仅接受 standard，旧版引擎仍可能读回 pro）、timeoutHours、qualityThreshold（可选，1–100 的整数） | 人工审核 |
postEdit | enabled | AI 审核 |
contentLength | enabled、mode：{ "_tag": "fixedCap", "maxColumns": n }、{ "_tag": "noLongerThanSource" } 或 { "_tag": "matchSource", "tolerancePct": n } | 此页面——没有单独的阶段页面 |
backTranslation | enabled | 回译检查 |
每个字段分别控制什么——使用哪个审核提供方、哪些译文会跳过审核、需要等待多久——都记录在该阶段自己的页面上。本页说明的是配置放在哪里，以及这两层如何叠加生效。
按请求覆盖#
大多数任务都应该直接使用引擎默认配置。例外是某次提交需要不同的 Pipeline：比如一批一次性的营销文案，希望启用引擎平时默认关闭的润色阶段；或者一份法务内容，反而应该跳过这一步。如果为了这一批任务去改引擎配置，就会连带影响其他所有任务。
所以，应该把差异直接写在请求里。在 pipelineConfig``POST /jobs/localization 请求体中添加一个 对象，它只会覆盖这一次提交的引擎默认配置。引擎本身不会被改动；下一个没有覆盖项的任务，仍然会回到默认配置。
{
"sourceLocale": "en",
"targetLocales": ["de", "fr"],
"data": { "headline": "Ship in every language." },
"pipelineConfig": {
"rephrase": { "enabled": true },
"backTranslation": { "enabled": false }
}
}这就是继承规则，也是让覆盖保持精简的关键：你点名的阶段会被覆盖；你省略的阶段会继承引擎默认值。 上面的请求会为这个任务开启 rephrase，并关闭 backTranslation。preEdit、humanEdit、postEdit 和 contentLength 没有被点名，因此它们会完全按照引擎中的配置运行。你只需声明不同之处。
写入某个阶段，就要提供该阶段的完整配置
覆盖是按阶段生效的，不是按字段生效的。你包含的每个阶段都必须是该阶段的完整对象——你不能发送 humanEdit: { "timeoutHours": 24 }，只改超时时间，同时继承其余设置。想覆盖，就传入整个阶段；想继承引擎默认值，就省略它。单个阶段对象内部不支持部分合并。
还有两点需要说清楚，因为这部分最容易让人误以为“什么都能改”：
- 它只影响这一次提交。它不会回写到引擎，所以不能用来做长期配置调整——真正的持久化修改应当在 Pipeline 标签页里完成。一次性需求用覆盖；新的常态配置用标签页。
- 它不会放宽阶段本身的运行规则。后编辑 只有在人工审核产出结果时才会运行，因此如果某个任务没有可供协调的人工审核阶段，启用
postEdit也不会产生任何效果——无论你是在哪一层启用它。
确认实际运行了哪些阶段#
配置决定的是哪些阶段应该运行；而任务本身的记录，才会告诉你哪些阶段真正运行了。任务会携带一个 steps[] 数组，你应该通过这个数组来确认按请求覆盖是否确实生效——而不只是确认你把它发出去了。
至于如何读取这些记录——比如每个阶段的 stepId、skipped 步骤代表什么、以及非关键失败会显示在哪里——这些内容会在单独的页面中说明。
后续步骤#
现在你已经可以在引擎上设置默认值，也可以在请求中按需覆盖。接下来，你可以提交一个带覆盖项的任务，或者回读步骤记录，确认到底运行了哪些阶段。