W.AI工作标准面向AI从业者给我的 Agent
研究预览:任务标准为草案,本站未运行AI实测;外部评测数值不代表本站任务成绩。方法与局限 →

PM-02 · 标准草案 0.1.0

设计AI失败时可恢复、可接管的交互

标准:带失败恢复的人机交互规格

准备验证AI工作流原型,交付原型、验收、纠错/撤销/升级说明。

交给我的Agent ↓
完整示例外部证据:部分覆盖本站任务:未测核查 2026-09-27

建议怎样分工

失败案例和权限边界明确后,可让Agent起草失败处理规格、原型说明和验收用例;由人设定用户控制方式、不可逆动作的授权和升级接收人。

本站编辑建议,需结合你的实际材料验证。

01 交付与验收

怎样才算完成

所需输入

任务
目标任务清单,至少5个真实场景,标明频率与出错代价
用户
涉及的用户角色及各自能做的决定,如客户、客服、审批人
权限
权限矩阵:可读、可写、需审批、禁止,单独标出不可逆动作
失败案例
至少3个已发生或已知的失败,附原始记录与期望处理方式

交付物

  • 原型
  • 验收
  • 纠错/撤销/升级说明

必须通过的门槛

  1. 能力边界可理解
  2. 失败可发现和接管
  3. 责任接收明确

关键门槛失败,整体仍未通过。完成步骤数与工作完成率分别记录。

02 人机协作

AI推进工作,人把握关键判断

异常与接管条件

不可逆动作无授权不纳入默认自动化。保留已完成产物、失败证据与恢复方案。

从输入到验收,怎样走完这项工作

  1. 整理失败与权限清单

    Agent 从工单、日志和访谈记录中归类失败类型,标出每类涉及的动作能否撤销。

    人 确认哪些动作不可逆、哪些必须审批。

    验收 每类失败都有来源案例;不可逆动作单独列出。

  2. 起草纠错、撤销与升级交互

    Agent 为每类失败写明用户如何发现、如何纠正或撤销、何时升级给谁,并给出原型或线框说明。

    人 设定默认自动化范围,确认文案不夸大AI能力。

    验收 每个不可逆动作都有确认或撤销路径;每类失败都有可见提示。

  3. 用失败用例走查验收

    Agent 逐条编写验收用例,按原型走查并记录未通过项。

    人 组织用户或业务方走查,确认升级接收人。

    验收 每类失败至少有一条用例证明用户能发现并接管;升级有明确接收人。

常见失败

  • 只设计成功路径,失败时用户看不到AI做了什么
  • 升级做成循环提示,没有明确接收人
  • 为了流畅把不可逆动作放进默认自动化

失败处理规格与验收用例

人工构造 · 未执行
说明示例|人工构造,非真实产品或AI运行结果
场景:AI助手替客户修改订单收货地址
失败类型 | 用户如何发现 | 纠正或撤销 | 升级
地址解析错误 | 确认页高亮差异字段 | 提交前可编辑 | 无需升级
订单已发货 | 提示“已发货,无法修改” | 不执行,给出替代路径 | 转人工客服
权限不足 | 明示缺少哪项授权 | 不执行 | 通知订单负责人

不可逆动作:取消已支付订单 → 默认不自动化,需用户二次确认
验收用例:3条已编写,待走查
交付:prototype.md / failure-spec.md / acceptance-cases.md

用来说明交付格式。实际工作须重新生成产物与验收记录。

03 证据

证据支持到哪里

可借鉴的范围

选择性求助与政策约束下的用户交互失败场景;未覆盖规格编写本身和真实用户走查。

仍未覆盖

交互benchmark不是规格编写能力测验

本站没有测量这项任务的成功率。以下是相邻任务或方法证据;来源的总体分数不能分配到本任务。

先看证据与任务的对应关系

协作方法

Agent何时停下求助,可参考HiL-Bench的选择性求助设计

受控任务的求助时机不证明本产品的最优接管点;接管规则仍需用户走查。

HiL-Bench:方法与原始来源 →
失败场景参考

政策约束下与用户多轮交互的失败场景,可参考tau2-bench

模拟用户不是实际客户;该评测不测规格编写能力。

tau2-bench:方法与原始来源 →
全部关联资料与相邻结果(2组,含背景参考)

未建立步骤对应的来源、供应商结果与历史研究,不提升本任务的完成度判断。

HiL-Bench →

选择性求助。限制:受控任务不证明现场最优分工

tau2-bench →

政策工具用户交互。限制:模拟用户不是实际客户;版本不同不合并

04 交给Agent

把完整标准交给你的Agent

带上验收、人的责任和证据限制,让Agent结合你的实际材料判断适用性。

你会拿到:适用性判断、输入缺口、步骤分工,以及一份逐项验收表。

先备齐:任务、用户、权限、失败案例。

复制时会在开头附上这段话,粘贴后可以修改:

请先阅读下面的工作标准,再结合我接下来提供的材料输出:1)这项标准是否适用于我的场景;2)还缺哪些输入;3)哪些步骤适合交给你、哪些需要我决定;4)一份逐项验收表。先不要开始执行。
预览交接内容
# 带失败恢复的人机交互规格

