系列导航：
- 开篇 · 2026 如何养好 Claude Code（开篇）：从养龙虾到养 Claude Code
- 第零篇 · 2026 如何养好 Claude Code（零）：ClaudeCode Basics
- 第一篇 · 2026 如何养好 Claude Code（一）：核心机制深度解析
- 第二篇 · 2026 如何养好 Claude Code（二）：插件生态深度实践
- 第三篇 · 2026 如何养好 Claude Code（三）：框架选型指南
- 第四篇 · 2026 如何养好 Claude Code（四）：多Agent协作实战
开篇：从工具到生态的升级
上一篇我们聊了养好 Claude Code 的基础心法——配置、规范和习惯。但如果只停留在"用得好"的层面，你的 Claude 仍然是一个单机工具。
真正的进阶，是把 Claude Code 升级成一个智能协作平台。
插件生态就是这道分水岭。通过 Memory 插件，Claude 获得了持久记忆；通过 Hookify，它学会了自我约束；通过 Planning with Files，它掌握了复杂任务管理。三者联动，你的 Claude 从"听话的助手"进化成"懂你的伙伴"。
本文将深入三大核心插件的实战配置，助你打造专属的 Claude Code 工作流。
配置层级：插件生效的基础
在深入插件之前，必须理解 Claude Code 的配置层级设计。这是所有配置生效的基础。
生活类比
配置层级就像公司的制度层级：
┌─────────────────────────────────────────────────┐
│ Local Settings（本机私有） │ ← 你的个人习惯
│ "我习惯用深色主题" │ 最高优先级
├─────────────────────────────────────────────────┤
│ Project Settings（团队共享） │ ← 部门规范
│ "我们项目用 2 空格缩进" │ 覆盖个人习惯
├─────────────────────────────────────────────────┤
│ User Settings（全局默认） │ ← 公司通用规定
│ "全员使用 TypeScript" │ 最底层，可被覆盖
└─────────────────────────────────────────────────┘
合并规则（一句话记住）
- 数组：合并并去重（大家的东西都要）
- 非数组：高层级覆盖低层级（听直属领导的）
// 三个层级都配了插件
// User: ["memory", "hookify"] ← 全局默认
// Project: ["planning-with-files"] ← 项目加一个
// Local: ["memory"] ← 本机再加（去重）
// 最终生效：["memory", "hookify", "planning-with-files"]
配置放哪里？
| 配置类型 | 放哪一层 | 原因 |
|---|---|---|
| 通用插件（Memory、Hookify） | User | 所有项目都可用 |
| 项目专属 Skills | Project | 团队共享 |
| API Key、密钥 | Local | 安全，不会提交 |
设计原理
为什么这样设计？
- 团队协作：Project 配置提交到 Git，团队成员自动获得一致的行为
- 个人偏好：User 配置保留个人习惯，不影响团队
- 安全隔离：Local 配置存储敏感信息（API Key），不会意外提交
最佳实践
| 配置类型 | 放在哪一层 | 原因 |
|---|---|---|
| 通用插件（Memory、Hookify） | User | 所有项目都可用 |
| 项目专属 Skills | Project | 团队共享，保持一致 |
| API Key、密钥 | Local | 安全，不会提交 |
| 团队规范（代码风格、工作流） | Project CLAUDE.md | 新成员自动获得 |
Memory 插件：让 Claude 拥有持久记忆
生活类比：
- 没有 Memory：每次对话都像初次见面的陌生人，要重新介绍自己
- 有了 Memory：Claude 记住了你的偏好，像老朋友一样了解你的习惯
无Memory 有Memory
┌──────────────┐ ┌──────────────┐
│ 对话1 │ │ 对话1 │
│ "我喜欢TS" │ │ "我喜欢TS" │
└──────────────┘ └──────┬───────┘
↓ ↓
┌──────────────┐ ┌──────────────┐
│ 对话2 │ │ 对话2 │
│ "你是谁？" │ │ "基于你的 │
│ (忘记一切) │ │ TS偏好..." │
└──────────────┘ └──────────────┘
选型对比：Ensue vs Claude Mem
市面上的 Memory 插件不少，目前最成熟的两款是 Ensue Memory Network 和 Claude Mem。
工具地址：
核心差异如下：
| 维度 | Ensue Memory Network | Claude Mem |
|---|---|---|
| 存储方式 | 云端 API（跨设备同步） | 本地文件（离线可用） |
| 搜索能力 | 语义向量搜索 + 时间线 | 索引搜索 + 3层过滤 |
| Token 优化 | 自动批量处理 | 3层工作流节省 87% |
| 依赖 | 仅需 curl + jq | 需要 Bun 运行时 |
| 体积 | 436 KB | 3.8 MB |
| 适用场景 | 多设备、长期知识积累 | 隐私敏感、离线环境 |
具体功能对比：
选型建议：
- 需要跨设备同步 + 语义搜索 → 选择 Ensue
- 需要数据隐私 + 离线工作 → 选择 Claude Mem
核心特性速览：
| 插件 | 独特功能 |
|---|---|
| Ensue | discover_memories 语义搜索、Research Agent 自主研究、Hypergraph 知识图谱可视化 |
| Claude Mem | 34 种多语言模式、/do 子代理编排、/make-plan 阶段式计划生成 |
Ensue Memory Network 配置实战
# Step 1: 安装插件
/plugin marketplace add https://github.com/mutable-state-inc/ensue-skill
/plugin install ensue-memory
# Step 2: 配置环境变量（放在 Local 层级！）
# ~/.claude/settings.local.json
{
"env": {
"ENSUE_API_KEY": "your-api-key-here"
}
}
# Step 3: 重启 Claude Code
核心命名空间设计：
preferences/ # 用户偏好
coding/ # 代码风格、模式
communication/ # 交互方式
projects/ # 项目知识
acme/ # 具体项目
architecture/ # 架构决策
conventions/ # 项目规范
research/ # 研究积累
gpu-inference/ # 领域知识
使用示例：
# 存储偏好
"remember 我偏好的技术栈是 React + PostgreSQL"
# 跨会话检索（7天后）
"基于我的技术偏好，推荐最佳实践"
# Ensue 自动检索历史偏好并应用
Claude Mem 3层工作流
graph LR
A[Step 1: search] -->|获取索引 + IDs| B[Step 2: timeline]
B -->|获取上下文| C[Step 3: get_observations]
C -->|仅获取过滤后的详情| D[完整信息]
Token 节省原理：先搜索索引（50-100 tokens/result），再获取上下文，最后只拉取需要的完整详情。相比传统全量返回，节省 87% Token。
实战：跨会话技术决策复用
场景：你在 Session A 做了技术选型决策，3 天后 Session B 需要基于同一决策继续开发。Memory 让决策跨越会话边界。
痛点：没有 Memory 时，每次新会话都要重新解释"为什么选 A 不选 B"，Claude 可能给出不一致的建议。
sequenceDiagram
participant U as 用户
participant C as Claude Code
participant M as Memory
rect rgb(240, 248, 255)
Note over U,M: Session A（3月15日）：技术选型
U->>C: 认证系统用什么方案？
C->>M: search("auth decisions")
M-->>C: 无历史记录
C->>U: 建议 JWT + refresh token（理由：无状态、可扩展）
U->>C: 确认，记住这个决策
C->>M: store("auth: 选用 JWT + refresh token，弃用 Session")
end
rect rgb(255, 248, 240)
Note over U,M: Session B（3月18日）：继续开发
U->>C: 帮我实现 token 刷新逻辑
C->>M: search("auth decisions")
M-->>C: 找到：auth: JWT + refresh token
C->>U: 基于之前选定的 JWT 方案，实现 refresh token 逻辑...
Note over C: 自动遵循 Session A 的决策，无需重新讨论
end
rect rgb(240, 255, 240)
Note over U,M: Session C（3月25日）：新人提问
U->>C: 为什么用 JWT 而不是 Session？
C->>M: search("auth decisions")
M-->>C: 找到：弃用 Session 的决策记录
C->>U: 因为3月15日的选型决策：JWT 无状态、可扩展...
end
操作流程：
Step 1 — 存储决策（Session A）
# 方式1：显式存储（推荐）
"remember 本项目认证方案：JWT + refresh token，弃用 Session-based，\
原因：无状态、水平扩展友好、团队熟悉度高"
# 方式2：Ensue 命名空间存储（结构化）
"存储到 preferences/auth：选择 JWT，access_token 有效期 15min，\
refresh_token 有效期 7d，使用 bcrypt 哈希密码"
Step 2 — 跨会话复用（Session B）
# 新会话中，Claude 自动检索相关记忆
"帮我实现 token 刷新逻辑"
# Claude 自动执行：
# 1. search("auth" 或 "token") → 找到 Session A 的决策
# 2. 基于 JWT + refresh token 方案实现
# 3. 参数与 Session A 一致（15min / 7d）
Step 3 — 决策回溯（Session C）
# 新同事提问，Claude 能给出与历史一致的回答
"为什么不用 Session？"
# Claude 检索到历史决策记录，给出一致的理由
关键技巧：
| 技巧 | 做法 | 效果 |
|---|---|---|
| 命名空间隔离 | 按 项目/领域 分（如 auth/、payment/） |
避免不同项目记忆混淆 |
| 决策必须显式存储 | 关键决策用 remember 存储 |
不依赖 Claude 的"自动记忆" |
| 记录弃用原因 | 不仅记"选了什么"，还记"弃了什么、为什么" | 避免后续重复讨论已否决的方案 |
| 定期清理 | 过时决策用 delete_memory 移除 |
避免旧决策干扰新方案 |
| 会议纪要入库 | 团队会议后，将决策批量写入 Memory | 团队共识自动成为 Claude 的参考 |
Hookify 插件：为 Claude 装上"刹车系统"
先理解：什么是 Hook？
Hook（钩子）是 Claude Code 在会话的关键节点自动触发的拦截机制。
工作原理：当特定事件发生时，Claude Code 会把事件上下文（JSON 格式）传给钩子处理程序。处理程序检查输入、执行逻辑，然后决定放行还是拦截。
触发频率：有些事件每会话只触发一次（如 SessionStart），有些会在代理循环中反复触发（如 PreToolUse）。
下图为 hook 在 session 会话中的生命周期流程图：
具体各节点含义如下表
| 事件 | 触发时机 |
|---|---|
SessionStart |
会话开始或恢复时 |
UserPromptSubmit |
当你提交提示时，在 Claude 处理它之前 |
PreToolUse |
在工具调用执行之前。可以阻止它。 |
PermissionRequest |
当出现权限对话框时 |
PostToolUse |
工具调用成功后 |
PostToolUseFailure |
工具调用失败后 |
Notification |
当 Claude Code 发送通知时 |
SubagentStart |
当生成子代理时 |
SubagentStop |
当子代理人完成 |
Stop |
当Claude回答完毕 |
TeammateIdle |
当一名Agent团队成员即将进入空闲状态时 |
TaskCompleted |
当一项任务被标记为已完成时 |
InstructionsLoaded |
当 CLAUDE.md 或其他.claude/rules/*.md文件加载到上下文中时触发。在会话开始时以及会话期间延迟加载文件时触发。 |
ConfigChange |
当会话期间配置文件发生更改时 |
WorktreeCreate |
--worktree当通过 git create-worktree或 git create-worktree 创建工作树时，isolation: "worktree"会替换默认的 Git 行为。 |
WorktreeRemove |
当工作树被移除时，无论是在会话退出时还是在子代理完成时。 |
PreCompact |
上下文压缩之前 |
PostCompact |
上下文压缩完成后 |
Elicitation |
当 MCP 服务器在工具调用期间请求用户输入时 |
ElicitationResult |
用户响应 MCP 请求后，在响应发送回服务器之前。 |
SessionEnd |
会话终止时 |
从 Hook 到 Hookify：降低使用门槛
Hook 是 Claude Code 的原生机制，功能强大但有门槛——你需要编写 Shell 脚本或 JSON 配置来定义规则。
这就好比：你想装一个门禁系统，但得自己接线、写控制程序。
Hookify 应运而生——它把复杂的 Hook 逻辑封装起来，让你用 Markdown + YAML 就能定义规则，无需写代码。
回到上面的比喻：Hookify 就像买了一个成品门禁，你只需要填几张配置卡（规则文件），刷一下就能用。
一句话总结：Hook 是底层能力，Hookify 是易用工具。你不需要懂 Hook 的原理，只要会用 Hookify 就够了。
Hookify：用 Markdown 写规则，不用写代码
GitHub: claude-code-plugins/hookify
生活类比：
- Hookify 就像公司门口的保安
- 你要进大楼？保安检查你的证件
- 你要执行危险命令？Hookify 拦下来问一句：“你确定吗？”
用户操作 → Hookify 检查 → 结果
│ │ │
│ ┌─────┴─────┐ │
│ │ │ │
│ 匹配规则？ 不匹配 │
│ │ │ │
│ ┌──┴──┐ │ │
│ block warn │ │
│ │ │ │ │
↓ ↓ ↓ ↓ ↓
[阻止] [警告] [警告] [放行] [放行]
Hookify 把复杂的钩子逻辑封装成 Markdown + YAML 格式，让你无需写代码就能定义行为规则。
配置层级与 Hookify
Hookify 钩子文件同样遵循三层架构：
| 层级 | 路径 | 用途 |
|---|---|---|
| User | ~/.claude/hooks/*.md |
全局通用规则（危险命令拦截） |
| Project | <project>/.claude/hooks/*.md |
项目专属规则（敏感文件保护） |
| Local | <project>/.claude/hooks.local/*.md |
本地临时规则（调试用） |
合并规则：所有层级的钩子都会生效，按层级顺序检查。
核心概念
---
name: rule-name
enabled: true
event: bash|file|stop|prompt
pattern: regex-pattern
action: warn|block
---
警告/阻止消息内容
5 大场景钩子配置
1. 危险命令拦截（block）- User 层级
# ~/.claude/hooks/block-dangerous-rm.md
---
name: block-dangerous-rm
enabled: true
event: bash
pattern: rm\s+-rf\s+.*(/|~)
action: block
---
检测到危险的 rm -rf 命令！
该命令可能删除整个目录或用户主目录，已被阻止。
**替代方案**:
- 使用 `rm -ri` 进行交互式删除
- 先用 `ls` 确认目录内容
2. 硬编码密钥防护（block）- Project 层级
# <project>/.claude/hooks/block-hardcoded-secrets.md
---
name: block-hardcoded-secrets
enabled: true
event: file
conditions:
- field: new_text
operator: regex_match
pattern: (API_KEY|SECRET|TOKEN|PASSWORD)\s*[=:]\s*["'][A-Za-z0-9_\-]{16,}
action: block
---
检测到硬编码的敏感信息！
**安全风险**: 密钥可能被提交到版本控制
**正确做法**: 使用环境变量
3. 调试代码警告（warn）- Project 层级
# <project>/.claude/hooks/warn-console-log.md
---
name: warn-console-log
enabled: true
event: file
conditions:
- field: file_path
operator: regex_match
pattern: \.(ts|js|tsx|jsx)$
- field: new_text
operator: regex_match
pattern: console\.(log|debug|info)\(
action: warn
---
检测到 console.log 调试代码
提交前记得删除调试语句。
4. 强制推送拦截（block）- User 层级
# ~/.claude/hooks/block-force-push.md
---
name: block-force-push
enabled: true
event: bash
pattern: git\s+push\s+.*(-f|--force)
action: block
---
强制推送已被阻止！
使用 `git push --force-with-lease` 更安全。
5. 完成前测试验证（block）- 按需启用
# <project>/.claude/hooks/require-tests.md
---
name: require-tests
enabled: false # 按需启用
event: stop
conditions:
- field: transcript
operator: not_contains
pattern: npm test|pytest|cargo test
action: block
---
未检测到测试运行！
停止前请运行测试验证更改。
事件类型速查
| 事件 | 触发时机 | 典型场景 |
|---|---|---|
bash |
Bash 命令执行 | 危险命令、权限操作 |
file |
文件编辑操作 | 敏感文件、调试代码 |
stop |
Claude 想停止时 | 完成验证、测试检查 |
prompt |
用户提交提示时 | 意图验证、确认操作 |
Planning with Files：Manus 风格的持久化规划
GitHub: OthmanAdi/planning-with-files
这据说是 Meta 以 20 亿美元收购 Manus 背后的工作流模式。
生活类比：
- 没有 Planning：Claude 像没有笔记本的学生，做到哪忘到哪
- 有了 Planning：Claude 像有项目管理办公室的团队，进度一目了然
传统方式 Planning方式
┌──────────────┐ ┌──────────────┐
│ 任务在脑子里 │ │ task_plan │
│ 容易忘记 │ │ ✓ 已完成 │
│ 难以追溯 │ │ ○ 待办 │
└──────────────┘ └──────────────┘
↓ ↓
会话结束 → 全部丢失 会话中断 → 从复选框继续
核心思想：文件系统即记忆。
安装
/plugin marketplace add OthmanAdi/planning-with-files
/plugin install planning-with-files@planning-with-files
# 使用
/plan
三文件结构
+===============================================================+
| .planning-work/ |
+===============================================================+
| |
| +-------------------+ +-------------------+ |
| | task_plan.md | | findings.md | |
| +-------------------+ +-------------------+ |
| | 任务计划 | | 研究发现 | |
| | + 进度复选框 | | + 知识积累 | |
| +-------------------+ +-------------------+ |
| |
| +-------------------+ |
| | progress.md | |
| +-------------------+ |
| | 会话日志 | |
| | + 测试结果 | |
| +-------------------+ |
| |
+===============================================================+
task_plan.md - 任务计划
# 构建用户认证系统
## 阶段 1: 设计
- [x] 分析需求文档
- [x] 设计数据模型
- [ ] 定义 API 端点
## 阶段 2: 实现
- [ ] 实现认证逻辑
- [ ] 添加密码加密
- [ ] 编写单元测试
## 错误日志
- [2026-03-15] bcrypt 版本冲突 → 升级到 5.1.0
findings.md - 研究发现
# 研究发现
## 技术决策
- **加密库**: bcrypt（成熟、安全）
- **Token**: JWT + refresh token
- **存储**: Redis 缓存 session
## 最佳实践
- 密码强度校验使用 zod schema
- 登录失败限流：5次/分钟
progress.md - 会话日志
# 会话日志
## Session 1: 2026-03-15 14:30
### 完成
- 项目初始化
- Prisma schema 设计
### 测试
- 密码加密测试: 通过
- Token 生成测试: 待运行
核心规则
- 创建计划优先 — 永远不要在没有
task_plan.md的情况下开始 - 2-Action 规则 — 每 2 次操作后保存发现到
findings.md - 记录所有错误 — 避免重复踩坑
- 会话恢复 — 中断后从复选框继续
适用场景
| 适合 | 不适合 |
|---|---|
| 多步骤任务（3+ 步） | 简单问答 |
| 研究分析任务 | 单文件编辑 |
| 长期项目追踪 | 快速查找 |
插件组合拳：Memory + Hookify + Planning 联动
联动场景：构建生产级 API
graph TB
A[用户: 构建支付 API] --> B[Planning: 创建 task_plan.md]
B --> C[Memory: 检索历史支付系统设计]
C --> D[Hookify: 拦截硬编码密钥]
D --> E[实现阶段]
E --> F[Hookify: 验证测试运行]
F --> G[Planning: 更新进度复选框]
G --> H[Memory: 存储架构决策]
实战配置
1. Memory 负责知识积累
# 存储项目偏好
"remember 本项目使用 Stripe 支付，货币单位为分"
# 后续会话自动检索
"基于之前的支付方案，添加退款功能"
2. Hookify 负责安全门禁
# 支付相关敏感文件保护
---
name: protect-payment-files
enabled: true
event: file
conditions:
- field: file_path
operator: regex_match
pattern: (payment|stripe|checkout)
- field: new_text
operator: regex_match
pattern: (secret|key|token)\s*=
action: block
---
3. Planning 负责进度追踪
# task_plan.md
## 阶段 1: 支付集成
- [x] Stripe SDK 安装
- [x] 支付意图创建
- [ ] Webhook 处理
- [ ] 退款逻辑
## 阶段 2: 测试
- [ ] 单元测试
- [ ] 集成测试
协同效果
| 插件 | 职责 | 价值 |
|---|---|---|
| Memory | 知识持久化 | 跨会话复用架构决策 |
| Hookify | 安全门禁 | 阻止敏感信息泄露 |
| Planning | 进度追踪 | 确保任务完整性 |
实战案例 1：从零构建订阅管理 API
场景：用 Claude Code 从零开发一个"用户订阅管理 API"（Express + Prisma + Stripe），全程三插件联动。
graph LR
subgraph "5 阶段流程"
A[1.项目初始化] --> B[2.核心开发]
B --> C[3.安全加固]
C --> D[4.测试验证]
D --> E[5.收尾归档]
end
subgraph "插件介入时机"
M[Memory]
H[Hookify]
P[Planning]
end
A -.-> P
A -.-> M
B -.-> P
B -.-> H
C -.-> H
D -.-> P
D -.-> H
E -.-> P
E -.-> M
阶段 1：项目初始化
# 用户指令
"帮我从零搭建一个订阅管理 API，用 Express + Prisma + Stripe"
# Planning 自动介入：创建任务计划
# → .planning-work/task_plan.md 自动生成
Planning 生成的 task_plan.md：
# 订阅管理 API 开发计划
## 阶段 1: 基础搭建
- [ ] 初始化 Express 项目
- [ ] 配置 Prisma + PostgreSQL
- [ ] 设计订阅数据模型
## 阶段 2: 核心功能
- [ ] 实现订阅 CRUD
- [ ] 集成 Stripe 支付
- [ ] 实现 Webhook 处理
## 阶段 3: 安全与测试
- [ ] 添加认证中间件
- [ ] 编写单元测试
- [ ] 编写集成测试
## 阶段 4: 收尾
- [ ] API 文档
- [ ] 环境变量配置说明
Memory 同时介入——如果之前存储过项目偏好：
# Memory 自动检索到历史决策
"检测到历史偏好：TypeScript + 2空格缩进 + Biome 格式化"
# → 自动应用，无需重新配置
阶段 2：核心开发
Hookify 在开发过程中自动执行安全检查：
# Claude 尝试写入支付模块
# Hookify 规则 protect-payment-files 自动触发：
# 场景 A：正常代码 → 放行
Claude 写入: const session = await stripe.checkout.sessions.create(...)
→ Hookify: 通过，未检测到敏感信息
# 场景 B：硬编码密钥 → 拦截
Claude 写入: const stripe = require('stripe')('sk_live_xxx...')
→ Hookify: BLOCKED! 检测到硬编码密钥
→ 自动重定向到使用环境变量: process.env.STRIPE_SECRET_KEY
每完成一个功能模块，Planning 自动更新进度：
## 阶段 2: 核心功能
- [x] 实现订阅 CRUD # ← 刚完成
- [ ] 集成 Stripe 支付 # ← 进行中
- [ ] 实现 Webhook 处理
Memory 存储关键决策到 findings.md：
# 研究发现
## 架构决策
- **Stripe 集成方式**: Checkout Session（推荐）而非 Charges API
- **货币单位**: 所有金额以"分"存储，避免浮点精度问题
- **Webhook 签名**: 必须验证 Stripe-Signature 头
阶段 3：安全加固
Hookify 在此阶段发挥最大价值：
# .claude/hooks/protect-env-files.md
---
name: protect-env-files
enabled: true
event: file
conditions:
- field: file_path
operator: regex_match
pattern: \.env($|\.)
- field: new_text
operator: regex_match
pattern: (SECRET|KEY|TOKEN|PASSWORD)
action: block
---
不允许将包含敏感信息的 .env 文件提交到版本控制。
请使用 .env.example 作为模板，实际值通过环境变量注入。
阶段 4：测试验证
Hookify 的 stop 事件确保测试不会遗漏：
# .claude/hooks/require-tests.md
---
name: require-tests
enabled: true
event: stop
conditions:
- field: transcript
operator: not_contains
pattern: npm test|jest|vitest
action: block
---
完成前请运行测试验证更改！
Planning 同步更新测试进度：
## 阶段 3: 安全与测试
- [x] 添加认证中间件
- [x] 编写单元测试 (12/12 通过)
- [ ] 编写集成测试 # ← 最后一步
阶段 5：收尾归档
# Planning: 标记所有任务完成
# Memory: 存储项目知识供未来复用
"remember 订阅管理 API 项目：Express + Prisma + Stripe，\
数据库用 PostgreSQL，所有金额以分为单位，\
Webhook 必须验证签名"
三个文件的最终状态：
.planning-work/
├── task_plan.md # 全部 ✓（7/7 任务完成）
├── findings.md # 12 条技术决策记录
└── progress.md # 3 个 Session 日志
实战案例 2：5人团队协作配置方案
场景：5人团队使用 Claude Code 开发同一项目，如何确保行为一致？
核心原则：团队共享的放 Project 层，个人偏好的放 User 层，敏感信息放 Local 层。
配置分层总览
| 配置项 | 放哪层 | 谁维护 | Git 提交 |
|---|---|---|---|
| 项目规范（技术栈、架构） | ./CLAUDE.md |
Tech Lead | 是 |
| Hookify 安全规则 | .claude/hooks/ |
安全负责人 | 是 |
| Planning 模板 | .claude/skills/ |
全员 | 是 |
| 个人语言偏好 | ~/.claude/CLAUDE.md |
个人 | 否 |
| 个人 Memory | Ensue / Claude Mem | 个人 | 否 |
| API Key | .claude/settings.local.json |
个人 | 否（gitignore） |
团队共享 Hookify 规则
.claude/hooks/
├── block-hardcoded-secrets.md # 密钥防护（全员生效）
├── block-dangerous-rm.md # 防误删（全员生效）
├── warn-console-log.md # 调试代码提醒
└── protect-payment-files.md # 支付模块保护
新成员 Onboarding 清单
## 新成员 Claude Code 配置清单
### 必做（5分钟）
1. clone 项目后运行 `claude`，确认自动加载 CLAUDE.md
2. 检查 Hookify 规则生效：`/hookify list`
3. 配置 API Key 到 `.claude/settings.local.json`
### 推荐做
4. 配置 Memory 插件（Ensue 或 Claude Mem）
5. 在 `~/.claude/CLAUDE.md` 设置个人偏好
6. 阅读 `.planning-work/findings.md` 了解项目已有决策
协作注意事项
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 新人行为不一致 | 未加载项目级配置 | 确认 .claude/hooks/ 已提交到 Git |
| Hookify 误报频繁 | 正则规则过于宽泛 | 调整 pattern 精度，block 改 warn |
| Memory 跨人共享 | Memory 是个人知识库 | 重要的决策写在 findings.md 提交共享 |
| Planning 文件冲突 | 多人同时修改 task_plan.md | 约定一人主维护，或分文件管理 |
settings.local.json 泄露 |
忘记 gitignore | 确保 .gitignore 包含 .claude/settings.local.json |
补充：/loop 与 Ralph Loop：定时任务与自我迭代
在程序开发中，while 循环是一个很重要的工具，它允许我们重复执行相同的代码块，直到满足特定条件为止。在AI开发中，它同样是一个很重要的工具，不断迭代直到条件收敛。
这是我最喜欢的一部分：让 Claude Code 能够"自己跑起来"。
Claude Code 支持两种循环机制，用于定时任务和自我迭代。
/loop：定时任务调度
2026年3月，Claude Code 新增了 /loop 命令，支持在会话内调度重复任务。
基本用法：
# 每5分钟检查一次PR状态
/loop 5m 检查我的PR是否有新的评论
# 每小时监控服务健康状态
/loop 1h 检查生产环境服务是否正常
与 OpenClaw cron 的区别：
| 维度 | OpenClaw cron | Claude Code /loop |
|---|---|---|
| 运行环境 | 独立后台进程 | 会话内运行 |
| 持续时间 | 无限制（7x24） | 最多 3 天 |
| 硬件要求 | 需要持续运行的服务器 | 任意开发机 |
| 状态保持 | 跨会话持久化 | 会话内有效 |
| 适用场景： |
- PR/Issue 状态监控（几小时内完成）
- 服务健康检查（短期监控）
- 自动化测试轮询（等待 CI 完成）
Ralph Loop：自我迭代循环
GitHub: anthropics/ralph-loop
Ralph Loop 是一种通过 Bash 脚本实现的自我迭代机制，让 Claude Code 能够持续改进自己。
工作原理：
# Ralph Loop 本质上是一个 Bash 循环
while true; do
# 向 Claude 喂入提示词文件
# Claude 执行任务并更新提示词
# 循环继续，带着上一次的"记忆"
done
核心思路：创建一个自引用反馈循环
- 提示词在每次迭代中保持
- Claude 的输出可以影响下一次迭代的输入
- 实现渐进式改进
典型应用：
- 自动优化代码质量（每轮发现并修复一个问题）
- 持续重构（逐步改进架构）
- 文档完善（迭代补充缺失内容）
注意事项： - 需要设置停止条件（如最大迭代次数、目标达成判断）
- 关注 Token 消耗（每轮都会消耗配额）
- 建议配合 Hookify 插件（防止失控操作）
小结：插件选型决策树
需要跨会话记忆？
├─ 是 → 需要 Memory 插件
│ ├─ 多设备同步？ → Ensue Memory Network
│ └─ 隐私优先？ → Claude Mem
│
├─ 需要行为约束？
│ ├─ 是 → Hookify
│ └─ 配置规则：危险命令 block + 敏感操作 warn
│
└─ 需要复杂任务管理？
├─ 是 → Planning with Files
└─ 创建 task_plan.md + findings.md + progress.md
三插件协同口诀：
- Memory 存知识，Hookify 守底线，Planning 追进度
- 联动使用，Claude Code 从工具变平台
进阶预告
下一篇《框架选型指南》将深入：
- SuperClaude vs Superpowers 设计理念对比
- 功能覆盖与学习曲线分析
- 选型决策树
- 组合使用最佳实践
思考题
看完这一篇，有兴趣可以试着回答这些问题，看看你的理解程度：
-
配置层级的合并规则是什么？如果 User 和 Project 都配置了
enabledPlugins，最终会生效哪些插件？ -
Memory 插件的 Ensue 和 Claude Mem 两个方案，核心差异是什么？你会如何选择？
-
Hookify 的 block 和 warn 有什么区别？举一个应该用 block 的场景和一个应该用 warn 的场景。
-
Planning with Files 的三个文件分别负责什么？为什么需要三个文件而不是一个？
-
如果你的团队有 5 个人，各自有不同的 Claude Code 配置偏好，如何设计配置层级才能保证团队行为一致？
