你可能已经在用 Claude Code 了。你打开终端，输入 `claude`，描述一个功能，它帮你写代码。你 review，修改，提交。

你觉得效率不错，甚至有点沾沾自喜。当然有时候 cc 也会犯错，会让你觉得他也有笨的时候。

但如果我们诚实一点：你只是把 Claude Code 当成一个“更快的复制粘贴工具”，或者一个可以解决你问题的 csdn 或者谷歌。

你仍然在掌控每一个线程、管理每一次上下文切换、监督每一个决策。你依然是整个工作流中最忙的那个。

真正顶尖的 1% 用户，他们并不比你更会写 prompt。

他们只是把 Claude Code 当成了一套可以编程的基础设施来搭建。

他们有精心设计的 `CLAUDE.md` 文件，在每个会话开始时自动加载完美上下文。

他们有 hooks，能在无需询问的情况下强制执行质量门禁。

他们有 subagents，可以并行处理同一问题的不同部分，而他们本人则专注于架构和方向。

他们还连接了 MCP 服务器，让 Claude 能够实时访问数据库、GitHub 和内部工具。

这篇文章，就是一份把 Claude Code 从“一个工具”升级为“一套系统”的实战指南。

1. 重新理解 Claude Code 的架构

很多人把 Claude Code 看作一个“编程助手”。但更准确的描述是：它是一个袋里编排框架，恰好非常擅长编码。

你可以把它理解为四层：

• CLAUDE.md / 技能（Skills）：这是项目的“永久记忆”和“领域知识”。
• 钩子（Hooks）：这是自动化的“质量门禁”和“护栏”。
• 子袋里（Subagents）：这是“并行处理”和“隔离上下文”的能力。
• MCP 服务器：这是连接“外部真实世界”的桥梁。

绝大多数用户只用到了第二层（基础对话与文件编辑）。高手则让这四层协同工作，产生的复合效应是指数级的。

2. `CLAUDE.md`：项目的“精炼大脑”

`CLAUDE.md` 是唯一一个会在每次会话中自动加载的文件。它是你给 Claude 的“永久记忆”。

但大部分人的用法是错的：他们把它写成了一本 400 页的“公司手册”，而 Claude 真正需要的是一份“项目便签”。

核心原则：少即是多

`CLAUDE.md` 有一个隐性的指令预算（大约 150-200 条）。系统提示已经占用了约 50 条。

你每增加一行 Claude 不需要的内容，就会稀释真正重要的信息。

```

# 错误示范：事无巨细的百科全书

# 我们使用 React 18.2.0，Node.js 20.11.0，TypeScript 5.3.3...

# 我们使用 ESLint 8.56.0 和 Prettier 3.1.1...

# 我们需要遵循以下 15 条代码规范...

# 正确示范：精炼的“差异”指南

## 项目痛点（Claude 容易出错的地方）

- 本项目使用 ESM 模块，**不要**生成 CommonJS 的 `require()` 语法。

- Redis 键必须包含版本前缀：`v2:user:{id}`

- 所有数据库查询必须经过 service 层，禁止在路由中直接调用 DB。

## 关键决策

- 选择 SSR 而非 CSR，因为我们的主要用户群体位于网络条件较差的地区。

```

我的规则是：如果这句话没有它，Claude 会犯错吗？如果答案是“不会”，就删掉它。

文件层级的力量

`~/.claude/CLAUDE.md` (全局) < `./CLAUDE.md` (项目根目录) < `./CLAUDE.local.md` (个人覆盖) < `./src/api/CLAUDE.md` (按需加载)

善用子目录的 `CLAUDE.md`。不要把前端、后端、数据库的规范全塞进一个文件。

在你工作到 `src/db/` 目录时，该目录下的 `CLAUDE.md` 会自动加载。这才是真正的“按需上下文”。

3. 钩子（Hooks）：自动化的“质量门禁”

Hooks 是 Claude Code 实现“自动化”的核心。它们是在特定生命周期点自动运行的 Shell 命令。

例如：文件写入前、命令执行后、会话结束时。

关键区别在于：Hooks 不依赖于 Claude 的判断，它们强制执行。

一个实用的 `settings.json` 配置

```json

{

"hooks": {

"PostToolUse": [

{

"matcher": "Write",

"hooks": [

{

"type": "command",

"command": "cd $PROJECT_ROOT && npm run lint --fix"

}

]

}

],

"PreToolUse": [

{

"matcher": "Bash",

"hooks": [

{

"type": "command",

"command": "python .claude/hooks/block_dangerous.py"

}

]

}

]

}

}

```

这个配置一共实现了两个自动化能力：

