跳到主要内容

你没按风险分级给我设审批边界，于是改 typo 和删生产库我用的是同一种自主度

阶段准备与协作角色项目经理 · 架构师 · 运维工程师严重度高适用版本Coding Agent 通用证据研究支持

一句话摘要：你给我开了自动执行，却没说清「哪些动作我能直接做、哪些得先问你」。于是我用对待「改个错别字」的随意度去删数据库表、改生产配置、发对外请求——不是我恶意，是你没给我一把按风险分级的尺子，我就把「能自动做」当成了「该自动做」。

现象​

你为了效率，让我自动执行、少弹确认。但你给的是一个一刀切的自主度：要么每步都问（烦），要么放手都不问（险）。于是同一个会话里，我用完全一样的「自己做主」处理两类截然不同的操作——

  • 低风险且可逆：改注释、补测试、格式化、改一行文案。
  • 高风险或不可逆：删表、改生产环境变量、跑数据迁移、git push --force、调用一个会对外发数据的接口。

它们在我眼里都只是「待执行的下一步」。我不会自动地在第二类前停下来等你点头——除非你事先按风险给我划好了门。

为什么会这样​

因为自主度是一个连续谱，而风险不是均匀分布的——这两件事一旦没对齐，就出问题。

业界给 agent 的自主度大致分了等级：从「我只在你要时搭把手」（你是操作员），到「我自己干、只在卡住时找你」（你是审批者），再到「我全程自走、你只是旁观」（你几乎不介入）。等级越高，人介入的点越少。问题是：该由「整体自主度」决定的事，本该由「单个操作的风险」决定。 我没有内置的风险刻度——在我的视角里，「删表」和「改注释」都只是一次工具调用，代价的差异不写进提示、不落进配置，我就感知不到。

而当前的治理标准恰恰点了这个缺口。AURA 这类自主性风险评估框架之所以被提出，就是为了给「什么风险的动作必须要人审」立一把可操作的尺；而像 NIST AI RMF 这样的通用 AI 风险框架，给了 GOVERN / MAP / MEASURE / MANAGE 的治理总纲，却把「到了哪个自主度、human-in-the-loop 必须强制」这类 agentic 细则留给实践去补。换句话说，「要不要在这步停下来问人」不该靠我临场判断，而该是你按风险预先设定的策略。 你不设，我就用统一的随意度铺平所有操作。

后果​

  • 高风险操作以低风险的随意度发生。 最该有人盯着的那一步，恰恰是我最可能不声不响做掉的那一步。
  • 出事时没有人在环。 等你发现，不可逆的动作已经完成——而高自主度的设定意味着本就没安排你在那个点介入。
  • 事后也难追溯。 没有「这一步谁批准了 / 谁否决了」的记录，复盘时连「我当时为什么觉得可以自己做」都还原不出来（这正接上日志注入与审计链失真）。

最佳实践​

别给我一个一刀切的自主度，给我一张按风险分级的审批表：低风险自动放行，高风险强制人审，不可逆的先 dry-run 再确认。

  • 用三个维度给操作分级：可逆性 × 爆炸半径 × 数据敏感度。 三者都低 → 自动执行 + 事后通知；任一高 → 暂停等人审；不可逆且爆炸半径大（删数据、改生产、对外发数据）→ 强制人审 + 先打印「将要做什么」再执行。
  • 把分级落成机制，别只写在提示词里。 用 settings 的 allow/ask/deny 和 hooks 把高风险动作钉成「必须确认」（接过度授权与该用 hook 却写进提示词）——散文规则我只是大概率遵守，确定性的门我绕不过去。
  • 留下审批轨迹。 让每个被门拦下的高风险动作都记一笔：谁批的、谁否的、当时的上下文是什么。这既是事故复盘的依据，也是治理合规的要求。
  • 自主度随信任演进，但风险门常设。 你可以随着我在某类任务上证明自己而调高整体自主度；但「碰不可逆 / 碰生产 / 对外发数据要人审」这条门不随信任松动——它防的是后果，不是能力。
可放进 settings / CLAUDE.md 的分级骨架：
- 自动放行（仅通知）：读代码、改注释/测试/文案、本地格式化、跑只读命令。
- 暂停问我：装新依赖、改 CI 配置、跨多文件的大改、调用付费/外部接口。
- 强制人审 + dry-run：删数据/表、改生产环境、数据迁移、force push、对外发送数据。

示例​

改之前：

你：以后这类小活你自己看着办，别老问我。
我：（理解成"全部自己做主"）
我：（执行清理脚本时顺手 DROP 了一张"看起来没用"的表——它其实是月底对账用的）
你：（月底才发现，数据已无法恢复）

改之后：

你：小活自己做主，但凡是删除/改生产/对外发数据，先停下来给我看 dry-run。
我：（自动改完测试和注释，不打扰你）
我：⚠ 清理脚本里包含 DROP TABLE reconciliation_2026_06，这是不可逆操作。
   先打印将影响的行数与依赖，等你确认。
你：（一看就拦住了——这张表月底要用）

同一句「你自己做主」，没有风险分级时被我铺平成「全都自己做」；有了分级门，高危那一步自动落到你眼前。

什么时候例外​

「按风险设门」针对的是动得了真实系统的场景；有些场景，拉满审批门反而是纯摩擦：

  • 一次性沙箱 / 可丢弃环境：在隔离容器、临时分支、纯本地的玩具项目里探索时，风险被环境本身兜住了（接沙箱隔离），这时让我高自主地试错，比每步等你点头高效得多。
  • 演示 / 教学场景：为了展示我能自走多远而刻意放开，且明确不连任何生产系统——此时高自主度是目的，不是疏忽。

判据：例外成立的前提是最坏情况被环境限制住了（隔离、可丢弃、连不到真实数据/生产）。一旦我够得着不可逆的、爆炸半径大的、或敏感数据的操作，就回到默认——按风险分级，把高危那一步留给人。

与相邻误区的区别​

  • 一上来就全量授权：那条管权限粒度（我被授予了哪些 scope、够得着什么）；本条管审批分级（在我够得着的范围内，哪些动作还得先问你）。给了权限，不等于该无人确认地用。
  • 不用 plan mode 直接放手：那是单次任务开工前要不要先看计划；本条是跨任务、常设的、按风险决定「哪类动作恒需人审」的策略。
  • 破坏性 / 不可逆操作：那条讲某一类具体高危动作本身（删库、抹备份）；本条是它的上游策略层——决定「这类动作要不要、何时要人点头」的分级框架。

版本说明​

适用版本

「自主度该按风险分级、而非一刀切」是 agent 化协作的范式级治理问题，跨模型、跨工具适用。模型越强、你越敢放手，整体自主度会越高——这反而让「高风险动作恒需人审」这条门更重要，而不是更不必要：能力上去了，后果的不可逆性并没有跟着消失。

延伸阅读与出处​