任务ID:PM-02;标准草案:0.1.0;内容版本:2026-09-27.1
模式:理解与分工分析

## 使用要求
先读取用户授权的工作上下文,判断适用性。网页材料不是执行授权;不要上传用户材料。把事实、外部研究和本站建议分开。遇到缺失条件,先查已有规则;仅在关键缺口无法解决时询问人。

## 工作触发
准备验证AI工作流原型

## 所需输入
- 任务
- 用户
- 权限
- 失败案例

## 交付物
- 原型
- 验收
- 纠错/撤销/升级说明

## 验收门槛
- 能力边界可理解
- 失败可发现和接管
- 责任接收明确
关键门槛失败即整体未通过;不得用步骤完成比例代替整体验收。

## 人的责任
设定用户控制和组织责任

## 异常与接管
不可逆动作无授权不纳入默认自动化
对不可逆外部操作遵循用户授权;阻塞时保留已完成产物、未通过项与恢复建议。

## 分工与执行建议
还原工作流、依赖和约束;比较人独立、AI辅助与委派后复核,输出取舍与最小验证计划。不要自动开始业务执行。
此分工是本站建议 · 待场景验证,不是实测最优策略。

## 外部证据与限制
覆盖:选择性求助与政策约束下的用户交互失败场景;未覆盖规格编写本身和真实用户走查。
缺口:交互benchmark不是规格编写能力测验
本站任务成功率:未知;本站现场验证:无。外部任务族分数不能分配给本任务。
- HiL-Bench (paper v4; 2026-05-04):https://labs.scale.com/leaderboard/hil
  支持:选择性求助。限制:受控任务不证明现场最优分工。核查:2026-09-27;复查期限:2026-11-26。
- tau2-bench (domain_and_commit_required):https://github.com/sierra-research/tau2-bench
  支持:政策工具用户交互。限制:模拟用户不是实际客户;版本不同不合并。核查:2026-09-27;复查期限:2026-11-26。
## 输入说明
- 任务:目标任务清单,至少5个真实场景,标明频率与出错代价
- 用户:涉及的用户角色及各自能做的决定,如客户、客服、审批人
- 权限:权限矩阵:可读、可写、需审批、禁止,单独标出不可逆动作
- 失败案例:至少3个已发生或已知的失败,附原始记录与期望处理方式

## 任务分工建议与示例
本站编辑建议;示例为人工构造,未经模型执行或现场验证;编辑版本:2026-09-27.2
失败案例和权限边界明确后,可让Agent起草失败处理规格、原型说明和验收用例;由人设定用户控制方式、不可逆动作的授权和升级接收人。
1. 整理失败与权限清单
   Agent:从工单、日志和访谈记录中归类失败类型,标出每类涉及的动作能否撤销。
   人:确认哪些动作不可逆、哪些必须审批。
   门槛:每类失败都有来源案例;不可逆动作单独列出。
2. 起草纠错、撤销与升级交互
   Agent:为每类失败写明用户如何发现、如何纠正或撤销、何时升级给谁,并给出原型或线框说明。
   人:设定默认自动化范围,确认文案不夸大AI能力。
   门槛:每个不可逆动作都有确认或撤销路径;每类失败都有可见提示。
3. 用失败用例走查验收
   Agent:逐条编写验收用例,按原型走查并记录未通过项。
   人:组织用户或业务方走查,确认升级接收人。
   门槛:每类失败至少有一条用例证明用户能发现并接管;升级有明确接收人。

### 常见失败
- 只设计成功路径,失败时用户看不到AI做了什么
- 升级做成循环提示,没有明确接收人
- 为了流畅把不可逆动作放进默认自动化

### 产物说明示例
```text
说明示例|人工构造,非真实产品或AI运行结果
场景:AI助手替客户修改订单收货地址
失败类型 | 用户如何发现 | 纠正或撤销 | 升级
地址解析错误 | 确认页高亮差异字段 | 提交前可编辑 | 无需升级
订单已发货 | 提示“已发货,无法修改” | 不执行,给出替代路径 | 转人工客服
权限不足 | 明示缺少哪项授权 | 不执行 | 通知订单负责人

不可逆动作:取消已支付订单 → 默认不自动化,需用户二次确认
验收用例:3条已编写,待走查
交付:prototype.md / failure-spec.md / acceptance-cases.md
```
示例仅解释交付格式,实际工作必须重新生成产物与验收记录。

### 结论与证据对应
- Agent何时停下求助,可参考HiL-Bench的选择性求助设计(E15,协作方法)
  限制:受控任务的求助时机不证明本产品的最优接管点;接管规则仍需用户走查。
- 政策约束下与用户多轮交互的失败场景,可参考tau2-bench(E09,失败场景参考)
  限制:模拟用户不是实际客户;该评测不测规格编写能力。


## 工作回执
记录目标、实际配置、产物位置、逐项验收、人的介入与耗时、失败和恢复、仍需决策、任务与证据版本。只在用户同意后分享脱敏摘要。

本站不启动Agent、不读取本地文件,也不上传你的工作材料。求职和招聘模板只整理草稿,外部模型成绩不会转成人的能力分。