brainstorming

只做足够的头脑风暴

把不确定的想法变成足以实施的明确决策。设计工作的深度应与不确定性、影响和判断错误的代价相匹配。

清晰且可回退的任务直接进入实施。只有仍存在会带来实质后果的未决决定时，才暂停实施。

理解上下文

在向用户提问前，先检查相关项目文件、约定、文档和已有行为。

确定：

• 目标和成功标准是否清晰；
• 多种方案是否会产生明显不同的后果；
• 变更范围有多大、是否容易回退；
• 错误假设的成本或风险有多高；
• 哪些决定需要用户意图，而无法从技术上推断；
• 是否应在细化前拆分独立的交付结果。

从可用上下文中发现事实；只有无法可靠推断的信息才提问。

如果请求覆盖多个独立子系统或结果，只拆分到足以识别清晰边界、依赖和合理的第一个切片，再设计细节。

只有在陌生或高度不确定的领域可能隐藏足以推翻当前方向的约束时，才做一次简短的盲点检查。

选择合适的深度

根据已有证据选择强度最低的路径。额外设计不太可能改变实现时使用快速路径；未决选择可能实质改变方案时使用设计简报；只有具体、影响高或难以回退的决策才使用完整设计。

快速路径

请求清晰、局部、低风险且容易回退时使用快速路径。

只说明重要但不明显的假设，然后直接继续用户请求的工作，不写设计文档、不列替代方案，也不另开一轮审批。

设计简报

存在一定不确定性或重要取舍，但变更不需要长期留存的规格说明时，使用对话式设计简报。

• 只询问答案会改变方案的问题。
• 当这对用户更清楚时，把密切相关的问题放在一起。
• 先给出建议。
• 只有方案确实不同才展示替代方案。
• 说明重要取舍，不要人为制造选项。
• 剩余选择属于用户时，取得确认。

当剩余决定及其重要取舍已足够清晰、用户可以确认时，停止简报。

完整设计

工作影响高、歧义大或回退代价高时，使用完整设计流程。例如：

• 破坏性或难以回退的数据变更；
• 安全、隐私、身份验证、授权或支付边界；
• 公开 API、持久化模式或跨系统契约；
• 跨越多个独立子系统的变更；
• 会明显改变用户可见行为的产品决策；
• 用户明确要求在实现前设计或规格化的工作。

对此类工作：

1. 确定目的、约束和成功标准。
2. 从相关的仓库决策和已验证模式开始。用户要求时，或未解决的设计问题会改变选择时，研究可比产品或成熟开源项目；证据足以解决该问题时停止。复用合适模式，并解释重要偏离。
3. 选择并展示最佳设计。只有仍有未解决、且取舍明显不同的方案时才比较替代方案。
4. 描述相关架构、边界、行为、故障处理和验证策略。
5. 解决会造成后果的歧义。
6. 提出设计。只有用户负责的决定仍未解决、后果超出已有授权，或用户要求在实施前审阅设计时才暂停；否则继续已授权工作。对于已批准的范围或契约，不要再次请求批准。

从清晰职责、明确接口或契约、依赖方向和边界清晰的失败行为等角度检查设计。它们是质量检查项，不是必需文档章节或固定模板。

定义可靠的实施切片

完整设计需要通过多个共享契约或彼此依赖的任务实施时：

1. 建立一个总设计（父设计），由它拥有共享契约、任务边界、依赖顺序、子任务不得重新定义的约束，以及集成验收标准。
2. 将工作拆为连贯、可独立验证的切片。对每个切片，说明其结果与非目标、前置条件、分配的责任或变更边界、继承的契约和不变量、仍可自由选择的局部实现方式，以及证明完成的证据。
3. 按实际依赖关系排序切片，并把端到端集成验收保留在总设计中。
4. 在把依赖切片设计视为最终方案前，先在总设计中解决属于用户的决定；已有对这些契约的批准依然有效。
5. 当切片证据要求修改共享契约时，修订总设计。实施依赖切片前，重新确认属于用户或曾获批准的契约改动；局部实现选择仍在其已授权范围内。

不要把切片变成推测性的编码指令。只有仓库证据表明文件、符号或调用顺序是稳定约束，而不是局部实现选择时，才点名它们。

根据契约所有权而不是任务先后确定这种关系。只有前置任务的设计拥有当前任务必须遵守的共享约束时，它才是总设计。

编写子任务设计时，让这一关系易于发现。仓库已有元数据约定时遵循它；否则可使用如下可选 frontmatter：

design_role: child
governing_design: ./governing-design.md

相对于子文档解析 governing_design。如果 frontmatter 不合适，添加一条直接标明总设计的 Markdown 链接。不要为独立设计添加关系元数据、复制全仓库文档索引，也不要要求设计文档在实施后必须保留。

不要强行让真正独立的实施任务形成总从关系；如果额外切片不能改善责任、顺序或验证，也不要继续拆分。