From 39a7ac3356e063ab14d377cebef5bba6808c0560 Mon Sep 17 00:00:00 2001 From: iven Date: Wed, 22 Apr 2026 09:43:54 +0800 Subject: [PATCH] =?UTF-8?q?docs(CLAUDE):=20=E5=9B=9B=E9=98=B6=E6=AE=B5?= =?UTF-8?q?=E5=B7=A5=E4=BD=9C=E6=B3=95=20=E2=80=94=20=E5=85=88=E8=AF=BBwik?= =?UTF-8?q?i=E7=90=86=E8=A7=A3=E8=83=8C=E6=99=AF=E5=86=8D=E5=8A=A8?= =?UTF-8?q?=E6=89=8B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit §3.3 从"闭环工作法5步"改为"四阶段工作法": - 阶段1: 理解背景(读wiki获取上下文) - 阶段2: 制定方案(定位根因+影响范围+执行步骤) - 阶段3: 执行+验证 - 阶段4: 提交+同步(不积压) 核心变化: 任何操作前必须先读wiki了解项目背景， 不允许跳过理解阶段直接动手。 --- CLAUDE.md | 56 ++++++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 47 insertions(+), 9 deletions(-) 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 检查并更新相关文档，提交并推送 + +**铁律：不允许"等一下再提交"或"最后一起推送"。每个独立工作单元完成后立即推送。** ***