你的大多数内容在引擎返回结果后就能立即上线。但有些不行。比如受监管的信息披露、医疗说明、承载品牌表达的标题——这类内容，你会希望先由人工通读译文并签字确认，再正式发布，而不是等客户投诉后再来补救。
要把人工审核接入自动化流程，常见做法往往都很折腾：要么一直挂着请求等人来审，要么自己搭建审核队列，要么手动对接翻译供应商的 API。而这个阶段把这些都直接放进任务内部。启用 humanEdit 后，异步任务会先跑完引擎，然后暂停等待人工审核——可以是你的团队，也可以是外部专业人员——待对方提交修改后再继续，并将该结果传递给后续所有阶段。
这是 本地化流水线 的第三个阶段，并且和其他阶段一样，只适用于通过 Async Localization API 创建的任务。刚接触流水线？建议先看 概览。
本页内容
暂停机制如何运作#
在核心翻译步骤之后，任务会把 AI 翻译交给人工审核。审核者通读后，可以选择直接批准，也可以提交修改后的版本。只有到这一步完成，任务才会继续。人工给出的结果——无论是原样批准还是修改后提交——都会成为后续每个阶段的输入，并最终成为任务的 outputData。
一提到让任务暂停几分钟、几小时甚至一整天，最直观的顾虑就是成本：如果请求一直挂着，那在什么都没发生时也会持续占用资源。但这个阶段不是这么工作的。
等待是事件驱动的，不是一直挂着连接
工作流会在事件发生时恢复——例如审核者在控制台中提交结果（内部审核），或翻译服务商发回回调（外部审核）。它不会高频轮询，也不会一直保持连接打开，因此即使超时时间设得很长，后台也不会消耗计算资源。任务可以像等待模型结果一样等待人工 48 小时：它只是被挂起，不是在空转。
支持两种审核模式，按引擎选择。二者唯一的区别是谁来审核——暂停、恢复以及结果向后传递的行为完全一致。
内部审核#
你的团队可以直接在 Lingo.dev 控制台中审核翻译。待审项目会进入你组织的 Human Reviewer 页面（/orgs/<org-id>/human-reviewer），有新项目到达时，审核者也会收到通知。审核者领取项目后，可以原样批准译文，或提交修改后的版本。任务会立即基于其输出继续执行。
如果某个项目已经有人在处理，第二位审核者就无法再接手。领取是独占的——同一时间一个项目只会由一位审核者持有，因此不会出现两个人同时编辑同一条翻译、最后悄悄互相覆盖的情况。在审核者释放项目或提交结果之前，该字符串都会锁定给领取者。
对于新引擎，内部审核是默认模式。如果你的团队具备所需的语言能力，并且希望完全掌控最终措辞、不让第三方介入，那就选它。
权限#
内部审核并不是对组织内所有人开放的——Human Reviewer 页面受权限控制，因此处于审核中的翻译只对被授予访问权限的人可见。组织管理员可通过角色（Settings → Roles）分配权限：
| 权限 | 解锁的能力 |
|---|---|
审核翻译 (engine:review_translations) | 查看并处理审核队列——领取待审核翻译、编辑、原样批准，或提交修改后的版本 |
管理审核 (org:manage_reviews) | 查看整个组织内所有内部审核的审核历史和审核者统计 |
这两项权限是刻意拆开的。审核者只需要 审核翻译——这一项授权就足以完成全部工作：领取、编辑、批准、提交。管理审核 则是给负责统筹流程的人准备的；它会增加全组织范围的历史记录和统计视图，但本身并不包含队列访问权限。既要审核又要汇报的负责人，请同时授予两项权限；只负责处理队列的人，只授予第一项即可。
外部审核#
如果某个语言区域没有内部审核者，翻译会改由外部服务商提交给合格的专业译者。任务暂停和恢复的方式完全一样；当服务商返回修改后的译文时，任务就会继续。你的代码无需任何改动——变化的只是由谁来审核字符串，而不是任务如何运行。
外部审核分为两个层级，区别在于内容对准确性的要求有多高：
| 层级 | 适用场景 |
|---|---|
| 标准 | 既要翻译准确，又要保留人工语言质感——营销文案、UI 字符串、帮助内容 |
| 专业 | 面向专业用途、对准确性要求更高——法律、医疗及受监管内容 |
有一点需要说清楚：External Review 的另一端是真实的人类译者，这也意味着相应的交付周期和成本。它不是一个更快的模型。把它用在真正需要人工判断的场景——受监管文本、高风险文案——而对于绝大多数不需要这一步的内容，则应更多依赖纯 AI 路径。
超时#
人工阶段会引入 AI 阶段没有的风险：人可能始终不响应。审核者在休假，服务商积压严重，或者项目被遗忘。如果不设上限，任务就可能永远等下去。
因此，等待时间是有边界的。你可以设置工作流等待人工结果的时长——同一个 timeoutHours 配置同时适用于两种审核模式。如果超时后仍未收到响应，该阶段会被标记为 skipped，并且任务会继续使用 AI 翻译作为最终输出。默认值为 48 小时。
这其中的代价也要讲明白：一旦超时，你上线的就是未经人工审核的 AI 翻译。对大多数内容来说，这是合理的回退方案——翻译顺利发布，总比任务无限期卡住更好——但这确实是一种取舍。对于无论如何都必须人工签字确认的内容，应设置较宽裕的超时，并在被跳过时发出告警；而对于审核只是加分项的内容，较短的超时能让流水线持续向前。
超时针对的是阶段，不是整个任务
超时只控制此阶段等待人工多久，与任务其余部分耗时多久无关。由于等待是事件驱动的，如果审核者响应慢，较长超时带来的只是最终输出延迟，绝不会增加后台计算开销。
启用此阶段#
humanEdit 的配置方式和其他流水线阶段一致：先在引擎的 Pipeline 标签页中设置引擎级默认值，也可以按请求单独覆盖。完整的双层配置模型见 配置流水线；而此阶段的配置形式如下：
{
"humanEdit": {
"enabled": true,
"provider": "internal",
"tier": "standard",
"timeoutHours": 48
}
}provider 用来选择模式——你的团队使用 internal，否则使用外部服务商。tier（standard 或 pro）适用于外部审核，在内部审核中会被忽略。timeoutHours 则对应上文提到的等待上限。若要只覆盖单次提交，请在 create 调用 的 pipelineConfig 中传入这一配置块；如果省略，任务将继承引擎设置。
当此阶段运行时，它会在任务下的 stepId: "humanEdit" 中记录自身状态，状态值为 completed、failed 或 skipped——这与每个阶段产出的步骤记录一致。如何读取这些记录，请参见 观察流水线运行。
人工修改可能会偏离你的引擎规则
人工译者的表达方式可能与你的 glossary、brand voice 或 instructions 不一致——他们擅长的是把翻译做好，而不是记住你的配置。若要自动把人工修改重新对齐到你的引擎规则，请启用下一个阶段 AI review。它只会在人工阶段确实产出结果后运行。
