安全放手（Safe Autonomy）：AI 自己跑也不闯祸

📍 自动化与协作

可爱机器人在赛道上奔跑，身上系着安全带，赛道两边有柔软的护栏

一条命令，全家沉默

先讲我们家最疼的一次事故。

某天要重启一个机器人的消息服务。执行的命令用了模糊匹配——「把叫这个名字的进程都杀掉」。

问题是：全家一窝机器人的消息服务，进程名长得一模一样。

一条命令下去，全部撂倒。瞬间全家失联。

事后复盘，教训简单得扎心：杀进程要用精确的进程号，不要用名字模糊匹配。这条经验从此写进了我们家的规则文件，再没犯过。

前面四篇讲的都是「怎么放手」——定时自动跑、远程指挥、聊天入口、组队协作。这一篇讲放手的前提：怎么不闯祸。

「安全放手（Safe Autonomy）」是本站自己起的叫法，Claude Code 里没有叫这个名字的功能。它对应的官方功能是：权限模式、权限规则（allow / ask / deny）、钩子（Hook）和沙箱（Sandbox）。

自主 ≠ 裸奔：先弄清它会不会问你

Claude Code 动手前会不会先问你，取决于权限模式。2.1.283 起新会话默认是 auto 模式：由另一个模型在后台替你审核，大多数操作不再弹窗；官方也提醒，auto 减少了弹窗，但不保证安全（接 DeepSeek 时 auto 大概率用不了，会从 Manual 开始，以状态栏显示为准）。一共六种模式各放行什么、怎么用 Shift+Tab 切换，统一见跑命令那一篇。

从「安全设计」的角度看，关键不是选哪种模式，是理解一个组合拳：

范围内自动跑 + 范围外必须问 + 红线永远禁止。

比如：「读文件、改这个项目目录、跑测试——放行；删东西、推代码、动配置、碰其他目录——必须问我；模糊匹配杀进程、sudo——永远禁止。」这才是「安全的放手」：不是信任它一切，是把信任圈划清楚。

三个同心圆：最里圈绿色'自动放行'，中间圈黄色'需要确认'，最外圈红色'永远禁止'

把信任圈落成规则

图里的三个圈，正好对应 Claude Code 权限规则的三种：allow（放行）、ask（询问）、deny（禁止）。在会话里输入 /permissions 就能查看和增删，也可以写进项目的 .claude/settings.json：

{
  "permissions": {
    "allow": ["Bash(npm test)"],
    "ask": ["Bash(rm *)", "Bash(git push *)"],
    "deny": ["Bash(pkill -f *)", "Bash(sudo *)"]
  }
}

deny 在所有模式下都生效，连 bypassPermissions 也不例外；你写的 ask 规则在 auto 模式下也照样弹窗
规则只按命令文字匹配，换个写法（比如 /bin/rm）就可能绕过去，所以它是「闸」不是「墙」
想把「能碰哪些文件、能连哪些网站」真正圈住，再打开沙箱：在会话里输入 /sandbox（macOS、Linux、WSL2 可用），由操作系统限制命令能写的目录和能连的网站

每条规则的细节和局限，见跑命令那一篇的「真正拦得住的」（官方说明：权限规则、沙箱）。

最小授权原则：每次只开一条缝

我们家有一条被真实事件焊死的规矩：加权限，只加当下明确需要的那一条，绝不「顺手多开」。

来历：有一次为了传文件，差点给 AI 开了一个「所有同步命令都放行」的大口子。被及时叫停——正确做法是只放行那一条具体命令。

为什么这么抠？因为权限的特点是开了就容易忘。今天为了省事开的大口子，三个月后你根本不记得，而它一直在那开着。每一条多余的授权，都是将来某次事故的伏笔。

实操建议：

权限申请出现时，看清楚具体是什么再点允许，不要条件反射
优先选「Yes」（只放行这一次），观察几次再考虑「Yes, and don’t ask again」（以后不再问）。后者对命令来说，通常会按命令开头保存一条规则，永久写进项目的 .claude/settings.local.json，放行的是一整类命令
每隔一两个月，在会话里输入 /permissions，把永久授权清单过一遍，不认识的删掉

看门狗：假设它一定会挂

