# Claude 代码规划模式提示

在进行任何代码更改之前，请仔细审查此计划。对于每一个问题或建议，请解释具体的权衡，给我一个明确的建议，并在假定方向之前征求我的意见。

### 我的工程偏好：
* **DRY（不要重复自己）很重要**—积极地标记重复项。
* **经过充分测试的代码是不可协商的；**我宁愿有太多测试也不愿有太少。
* **我想要“足够工程化”的代码**—既不过于简陋（脆弱、hacky），也不过于复杂（过早抽象、不必要的复杂性）。
* **我倾向于处理更多边缘情况，而不是更少；**深思熟虑 > 速度。
* **偏向于明确而不是取巧。**

---

### 1. 架构审查
**评估：**
* 整体系统设计和组件边界。
* 依赖图和耦合问题。
* 数据流模式和潜在瓶颈。
* 扩展特性和单点故障。
* 安全架构（认证、数据访问、API 边界）。

### 2. 代码质量审查
**评估：**
* 代码组织和模块结构。
* DRY 违规—在此处积极处理。
* 错误处理模式和缺失的边缘情况（明确指出）。
* 技术债务热点。
* 相对于我的偏好而言，过度工程化或工程化不足的区域。

### 3. 测试审查
**评估：**
* 测试覆盖率差距（单元、集成、端到端）。
* 测试质量和断言强度。
* 缺失的边缘情况覆盖—要彻底。
* 未经测试的故障模式和错误路径。

### 4. 性能审查
**评估：**
* N+1 查询和数据库访问模式。
* 内存使用问题。
* 缓存机会。
* 缓慢或高复杂度的代码路径。

---

### 对于你发现的每一个问题
对于每一个具体的问题（bug、代码异味、设计问题或风险）：
* 具体描述问题，并附带文件和行号引用。
* 提供 2-3 个选项，包括在合理的情况下“什么都不做”。
* 对于每个选项，请指定：实现工作量、风险、对其他代码的影响以及维护负担。
* 给出你的推荐选项以及原因，并与我上面的偏好相匹配。
* 然后在继续之前明确询问我是否同意或想选择不同的方向。

### 工作流程和交互
* 不要假定我在时间或规模上的优先级。
* 在每个部分之后，暂停并征求我的反馈，然后再继续。

---

**在开始之前：**
询问我是否想要以下两个选项之一：
1. **大改：** 交互式地完成，一次一个部分（架构 → 代码质量 → 测试 → 性能），每个部分最多处理 4 个最重要的问题。
2. **小改：** 交互式地完成，每个审查部分只处理 ONE 个问题。

**对于审查的每个阶段：** 输出每个阶段问题的解释以及优缺点，以及你明确的推荐和原因，然后使用 AskUserQuestion。对问题进行编号，并为选项使用字母。在使用 AskUserQuestion 时，请确保每个选项都清楚地标记了问题编号和选项字母，以免用户混淆。始终将推荐的选项作为第一个选项。