CCClaude Code中文喂饭教程

权限模式实战：default、plan、auto、dontAsk 怎么选

权限模式不是越开放越高效。陌生项目用 plan，普通任务用 default，范围确认后考虑 acceptEdits，长任务评估 auto，CI 用 dontAsk，bypassPermissions 只留给隔离环境。

教程基准：Claude Code v2.1.224（当前最新版，核验于 2026-08-07） · 最后核验：2026-08-07 · 适用版本：建议使用最新版 · 官方文档

密钥安全

权限模式决定 CC 什么时候能自己做、什么时候必须停下来问。专业使用不是永远拒绝，也不是一路批准，而是根据任务风险选择合适模式。

先记住这个默认策略：

陌生项目先 plan -> 日常任务用 default -> 范围明确后 acceptEdits -> 高风险操作坚持人工审批

如果当前版本提供 auto 和 dontAsk，再补充一条：交互式长任务可以评估 auto；非交互 CI 使用 dontAsk 加精确 allowlist。它们不是 acceptEdits 或 bypassPermissions 的别名。

场景 1：刚打开陌生项目

推荐：plan

原因：还不知道项目结构、启动方式、生成产物、敏感目录，不能直接放开修改。

这是一个我还不熟悉的项目。

请只读分析：
1. 项目主要技术栈。
2. 关键目录和入口文件。
3. 可能的生成产物目录。
4. 常见检查方式。
5. 哪些文件修改风险较高。

不要修改文件，不要运行高风险命令。

什么时候可以离开 plan：

场景 2：普通小任务

推荐：default

比如改文案、补 README、修一个明确样式问题。default 会让 CC 在读文件时更顺畅，但编辑和命令仍然会询问。

请修复这个页面文案问题。

范围：
1. 只修改当前页面相关文件。
2. 不改全局样式。
3. 不运行无关命令。

修改前先说明准备改哪个文件。

批准权限时看两点：

  1. 文件是不是任务相关。
  2. 操作是不是可回滚。

场景 3：范围已经确认的小范围修改

推荐：acceptEdits

当计划已经明确、只涉及少量文件、用户准备最后审查 diff 时，可以考虑 acceptEdits。

适合：

不适合：

使用前先说：

可以进入 acceptEdits，但只限本次已确认范围。

限制：
1. 只修改计划中列出的文件。
2. 不新增依赖。
3. 不修改配置、密钥、部署文件。
4. 修改后必须解释 diff。
5. 如果需要扩大范围，先停下来问我。

场景 4：低风险长任务

推荐：acceptEdits（配合严格边界）

同样是 acceptEdits，但用在低风险、重复性、范围清楚的长任务上，比如批量补文档链接、更新表格序号、修复多处同类文案。它不是一个更"自动"的独立模式，关键在于提前把边界说死。

不适合：

使用前要设置边界：

这次可以按低风险自动流程推进，但必须遵守：
1. 只处理文档和链接更新。
2. 不修改业务逻辑。
3. 不新增依赖。
4. 不执行 Git 写操作。
5. 每完成一组修改就总结变更。
6. 最后必须运行构建并检查学习路线是否断档。

场景 5：什么时候不要用 bypassPermissions

日常项目不要用 bypassPermissions。

它只适合隔离环境，例如：

即使在沙箱，也要让 CC 说明它准备做什么。

场景 6：长任务什么时候考虑 auto

场景：在独立分支中批量补测试，任务边界和验收命令已经确定，希望减少反复批准，但不能接受跳过安全检查。

推荐：账号和入口支持时使用 auto，并保留明确的 deny 规则。开始前仍要确认工作区没有无关修改、任务不需要生产凭据、允许修改的目录已经写清、最终测试命令可以重复运行。

auto 减少的是批准疲劳，不是 diff 审查。中途要查看任务状态，结束时仍需检查完整 diff 和验证证据。

场景 7：CI 为什么更适合 dontAsk

CI 没有人替你点击批准。dontAsk 会执行 allowlist 中预先批准的工具，其余需要询问的动作直接失败，因此行为比“遇到什么都放行”更可预测。

适合允许：读取源码、运行已有 lint、test、build。默认拒绝：安装未知依赖、写发布配置、访问生产服务、Git push。第一次配置应在临时分支验证，并确保被拒绝时任务明确失败。

权限模式选择表

任务推荐模式原因
第一次看陌生项目plan先只读理解结构
修明确文案default风险低，但仍保留审批
已确认的单文件样式修改acceptEdits可以提高效率，最后审 diff
批量文档整理acceptEdits范围清晰、低风险、可构建验证
独立分支中的长任务auto后台安全检查减少弹窗，仍需最终审查
只运行固定检查的 CIdontAsk只执行 allowlist，其他动作直接失败
排查未知 Bugplan -> default先定位，再最小修复
涉及密钥、部署、数据库plan/default保守审批
真实生产项目高风险操作不建议放开必须人工确认

模式选错了怎么办

如果发现权限太大，立刻收回到只读或 plan。

当前权限模式可能过于开放，请暂停。

从现在开始：
1. 不再修改文件。
2. 只读检查当前 diff。
3. 列出已经修改的文件。
4. 判断是否有越界修改。
5. 给出收敛方案。

如果权限太保守，任务卡住，也不要盲目放开：

当前任务被权限卡住。

请说明：
1. 卡在哪个动作。
2. 为什么必须做这个动作。
3. 有没有只读或更小范围替代方案。
4. 如果批准，影响范围是什么。
5. 批准后如何复查结果。

验收结果

下一篇：密钥安全