让 Claude Code 接手项目前，先做这 4 个安全配置

这是一篇基于 XDA Developers 文章整理的分享教程。原文重点是：不要把 Claude Code 当成“直接开工的聊天机器人”，而要先给它上下文、权限边界、计划流程和模型策略。

来源与边界

原文事实

原文标题：4 Claude Code settings I change before letting it touch a project
原文链接：https://www.xda-developers.com/claude-code-settings-i-change-before-letting-it-touch-a-project/
来源：XDA Developers
发布时间：2026-05-30
原文提到的工具与命令：Claude Code、/init、/permissions、Shift+Tab、/model opusplan、/effort
原文未提供 GitHub 仓库

本文提炼

这篇文章可以提炼成一个适合团队内部分享的原则：

让 AI 编码助手写代码之前，先把“上下文、权限、计划、模型”四件事配置清楚。

否则，AI 很容易出现两类问题：

不理解项目约定，改出看似正确但不符合团队规范的代码。
权限边界不清，要么频繁打断确认，要么一次性放权过大。

实践扩展

下面的教程把原文观点改造成一个可落地的项目接入流程。示例文件是通用模板，适合在真实项目中按需改写。

---

适用场景

适合：

你准备让 Claude Code 参与一个已有项目。
项目里有明确的技术栈、测试命令、安全红线。
团队希望 AI 先提方案，再动代码。
你不想每条无害命令都手动确认，也不想直接跳过所有权限。

不适合：

临时一次性脚本，且没有长期维护价值。
没有版本控制、没有测试、也没有回滚路径的生产目录。
需要直接访问生产数据库、生产 K8s、密钥文件的高风险任务。

---

总体流程

在项目根目录生成或补齐 CLAUDE.md。
配置 .claude/settings.json，定义允许、询问、拒绝规则。
默认用计划模式启动，让 AI 先读项目、写方案。
按任务复杂度选择模型和推理预算。
每次执行前做一个小型安全检查。

---

第 1 步：用 CLAUDE.md 给 AI 项目上下文

原文建议用 /init 初始化 CLAUDE.md。它的作用类似“给新同事的项目入门说明”。

cd your-project
claude
/init

如果你不想完全依赖自动生成，可以手动维护一个最小模板：

# CLAUDE.md

## Project

This is a Python automation service.

## Tech stack

- Python 3.13
- uv
- pytest
- ruff

## Common commands

uv sync uv run pytest -q uv run ruff check .


## Coding rules

- Add type annotations for new functions.
- Use logging, not print.
- Do not hardcode secrets.
- Keep functions small and readable.

## Safety boundaries

- Do not edit `.env`.
- Do not run destructive database commands.
- Ask before changing CI, deployment, or infrastructure files.
- Run tests before claiming the task is complete.

预期效果：Claude Code 每次进入项目时都有稳定上下文，不需要从零猜测项目结构和团队习惯。

验证标准：

文件位于项目根目录。
包含技术栈、常用命令、编码规范、安全边界。
禁止项写得具体，例如 .env、生产数据库、部署文件，而不是只写“注意安全”。

---

第 2 步：用 settings.json 配权限边界

原文反对两个极端：

每次都手动确认，效率很差。
直接使用 --dangerously-skip-permissions，风险过大。

更实际的方式是配置细粒度权限。

创建目录和配置文件：

mkdir -p .claude
${EDITOR:-vi} .claude/settings.json

示例配置：

{
  "permissions": {
    "allow": [
      "Bash(uv run pytest*)",
      "Bash(uv run ruff check*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Read(*)"
    ],
    "ask": [
      "Edit(*)",
      "Bash(uv add*)",
      "Bash(git commit*)"
    ],
    "deny": [
      "Read(.env*)",
      "Edit(.env*)",
      "Bash(rm -rf*)",
      "Bash(kubectl delete*)",
      "Bash(psql*DROP*)"
    ]
  }
}

配置思路：

allow：只放低风险、可重复、只读或验证类命令。
ask：放会修改文件、依赖、提交历史的动作。
deny：放密钥、破坏性命令、生产高风险操作。

验证配置语法：

python3 -m json.tool .claude/settings.json >/dev/null

预期输出：没有输出，退出码为 0。

失败示例：如果 JSON 少了逗号或引号，命令会报解析错误，应先修正再让 Claude Code 使用。

---

第 3 步：默认先用计划模式

原文建议：不要让 AI 一上来就修改代码。先进入计划模式，让它只能读取和分析。

常见操作方式：

在 Claude Code 里用 Shift+Tab 切换计划模式。
让 AI 先输出任务理解、影响范围、修改文件、验证命令。
人确认方案后，再允许执行写入。

可以给 Claude Code 这样的开场提示：

