1. 人在循环还是人在看戏Claude Code 的权限机制现状我第一次给终端接上 Claude Code 的时候下意识做了一件反直觉的事——把 autoAccept 关掉然后全程盯着它跑命令一个确认键都不敢漏。那时候我还抱着旧习惯AI 只是我的补全工具它动一下手我就得验一次货。但跑了不到半天我就发现这套思路根本不可持续。它改一个文件要弹一次确认跑一条测试要弹一次确认十分钟下来我的手指比写代码还累而且整个协作节奏被切得稀碎。真正让我意识到问题严重的是那天它连续改了七个文件我点了七次接受到第四次的时候我其实已经没仔细看 diff 了——我只是在机械地按键。这其实就是人机结对编程里最核心的问题决策权到底该给谁。传统结对编程是两个人一个 Navigator 一个 Driver决策权靠语言和默契实时切换现在对面坐的是一个语言模型它的决策边界、置信度、知识盲区都是动态的你没法用眼神给它示意也来不及在每个瞬间都解释上下文。如果你把所有决策都攥在自己手里那 AI 的价值就退化成一个会打字的搜索引擎如果你全盘放手它又可能在某个语义死角里把一个不该删的模块剁了。所以决策权分配不是一种偏好而是人机协作能不能落地的前提。拿 Claude Code 这个工具本身来说它之所以值得聊是因为它比普通 AI 辅助编码工具往前多走了一步它能读整个仓库、能执行终端命令、能改文件、能跑测试它实际上是一个住在你命令行里的智能体而不仅是 IDE 里的一行补全。正因如此它带来的风险也比补全一个函数大得多。它手里有三把钥匙读代码的钥匙、改文件的钥匙、执行命令的钥匙。三把钥匙串在一起就是完整的改你代码的能力。而我们聊的决策权分配本质上就是在决定这三把钥匙分别在什么场景下递出去、递到什么程度、什么时候必须收回来。我在团队里见过两种极端。一种是把 Claude Code 当成自动驾驶跑起来之后根本不看结果它把测试文件里一段重要的 mock 数据按无用代码清掉了CI 挂了整整一个下午。另一种是把它当打字员每一步都要人工批准结果产出质量太依赖人而人的注意力恰恰是最稀缺的资源半天之后人的审查质量直线下降和小模型生成的低质量代码没有本质区别。这两个方向都是同一个病根没有把决策权分层没有想清楚哪些决策适合模型自主、哪些必须人工兜底、哪些需要按条件动态切换。本文就围绕这个病根展开把我自己从盯防模式调整到分工模式过程中的思路、配置和踩坑记录完整写出来给同样在接 Claude Code 或类似编程智能体的人做一个参考。2. 配置背后的博弈autoAccept、权限模式与对话框里的阶级关系很多人第一次接触 Claude Code 的权限设置都会觉得这就是几个开关开得越大越危险关得越小越安全。我一开始也这么认为直到我把各种模式跑了一圈才意识到这些开关不只是安全阀门它们实际上是人与模型决策权分配的静态映射。你选哪种模式等于在告诉模型哪些层面你有自主权哪些层面你只是提案者。Claude Code 在交互上主要区分两类动作一类是改文件Edit包括写新文件和修改已有文件一类是跑命令Bash Command包括执行测试、安装依赖、Git 操作等。这两类动作对应的权限配置直接决定了模型是动手者还是提建议者。2.1 三种权限模式的实际行为差异官方其实提供了一条从严格到宽松的权限光谱我实测下来的行为是这样的模式配置方式模型能做什么你被迫要看什么适合的阶段normal默认不需要额外配置能读文件、能给出修改方案但每次改动前都要征得同意每一个编辑和命令第一次接触、代码库不熟、涉及核心业务逻辑acceptEdits启动时加--permission-mode acceptEdits或会话中切换文件修改自动接受但执行命令仍需确认命令输出、命令副作用已经信任模型对代码风格的判断但还担心外部副作用bypassPermissions启动时加--permission-mode bypassPermissions改文件、执行命令全部自动放行几乎不用看但事后要查沙箱环境、一次性脚本、完全可回滚的场景这里有个特别容易被误解的点acceptEdits 并不等于危险它只是把文件编辑这个低频高风险动作和命令执行这个高频高副作用动作分开了。我在做代码重构时非常依赖 acceptEdits——因为我需要模型连续改十几个文件如果每个文件都弹确认整个重构的上下文就断了。模型的短期记忆再强也架不住人每十秒打断它一次。但命令执行我通常保持确认因为命令的副作用是不可预测的模型可能为了装一个包顺手把环境里的 Python 版本换了。2.2 权限提示符夹在人类和模型中间的裁判Claude Code 在等待你决策时会显示一个 提示符这个细节很容易被忽略但它就是整个决策权机制的咽喉。它会区分几类动作编辑文件、执行命令、调用某个工具。你在这个提示符下的每一次回车都是一次决策权的转移声明。我后来给自己定了一个规则文件编辑看 git diff 的前 30 行命令执行先看命令本身再想副作用其余细枝末节不多想。因为人不可能对每个动作保持同等注意力与其硬撑着看完全部不如把精力留给真正有风险的部分。我见过有人把autoAccept打开后就完全把终端最小化了。这等于把决策权全部交出去但事后又抱怨模型乱改代码。这不是模型的错是配置和场景不匹配。决策权不是一次给完的而是像授权书一样可以限定范围、限定时间、限定目录。我自己的习惯是进入一个大型重构任务时明确告诉模型这个仓库的 src/modules/order 目录你可以直接改但 src/core 目录只准看不准动然后配合权限模式把物理边界变成模型的行为边界。2.3 对话中的隐性授权比配置更危险这里必须说一个配置之外的问题模型在对话里会捕捉你的语气和措辞把你可以自己看着办理解成一种授权信号。有一次我想让它帮我清掉几个 TODO我随口说了一句你看着处理吧它直接把一个废弃模块里关联的三四个文件全删了。我当时没意识到我在自然语言里泄露了太多决策权而这种授权是权限模式捕捉不到的——它发生在语义层面而不是工具层面。所以我后来会在 CLAUDE.md 里写死一条除非我明确说执行否则所有涉及删除文件的操作都必须先给我看清单。这条规则比任何模式开关都管用。实操建议如果你想循序渐进地找到适合自己的授权粒度我建议从 normal 模式开始跑一周记录自己最常确认的三类动作然后针对这三类动作里的低风险项逐步开放 acceptEdits 或 bypassPermissions。不要一步跨到最大权限除非你有一个随时能恢复的干净环境。3. 把决策权显性化我在实战中打磨出的三层授权模型权限模式解决的是工具层面让不让动的问题但真正决定协作质量的是你在任务层面怎么分配决策权。我经过几个项目的磨合慢慢形成了一套三层授权模型。这套模型的核心思想很简单授权不等于弃权而是把人的注意力集中在模型做不好的决策上。每一层对应一种任务类型每种任务类型对应一种权限策略和审查策略。3.1 第一层探索与只读——把地图给模型但把笔留在自己手里第一层适用于所有理解型任务让模型读代码、梳理调用链、解释某个模块的设计意图、找 bug 线索、对比实现方案。这一层我给它最大限度的自由Claude Code 默认就能做不需要额外授权。它读文件、搜代码、画调用链这些都是零副作用的动作就算读错也不会造成破坏。但这一层有一个管理细节模型的阅读范围需要被约束。如果你让它看一遍这个项目然后告诉我哪里有问题它可能会翻遍整个代码库最后给你一份覆盖所有模块的泛泛总结——既不深入也没重点。正确做法是给它锚点指定目录、指定函数名、指定某次 commit 的范围。比如我会说只看 src/services/payment 目录下与退款相关的调用链忽略测试文件这样它就聚焦了。这个层级的决策权分配策略本质上是信息检索权全部下放但检索范围的设定权留在人手里。因为它泛读能力再强也架不住问题本身问得模糊。3.2 第二层提案与执行——让模型动手但要先交方案第二层适用于实现型任务新增功能、修 bug、重构、迁移代码。这一层是决策权分配的主战场也是最多人拿不准的地方。我的做法是要求模型先输出改动方案包括涉及的文件清单、每个文件改动什么、关键风险点然后我再决定放不放行。这样做不是为了流程好看而是因为方案阶段可以让模型暴露它的理解人有机会在动手之前纠偏。举个例子我让 Claude Code 修复一个订单超时未支付的问题。它最初的设计是在订单 Service 里加一个定时轮询。我看完方案就知道方向错了——这个项目已经有消息队列应该用延迟消息而不是轮询。如果我让它直接改代码改完再 review那等于把方向性的大决策也交给它了返工成本极高。而方案先行大决策留给人执行层面的小决策变量命名、代码结构、单元测试怎么写留给它协作就顺了。这一层我使用的权限配置是 acceptEdits 加命令需要确认。模型改文件我不拦但跑测试和改依赖的命令必须经过我确认。因为测试执行和依赖安装是外部行为它们会改变系统状态、拖慢时间而且模型对跑出一条失败测试是否值得的判断经常不靠谱。3.3 第三层护航自主——信任靠验证建立不自证第三层适用于模型已经验证过能力边界的高频任务比如按既有代码风格生成重复性组件、写单元测试模板、批量重命名变量、格式化代码。这些任务如果每次都要人逐行确认是对双方效率的浪费。我会针对这些任务开放 bypassPermissions让它一口气做完。但这层有个铁律开放自主权的前提是可回滚。我会在让它批量改动前先确保当前分支是一个干净的 git 状态留一个能随时恢复的 checkpoint。它跑完我看 diff 的统计信息而不是每一行。所谓护航自主说白了不是信任模型而是建立了一个意外兜底机制出了岔子我能秒回滚损失可控才敢放手。三层模型用表格总结一下就是层级任务类型模型决策范围人工决策范围常用权限模式探索层阅读理解、方案分析读什么、怎么读、总结哪些读的范围、问题定义normal执行层实现功能、修复 bug代码怎么写、测试怎么补方案是否可行、是否涉及外部副作用acceptEdits自主层重复性、可回滚任务直接用最佳实践完成验收、回滚决策bypassPermissions这套模型的核心价值不是给出一个标准答案而是强迫我把哪些决策我必须在场这个问题想清楚。很多协作翻车根源不是 AI 太笨而是人压根没想清楚自己应该守在哪一层。4. 一次真实的失控复盘当 AI 的自作主张滚成了生产事故理论讲再多不如一个真实翻车案例让人长记性。下面这个事故不是编的是我在一个内部项目上真真切切踩过的坑也是我后来下定决心写 CLAUDE.md 权限边界条款的直接导火索。4.1 事故背景与第一现场我负责一个订单服务代码里有一段定时任务注册逻辑通过Scheduled注解启动每天凌晨三点跑一次做超时订单的自动关单。当时 Claude Code 在帮我做一次陈旧代码清理——我给它下达的任务是把 src/main/java/com/example/order 下面没有引用的方法清理掉但保留所有带 Scheduled 和 EventListener 注解的方法。任务下得已经很明确了但我犯了一个致命错误我把它放在 bypassPermissions 模式下跑因为当时的改动看起来都是低风险清理。它花了两分钟改了九个文件全部自动放行。我扫了一眼 diff 统计300 行删除、80 行新增没有异常就让它继续了。第二天上线后凌晨三点的超时关单任务没有执行——它静默消失了。4.2 排查链路找到失控的那一环我们的第一反应是查服务日志发现定时任务根本没有触发注册类OrderTimeoutScheduler压根没被加载。然后查 git 历史发现 Claude Code 把调度器类整个删了原因是静态分析显示这个类没有任何引用——Java 的反射机制和框架注解驱动的注册方式静态调用链分析根本看不到。模型按照没有引用就是死代码的逻辑把它判定为可清理项。这里有两层问题。第一层是技术层面模型的调用图分析基于符号引用而不是框架的运行时行为这在 Spring 这类反射驱动框架里特别容易误判。第二层是决策权分配层面我在任务描述里给了它一个过滤器保留带注解的方法但它在实际操作中认为调度器类整体没有直接引用比过滤器优先级更高于是把整个类连带注解一起删了。4.3 事故链条拆解我在哪个环节放弃了守卫回顾整个链条真正的问题不是AI 删错了文件而是我在三个环节都放权过度了第一我用了 bypassPermissions等于放弃了逐动作确认的可能把是否删除某个文件的最终决定权全部交给了模型。第二我只看了 diff 统计没有看具体删除了哪几个类和注释。如果当时打开 diff 看类名列表这个调度器类的删除是绝对显眼的——它有一百多行删了不可能毫无察觉。第三我任务里的过滤器是黑名单式的保留某些东西而不是白名单式的只允许清理某些东西。黑名单式的授权在边界外的所有东西都是默认放行这对模型来说其实是巨大的自由度。修复本身不难git revert 到上一个干净提交把文件恢复再补一个回归测试确保调度器能被加载。但真正让我反思的是清理陈旧代码这种任务听起来低风险实际上因为它的改动范围横跨整个包反而放大了模型的误判可能。每个决策的风险不是由动作本身的类型决定的而是由动作发生的上下文决定的。批量删除动作在任何上下文里都是高风险因为单个误判的代价被批量操作的规模放大了。从那以后我给自己定了三条硬性规范涉及删除文件的操作一律不让模型自主决定凡是模型要删除的文件必须先输出清单等我确认任何清理任务都不允许在 bypassPermissions 下运行。这些规范我写进了 CLAUDE.md让它每次开工前都先读到这些约束——不是靠我嘴巴提醒而是靠工具层面的强制策略。5. 决策权的边界哪些事永远不该交给模型前面讲的三层授权模型解决的是在安全的任务里分权但经历过事故之后我发现更重要的其实是反向问题哪些决策无论模型有多强都应该留在人手里。这不是能力问题而是决策类型本身的属性决定的。我把这些场景梳理成了四类也称之为否决清单。5.1 外部副作用型决策不只是写代码的问题模型能访问的只有你的代码库和执行环境它对代码库之外的世界一无所知。所以任何会产生外部副作用的决策都必须由人来定。典型例子包括发送真实的 HTTP 请求到生产环境接口操作数据库的数据变更尤其是 DELETE 和批量 UPDATE直接调用支付、短信、邮件等第三方服务发布 npm 包、打 tag、推送到生产分支修改 CI/CD 配置我见过一个案例同事让 Claude Code 调试一个接口返回异常的问题模型为了复现问题直接对着生产环境的 URL 发了几十条测试请求。虽然只是 GET 请求没造成破坏但这类行为一旦失控节奏就不是人能追上的了。所以我在 CLAUDE.md 里直接列了一条生产环境地址默认视为不可访问资源任何涉及生产域名的操作都必须先由人工确认。模型读到了这条约束就会在行动前停下把决定权还给我。5.2 信息不对称型决策模型看不到全局凭什么替你拍板模型虽然能读整个仓库但它的全局视野是上下文窗口内的全局不是业务层面的全局。很多决策依赖的信息根本不在代码里——比如客户合同的约束、合规要求、某段代码为什么写成这样这些背景信息只存在于人的脑子里。如果模型基于局部上下文做判断大概率会在它不知道的盲区里翻车。我在一个支付对接项目里就遇到过Claude Code 建议把某个旧接口替换成新接口原因是新接口在文档里标记为推荐看起来功能完全兼容。但它不知道旧接口被我们用来兼容一个老客户的私有协议这个客户没有迁移意愿。这个决策包含了商务层面、客户关系层面的信息模型根本无从知晓。所以我把这类决策也列入否决清单涉及接口契约变更、数据格式变更、公共 API 兼容性的决策人必须参与。模型可以做方案对比但最终拍板权不能给出去。5.3 安全凭据与身份型决策权限越大越要小心Claude Code 在执行命令时用的就是你的 shell 权限。如果模型拿到的是生产环境密钥它就可能在自己都不知道后果的情况下执行一系列危险操作。我在本地开发时习惯把环境变量加载到.env文件里Claude Code 出于安全设计不会主动读取密钥文件但如果你在对话里贴了一段含密钥的日志后面所有指令的上下文就都被污染了。我的建议是任何涉及密钥、Token、证书处理的操作都应该做隔离。比如让模型检查环境变量配置只让它看配置文件里的键名不要让它看到值让模型执行需要凭据的命令时用环境变量传递而不是明文写在命令里。更关键的是一旦你发现上下文里出现了敏感信息马上清理会话或轮换密钥不要嫌麻烦。决策权分配的前提是信息可控给了太lao权限的模型再加上一把钥匙后果可能是爆炸性的。5.4 道德与体验型决策代码背后的用户感受最后这一条容易被技术人忽略模型优化的目标是完成指令而不是对用户负责。当一个需求涉及到产品体验取舍、内容表达、面向用户的文案时模型倾向于按照最标准的写法输出但标准不等于合适。比如让模型写一个错误提示它可能会写出系统内部错误请稍后重试这种正确但冷漠的话而一个有经验的开发者会考虑到用户此刻的挫败感给出更有人情味的引导。虽然这类决策在纯技术场景里不多见但只要你在做面向用户的软件就一定绕不开。我的处理方式是把体验类决策划入人的专属决策区模型只负责提供候选文案或方案不负责最终选择。人机协作的底线是人要把控产品对外呈现什么样子这个决策不能随手交给模型否则产品会越来越像模板拼接出来的产物失去人格化的温度。6. 更少确认更高质量把决策权分配方案焊进工作流说完边界回到实用的层面。很多人觉得决策权分配听起来是哲学问题不落地。实际上它是可以通过 CLAUDE.md、目录约束和工具配置落地的。下面这套是我目前每天都在用的工作流你可以直接抄作业再根据自己的项目微调。6.1 CLAUDE.md把授权范围写进模型的开机自检Claude Code 每次启动都会自动读取项目根目录的 CLAUDE.md把它当作用户给它的最高指导原则。这个文件的优势是它不依赖你在每次对话里重复交代而是模型每次开工前都会读一遍。所以我的 CLAUDE.md 里除了项目说明、技术栈介绍专门有一大段是权限与决策边界内容包括我前面说的否决清单和三层授权模型的要求。一个实用的示例片段长这样# 决策边界 1. 本仓库中所有删除文件的操作必须先列出完整文件清单等待用户明确确认后才能执行。 2. src/core 目录为只读目录只能分析不允许修改。 3. 涉及执行外部命令时需要先说明命令目的和潜在影响等待用户确认。 4. 生产环境域名、数据库地址默认不可访问。 5. 清理任务必须使用 normal 权限模式运行不允许 bypassPermissions 下批量删除。 6. 涉及公共接口签名变更时必须先给出迁移方案由用户决定是否执行。我建议你把这份清单写得越具体越好最好精确到目录名、代码模块名。模型对具体指令的遵循程度远高于对抽象原则的理解程度。它不懂不该乱删但它懂src/core 目录只能读。6.2 关键目录加锁与最小化执行范围Claude Code 虽然不直接提供目录级 ACL但你可以通过两种方式实现类似效果一种是在 CLAUDE.md 里声明限制另一种是在启动命令里限定工作路径。如果项目里有绝对不能动的目录比如包含安全校验的核心模块、包含数据库迁移脚本的目录我会在 CLAUDE.md 里标注为只读或需要单独授权。同时在给模型下达任务时尽量把执行范围收窄。不要让它优化整个项目的代码质量而是优化 src/utils/string-helper.ts 里的函数实现。范围越小模型的决策空间越小人的审查成本越低。这其实是在决策权分配里用物理手段压缩模型的自由度比任何权限配置都直接。6.3 提案制 prompt 模板把执行权申请变成固定流程我在前文提到方案先行这里给一个可直接复制的模板。每当我需要模型做实现型任务时我会在 prompt 里这样写在你开始修改代码之前请先完成以下输出 1. 问题诊断你理解的当前问题是什么 2. 修改方案你计划改动哪些文件每个文件改什么 3. 风险评估哪些改动可能影响现有功能你打算如何验证 4. 执行顺序你准备按什么顺序执行这些改动 在我明确回复开始之前请不要修改任何文件。这个模板的本质是把一次大授权拆成两次小授权第一次是允许你分析第二次是允许你动手。模型在分析阶段拿到的信息越多、思考得越充分执行阶段犯错的概率就越低。我实测下来这套模板带来的额外成本大约是一分钟的方案等待但省下的返工时间和排查时间远超这个数字。6.4 事后审查用 git diff 的统计信息代替逐行盯防很多人以为不逐行看 diff 就是不负责但人的注意力是有限的逐行盯防半小时后就会出现严重的视觉疲劳。我的习惯是分层审查第一步看git diff --stat确认文件数量在合理范围新增删除行数没有异常悬殊。如果一次改动删了两千行首先要问为什么。第二步看git diff中删除的行因为删除比新增更容易隐藏问题。第三步只看模型给出的 commit message 和它的自述总结把它说的和实际改的对比一下——模型经常忘了提它做了某些操作这种遗漏本身就是风险信号。这些步骤加起来的成本不到两分钟但能覆盖绝大多数失控场景。我把这个过程叫抽样审查它的理念和代码评审里的抽样是一个道理不是每行都要看但关键的删除点和高风险点必须覆盖。决策权分级分配的最后一道防线永远是人的注意力要用在刀刃上。做完了这些人机结对编程才能真正称得上协作而不是监工与苦力的畸形关系。我现在和 Claude Code 配合的核心感受是模型越强人越要清楚自己在协作里的角色是定方向的而不是打字的。决策权分配不是放权多少的问题而是人的判断力该用在哪里的问题。把高价值决策留在自己手里把低价值执行交给模型这才是协作效率的真实来源。