AI 为什么需要“确认”？OpenClaw 的安全启示

网罗开发 （小红书、快手、视频号同名）

大家好，我是展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验 。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员

👋 大家好，我是展菲！

📱 全网搜索"展菲"，即可纵览我在各大平台的知识足迹。

每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

文章目录

- 引言
- 一、我们为什么会忽略"确认"？
- - 于是很多系统默认：
  - 但这其实是一个错觉
- 二、"确认机制"到底在解决什么问题？
- - 举个例子
  - [AI 如果直接执行](#AI 如果直接执行)
  - 如果有确认
  - 差别在哪？
  - 本质变化
- [三、OpenClaw 中的"确认缺失"风险](#三、OpenClaw 中的“确认缺失”风险)
- - 示例
  - 1、误操作
  - 2、越权操作
  - 3、不可逆操作
  - 一句话总结
- 四、确认机制的三种形态
- - 1、显式确认
  - 2、隐式确认
  - 优点
  - 3、策略确认
- 五、确认机制的核心价值
- - 1、降低误解风险
  - 2、防止越权执行
  - 3、提供"最后一道防线"
- 六、为什么很多系统不愿意做确认？
- 七、如何设计"好的确认机制"？
- - [原则 1：只在"必要时"确认](#原则 1：只在“必要时”确认)
  - [原则 2：确认必须"清晰"](#原则 2：确认必须“清晰”)
  - [原则 3：支持"撤销"（Undo）](#原则 3：支持“撤销”（Undo）)
  - [原则 4：结合 Policy Engine](#原则 4：结合 Policy Engine)
  - [原则 5：结合 Guardrails](#原则 5：结合 Guardrails)
- [八、在 OpenClaw 中的落地设计](#八、在 OpenClaw 中的落地设计)
- - 执行链路
  - 示例代码
  - 判断逻辑
- 九、一个更深的思考
- - 为什么？
  - 所以必须：
- 总结
- - 核心结论
  - 一句话总结

引言

如果你用过 AI 助手，大概率已经习惯了这样一种交互：

复制代码

你说一句
AI 直接执行

看起来很高效，但问题也藏在这里：

AI 很少"确认"，就开始行动。

在 OpenClaw 这样的系统中，这个问题会被放大------因为它不仅是"聊天"，而是：

复制代码

真实执行
修改状态
影响系统

于是一个关键问题出现了：

AI 到底该不该"先确认，再执行"？

一、我们为什么会忽略"确认"？

原因很简单：

复制代码

确认 = 多一步
多一步 = 更慢
更慢 = 更差体验（表面上）

于是很多系统默认：

复制代码

直接执行
自动完成
减少交互

但这其实是一个错觉

你省掉的不是一步操作，而是一道"安全边界"。

二、"确认机制"到底在解决什么问题？

确认不是形式，而是一个核心能力：

把"模糊意图"，变成"明确决策"。

举个例子

用户说：

复制代码

"帮我清理一下数据"

AI 如果直接执行

可能理解为：

复制代码

删除所有数据

如果有确认

复制代码

你是要：
1、删除临时文件
2、 删除全部数据

差别在哪？

复制代码

前者：AI 决定
后者：用户确认

本质变化

从"AI 决策"，变成"用户授权"。

三、OpenClaw 中的"确认缺失"风险

在 OpenClaw 中，很多操作是"直接生效"的：

示例

复制代码

生成实体（spawn）
删除对象（destroy）
修改状态（update）
触发事件（trigger）

如果 AI 接入这些能力，并且：

复制代码

没有确认机制

就可能出现：

1、误操作

复制代码

本想生成 5 个敌人
→ 实际生成 500 个

2、越权操作

复制代码

修改普通对象
→ 实际影响核心系统

3、不可逆操作

复制代码

删除资源
→ 无法恢复

一句话总结

没有确认，错误就会"直接变成结果"。

四、确认机制的三种形态

很多人以为确认只有一种：

复制代码

弹窗确认

其实不是。

1、显式确认

最常见：

复制代码

"是否删除？"
[确认] [取消]

适合：

复制代码

高风险操作
不可逆操作

2、隐式确认

通过上下文判断：

复制代码

用户连续两次相同指令
→ 视为确认

优点

复制代码

减少打断
体验更好

3、策略确认

由系统策略决定：

复制代码

高风险 → 必须确认
低风险 → 自动执行

示例

ts 复制代码

if (riskScore > 70) {
  requireConfirmation();
}

五、确认机制的核心价值

1、降低误解风险

复制代码

自然语言 → 模糊
确认 → 明确

2、防止越权执行

复制代码

AI 不能"自己决定一切"

3、提供"最后一道防线"

即使：

复制代码

模型错了
规则漏了

确认仍然能拦住。

本质

确认 = 最后的"人类控制点"。

六、为什么很多系统不愿意做确认？

因为它带来三个"看起来的缺点"：

1、降低效率：多一步交互

2、打断体验：用户被中断

3、增加复杂度：需要设计逻辑

4、但这是一个典型误判：

你牺牲的是"表面效率"，换来的是"系统安全"。

七、如何设计"好的确认机制"？

重点来了。

原则 1：只在"必要时"确认

复制代码

低风险 → 不确认
高风险 → 必须确认

原则 2：确认必须"清晰"

不要：

复制代码

是否继续？

要：

复制代码

是否删除 120 个文件？

原则 3：支持"撤销"（Undo）

确认不是唯一手段：

复制代码

执行 + 可回滚

原则 4：结合 Policy Engine

复制代码

策略决定是否确认

原则 5：结合 Guardrails

复制代码

确认前先过滤危险行为

八、在 OpenClaw 中的落地设计

在 OpenClaw 中，可以这样设计：

执行链路

复制代码

AI → Plan → Policy → Guardrails → Confirmation → Gateway → 执行

示例代码

ts 复制代码

if (needsConfirmation(action)) {
  askUser(action);
} else {
  execute(action);
}

判断逻辑

ts 复制代码

function needsConfirmation(action) {
  return action.risk > 50 || action.isDestructive;
}

九、一个更深的思考

确认机制的存在，其实揭示了一个本质问题：

AI 不应该"完全自主"。

为什么？

因为：

复制代码

AI 不理解后果
AI 不承担责任
AI 无法真正"后悔"

所以必须：

在关键节点，把控制权交还给人类。

总结

在 OpenClaw 这样的系统中：

复制代码

AI 可以执行
AI 可以决策
AI 可以自动化

但有一件事不能省：

确认。

核心结论

复制代码

确认不是多余步骤
确认是安全边界

一句话总结

AI 越强，越需要"确认"；自动化越高，越需要"人类在环"。