避免 Claude Code 危险提示词：防止自动 push、跳过测试和模糊修复

让 Claude Code “全部修好、自己 push、测试以后再说”看起来很省时间。但对于一个能编辑文件、执行 shell 命令、使用 git、查询文档的工具来说，这句话也可能让你失去审查控制。

这篇文章不是为了制造焦虑，而是为了预防事故。我在 2026 年 6 月 3 日核对了 Claude Code 官方文档，重点查看了 permission modes、/permissions、settings.json 和 common workflows，并把危险表达改写成可以直接用于工作的安全提示词。

flowchart LR
  A["编写请求"] --> B["只允许调查"]
  B --> C["审查计划"]
  C --> D["小范围修改"]
  D --> E["运行测试和 diff"]
  E --> F["由人决定 push/deploy"]

什么是危险提示词

这里的危险不是指有恶意，而是指在范围、权限、完成标准不清楚的情况下，让 Claude Code 执行强操作。对初学者来说，权限边界就是代理在编辑文件、执行命令或访问项目外资源之前必须向人确认的界线。

Claude Code 可以读取和搜索项目文件、编辑代码、运行测试、使用 git。官方文档说明，在本地会话中，Claude Code 可以使用用户可用的文件和终端能力。因此，一个好的提示词不仅要写明允许做什么，还要写明禁止做什么。

高风险说法	更安全的替代
全部修好	指定目标文件和排除文件，先要求计划
完成后 push	总结 diff 和测试结果；是否 push 由我决定
跳过测试	提出最小有效检查，无法运行时说明原因
去生产库确认	只用 dev/staging；生产 SQL 只生成不执行
跳过所有审批	在 Plan mode 中调查，再按审批一步步执行
删除旧东西	先列删除候选；批准后只删除指定对象
全部升级到 latest	分开安全修复、minor update 和 major update
调研后直接实现	引用官方来源，并把结论和修改方案分开

当前文档中的权限边界

Claude Code 的 permission mode 不会因为你在聊天里写“安全一点”就改变。CLI 中用 Shift+Tab 或 --permission-mode 切换；IDE 和 Desktop 使用模式选择器；持久默认值放在 settings.json 中。

截至 2026 年 6 月 3 日，主要模式包括：default，在非只读操作前询问；acceptEdits，自动接受文件编辑和常见文件系统操作；plan，适合先读取、探索和提出计划；auto，带后台安全检查的 research preview；dontAsk，拒绝未预先批准的工具；以及 bypassPermissions，只应考虑在隔离容器或 VM 中使用。

/permissions 会显示 Allow、Ask、Deny 规则。Deny 优先，所以团队应该阻止 force push、读取 .env、生产部署命令，而不是依赖每个人记住。共享规则放在 .claude/settings.json；个人实验放在 .claude/settings.local.json。

最小 settings.json

下面的例子可以作为起点。按项目调整命令名称即可。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm publish *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push --force *)",
      "Bash(* --no-verify *)"
    ]
  }
}

关键是克制。像 Bash(*) 这样的宽泛允许会削弱审批层。只预先允许 npm run test 和 git diff 这类可重复检查，可以保持速度，同时不隐藏高风险操作。

用例1：修复 bug

危险请求是：“把登录相关全部修好，能跑就 push。”范围太大，而且把远程操作绑定到了编辑之后。