先不要修改文件。请只读取项目，输出：
1. 你对问题的理解
2. 计划修改的文件
3. 每个修改的理由
4. 需要运行的验证命令
5. 你不会触碰的边界

一个合格计划应该长这样：

计划：
- 读取 src/auth.py 和 tests/test_auth.py，确认失败路径。
- 新增一个回归测试，覆盖 token 为空的场景。
- 修改 src/auth.py 的输入校验逻辑。
- 运行 uv run pytest tests/test_auth.py -q。
不会修改：
- .env
- 数据库迁移
- CI 配置

不合格计划通常有这些问题：

只说“我会修复问题”，没有文件路径。
没有验证命令。
没有说明不触碰的边界。
一上来就要大重构。

---

第 4 步：按任务切模型和推理预算

原文提到可以用模型和推理预算控制成本与效果。

简单理解：

简单整理、脚本、格式化：用更轻量的模型。
常规功能、测试补齐：用中间档模型。
难定位 bug、架构判断、复杂重构：用更强模型和更高推理预算。

原文提到的命令包括：

/model opusplan
/effort high
/effort max

推荐策略：

| 任务类型 | 建议策略 | |---|---| | 读代码、写计划 | 使用更强推理模型 | | 小修小补 | 使用常规模型 | | 复杂 bug | 提高 /effort | | 批量重命名、格式调整 | 使用轻量模型 | | 涉及生产边界 | 不靠模型强度解决，必须人工确认 |

注意：模型更强不等于可以跳过测试，也不等于可以放开权限。

---

一个可复制的接入模板

如果你要把这个流程用于一个真实项目，可以按下面顺序执行。

1. 新建上下文文件

cat > CLAUDE.md.example <<'EOF'
# CLAUDE.md

## Project

Describe what this project does.

## Commands

uv sync uv run pytest -q uv run ruff check .


## Rules

- Keep changes small.
- Add tests for behavior changes.
- Do not hardcode secrets.

## Boundaries

- Do not edit `.env`.
- Ask before migrations, deployments, or infrastructure changes.
- Do not run destructive commands.
EOF

2. 新建权限样例

mkdir -p .claude
cat > .claude/settings.json <<'EOF'
{
  "permissions": {
    "allow": [
      "Read(*)",
      "Bash(git status*)",
      "Bash(git diff*)",
      "Bash(uv run pytest*)",
      "Bash(uv run ruff check*)"
    ],
    "ask": [
      "Edit(*)",
      "Bash(git commit*)",
      "Bash(uv add*)"
    ],
    "deny": [
      "Read(.env*)",
      "Edit(.env*)",
      "Bash(rm -rf*)",
      "Bash(kubectl delete*)",
      "Bash(psql*DROP*)"
    ]
  }
}
EOF

3. 验证权限 JSON

python3 -m json.tool .claude/settings.json >/dev/null

预期结果：命令成功退出，没有输出。

4. 启动前提示词

你现在是这个项目的代码助手。先进入计划阶段，不要修改文件。
请读取 CLAUDE.md 和相关源码后输出计划。
计划必须包含：修改文件、原因、验证命令、安全边界。

---

常见失败案例

失败案例 1：CLAUDE.md 写得太空

坏例子：

# CLAUDE.md

Please write good code and be careful.

问题：这对 AI 没有实际约束。

改法：至少补齐技术栈、命令、目录、禁止项。

失败案例 2：权限直接全放开

坏例子：

claude --dangerously-skip-permissions

问题：AI 可能在你没注意时修改大量文件、删除内容或读取敏感文件。

改法：只在隔离容器或临时 VM 中使用；真实项目优先配置 allow / ask / deny。

失败案例 3：没有计划就开始改

坏提示：

帮我修一下这个项目。

更好的提示：

先不要修改文件。请分析问题并输出计划，列出需要修改的文件和验证命令，等我确认后再执行。

---

团队落地检查清单

让 Claude Code 介入真实项目前，至少检查这些项：

[ ] 项目根目录有 CLAUDE.md。
[ ] CLAUDE.md 包含测试、格式化、类型检查命令。
[ ] .claude/settings.json 能通过 JSON 解析。
[ ] .env、密钥、生产配置被 deny 或明确禁止。
[ ] 破坏性命令被 deny。
[ ] 写文件、提交、依赖变更默认 ask。
[ ] 默认先进入计划模式。
[ ] 每次执行后运行明确的验证命令。
[ ] 复杂任务使用更强模型或更高推理预算。
[ ] 生产相关操作仍由人确认，不交给 AI 自动执行。

---

最后一句话

Claude Code 的价值不在于“让 AI 无限制写代码”，而在于把 AI 放进一个清晰、可审查、可回滚的工程流程里：先给上下文，再设权限，先出计划，再执行验证。