如何让Claude Code写代码的时候非常资深
输入“/”快速插入内容
如何让Claude Code写代码的时候非常资深
如何让Claude Code写代码的时候非常资深
用户2用户25月14日修改
在你的项目目录下创建Claude.md，写入如下提示词
代码块
## Workflow — 五阶段工作流模式 (必须严格遵守)
你必须依照以下顺序推进任务，严禁跳步。
### 🔴 [MODE: RESEARCH] - 深度调研
**目标**：构建完整的上下文认知，像编译器预处理一样扫描全局。
* **允许**：读取文件、分析依赖、提问澄清、建立心理模型。
* **禁止**：编写任何实现代码、给出解决方案、通过假设填补未知。
* **操作**：
1. 定位所有相关文件。
2. 识别潜在的副作用（Side Effects）。
* **输出**：现状分析报告 -> 自动转入 INNOVATE。
### 🟠 [MODE: INNOVATE] - 方案架构
**目标**：寻找最优解，而非第一个解。
* **允许**：头脑风暴、权衡算法复杂度、对比技术栈。
* **禁止**：具体的代码实现、做出承诺。
* **思维**：评估方案的简洁性（是否符合 C 风格哲学）。
* **输出**：技术方案比对与最终选择 -> 自动转入 PLAN。
### 🟡 [MODE: PLAN] - 蓝图与测试策略
**目标**：生成可执行的、原子化的指令集。
* **允许**：定义文件路径、函数签名、数据结构。
* **必须**：
1. **编写实现清单**：详细到函数级别的步骤。
2. **编写验证策略**：明确后端如何单元测试，前端如何验证视觉效果（无报错）。
* **禁止**：编写具体逻辑代码、模糊描述（如"实现相关逻辑"）。
* **输出**：带编号的精密执行清单 -> 自动转入 EXECUTE。
### 🟢 [MODE: EXECUTE] - 暴力执行
**目标**：以机器般的精准度执行计划。
* **原则**：**All or Nothing**。要么给出完整代码，要么不给。
* **禁止**：`// TODO`、`// ...原有代码`、简化逻辑、跳过错误处理。
* **操作**：
1. 严格按清单编写代码。
2. 同时编写对应的测试代码（Test Logic）。
* **输出**：完整代码块 + 进度更新 -> 自动转入 REVIEW。
### 🔵 [MODE: REVIEW] - 静态合规检查
**目标**：代码层面的静态审计。
* **检查项**：
1. 是否包含未实现的占位符？（如有，必须驳回重写）
2. 是否符合 C 风格简洁性？（有无过度封装）
3. 是否破坏了现有功能？
* **输出**：审计结果（通过/整改） -> 自动转入 CHECK。
### 🟣 [MODE: CHECK] - 运行时验证 (关键)
**目标**：确保代码在现实世界中有效。
* **后端要求**：运行单元测试，确保逻辑覆盖率和边界条件处理正确。
* **前端要求**：检查控制台（Console）是否有红字报错，布局是否崩坏。必须检查所有的变动，每一处变动都要考虑是不是有变动错，有没有少覆盖，有没有多覆盖，有没有没覆盖。
* **输出**：
* **成功**：最终交付确认。
* **失败**：携带错误日志自动回退到 **INNOVATE** 或 **PLAN** 模式进行修复。
---
## 6. 任务追踪模板
在每次响应的末尾，必须维护并更新此状态块：
```markdown
---
### 🛡️ 任务控制面板
**当前模式**: `[MODE: NAME]`
**当前任务**: [简述]
**执行清单**:
- [x] [RESEARCH] 上下文分析
- [x] [INNOVATE] 方案选型
- [ ] [PLAN] 1. 定义数据结构
- [ ] [PLAN] 2. 设计测试用例
- [ ] [EXECUTE] 实现核心逻辑 (禁止代码省略)
- [ ] [EXECUTE] 编写单元测试
- [ ] [REVIEW] 静态代码审计
- [ ] [CHECK] 运行时/视觉验证
**质量门禁**:
- [ ] 无 `TODO` 或占位符
- [ ] 逻辑无过度封装
- [ ] 测试/验证通过
---
```
## 7. 异常处理
* 如果用户需求模糊，**不要猜测**，保持在 RESEARCH 模式直到澄清，需要用户澄清的内容在最后加粗提问用户。
* 如果在 EXECUTE 阶段发现原计划不可行，**立即暂停**，回退到 INNOVATE 模式重新评估，不要试图打补丁。
* 后面若用户让你修改内容，**只改对应的东西**，严禁扩大修改范围。
## Testing — 测试策略与质量保障
### 🎯 核心理念
**测试不是开发的附属品，而是交付高质量软件的核心环节。**
#### 质量保障三原则
1. **左移测试**: 在开发早期发现问题，成本最低
2. **分层验证**: 不同层次的测试解决不同层次的问题
3. **持续反馈**: 快速发现、快速修复、快速验证
### 📐 测试策略金字塔
```
┌───────────┐
│ E2E测试 │ ← 端到端验收（Chrome DevTools手工测试）
│ 10% │ 验证完整用户流程
├───────────┤
│ 集成测试 │ ← API集成测试（Go test）
│ 30% │ 验证模块间协作
├───────────┤
│ 单元测试 │ ← 函数级别测试
│ 60% │ 验证独立逻辑正确性
└───────────┘
```
#### 各层测试职责
| 测试层 | 目标 | 工具 | 执行频率 |
|-------|------|------|---------|
| 单元测试 | 验证函数逻辑 | Go test, Vitest | 每次提交 |
| 集成测试 | 验证API契约 | Go test + DB | 每次PR |
| E2E测试 | 验证用户流程 | Chrome DevTools | 功能完成时 |
### 🔄 测试驱动开发流程
#### 1. 需求分析阶段
```
需求文档 → 流程图 → 测试用例矩阵 → 验收标准
```
#### 2. 测试用例设计
**流程图驱动法**: 从业务流程图出发，确保每个分支都有测试用例
```
业务流程节点
├── 正向路径 → 正向测试用例
├── 异常路径 → 异常测试用例
└── 边界条件 → 边界测试用例
```
**覆盖矩阵法**: 使用多维矩阵确保组合覆盖
| 维度1 | 维度2 | 维度3 | 测试用例 |
|-------|-------|-------|---------|
| 状态A | 条件X | 操作1 | TC-001 |
| 状态A | 条件Y | 操作2 | TC-002 |
| 状态B | 条件X | 操作1 | TC-003 |
#### 3. 开发与测试并行
```
开发代码 ←→ 编写测试 ←→ 运行验证 ←→ 修复问题
↑_____________________________|
```
#### 4. Bug发现与修复循环
```
发现Bug → 记录Bug → 分析根因 → 修复代码 → 验证修复 → 更新文档
```
### 🐛 Bug管理规范
#### Bug严重程度定义
| 级别 | 定义 | 响应时间 | 示例 |
|-----|------|---------|------|
| P0 | 系统崩溃、数据丢失 | 立即修复 | 页面白屏、数据库写入失败 |
| P1 | 核心功能不可用 | 24小时内 | 登录失败、支付异常 |
| P2 | 次要功能异常 | 下个迭代 | 提示文案错误、样式问题 |
#### Bug记录模板
```markdown
### BUG-XXX: [简明标题]
**严重程度**: P0/P1/P2
**状态**: 🔵 待修复 / ✅ 已修复
**关联用例**: TC-XXX
**问题描述**: [一句话描述]
**复现步骤**:
1. ...
2. ...
**预期 vs 实际**:
- 预期: xxx
- 实际: xxx
**根因分析**: [为什么会出现这个问题]
**修复方案**: [如何修复]
```
### 🔧 测试环境规范
#### 环境配置
```yaml
开发环境:
前端: http://localhost:5173
后端: http://localhost:8080
数据库: SQLite / MySQL / PostgreSQL
测试工具:
浏览器: Chrome DevTools - 设备模拟模式 - iPhone SE 模式
API测试: curl / Postman
数据库: 对应客户端
```
#### 测试数据管理
**原则**:
1. 测试数据与生产数据隔离
2. 测试后清理或重置数据
### 📊 后端集成测试规范
#### 测试代码模板
```go
func TestScenarioName(t *testing.T) {
// 1. 准备数据
// 2. 执行操作
// 3. 验证结果
}
```
#### 测试设计原则
1. **正向流程**: 验证正常业务路径
2. **异常流程**: 验证错误处理
3. **权限验证**: 验证角色权限控制
4. **数据隔离**: 验证多租户数据隔离
5. **边界条件**: 验证极端情况处理
#### 运行命令
```bash
# 运行所有测试
go test -v ./... -count=1
# 运行特定测试
go test -v ./model/... -run TestXxx -count=1
```
### 📱 前端E2E测试规范
#### Chrome DevTools测试技巧
1. **设备模拟**: iPhone SE模式测试移动端
2. **网络模拟**: 模拟慢网络、断网
3. **存储检查**: Application面板查看localStorage
4. **控制台监控**: 检查红字报错
### ✅ 质量门禁
#### 功能测试完成标准
- [ ] 所有测试用例执行完毕
- [ ] 测试通过率 ≥ 95%
- [ ] P0/P1 Bug 全部修复
- [ ] P2 Bug 已记录评估
#### 上线检查清单
- [ ] 功能测试通过
- [ ] 集成测试通过
- [ ] Bug修复验证
- [ ] 代码Review通过
### 🔑 常见Bug类型与预防
1. **参数缺失**: 前端调用API时漏传参数
2. **导入遗漏**: 使用了模块但忘记import
3. **类型错误**: 类型检查不严格导致运行时错误
4. **边界处理**: 空值、零值、极端值处理不当
5. **状态同步**: 前后端状态不一致
**预防措施**:
1. 代码Review重点检查参数传递和导入
2. 单元测试覆盖边界条件
3. 集成测试验证前后端契约
---
**核心理念**: 质量是设计出来的，不是测试出来的。测试是验证质量的手段，而非创造质量的方法。
## Task Planning — 任务规划指南
### 核心原则
1. **增量开发**: 每个任务建立在前一个任务基础上，确保代码始终可工作，避免大爆炸式集成
2. **可追溯性**: 每个任务必须引用具体需求编号，格式：`_Requirements: X.Y, X.Z_`
3. **可测试性**: 实现任务和测试任务成对出现
### Phase划分标准
```markdown
## Phase 1: 数据库和模型层
- 枚举定义、数据库迁移、Model定义、DTO定义
## Phase 2: 后端核心功能
- Repository层、Service层（含属性测试）、中间件、Controller层、路由配置、Checkpoint
## Phase 3: 前端开发
- Service层（API调用）、Context/状态管理、页面组件、路由配置、Checkpoint
## Phase 4: 集成测试
- 功能测试、权限测试、性能测试
## Phase 5: 部署上线
- 数据迁移、部署流程、监控验证
```
### 任务编号规范
```markdown
- [ ] 1. 顶层任务名称（预计时间）
- [ ] 1.1 子任务名称
- 具体实现内容（bullet points）
- _Requirements: X.Y_
- [ ] 1.2 对应的测试任务
- **Property N: 属性名称**
- 测试内容描述
- **Validates: Requirements X.Y**
```
### 任务描述要素
每个任务必须包含：
1. **任务名称**：动词开头，清晰描述要做什么
2. **实现内容**：具体编码步骤（bullet points）
3. **需求引用**：`_Requirements: X.Y_`
4. **预计时间**：在Phase级别或任务级别标注
### Checkpoint任务
在 Phase 2、Phase 3、Phase 4 结束时放置 Checkpoint：
```markdown
- [ ] X. Checkpoint - 阶段名称
- [ ] X.1 运行所有测试
- [ ] X.2 检查测试覆盖率
- [ ] X.3 询问用户是否有问题
```
### 时间估算参考
| 任务类型 | 预计时间 |
|---------|---------|
| 枚举/Model/DTO定义 | 30分钟 |
| 数据库迁移脚本 | 30分钟 |
| Repository层（每个） | 1小时 |
| Service方法实现 | 30分钟/方法 |
| 属性测试 | 30分钟/测试 |
| Controller接口 | 15分钟/接口 |
| 中间件实现 | 30分钟/中间件 |
| 前端页面 | 2-3小时/页面 |
| 前端组件 | 1小时/组件 |
### 任务粒度控制
- **太大** ❌：一个任务包含多个Service方法
- **太小** ❌：每个函数一个任务
- **合适** ✅：一个Service方法一个任务，包含实现和测试
### 任务计划必备元素
1. **时间估算表格**：Phase级别的任务数和预计时间
2. **任务依赖关系图**：Phase间和任务间的依赖
3. **关键里程碑**：完成标志和预计时间
4. **风险和应对措施**：风险项、影响、应对
5. **验收标准**：功能验收、性能验收、测试验收
### 验收标准模板
```markdown
### 功能验收
- [ ] 核心功能正常工作
- [ ] 用户流程顺畅
### 测试验收
- [ ] 单元测试覆盖率 ≥ 80%
- [ ] 所有属性测试通过
- [ ] 所有集成测试通过
### 性能验收
- [ ] API响应时间 < 300ms
- [ ] 页面加载时间 < 2s
```
### Do's and Don'ts
**✅ Do's**:
1. 使用动词开头：实现、创建、编写、修改、添加
2. 具体明确：说明要做什么
3. 包含验收标准
4. 引用需求
5. 标注时间
**❌ Don'ts**:
1. 避免模糊描述："实现相关逻辑"、"完成功能"
2. 避免遗漏测试
3. 避免跳跃依赖
4. 避免混合职责：一个任务只做一件事