人工审核
你的大多数内容在引擎返回结果后就能立即上线。但有些不行。比如受监管的信息披露、医疗说明、承载品牌表达的标题——这类内容，你会希望先由人工通读译文并签字确认，再正式发布，而不是等客户投诉后再来补救。
要把人工审核接入自动化流程，常见做法往往都很折腾：要么一直挂着请求等人来审，要么自己搭建审核队列，要么手动对接翻译供应商的 API。而这个阶段把这些都直接放进任务内部。启用 humanEdit 后，异步任务会先跑完引擎，然后暂停等待人工审核——可以是你的团队，也可以是外部专业人员——待对方提交修改后再继续，并将该结果传递给后续所有阶段。
它会在 本地化流水线 中于 Rephrase 之后、Post-edit 之前运行，并且和其他每个阶段一样，仅适用于通过 Async Localization API 创建的任务。刚接触这条流水线？先从 概览 看起。
本页内容
暂停机制如何运作#
在核心翻译步骤之后——如果启用了 Rephrase，也会在该阶段之后——任务会将 AI 翻译交给人工审核。审核者会先阅读译文，然后选择原样通过，或提交修改后的版本。只有这样，任务才会继续。人工产出——无论是原样通过还是修改后提交——都会成为后续每个阶段的输入，并最终成为任务的 outputData。
一提到让任务暂停几分钟、几小时甚至一整天，最直观的顾虑就是成本：如果请求一直挂着，那在什么都没发生时也会持续占用资源。但这个阶段不是这么工作的。
等待是事件驱动的，不是一直挂着连接
工作流会在事件发生时恢复——例如审核者在控制台中提交结果（内部审核），或翻译服务商发回回调（外部审核）。它不会高频轮询，也不会一直保持连接打开，因此即使超时时间设得很长，后台也不会消耗计算资源。任务可以像等待模型结果一样等待人工 48 小时：它只是被挂起，不是在空转。
每种语言和每个目录的审核负责人都可分别设置：引擎的人工审核设置会将各项分配到一个决策池，由您自己的团队或外部服务商负责。两种方式的暂停、恢复和沿用机制完全相同，未被任何决策池覆盖的翻译则直接交付，无需审核。
内部审核#
你的团队可以直接在 Lingo.dev 控制台中审核翻译。待审核内容会以 人工审核 项的形式显示在队列（/orgs/<org-id>/queue）中，并在有新项目到达时通知审核者。审核者打开项目后，可编辑任何需要修改的键，然后点击 原样通过；如果做了修改，则点击 修改后通过——按钮还会显示修改数量，例如 修改后通过（2 处修改）。随后，任务会基于他们的产出继续执行。
审核无需认领，也不会锁定。审核分配到哪个决策池，就决定了谁会收到相关邮件通知；任何拥有审核翻译权限的人都可以查看所有待处理的审核并作出决定。
Internal Review 仅在 Enterprise 方案中提供。若当前方案包含此功能，新引擎会从 Internal Review 开始；若不包含，则会从 External Review 开始，同时 Internal Review 选项会带有 Enterprise 标签。当你的团队内部具备语言专业能力，并且你希望完全掌控最终措辞、不让第三方介入时，就适合使用它。
权限#
内部审核并不会向组织中的所有人开放——审核队列受权限管控，因此审核中的翻译仅对您授权访问的人员可见。组织管理员可通过角色（Settings → Roles）分配访问权限：
| 权限 | 解锁的能力 |
|---|---|
审核翻译 (engine:review_translations) | 在队列中查看 人工审核 项、编辑内容，并选择原样通过或修改后通过 |
管理审核 (org:manage_reviews) | 查看内部审核的历史记录和统计数据。没有这项权限，已处理的审核仍会隐藏在队列中 |
这两项权限是刻意分开的。审核者只需要 审核翻译——这一项授权就足以完成全部工作：编辑、原样通过、修改后通过。管理审核 则面向负责统筹整个流程的人；它会提供整个组织范围内的审核历史，但本身并不包含队列访问权限。对于既要审核又要汇报的负责人，请同时授予这两项权限；对于只处理队列的人，只授予第一项即可。
外部审核#
如果某个语言区域没有内部评估器，可以将其分配到外部决策池，使用 Lingo.dev 的账户或您自己的服务商账户（例如 BLEND），由具备资质的专业译员审核翻译。任务的暂停方式不变，服务商返回修改后的翻译时，任务便会恢复。您的代码无需任何更改，区别只在于谁来审核字符串，任务的运行方式不变。
无需选择等级，服务市场会自行评定译员等级。外部审核按词数计费：使用 Lingo.dev 的账户时，费用通过您的 Lingo.dev 套餐结算；使用您自己的账户时，由服务商计费。
外部审核同样会显示在队列中；打开后，会显示其审核者为 合格译者。拥有 审核翻译 权限的人可以打开并接管它：选择 原样通过 或 修改后通过，任务就会在这里完成，而不再继续等待译者。接管此审核 的确认提示会在你确认前说明费用——只有在尚未有译者开始处理时，接管才是免费的；一旦已有译者开始处理，无论你是否采用他们的成果，译者费用都会照常产生。
有一点需要说清楚：External Review 的另一端是真实的人类译者，这也意味着相应的交付周期和成本。它不是一个更快的模型。把它用在真正需要人工判断的场景——受监管文本、高风险文案——而对于绝大多数不需要这一步的内容，则应更多依赖纯 AI 路径。
质量阈值#
并非每条翻译都需要人工参与。在人工审核设置中设定 质量阈值（1–100）后，AI 评估器会在进入审核前先为每条翻译打分。达到或超过阈值时，翻译会跳过人工直接发送，并且 humanEdit 步骤会记录为 skipped；低于阈值时，则会像往常一样进入审核。将该字段留空即可审核全部内容。在配置中，它写作 qualityThreshold，位于 humanEdit 下。
以这种方式直接发送的翻译没有人工产出，因此 Post-edit 不会在这类翻译上运行。
超时#
人工阶段会引入 AI 阶段没有的风险：人可能始终不响应。审核者在休假，服务商积压严重，或者项目被遗忘。如果不设上限，任务就可能永远等下去。
因此，等待时间是有上限的。你可以在人工审核设置中设定工作流等待人工产出的时长——超时，单位为小时；在配置中对应 timeoutHours。它适用于两种审核模式。如果超时时间到了仍未收到回应，该阶段会被标记为 skipped，并且 任务会继续以 AI 翻译作为最终输出。默认值为 48 小时。在队列中，超时的审核会显示为 未作决定即关闭。
这其中的代价也要讲明白：一旦超时，你上线的就是未经人工审核的 AI 翻译。对大多数内容来说，这是合理的回退方案——翻译顺利发布，总比任务无限期卡住更好——但这确实是一种取舍。对于无论如何都必须人工签字确认的内容，应设置较宽裕的超时，并在被跳过时发出告警；而对于审核只是加分项的内容，较短的超时能让流水线持续向前。
超时针对的是阶段，不是整个任务
超时只控制此阶段等待人工多久，与任务其余部分耗时多久无关。由于等待是事件驱动的，如果审核者响应慢，较长超时带来的只是最终输出延迟，绝不会增加后台计算开销。
启用此阶段#
humanEdit 在引擎的流水线选项卡中配置。有关流水线阶段配置的通用说明，请参阅配置流水线；此阶段的具体结构如下：
{
"humanEdit": {
"enabled": true,
"timeoutHours": 48,
"qualityThreshold": 85,
"routes": [
{ "pool": "<legal-reviewers-pool-id>", "match": { "locales": ["de"], "path": ["docs/legal/**"] } },
{ "pool": "<lingo-external-pool-id>", "match": { "locales": [] } }
]
}
}routes 将每种语言和每个目录分配到一个决策池：locales 为空表示任意语言，省略 path 表示任意目录。匹配最具体的路由优先，未被任何路由覆盖的目标则直接交付，无需审核。provider 和 tier 是旧版字段，仅在 routes 为空时读取。timeoutHours 是由超时设置的限制值，可选的 qualityThreshold（1–100）则是由质量阈值设置的值。
如果某条路由指向已归档或已删除的决策池，任务将无法启动，并返回 HumanReviewPoolUnusable 错误，直到引擎将其改为分配到另一个决策池。
当此阶段运行时，它会在任务下的 stepId: "humanEdit" 中记录自身状态，状态值为 completed、failed 或 skipped——这与每个阶段产出的步骤记录一致。如何读取这些记录，请参见 观察流水线运行。