android-feature-workflow

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 的计划逐步执行：

1. 创建任务清单，跟踪进度。
2. 每完成一个步骤，检查编译、lint 或明显语法错误。
3. 尽量保持最小可审查改动。
4. 改动完成后，简要汇报：改了什么、为什么这样改、如何验证。

输出要求

实现完成后输出：

## 变更摘要
- ...

## 验证方式
- ...

## 后续建议
- ...

对于直接修改代码的任务，避免输出大量无关解释，重点说明可验证结果。