改写成更自然的文案

翻译本身很准确，术语表也没问题，但读起来还是像“翻译出来的”。润色就是用来补上这最后一步的流水线阶段：由 AI 代理改写当前输出，让它在目标语言里读起来更像原生文案，同时保留原意、占位符和标签。

本页单独介绍 rephrase 这个阶段——它会改写什么、不会动什么、失败时会发生什么，以及它摆在你面前的唯一选择：启用，还是跳过。第一次接触这条流水线？先看 异步本地化流水线概览，了解各个阶段如何衔接。润色仅适用于异步流程——它只会运行在通过 异步本地化 API 创建的任务中，不会用于同步的 /localize 调用。

它能做什么#

直译常常会把源语言的表达方式一并带进目标语言——语法没错，但一看就是翻译。润色阶段会改写当前的最佳输出，让它读起来更像目标语言里的原生文案：自然、地道，优先采用惯用表达，而不是逐词对应。它会保留原始含义和意图，并应用你在引擎中配置的 glossary、品牌语气 和 说明——也就是说，生成翻译时使用的同一套配置，也会约束这次改写。

它会在 AI 和人工润色步骤之后运行，处理的是到达这一阶段时的输出。因此，无论是否启用了 人工审核 和 AI 后编辑，它的工作方式都一样——都会改写当前的最佳版本。若同时启用了 回译检查，校验的也是润色后的输出，而不是润色前的版本。

直译让你更贴近源文措辞；润色则让文案更接近母语写作者会采用的表达。因此，两者并不能互相替代——该选哪一个，就是你接下来要做的决定。

占位符和标签都会原样保留#

对于一个职责就是改写文本的阶段，最容易让人担心的是：它会不会动到那些并非正文的部分？不会。润色会将占位符、变量、标签和格式完整保留下来——它改写的是它们周围的文字，而不是应用运行所依赖的那些标记。

所以，像下面这样的字符串会保留所有插值和标签，变化的只有人能读懂的文案本身：

Source (en):        "Hi {firstName}, you have <b>{count}</b> new messages."
Translated (de):    "Hallo {firstName}, du hast <b>{count}</b> neue Nachrichten."
After rephrase (de):"Hey {firstName}, <b>{count}</b> neue Nachrichten warten auf dich."

{firstName}、{count} 和 <b> 这些标签在三个版本中完全一致。德语文案读起来更自然，而运行时依赖的结构完全不变。

它会失败，但任务不会#

润色是一个非关键阶段。AI 改写可能失败，也可能超时——但即便如此，你已经付费得到的翻译也不会丢失。系统会原样沿用上一步输出并继续执行任务。换句话说，你不会为了追求文风更自然，而拿一份准确翻译去冒险。

润色失败并不会导致任务失败。它会以带有 status: failed 的步骤记录呈现，任务最终状态仍为 completed_with_warnings，而写入 outputData 的则是润色前的翻译：

{
  "id": "ljb_C3d4E5f6G7h8I9j0",
  "status": "completed_with_warnings",
  "outputData": {
    "greeting": "Hallo {firstName}, du hast <b>{count}</b> neue Nachrichten."
  },
  "warnings": [
    { "step": "rephrase", "message": "<the failure reason for this step>" }
  ],
  "steps": [
    { "stepId": "localize", "type": "action", "status": "completed" },
    { "stepId": "rephrase", "type": "action", "status": "failed" }
  ]
}

最终交付的是 de 翻译。这里的 message 具体文本仅作示意——固定不变的是它的结构：一条带有 step 和 message 的 warnings[] 记录，rephrase 步骤被记为 failed，且润色前的输出保存在 outputData 中。查看 step 字段，就能确认本次运行中文案并未完成润色；如果自然表达对该语言区域很重要，你就可以重新运行该语言区域。关于完整的 steps[] 与 warnings 结构，以及非关键失败如何汇总为 completed_with_warnings，请参见 观察流水线运行。

何时启用，何时跳过#

润色只优化一件事：让内容读起来像母语原创。对有些内容来说，这正合适；但对另一些内容来说，则完全不对。所以这应该按内容逐项决定，而不是设成全局默认。

适合启用的内容包括 营销文案、落地页、产品描述和引导流程——凡是“读起来像母语文案”比“紧贴源文措辞”更重要的地方，都适合启用。

应当跳过的内容包括 技术和法律内容，这类内容的首要目标是字面准确。润色会为了自然流畅而改写措辞；但在合同条款、API 参考文档或合规文案中，更接近源文的措辞往往更稳妥。对于这类内容，请关闭润色，直接采用 核心本地化 步骤的输出。

如何开启#

润色的配置方式与其他阶段相同——既可以设置引擎级默认值，也可以按请求单独覆盖——因此完整机制请参见 配置流水线。简而言之：你可以在引擎的 Pipeline 选项卡中切换它，让它应用到每个任务；也可以通过 pipelineConfig 仅为单次提交设置它：

{
  "sourceLocale": "en",
  "targetLocales": ["de", "fr"],
  "data": { "headline": "Ship global products faster." },
  "pipelineConfig": {
    "rephrase": { "enabled": true }
  }
}

你省略的阶段会继承引擎配置——因此，上面的覆盖只会为这次提交开启润色，而不会影响其他任何阶段。这样一来，你就可以在引擎层面对强调字面准确的内容默认关闭润色，同时按请求为营销类内容单独开启它。

下一步#