• 当 Claude 每次完成文件写入后，系统会自动触发 linter 来修复格式问题。
• 当 Claude 每次准备执行命令之前，会先由一个 Python 脚本进行安全检查。

这个脚本用来识别是否包含 rm -rf、DROP TABLE 这类危险操作。

如果退出代码为 2，就会直接拦截该命令，并把错误信息返回给 Claude。

我见过最巧妙的用法是 CI/CD 流水线钩子：一个子袋里完成规范编写后，通过 `SubagentStop` 钩子读取队列中的下一个任务，让整个工作流像流水线一样推进，无需人工干预。

4. 子袋里（Subagents）：真正的“并行团队”

这是 Claude Code 区别于其他工具的核心功能。

子袋里让你能同时运行多个独立的 Claude 实例，每个都有独立的上下文、系统提示、工具权限，甚至模型。

创建一个代码审查员（Code Reviewer）

在 `.claude/agents/code-reviewer.md` 中：

```markdown

---

name: code-reviewer

description: 对代码进行风格、正确性、安全性和性能审查。

tools: Read, Grep, Glob

model: claude-opus-4-6

---

你是一位资深工程师，负责进行严格的代码审查。

对每个更改的文件，检查：

1. 正确性——是否实现了预期功能？

2. 边缘情况——什么输入会破坏它？

3. 安全性——是否存在注入、泄露或认证漏洞？

4. 可读性——新成员在 6 个月后还能理解吗？

输出结构化的报告，包含“必须修复”、“应该修复”、“可以考虑”三部分。

```

“双 Claude 审查”模式

这是我最推荐的高杠杆技术：

• 会话 A：实现功能，并进行测试。
• 会话 B（在另一个终端中启动）：`claude "作为架构师，审查会话 A 的最近一次提交。务必严格。"`

因为会话 B 没有会话 A 的任何上下文，它会冷眼看待所有代码。

这样更容易发现那些被“想当然”的假设掩盖的问题。这比任何同行评审都更诚实、更快速。

5. MCP 服务器：连接“真实世界”

MCP（模型上下文协议）让 Claude 能够连接到你的数据库、GitHub、Jira 等外部工具。

这意味着它从“能读写本地文件”，升级为“能与你的整个开发生态系统交互”。

```json

{

"mcpServers": {

"github": {

"command": "npx",

"args": ["-y", "@modelcontextprotocol/server-github"],

"env": { "GITHUB_TOKEN": "ghp_your_token_here" }

}

}

}

```

配置后，你可以直接说：“查一下最近 5 次失败的 GitHub Actions 运行，找出共同原因。”

Claude 会自动调用 GitHub MCP，获取数据并分析。

一个关键原则：最小权限

大部分场景下，Claude 读取数据库就够了，不需要写入。

为你的 MCP 服务器配置两个版本：

• 一个只读（用于探索和分析）
• 一个读写（仅用于开发环境）

永远不要让生产环境的 MCP 有写入权限。

一个 25 分钟的端到端实战

假设需要构建一个新的 `/api/v2/recommendations` 接口。

• 第 0 步：你的 `CLAUDE.md` 已经加载，Claude 已知晓技术栈和规范。
• 第 1 步（访谈与设计）：`claude "我想构建这个接口，通过 `AskUserQuestion` 工具访谈我，询问鉴权、缓存、响应格式等。然后产出完整设计文档。"`
• 第 2 步（实现）：Claude 开始编码。同时，PostToolUse Hook 自动运行 linter 修复格式，PreToolUse Hook 拦截任何危险命令。
• 第 3 步（并行审查）：在另一个终端，运行 `claude "使用 code-reviewer 子袋里审查最新提交"`。子袋里返回一份报告：“必须在错误路径上释放 Redis 连接”、“鉴权中间件应在限流器之前”。
• 第 4 步（修复与验证）：主会话根据报告进行修复，并再次运行测试。
• 第 5 步（安全审计）：运行 `security-auditor` 子袋里进行安全检查。
• 第 6 步（创建 PR）：通过 GitHub MCP，Claude 自动创建 PR，描述变更和测试覆盖情况。

整个流程约 25 分钟，完成了一个原本可能需要 2-3 小时的功能。

而且质量门禁自动运行，安全审计从未被遗忘。

结语：从使用者到系统设计师

Claude Code 已经提供了所有必要的“积木”：子袋里、钩子、MCP、技能。

差别在于，你是把它们当作“可选项”，还是把它们当作一个连贯的、可编程的系统来设计和构建。

真正顶尖的 1% 用户，他们不是更好的“提示工程师”，他们是更好的 “系统设计师”。

他们思考的是：

• 上下文在哪里会退化，如何预防
• 哪些质量门禁应该自动化
• 哪些任务可以并行