VOCABULARY / 词条
人工审批检查点
Human Approval Checkpoint
在自动化或代理式流程中设置的一个明确暂停点：系统在执行会产生实际后果的动作之前停下来，把是否继续的决定权交给一个人，只有获得批准之后动作才会生效。
识别特征
- 动作在获得批准前不会生效，流程保持在可撤回的暂停状态
- 检查点展示的是动作生效后会发生的具体效果，而不只是动作的名称或类型
- 批准与拒绝这两个操作在界面上同等易得、同等清楚，没有一个被设计得更顺手
概念边界
这是一种具体的交互机制，不同于哲学层面'是否应当保留人的自主权'这一更大的问题——那是设计目标层面的取舍，本词条只处理已经决定要保留人工把关时，界面如何落实这个决定点。它也不等同于模态对话框：模态对话框只是一种阻断式的呈现形式，任何需要用户先处理的事情都可能用它来做（例如收集必填信息），并不天然带有'审批'的语义；审批检查点可以借助模态对话框来呈现，也可以用其他非阻断形式（例如一条需要点击才生效的待办）。它同样不等同于防错这一原则：防错关心如何从设计上减少错误发生的可能性，审批检查点只是实现防错的其中一种具体手段——在动作生效前引入人的判断，而不是防错原则本身。
什么时候考虑它
- 自动化或代理式流程即将执行有实际后果、难以撤销的动作
- 复核者对即将发生的具体后果确实拥有判断依据和拒绝的正当性，不是被动盖章
- 动作可以等待人工复核而不会因此错过关键时限或造成额外损失
什么时候慎用
- 复核者既没有时间也没有专业背景去判断内容，签字只会变成走过场
- 动作本身很容易撤销，实时防错或事后审计已足以覆盖风险，暂停反而拖慢日常工作
- 同一类低风险动作被反复要求审批，导致复核者产生审批疲劳并机械通过
取舍
换来的是在不可逆或高代价动作生效前拦下错误、把关键判断留给人的机会，代价是拖慢流程；如果复核者没有真正看清后果，或者批准比拒绝更省事，这道关卡就会退化为盖橡皮图章式的走过场——审批检查点因此制造的是虚假的安全感，而不是真实的把关。
条件规则 · 编辑建议
相关词条
审批检查点是防错原则的一种具体落地方式：把'减少错误发生可能性'这一目标，实现为流程里一个必须经过人的暂停点。
检查点常常用模态对话框来阻断主流程并展示待批准的动作，但模态对话框只是一种呈现形式；审批语义、对等的批准/拒绝出口以及审批留痕，是检查点本身必须满足的要求，不会因为换了呈现形式而消失。
如果复核者对自动化结果的信任程度没有被恰当校准，就会出现自动化偏见——不加阅读地批准；检查点要和信任校准配合设计，才能避免沦为盖章仪式。
来源与支持范围
HAX 准则 G16（Convey the consequences of user actions）要求让用户方便看清自己动作会带来的后果，G9（Support efficient correction）要求让用户能高效地纠正或撤回系统的错误判断，二者共同支持审批检查点必须展示具体后果、并保留同样顺手的拒绝出口。
检索日期：2026-09-15 · 存档于 2026-09-16该指南建议识别哪些内容会被共享、被执行或被自动化，为影响他人或涉及承诺的决定设置检查点，要求在代理式工作流把不完整信息推进到下一步之前先经过人的复核。
检索日期：2026-09-15 · 存档于 2026-09-16第14条要求负责监督的人具备能力，在具体情境下决定不使用、无视、推翻或撤销系统的输出，并能通过停止按钮或类似程序干预、中断系统运行；这是审批检查点应当保留的否决权在法规层面的表述。
检索日期：2026-09-15 · 存档于 2026-09-16定义参考以上来源；数字界面示例、选择建议、条件关系及配方由本样例编辑，尚未经用户研究验证。
类型扩展与实现说明
本词条尚无可操作示例；插画为编辑示意。应用到产品时仍须验证：复核者是否真的拥有拒绝的权力和依据、是否有足够时间阅读后果、批准与拒绝的记录是否被正确写入审计日志，以及在审批频次很高时是否会出现审批疲劳而使检查点名存实亡。
{
"states": [
"pending",
"approved",
"rejected",
"expired"
],
"a11y": [
"待批准的内容以可访问的方式呈现具体后果，而不仅依赖按钮文案",
"批准与拒绝控件均可通过键盘到达，且没有把默认焦点预先放在批准上",
"状态变化（等待、已批准、已拒绝）以文本形式播报，不仅依赖颜色"
],
"motion": "无需强调性动画；出现与消失方式可复用其所在容器（如模态对话框）的动效设置"
}打开本词条的 Agent JSON 文件这个文件原样收录本词条的全部字段，并附上来源、存档与编辑声明。