docs(CLAUDE): 四阶段工作法 — 先读wiki理解背景再动手
Some checks failed
CI / Lint & TypeCheck (push) Has been cancelled
CI / Unit Tests (push) Has been cancelled
CI / Build Frontend (push) Has been cancelled
CI / Rust Check (push) Has been cancelled
CI / Security Scan (push) Has been cancelled
CI / E2E Tests (push) Has been cancelled
Some checks failed
CI / Lint & TypeCheck (push) Has been cancelled
CI / Unit Tests (push) Has been cancelled
CI / Build Frontend (push) Has been cancelled
CI / Rust Check (push) Has been cancelled
CI / Security Scan (push) Has been cancelled
CI / E2E Tests (push) Has been cancelled
§3.3 从"闭环工作法5步"改为"四阶段工作法": - 阶段1: 理解背景(读wiki获取上下文) - 阶段2: 制定方案(定位根因+影响范围+执行步骤) - 阶段3: 执行+验证 - 阶段4: 提交+同步(不积压) 核心变化: 任何操作前必须先读wiki了解项目背景, 不允许跳过理解阶段直接动手。
This commit is contained in:
56
CLAUDE.md
56
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 检查并更新相关文档,提交并推送
|
||||
|
||||
**铁律:不允许"等一下再提交"或"最后一起推送"。每个独立工作单元完成后立即推送。**
|
||||
|
||||
***
|
||||
|
||||
|
||||
Reference in New Issue
Block a user