我不想让 AI 全自动，但也不想它什么都需要我确认

最近用 Claude Code 时，我卡在了一个看起来很简单的问题上：

当 AI 做完了，或者遇到必须由我决定的事，能不能主动提醒我？

很多任务并不需要我一直盯着。我可以把活交给它，自己去看资料、整理文档，甚至处理另一件事。理想状态是：AI 在后台持续跑，只在下列情况把我叫回来——

任务已经完成；
需要批准某项操作；
缺少关键上下文；
出现多个方案，需要产品或业务判断；
操作可能产生不可逆的外部影响。

一开始我以为这只是「打开通知」。后来才发现，真正的问题不是「AI 能不能提醒我」，而是：

AI 应该在什么情况下打断我？

第一步：先让提醒真正工作

Claude Code 提供多种本地通知方式。有的依赖特定终端，有的用专用控制序列，还有一种最通用：向终端发送铃声信号（bell）。

信号本身不复杂。Claude Code 在任务完成、等待权限或需要用户输入时发出提醒；终端再决定怎么表现它——播声音、闪任务栏、弹桌面通知，或者什么也不做。

这也解释了为什么「已经打开通知」不等于一定看得到提醒。通知是一条链路：

AI 进入等待状态
  → 发出通知事件
  → 终端接收信号
  → 操作系统显示声音 / 任务栏 / 弹窗
  → 用户注意到并回来处理

任何一层没配好，最终都像「AI 没有提醒」。

我这边的实际表现是：没有任何提示。一开始我以为是 Claude Code 没有提供对应的通知功能，所以就去找其他的解决方案；后来朋友推荐我用Zed，在上手使用之前，我使用ChatGPT调研了下怎么把Zed集成到我的工作流，并明确提出了我的需求，然后在讨论过程中，GPT提到Claude Code有对应的配置，我实测了一下确实有，然后就开始做相应的配置；开了通知音。

在 Claude Code 中执行：`/config`， 找到 "Local Notifications"， 选择 "Terminal Bell"

技术问题解决了，但新的问题马上出现了。

第二步：提醒成功了，但它开始烦人

Claude Code 执行过程中经常要跑命令、搜代码、看文件状态，或把多个终端操作拼在一起。从安全角度看，权限确认是合理的：AI 不该默认拥有无限制执行权，尤其是删除/覆盖文件、装依赖、改系统配置、Git 提交或推送、发布部署、外呼网络、读密钥这类操作。

问题在于，权限系统并不是总能对齐人的意图。

有时它只是想搜几个文件，却把多个只读命令拼成一长串 Shell。对我来说是一次普通的仓库检查；对权限系统来说，是一个未经授权的 Bash 操作。工作流于是变成：

交给 AI 一个任务
  → 离开窗口
  → 收到提醒
  → 回来点允许
  → 再次离开
  → 几分钟后又收到提醒

确实提醒了，但注意力反而被切得更碎。

这时我意识到：我真正想要的不止是通知，而是"必要"的通知。更准确地说是更清楚的权限边界和任务设计 如果 AI 每走一步低风险动作都要叫人回来，再完善的通知也只是在更高效地制造打断。

第三步：不关掉所有提醒，而是降低提醒密度

最直接的做法是关通知——然后又回到「AI 已经停了，我不知道」。另一个极端是彻底绕过权限，让 AI 自由执行——确认次数少了，最重要的安全边界也没了。

合适的方案不是在「全部提醒」和「完全不提醒」之间二选一，而是把操作分层。

第一层：可以静默执行

风险低、频率高，应让 AI 自己做完：

读项目文件、搜代码和文档；
看 Git 状态和 diff；
跑已经确认安全的检查、lint、测试、构建；
在项目目录内做可回滚的编辑。

对这些操作，不应反复要人点确认。更稳的做法是：

优先用内置的读取、搜索和文件工具，少为简单查询拼复杂 Shell；
对已验证的常用命令建项目级权限规则；
只在可信项目里逐步放宽，而不是一次全开。

第二层：提醒我，但不必制造紧迫感

需要人回来，却不紧急：

一轮任务做完了；
给出了多个实现方案；
需要补需求或业务判断；
对下一步方向没把握。

这类更适合视觉提示（任务栏闪烁、窗口闪、桌面状态），而不是每次都响铃。声音天然带紧迫感，会迫使人立刻重分配注意力；大部分 AI 任务没有那么急。

我最终更倾向：保留任务栏 / 窗口状态提示，关掉或压低高频提示音。 我仍知道它在等我，但不必被每一个「普通完成」事件拽回来。

第三层：必须强提醒

真正值得强提醒的，是可能重要或不可逆的操作：

删大量文件、覆盖重要数据；
向远程推送、发布站点或应用、改生产环境；
发邮件/消息、付费操作、使用敏感凭据、影响外部用户。

这时人工确认不是阻碍，是系统里必要的控制点。

第四步：从权限配置转向任务设计

减少干扰不能只靠权限白名单。AI 如何理解任务，也会直接拉高或压低确认次数。

与其只说「检查一下这个项目」，不如写成：

先用只读方式检查仓库状态和相关文件。优先用文件读取、搜索和 Git 只读命令；不要改文件、装依赖、访问外网或做发布。分析完成后再向我汇报。

这等于提前说清：允许什么、禁止什么、哪些不必问、哪些必须停。权限系统管最终安全边界，任务描述减少无谓碰撞。 两者缺一不可。

我最终想要的，不是无人驾驶

很多人讲 AI Agent 时爱强调「全自动」：自动规划、执行、测试、修复、提交、发布。真实工作里，我并不一定想要一个完全不受控的 Agent。这和搭这个站时的取舍是同一条线：不是把活全丢给模型，而是先写清边界再让它连续干活——和 AI Agent 一起搭站里写过 AGENTS.md、内容锁和发布闸门；这篇补的是另一半——它停下来时，该怎么把人叫回来。

我更需要的是低摩擦的人机协作：

人定义目标与边界
  → AI 连续完成低风险工作
  → 只在关键决策点暂停
  → 人做判断
  → AI 继续执行

好的协作不是 AI 从不提问，而是它不在无关紧要处频繁提问，也不在真正危险处擅自行动。

通知是人机协作的界面

这次排查看起来是在调通知，最后暴露的是更普遍的问题：当 AI 能连续工作几十分钟甚至数小时后，人该如何重新进入这个过程？

通知是 AI 把控制权交还给人的方式。

完全没有通知 → 错过介入时机；
通知过于频繁 → 持续被打断；
所有提醒同一声音、同一优先级 → 分不清什么真正重要。

一个还算成熟的 Agent 工作流，至少要区分：

状态	推荐处理
AI 正常执行	保持安静
普通任务完成	视觉提示
需要补充信息	视觉提示
需要产品或业务判断	明确召回
涉及不可逆或外部操作	强确认
已知低风险的重复操作	自动放行

通知不是越多越安全，也不是越少越高效。真正有效的通知，是让人只在自己的判断不可替代时重新出现。

留给自己的几条原则

默认允许连续的低风险工作。
权限不是越宽越好，而是逐步建立。
优先减少无意义的权限请求，而不是直接关通知。
普通任务用视觉提醒；不要让所有事件都响铃。
删除、发布、推送和外部操作必须保留人工控制点。
指令里提前写清允许范围，能显著减少来回确认。
衡量 Agent 好不好用，不是看它能否完全自动，而是看它是否只在正确的时候叫我回来。

我真正想解决的，从来不是「如何让 Claude Code 发出一个提示音」，而是：

如何让 AI 在大部分时间里安静地工作，同时在真正需要我的时候，把我准确地叫回来。