1355 Auto Execution Bcc6520b

# 自动执行模式

> **核心原则**: 计划 → 确认 → 执行到底 → 验收

---

## 工作流程

```
1️⃣ 收到任务 → TodoList 规划
                ↓
2️⃣ 展示计划 → 用户确认
                ↓
3️⃣ 用户确认 OK → 执行到底（不问问题，除非致命阻塞）
                ↓
4️⃣ 全部完成 → 总结 + 请求用户验收
```

---

## 4 种致命阻塞（唯一允许提问）

只有以下情况才能中断执行并提问：

### 1. 缺少关键凭证

```
❗ 需要数据库密码、API key、敏感信息
❗ 无法从代码库或环境中获取

示例：
- "需要 Stripe API Key 才能继续"
- "请提供数据库连接字符串"
```

### 2. 多个对立方案

```
❗ 完全不同的技术方案
❗ 无法从代码库判断应该选哪个
❗ 选择会影响架构方向

示例：
- "用户认证选择 JWT 还是 Session？两者架构完全不同"
- "状态管理用 Redux 还是 Context？需要确认项目规模"
```

### 3. 需求本质矛盾

```
❗ 用户要求互相冲突
❗ 无法同时满足

示例：
- "既要实时同步又要离线工作，需要确认优先级"
- "既要高安全性又要一键登录，请确认取舍"
```

### 4. 不可逆高风险

```
❗ 删除生产数据
❗ 强制推送到 main/master
❗ 修改计费相关配置
❗ 影响用户数据的操作

示例：
- "即将删除 users 表中的数据，确认继续？"
- "即将 force push 到 main 分支，确认继续？"
```

---

## 禁止提问的情况（自行决策）

以下情况必须自行决策，不得中断流程：

| 类型 | 决策原则 |
|-----|---------|
| **文件命名** | 遵循现有规范 |
| **目录结构** | 遵循现有结构 |
| **代码实现细节** | 选择最佳实践 |
| **依赖版本** | 使用最新稳定版 |
| **测试策略** | 全面覆盖 |
| **代码风格** | 遵循 eslint/prettier |
| **UI 布局细节** | 遵循设计系统 |
| **变量/函数命名** | 语义化命名 |
| **注释风格** | 简洁、有意义 |
| **错误信息措辞** | 用户友好 |

---

## TodoList 使用规范

### 创建 TodoList

```markdown
## 任务计划

### 阶段 1: 准备工作
- [ ] 分析现有代码结构
- [ ] 确认依赖关系

### 阶段 2: 实现功能
- [ ] 创建数据模型
- [ ] 实现 API 接口
- [ ] 添加输入验证

### 阶段 3: 测试和文档
- [ ] 编写单元测试
- [ ] 更新 API 文档
```

### 实时更新

执行过程中实时更新状态：

```markdown
### 阶段 1: 准备工作
- [x] 分析现有代码结构 ✓
- [x] 确认依赖关系 ✓

### 阶段 2: 实现功能
- [x] 创建数据模型 ✓
- [ ] 实现 API 接口 ← 正在进行
- [ ] 添加输入验证
```

---

## 验收报告格式

任务完成后，生成验收报告：

```markdown
## 任务验收报告

### 完成内容
1. ✅ 功能 A - 已实现并测试
2. ✅ 功能 B - 已实现并测试
3. ✅ 测试 - 覆盖率 85%

### 变更文件
- `src/models/user.ts` - 新增用户模型
- `src/api/users.ts` - 新增 API 接口
- `tests/users.test.ts` - 新增测试

### 如何验证
1. 运行 `npm test` 确认测试通过
2. 启动服务访问 `/api/users`
3. 检查数据库记录

### 注意事项
- 需要先执行数据库迁移
- 环境变量需要添加 `USER_SECRET`

### 后续建议
- 考虑添加缓存层
- 建议增加 rate limiting
```

---

## 错误处理

### 遇到错误时

1. **记录错误** - 记录具体错误信息
2. **分析原因** - 确定根本原因
3. **尝试修复** - 最多尝试 3 次
4. **升级处理** - 3 次失败后报告用户

### 错误记录格式

```markdown
## 遇到的问题

### [时间] 错误类型
**Error**: 具体错误信息
**Root Cause**: 根本原因分析
**Attempts**:
1. 尝试 A - 失败原因
2. 尝试 B - 失败原因
3. 尝试 C - 成功/失败

**Solution**: 最终解决方案
**Learning**: 经验教训
```

---

## 最佳实践

### 1. 计划阶段

- 详细拆分任务
- 识别依赖关系
- 预估复杂度
- 标记风险点

### 2. 执行阶段

- 按计划顺序执行
- 每完成一项立即标记
- 遇到问题先尝试解决
- 只在致命阻塞时提问

### 3. 验收阶段

- 生成完整报告
- 提供验证步骤
- 说明注意事项
- 给出后续建议

---

## 示例场景

### 场景: 添加用户注册功能

```
用户: 添加用户注册功能，包含邮箱验证

Claude:
1. 创建 TodoList
   - 设计数据模型
   - 创建注册 API
   - 实现邮箱验证
   - 编写测试

2. 展示计划并等待确认

3. 用户确认后执行：
   - 创建 User 模型
   - 实现 POST /api/register
   - 集成邮件服务
   - 编写测试用例

4. 生成验收报告
```

### 场景: 遇到致命阻塞

```
Claude 执行中...

发现问题: 需要 SMTP 配置才能发送验证邮件

⚠️ 致命阻塞: 缺少关键凭证

请提供:
- SMTP_HOST
- SMTP_USER
- SMTP_PASSWORD

或者选择:
A) 使用 SendGrid（需要 API Key）
B) 使用 Mailgun（需要 API Key）
C) 暂时跳过邮件功能，后续配置

等待用户响应...
```