brainstorming · diff
git:20260929.603248c to git:20261015.b377f6b
15 added, 2 removed. Audit A to A.
---
name: brainstorming
description: 在目标、范围或成功标准不清，存在接近的实现方案，或高成本假设可能导致返工时使用。适用于实现前澄清需求、挑战隐含前提并收敛到一个推荐方案；不用于已经明确的小改动。
---
# 需求澄清与方案收敛
## 目标
在实现前识别真正会改变范围或方案的未知项，以最少沟通收敛到可执行选择。
## 何时使用
- 需求存在多种合理解读，结果会明显不同
- 接口、数据、权限、部署或兼容性假设错了会造成高成本返工
- 多个方案取舍接近，需要基于当前代码和约束比较
- 用户在判断某项能力是否值得保留或继续投入
任务已经明确、改动可逆且局部，或用户明确要求直接执行时，不要增加头脑风暴流程。
## 最小流程
- 1. 读取当前代码、文档、issue/PR、项目规则和相邻实现；能查到的事实不要再问用户。
+ 1. 读取当前代码、文档、issue/PR、项目规则和相邻实现；能查到的事实不要再问用户。涉及默认值、环境变量或配置字段时，从实际配置文件读取当前值，不凭记忆或文档引用。项目记录过相关决定（ADR、设计文档、issue 讨论）时先读。
2. 明确目标、成功标准、必须保留的行为和会改变方案的约束。
3. 找出最可能推翻方案的 1-3 个假设，优先验证可由代码、工具或官方资料确认的部分。
- 讨论领域概念时，先对照现有术语文档和代码；同一个词若指向不同对象或状态，用具体边界场景澄清含义，再沿用仓库已有名称。
4. 只有剩余歧义会实质改变成果且无法自行安全判断时，提出少量可行动问题。
- 5. 给出一个推荐方案及其主要代价。只有取舍接近时再给一个备选。
+ 5. 给出一个推荐方案及其主要代价，并明确表态：说清什么证据会改变这个推荐。只有取舍接近时再给一个备选；同时用一句话写出最朴素的做法，推荐方案要在风险、回滚或性能上胜过它，而不是只更优雅。
6. 说明最脆弱假设、验证方式和下一步；需求足够清楚后立即结束探索。
+ ## 方案来源
+
+ - 先查框架内建能力、官方模式和生态标准；已有官方方案时默认推荐它，除非能说明它在当前场景为什么不够。
+ - 问题较难，或同一处已经调了多次仍不对时，先看 2-3 个成熟开源项目或直接竞品的实际实现，提炼可迁移的机制，并说明从每个项目借鉴了什么。
+ - 需要用户安装或配置的东西（钩子、MCP、插件、配置项、额外服务）是每个使用者都要付出的成本。默认选择无需配置的形式，只有说明它做不到时才提出需要配置的方案。
+ - 不经用户同意，不在单一技术栈的项目中引入新的语言或运行时。
+ - 方案与项目规则中的“必须”“禁止”“优先”冲突时，用一句话指出冲突的规则、冲突的步骤和建议的处理方式，不悄悄覆盖；规则阻止方案时先询问。
+
## 评估模式
用户问“是否有必要、值得不值得、是否保留”时，先给出保留、放弃或转向的结论，再说明 2-3 条与当前约束直接相关的理由。若建议转向，给出具体替代方向，不把价值判断伪装成实现计划。
## 高风险检查
重点检查：
- 目标实际优化的是速度、稳定性、成本、体验还是维护性
- 哪些模块、平台、历史行为和用户群必须兼容
- 数据规模、脏数据、权限边界、并发和外部服务是否被默认假设
- 什么命令、测试、运行现象或指标能够证明成功
- 错误方向的回滚和迁移成本
- 状态、阶段或形状假设是否已经重复出现在多个分支；如果是，先考虑状态机、领域模型、判别联合或 registry，再决定是否继续增加条件。
- 如果多个修复共享同一个前提却连续失败，先写出这个前提并检查它，而不是继续在同一前提上叠加补丁。
- 多阶段实现是否能拆成每步都有可验证结果的垂直切片，并按“先验证、再推进”的顺序交付。
高成本或长期决策按 [设计文档与 ADR 路由](references/design-record-routing.md) 判断。头脑风暴只完成路由，不在这里编写长文档。
+
+ ## 冲突与返工
+
+ - 需求来源互相矛盾，或存在两种成本不同的合理解读时，用一句话写出具体冲突并询问以哪个为准，不自行挑一个。
+ - 方案被否决后，先问清具体哪里不行，带着收窄的约束重新进入，不从头再来。
## 输出
先给推荐结论和关键依据，再说明真正影响选择的约束、代价或脆弱假设。没有实质内容的字段不补；只有存在需要执行的验证或实施动作时才写下一步。不要固定使用同一组标签组织每次回答。
不要为了展示思考而生成大量相似候选，也不要为简单任务强制写设计文档。