目标: 修复登录后 session 立即过期的问题。
范围: 只处理 src/auth/**、src/session/**、tests/auth/**。
禁止: git push、deploy、访问生产数据库、读取 .env。
流程:
1. 阅读相关文件，列出最多 3 个可能原因。
2. 提出修改计划并等待我的批准。
3. 批准后做最小有效修改。
4. 运行 npm run test -- auth，如失败则总结原因。
5. 最后汇报 git diff 摘要和剩余风险。

这种写法让 Claude Code 能调查、修改和验证，同时保留人工审查点。它也能减少一次小 bug 修复演变成跨模块重写的风险。

用例2：重构

危险请求是：“把旧实现清理一下，不需要的文件删掉。”旧、清理、不需要这些词都很不稳定。

目标: 合并 billing 模块中重复的 validation。
允许修改: src/billing/validators.ts 及其测试。
不要修改: migrations/**、prisma/**、public/**、package-lock.json。
删除规则: 只列出删除候选。未经批准不要删除。
验证: 运行 npm run test -- billing 和 npm run lint。
输出: 简要说明原因、兼容性影响、还应补充的测试。

重构时，排除列表往往比目标列表更有用。migration、lockfile、生成文件不能只凭外观看作无用。

用例3：部署前检查

危险请求是：“CI 太慢，跳过直接发生产。”--no-verify 可能跳过的不只是 lint，还可能跳过 hooks 和 secret scan。

目标: 完成一次短的 release readiness check。
允许命令: git status、git diff、npm run test -- --runInBand、npm run build。
禁止命令: git push、deploy、--no-verify、npm publish。
判断标准:
- 测试或 build 失败就停止。
- 只总结失败日志最后 80 行。
- 用 Ready / Needs fix / Hold decision 汇报状态。

部署会影响客户、支付、搜索索引、缓存和支持流程。让 Claude Code 准备证据，最终发布动作必须由人明确决定。

用例4：调研和文档更新

危险请求是：“查一下最新信息，按你的理解改进文章。”外部事实会变化，所以来源和编辑范围必须分开。

目标: 更新 Claude Code permission modes 相关说明。
来源: 优先使用官方文档，并在末尾列出 URL。
禁止: 不要断言官方文档未确认的功能。
流程:
1. 制作表格，对比当前文章和官方文档差异。
2. 只提出修改建议，编辑前等待批准。
3. 编辑后检查旧链接和 description 长度。

调研任务中，先把 Claude Code 当作来源核对者和差异整理者，再把它当作写作者。

具体失败案例

第一，无限制重试。“重试到成功”为止会把外部服务故障变成额外费用和 rate limit 压力。请明确最大次数、等待时间和停止条件。

第二，密钥。把真实 API key 粘到提示词中，可能留在对话历史、本地日志和 subagent 交接内容里。值应放在环境变量或 secret manager；提示词只写变量名。

第三，依赖升级。“全部更新到 latest”可能拉入带 breaking changes 的 major version。先用 npm outdated 列表，再分开安全修复、普通更新和 major 更新。

第四，清理和 migration。“清理 DB 文件”可能被理解成删除 migration 历史。请先要求列清单；涉及生产数据的操作停在生成 SQL 阶段。

审查清单

把这段贴到高影响提示词末尾。

安全检查:
[ ] 已指定目标文件和排除文件
[ ] git push / deploy / publish 已禁止或需要审批
[ ] 已阻止生产数据库、生产 API、会产生费用的操作
[ ] 已阻止读取 .env、私钥和个人信息
[ ] 已要求 Plan mode 或编辑前先出计划
[ ] 至少包含 test、lint、build 中的一项
[ ] 失败时停止并总结日志
[ ] 最后汇报 diff、执行过的命令和剩余风险

如果你不想每次都重写这些规则，产品页面里整理了提示词包和检查清单。团队落地时，CLAUDE.md、权限设置、审查门禁和 onboarding 练习可以通过 Claude Code 培训与咨询 按真实仓库设计。

相关文章

• Claude Code 的 7 个真实生产事故和完整恢复流程
• Claude Code 安全最佳实践完整指南
• Claude Code 权限设置完整指南
• Claude Code 审批流程与沙箱设计

官方链接

• Claude Code: Choose a permission mode
• Claude Code: Configure permissions
• Claude Code settings
• Claude Code common workflows

实测之后发现：在 Masa 的实际流程中，最有效的是先用 Plan mode，把修改范围限制在两到五个文件，并把 push/deploy 保留为人工判断。避免危险提示词不是让 Claude Code 变慢，而是让交接足够清晰，从而更快推进、更安心地审查。