---
name: brainstorming
description: 在目标、范围或成功标准不清，存在接近的实现方案，或高成本假设可能导致返工时使用。适用于实现前澄清需求、挑战隐含前提并收敛到一个推荐方案；不用于已经明确的小改动。
---

# 需求澄清与方案收敛

## 目标

在实现前识别真正会改变范围或方案的未知项，以最少沟通收敛到可执行选择。

## 何时使用

- 需求存在多种合理解读，结果会明显不同
- 接口、数据、权限、部署或兼容性假设错了会造成高成本返工
- 多个方案取舍接近，需要基于当前代码和约束比较
- 用户在判断某项能力是否值得保留或继续投入

任务已经明确、改动可逆且局部，或用户明确要求直接执行时，不要增加头脑风暴流程。

## 最小流程

1. 读取当前代码、文档、issue/PR、项目规则和相邻实现；能查到的事实不要再问用户。
2. 明确目标、非目标、成功标准和必须保留的行为。
3. 找出最可能推翻方案的 1-3 个假设，优先验证可由代码、工具或官方资料确认的部分。
4. 只有剩余歧义会实质改变成果且无法自行安全判断时，提出少量可行动问题。
5. 给出一个推荐方案及其主要代价。只有取舍接近时再给一个备选。
6. 说明最脆弱假设、验证方式和下一步；需求足够清楚后立即结束探索。

## 评估模式

用户问“是否有必要、值得不值得、是否保留”时，先给出保留、放弃或转向的结论，再说明 2-3 条与当前约束直接相关的理由。若建议转向，给出具体替代方向，不把价值判断伪装成实现计划。

## 高风险检查

重点检查：

- 目标实际优化的是速度、稳定性、成本、体验还是维护性
- 哪些模块、平台、历史行为和用户群必须兼容
- 数据规模、脏数据、权限边界、并发和外部服务是否被默认假设
- 什么命令、测试、运行现象或指标能够证明成功
- 错误方向的回滚和迁移成本

高成本或长期决策按 [设计文档与 ADR 路由](references/design-record-routing.md) 判断。头脑风暴只完成路由，不在这里编写长文档。

## 输出

```text
结论：<推荐方案>
目标与非目标：<范围>
关键依据：<代码、文档或已确认约束>
主要代价：<真实取舍>
最脆弱假设：<可能推翻方案的条件>
下一步：<验证或实施入口>
```

不要为了展示思考而生成大量相似候选，也不要为简单任务强制写设计文档。