| name | android-feature-workflow |
| description | Android 功能需求的完整交付流程：需求分析 → 不确定点确认 → 技术方案 → 编码实现。用于新增功能、实现模块、开发页面、重构 Android 功能等任务。根据复杂度选择流程深度，避免无意义确认，也避免需求不清时直接编码。 |
Android 功能交付流程
收到功能需求后，根据复杂度选择合适流程。目标是：先理解，再实现；简单任务不拖沓，复杂任务不盲写。
流程选择指南
| 需求类型 | 流程 | 示例 |
|---|
| 琐碎改动 | 直接 Phase 4，并简短说明 | 改文案、调颜色、加日志 |
| 小功能 | Phase 1 → Phase 4 | 加一个按钮点击事件、补一个参数 |
| 中等功能 | Phase 1 → Phase 2 → Phase 4 | 新增列表页、接入一个 API |
| 复杂功能 | Phase 1 → Phase 2 → Phase 3 → Phase 4 | 新模块、架构变更、跨模块功能 |
判断标准：如果你对“该怎么做”有任何关键不确定点，就不要直接编码。
Phase 1: 需求拆解
用以下结构梳理需求，将模糊描述转化为明确待办：
## 需求理解
- 一句话目标：[用户要什么]
- 涉及的用户场景：[谁、在什么情况下、做什么操作]
## 功能拆解
- [ ] 子功能 1：...
- [ ] 子功能 2：...
## 边界与约束
- 需要支持的 Android 版本范围：
- 需要适配的屏幕/设备类型：
- 性能要求（如响应时间、内存）：
- 与现有功能的交互：
对于琐碎改动，Phase 1 可压缩为一句话。
Phase 2: 不确定点确认
只有存在影响实现方向的关键不确定点时才进入本阶段。
确认模板：
我对需求的理解如下：
✅ 明确的部分：
1. ...
2. ...
❓ 需要确认的部分：
1. [问题] — 我倾向于 [方案A]，因为 [理由]。还是你希望 [方案B]？
2. [问题] — 有两种做法：
- A: [描述] → 优点：... / 缺点：...
- B: [描述] → 优点：... / 缺点：...
建议选 [X]，原因是 ...
关键原则：
- 每个问题附带倾向性建议，不做纯甩锅式提问。
- 一次性收集所有问题，避免多轮碎片化确认。
- 对明显可默认的细节，直接给出合理默认值并继续推进。
- 如果没有不确定点，明确说明“需求清晰，直接进入方案/实现”。
Phase 3: 技术方案
确认完成后，输出实现方案：
## 技术方案
### 架构层面
- 采用的架构模式：[MVVM/MVI/沿用现有架构/...]
- 新增/修改的模块：
### 实现计划
| 步骤 | 文件 | 改动说明 | 风险点 |
|------|------|----------|--------|
| 1 | | | |
| 2 | | | |
### 关键设计决策
- [决策1]：选择 X 而非 Y，因为 ...
对于简单需求，Phase 3 可简化为一句话说明。
Phase 4: 编码实现
按 Phase 3 的计划逐步执行：
- 创建任务清单，跟踪进度。
- 每完成一个步骤，检查编译、lint 或明显语法错误。
- 尽量保持最小可审查改动。
- 改动完成后，简要汇报：改了什么、为什么这样改、如何验证。
输出要求
实现完成后输出：
## 变更摘要
- ...
## 验证方式
- ...
## 后续建议
- ...
对于直接修改代码的任务，避免输出大量无关解释，重点说明可验证结果。
