只做足够的头脑风暴

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

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

理解上下文

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

确定：

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

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

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

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

选择合适的深度

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

快速路径

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

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

设计简报

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

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

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

完整设计

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

• 破坏性或难以回退的数据变更；
• 安全、隐私、身份验证、授权或支付边界；
• 公开 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 链接。不要为独立设计添加关系元数据、复制全仓库文档索引，也不要要求设计文档在实施后必须保留。

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

将大型设计分成易于消化的部分，但除非逐段确认确实能减少误解，否则不要在每部分后要求批准。

选择最佳设计

基于项目上下文、用户目标和工程判断选择最佳方案。

如果某个方法明显更好，直接提出它并简要说明为何适合。只在需要暴露重要且未解决的取舍时才生成替代方案。

只有检查上下文后仍存在两个或更多可信方案，且它们的取舍明显不同时，才展示多个方案。只展示解释决策所需的最少选项。

可信方案是指了解情况的工程师在当前约束下可能合理选择的方案。不要包含：

• 较差或故意过度简化的陪衬方案；
• 只换用不同术语表达的同一设计；
• 与既有项目约定冲突的方案；
• 当前需求没有支持的推测性抽象。

即使存在多个可信方案，也先给出建议。只有当决定取决于产品意图、风险偏好、成本或模型无法推断的其他偏好时，才让用户选择。

文档

只有设计文档会在实施或未来协作中持续有用时才编写，例如耗时长、跨组件或多人协作的工作，或用户明确要求时。

记录决定设计的证据、采用的模式，以及重要偏离及其原因。使用外部研究时链接它；仓库证据足够时，不要硬造研究章节。

遵循仓库现有文档约定。只有规格说明会持续有用时才创建；只有用户或仓库工作流要求时才创建 Git 提交。

交付书面设计前，检查其中是否有：

• 未解决的占位符或模糊需求；
• 内部矛盾；
• 应拆分的范围；
• 仍可能被实质性不同理解的决定。

视觉决策

当具体视觉问题通过看图更容易判断时，及时提供视觉辅助。

用户接受后，使用该辅助前先阅读 visual-companion.md。

设计完成后继续

在选定深度下，满足以下条件时可以停止设计：

• 预期结果和可信的成功证据清晰；
• 可能使所选方向失效的约束已解决或明确说明；
• 已选定一个推荐方案，只保留重要取舍；
• 没有尚未解决、且会大幅改变实现的用户决定；
• 验证策略与变更风险相称。

把它们作为内部完成检查，不要作为文档模板。任何缺失项都不会改变实现时，停止设计。

获得授权后，满足条件即继续实施和相称验证。仅要求设计的任务到交付所需设计为止；它不授权实施。

只有计划技能、设计产物、交接或额外批准确实能改善结果时，才添加它们。