diff --git a/CLAUDE.md b/CLAUDE.md
index f3c1a6b..ecf1c04 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -132,19 +132,57 @@ desktop/src-tauri    (→ kernel, skills, hands, protocols)
 4. **配置问题** - TOML 解析、环境变量
 5. **运行时问题** - 服务启动、端口占用
 
-不在根因未明时盲目堆补丁。
+不在根因未明时盲目堆补丁。这一步在四阶段工作法的"阶段 2: 制定方案"中完成。
 
-### 3.3 闭环工作法（强制）
+### 3.3 四阶段工作法（强制，不可跳过任何阶段）
 
-每次改动**必须**按顺序完成以下步骤，不允许跳过：
+任何操作 — 无论是修 bug、加功能、重构、还是回答技术问题 — 都必须按以下 4 个阶段执行。不允许跳过、不允许合并阶段。
 
-1. **定位问题** — 理解根因，不盲目堆补丁
-2. **最小修复** — 只改必要的代码
-3. **自动验证** — `tsc --noEmit` / `cargo check` / `vitest run` 必须通过
-4. **提交推送** — 按 §11 规范提交，**立即 `git push`**，不积压
-5. **文档同步** — 按 §8.3 检查并更新相关文档，提交并推送
+#### 阶段 1: 理解背景（先读 wiki）
 
-**铁律：步骤 4 和 5 是任务完成的硬性条件。不允许"等一下再提交"或"最后一起推送"。**
+**接到任务后，第一件事是阅读 wiki 获取上下文，而不是直接动手。**
+
+1. 读取 `wiki/index.md` — 理解全局架构和模块导航
+2. 根据任务涉及的模块，读取对应的 wiki 页面：
+   - 聊天/消息相关 → `wiki/chat.md`
+   - 连接/路由相关 → `wiki/routing.md`
+   - 记忆/上下文相关 → `wiki/memory.md`
+   - Agent/分身相关 → `wiki/chat.md` (Agent 部分)
+   - Hands/技能相关 → `wiki/hands-skills.md`
+   - 管家/行业相关 → `wiki/butler.md`
+   - 中间件相关 → `wiki/middleware.md`
+   - SaaS/认证/计费 → `wiki/saas.md`
+   - 安全相关 → `wiki/security.md`
+   - 数据库相关 → `wiki/data-model.md`
+   - Pipeline/工作流 → `wiki/pipeline.md`
+   - 功能链路追踪 → `wiki/feature-map.md`
+3. 如涉及已知问题，检查 `wiki/known-issues.md`
+
+**判断标准**: 你能用一句话说清楚"这个改动涉及哪个模块、走哪条数据链路、影响哪些组件"吗？如果不能，你还没读完。
+
+#### 阶段 2: 制定方案（先想清楚再动手）
+
+基于阶段 1 的理解，制定执行方案：
+
+1. **定位根因** — 确认属于哪一类问题（协议/状态/UI/配置/运行时），不盲目堆补丁
+2. **确定影响范围** — 哪些文件需要改？哪些 crate 受影响？有没有上下游依赖？
+3. **列出执行步骤** — 按顺序列出要改的文件和验证点
+4. **预判风险** — 这个改动可能破坏什么？需要跑哪些测试？
+
+**判断标准**: 你能用 3 句话说清楚"改什么、为什么改、改完怎么验证"吗？如果不能，方案还不成熟。
+
+#### 阶段 3: 执行 + 验证
+
+1. **最小修复** — 只改必要的代码
+2. **自动验证** — `cargo check` / `cargo test` / `tsc --noEmit` / `vitest run` 必须通过
+3. **回归测试** — 跑受影响 crate 的全量测试，确认无回归
+
+#### 阶段 4: 提交 + 同步（立即，不积压）
+
+1. **提交推送** — 按 §11 规范提交，**立即 `git push`**
+2. **文档同步** — 按 §8.3 检查并更新相关文档，提交并推送
+
+**铁律：不允许"等一下再提交"或"最后一起推送"。每个独立工作单元完成后立即推送。**
 
 ***