自动化系统的成熟标志，是为失败设计。我们家的做法叫「看门狗」（watchdog）：

一个独立的小程序，每分钟检查一遍所有服务：活着，不管；挂了，自动拉起来，并记一笔日志。

它救过场很多次：机器重启后服务没起来、进程悄悄崩了……每次都是一分钟内自动恢复，人事后看日志才知道出过事。

这个思路可以浓缩成一句话：

不要问「它会不会挂」，要问「它挂了之后，多久、由谁、怎么恢复」。

哪怕你不写看门狗，每天定时巡检一遍，也是同一个思路的轻量版：本机和家里内网的服务，用系统自带的定时任务（macOS、Linux 的 cron，Windows 的任务计划程序）来查；只查公网上的网站，也可以用例行任务（需要 Claude 付费订阅，还要在它的云端环境里放行你的网站域名），但它跑在云端，碰不到你的电脑和内网。

一只警觉的小狗机器人守在一排服务器架子前，其中一个服务器倒了，小狗正把它扶起来

用事故换来的四条铁律

我们家几年自动化跑下来，每条都有对应的真实翻车：

1. 危险命令，精确打击

开头那个全家沉默的故事。删除、终止、覆盖类的操作，永远指名道姓（精确路径、精确进程号），不用通配符和模糊匹配。给 AI 的规则文件里明写这一条，再按第 4 条加一道硬闸。

2. 上公网前，过一遍「陌生人测试」

Web Chat 那一篇的三周裸奔。任何东西暴露到公网前问一句：陌生人拿到链接能干什么？答案不舒服就先加门。

3. 改坏之前，先留后路

大改动前存档（git 提交、备份、快照）。AI 手快，它三分钟能改二十个文件——没有存档点，回滚就是灾难。我们家的习惯：让 AI 动手前自己先说「我会先备份到哪」。

4. 出事之后，把教训写进规则

每次翻车，复盘出的规则分两层落地：

软约束：写进 AI 能读到的规则文件（比如 CLAUDE.md），告诉它「不许这么做，因为……」。它会照着做，但这只影响它倾向怎么做。官方说得很清楚：CLAUDE.md 里的指令，改变不了 Claude Code 程序允许它做什么。
硬约束：真要拦住，用程序层面的闸：deny 权限规则（所有模式下都生效，包括 bypassPermissions），或者 PreToolUse 钩子（每次动手前先跑你写的检查脚本，判定拒绝时连 bypassPermissions 也拦得住，写法见 Hooks）。

拿开头那次事故举例：软约束是在 CLAUDE.md 里写「杀进程只用进程号」；硬约束可以加一条 deny 规则 Bash(pkill -f *)。但要知道它只按命令文字匹配：pkill -9 -f、/usr/bin/pkill -f、sh -c 'pkill -f …'、killall 都拦不住。更稳的是写一个 PreToolUse 钩子，检查完整命令里有没有 -f 模糊匹配或者 killall。

两层都做，才能大幅降低再犯的概率；不写，三个月后换个马甲再来一次。AI 的好处是：教训能变成程序替你把关，不靠人记性。

一张自查清单

放手自动化之前，过一遍：

危险操作（删 / 杀 / 覆盖）是否都要求精确指定目标？
公网入口是否都有门（密码 / 白名单 / 验证）？
自动任务挂了，有没有人或机制会发现？多久？
大改动前有没有存档点？
权限清单里（/permissions 能看全），有没有你已经想不起来为什么开的？
翻车教训写进规则文件了吗？真要拦住的，加了 deny 规则或钩子吗？

六个都打勾，你就可以安心放手了。

这一篇的核心信息

自主和安全不是对立的——安全恰恰是放手的前提。

不敢放权的人，永远在每一步确认里消耗自己；裸奔放权的人，迟早被一次事故吓回原点。真正的自动化高手，是把护栏修得足够好，然后彻底放手的人。

看一眼上面那张清单——你现在的系统，几个能打勾？差的那几个，就是你本周该补的课。

下一步

「自动化与协作」五篇到这里完结。回头看这条线：让 AI 按时干活 → 人在外面也能指挥 → 住进聊天软件 → 组成团队 → 系好安全带（本篇）。

这五件事拼起来，就是「AI 员工」的完整形态。