Safety topic

危险的往往不是命令本身，而是你没看清影响范围却还是点了批准。

批准流的作用，不是替高风险动作贴一张礼貌标签，而是让人真的能判断：这一步会改什么、为什么现在要做、失败时该停在哪里。

先看批准清单回到安全中心

快速提示

解释不清的高风险动作，不会因为写得客气就变安全。

批准应该帮助判断，而不是帮助麻木。

当前一步说不明白时，继续加权限通常是坏主意。

你将获得

内容风格

少废话，先给结果

先告诉你该做什么、会遇到什么，再给出最短可用路径。

阅读体验

能看懂，也能照着做

重点信息会被拆成清单、步骤和提示，减少第一次上手的理解成本。

页面重点

先把关键问题讲清楚

实用优先

Approval checklist

批准前最该看的 5 件事

如果这五件事里有关键一项仍然模糊，那就先别急着通过。

批准前先看工作目录、目标对象和命令真正会影响哪里。

把高风险动作拆开说，不要把多步写入、删除、外发或系统变更打包成一次模糊批准。

说明失败停点：如果结果不对，应该停在第几步，而不是继续追加更高权限。

只在你真的理解影响范围时批准；看不懂就先拒绝或让说明更具体。

批准机制的价值是让人能判断，不是让人更快点通过。

好的批准说明长什么样

它会明确说：在哪个目录、对哪些文件或外部目标、执行什么动作、预期出现什么结果。你读完后能知道自己到底放行了什么。

坏的批准说明长什么样

“常规修复”“整理一下”“更新配置”这类说法都不够。它们的问题不是不礼貌，而是没有提供足够判断所需的信息。

什么时候不该继续加权限

当前一步解释不清、失败原因不明或影响范围模糊时，继续加权限通常只会把问题放大，而不是把它解决。

Minimum fields

一段合格批准说明至少应包含这些信息

你不需要把每次动作写成论文，但至少要让人读完后能判断风险落点。

至少要看到

工作目录、目标文件/目标站点、动作类型、预期输出。

最好再看到

失败停点、回滚线索、为什么现在必须做这一步。

绝不能省略

会不会写文件、会不会改状态、会不会发到外部、会不会碰系统级配置。

Hard stops

看到这些情况就先停

继续放行不会让模糊变清楚，只会让代价变大。

批准文案看起来很顺，但你仍说不清它会改哪些文件或外部状态。

多条高风险动作被打包成一次“顺手做完”。

执行失败后，下一步建议只是“再给更高权限试试”。

你已经把批准弹窗当成流程装饰，而不是判断停点。

Copy-ready command

批准说明应该比这组命令更清楚，而不是更模糊

命令本身可以很短，但批准说明不能因此偷懒。真正该解释的是影响范围、目标对象和失败停点。

# 例子：只有命令，没有上下文，这就不够
npm run build
npm run lint
git push origin main

Official sources

这一页只优先采信 OpenClaw 官方文档对权限、批准与网页操作边界的说明。

站内不会把批准流写成抽象规范，而是只保留对真实操作最关键的判断：什么时候该继续、什么时候该拒绝、什么时候该先要更具体说明。

官方文档 · 权限与批准

用于核对批准、权限边界与高风险动作说明方式。

https://docs.openclaw.ai/zh-CN/config/permissions

官方文档 · Doctor & Health Check

用于提醒先排环境和阻断项，不把批准机制当成万能排错按钮。

https://docs.openclaw.ai/zh-CN/config/doctor-and-health-check

官方文档 · Browser Relay / 浏览器接管

用于核对涉及网页登录态、可见标签页和外部账号操作时的说明边界。

https://docs.openclaw.ai/zh-CN/tools/browser