什么是分级自治？高危操作（写库 / 发邮件 / 付款）怎么设计人工确认？
谁在问：toB / 金融 / 企业内部工具团队必问；用来验证你是否设计过真正落地的高危动作流程
口语化问法
- Agent 要动真数据了，你们怎么控？
- 什么动作必须让人点确认，什么可以自动执行？依据是什么？
- 弹窗弹多了用户就闭眼点了，你怎么办？
考察意图
第三个问法是这题真正的分水岭：确认疲劳。做过真产品的人一定撞过——确认弹得太多，用户变成无脑点通过，护栏名存实亡，还制造了安全的错觉并把责任转嫁给用户。答不到这一层的人，说明只在文档里设计过流程，没看过用户怎么用。
除此之外，面试官在看：分档依据是不是可操作（不是"重要的就确认"）、知不知道很多"高危"其实该用代码判而不是打扰人、以及批量操作和责任归属这两个真实场景里最难的部分。
参考答案
60 分答案（及格线）
分级自治就是按风险给动作分档，不同档位给不同的自主程度，而不是一刀切"全自动"或"全都要确认"。
我常用的分档：
| 档位 | 形态 | 典型动作 |
|---|---|---|
| L0 | 只出建议，人来执行 | 敏感变更、跨系统操作 |
| L1 | 自动执行 + 留撤销窗口 | 可逆的写入、延迟发送 |
| L2 | 自动执行 + 事后审计抽检 | 低风险写、内部记录 |
| L3 | 执行前人工确认 | 对外发送、金额较大的操作 |
| L4 | 双人或多人审批 | 大额付款、批量删除 |
分档依据三条：可逆性（撤销得了吗、撤销成本多大）、影响面（影响一个人还是一批人、对内还是对外）、可验证性（执行前能不能用代码判对错）。
确认界面上要给出足够的决策信息：要做什么、依据是什么、影响多少条、哪一步不可逆；默认拒绝，超时不执行。
90 分答案（有生产经验的回答）
补四层。
1. 可验证性这条最容易被忽略，也最能省事。 很多人把"高危"直接等同于"要人确认"，其实凡是能用代码判定的，就该用代码判，别打扰人——金额是否超限、收款方是否在白名单、订单是否属于当前用户、时间窗口是否合法，这些都是确定性判断，交给策略引擎，通过就自动执行，不通过就直接拒绝。人工确认应该只留给代码判不了、真的需要人类判断的那部分（比如"这封邮件的措辞对这个客户合不合适"）。这一条能把确认量砍掉一大半，也是治疗确认疲劳的根本手段。
2. 确认疲劳要量化，不能靠感觉。 我会盯两个指标：确认通过率和确认响应时长。如果某一档的通过率高到接近全通过、响应时长只有一两秒，说明这道闸已经失效了——用户在无脑点。正确的处理不是"教育用户认真看"，而是改设计：把这一档降级成自动执行 + 事后审计，或者改成异常触发式确认（只有偏离历史基线时才弹，比如金额超过该用户常规区间、收款方是首次出现）。让弹窗变稀有，它才重新变得有意义。
3. 可撤销窗口往往比确认更好用。 把不可逆变可逆——延迟发送几分钟、软删除、先置"待生效"状态，用户随时能撤回。它的优势是不打断流程：自动化率不掉，风险却被控制住了。设计上要注意撤销必须是真撤销（发出去的邮件撤不回，所以延迟发送要真延迟），并且撤销入口要显眼。优先级排序我会写成：能代码判的用代码判 → 能变可逆的变可逆 → 剩下的才用人工确认。
4. 批量操作是最容易翻车的地方。 一次要改五百条记录，逐条弹窗是灾难，一次性弹一个"确认执行"又等于没确认。做法是：先给影响面统计和预览（会改哪些、按类型分组各多少条、有没有超出预期的对象）、抽样展示差异视图（before/after，而不是让人读参数 JSON）、分批执行且中途可停、以及明确的回滚方案。判断标准很简单：用户看完这个界面，能不能回答"如果它错了，最坏会怎样"。
5. 配套三件事：预算与配额（单笔上限、日累计上限、频率限制，即使在自动档也生效）；影子模式（新能力先只产出不执行，跑一段时间对比人工决策，再放开）；审计留痕（谁的会话、依据什么、执行了什么、谁确认的，全链路可追，且确认时展示给用户的内容要存快照）。
追问链
「重要的动作就要人确认」这句话错在哪？
期望错在两头。该自动的被拦住 —— 额度、白名单、归属校验本可代码判定，让人来点是把确定性判断变成概率性的（人会看错也会疲劳）；不该自动的漏了 —— 给一批客户发条无关紧要的通知，单看不重要却影响面大、撤不回。判据要换成可逆性、影响面、可验证性这类可观察属性，不是「重要」这种主观标签信号指出「重要性是主观标签，要换成可观察属性」并给出两头的反例 → 设计过分级；只答「按业务重要程度分级」→ 落不了地怎么发现确认疲劳？发现了怎么治？
期望发现靠数据：确认通过率、响应时长分布、拒绝后发生了什么 —— 拒绝率近零这道闸就是摆设；偶尔插一个明显不该通过的请求做内部演练。治三招按序：能代码判定的收回代码，砍弹窗基数 → 固定档改成异常触发式，只在偏离基线时打断 → 同批次合并成一次带预览的批量确认。确认的价值来自稀缺性信号提出「确认通过率接近 100% 即失效」这个量化判据、并给出异常触发式确认 → 见过真实用户行为；答「培训用户认真看」→ 把系统问题推给人一次要修改 500 条记录，确认流程怎么设计？
期望绝不逐条弹：① 影响面统计（按类型／归属分组各多少条、有无预期外对象）；② 抽样差异视图（抽几条看 before/after，不是读参数JSON）；③ 异常项优先展示，信息量最高；④ 分批 + 中途可停，先跑 10 条无误再跑剩下；⑤ 回滚方案写在界面上。适合先跑影子模式信号提出「异常项优先展示」和「分批执行可中途停」→ 做过批量工具；答「弹一个确认框说要改 500 条」→ 等于没确认用户点了确认之后出了事，责任怎么算？系统怎么支撑？
期望确认有效的前提是信息充分：只写「是否执行操作？」的确认，产品和道义上都不成立，不能免责。三件事：① 最小充分信息：做什么、依据、影响面、不可逆点；② 存快照，展示的内容原样留档；③ 极高危双人复核。确认转移的是操作决定，不是设计责任 —— Agent 呈现的依据错了，责任仍在系统信号提出「信息不充分的确认无效」和「展示内容存快照」→ 考虑过真实追责；答「用户确认了就是用户的责任」→ 在 toB 场景会出大问题产品要「全自动别弹窗，用户嫌烦」，但流程里有付款动作，你怎么办？
期望「别弹窗」翻译成「别打断」，弹窗是最差的手段 → 三条替代：① 能代码判定的全代码化（额度、白名单、频率、归属校验），通过即自动 ② 不可逆变可逆：延迟执行 + 撤销入口 ③ 剩下的用异常触发式确认，99% 的正常场景零弹窗 → 摆确认通过率，证明产品的抱怨是对的 → 验收换成误操作率、单日资金损失上限 → 四条不谈判：额度上限、白名单、可撤销窗口、全量审计信号把「别弹窗」翻译成「别打断」、给三条替代路径、守住四条不打扰用户的底线 → 能和产品共赢；只坚持「付款必须确认」或干脆全放开 → 都答不到位
评分要点
- 说清分级自治是按风险分档给不同自主程度，不是二元开关
- 分档依据可操作：可逆性、影响面、可验证性
- 明确"能代码判定的用代码判，别打扰人"
- 知道确认疲劳，并能给出量化判据（确认通过率、响应时长）
- 可撤销窗口优于确认（不打断流程且控住风险）
- 确认界面要给最小充分信息，默认拒绝、超时不执行
- 批量操作要预览、抽样、异常优先、分批可停
- 加分：影子模式、预算与配额、全链路审计与展示快照
- 加分：能讨论确认的责任边界与信息充分性