Zc Brainstorming And Design

Brainstorming and Design

Overview

当需求模糊、跨模块、存在不可逆决策或真实方案分歧时，通过自然的协作对话将想法收敛为足够实施的设计。先理解当前项目上下文，只澄清会改变路线的问题，再提出有真实取舍的方案。

只有当选择会改变架构、外部契约、数据安全或用户明确要求先评审时，才在实现前暂停并等待确认。 明确、局部、可逆的任务可声明假设后直接选择最小路径。

When to Use

• 开始一个方向未收敛或影响跨模块的新项目或功能之前
• 需求模糊，需要通过对话探索清晰化
• 有多种实现方案需要权衡
• 涉及跨模块边界、不可逆决策或高风险外部副作用
• 在 /idea（发散思维）之后、/spec（正式规格）之前

不适用：

• 目标、边界和验收已经清晰的局部修改
• 可快速验证和回退的单文件配置、文案或机械性调整
• 没有真实方案分歧、不会改变外部契约的直接实现

复杂度门

不要用“简单”跳过会改变路线的风险，也不要把所有任务升级为完整设计流程。设计深度应由真实分歧、影响范围和可逆性决定；几句话能说明的就不要制造多轮确认。

流程清单

按顺序完成以下步骤：

1. 探索项目上下文 — 检查文件、文档、近期提交
2. 收敛关键问题 — 只有答案会改变路线时才提问
3. 比较真实方案 — 存在真实 trade-off 时提出 2-3 种方案；否则给出一个推荐方案和明确放弃项
4. 按风险展示设计 — 按复杂度缩放；只有不可逆或跨边界部分需要逐段确认
5. 设计自审 — 检查占位符、矛盾、歧义、范围
6. 必要时用户审核 — 架构、外部契约、数据安全或用户要求评审时，确认后再进入下一步
7. 转入实现 — 调用 planning-and-task-breakdown 或 spec-driven-development

理解想法

探索项目状态

• 先检查当前项目状态（文件、文档、近期提交）
• 在深入细节之前，评估范围：如果请求描述了多个独立子系统（如"构建一个包含聊天、文件存储、计费和分析的平台"），立即标记
• 如果项目过大无法用一个规格覆盖，帮助用户分解为子项目

提问原则

• 只问会改变路线的问题 — 能从仓库、日志或现有约定判断的，不重复询问
• 一次一个问题 — 不要用多个问题淹没用户
• 多选题优先 — 比开放式问题更容易回答
• 聚焦理解 — 目的、约束、成功标准
• 如果一个话题需要更多探索，分成多个问题

探索方案

• 存在真实取舍时提出 2-3 种不同方案，附带权衡
• 没有真实取舍时直接给出一个推荐方案和未采用项，不为凑数制造伪方案
• 以对话式呈现，先说推荐方案并解释原因
• 不要过早锁定方案

展示设计

一旦你认为理解了要构建什么，展示设计：

• 按复杂度缩放：直接的部分几句话，复杂的部分详细展开
• 按风险确认：只有会改变架构、外部契约或数据安全的部分需要暂停确认
• 覆盖面：架构、组件、数据流、错误处理、测试策略
• 准备回退：如果什么不合理，随时回去澄清

设计原则

• 隔离与清晰 — 系统拆分为小单元，每个有单一目的，通过定义良好的接口通信
• 可独立理解 — 每个单元能回答：它做什么、怎么用它、它依赖什么
• YAGNI 无情砍 — 移除所有不必要的功能，不为可能的未来需求过度设计

在已有代码库中工作

• 先探索现有结构，遵循已有模式
• 如果现有代码有问题影响了当前工作（文件太大、边界不清等），将改进作为设计的一部分
• 不要提出无关的重构，保持聚焦

设计自审

写完设计后，用新鲜的眼光审视：

1. 占位符扫描 — 有任何"TBD"、"TODO"、不完整部分？修复它们
2. 内部一致性 — 有矛盾的部分吗？架构与功能描述匹配吗？
3. 范围检查 — 是否足够聚焦可以用一个实现计划覆盖？
4. 歧义检查 — 有需求可以两种方式解读吗？选一种，明确写出

发现问题就地修复，不需要重新审查。

用户审核门控

当设计涉及不可逆决策、跨边界影响、数据安全，或用户明确要求先评审时，自审通过后请用户审核：

"设计已完成。请审核后告诉我是否需要修改，确认后我们将开始制定实现计划。"

等待用户回应。如果请求修改，修改后重新进行自审。其他明确、局部、可逆的任务可以记录假设和推荐方案后继续，不增加形式化等待。

与其他技能的关系

/idea (idea-refine)          ← 发散思维，探索可能性
    │
    ▼
brainstorming-and-design     ← 本技能：收敛为具体设计
    │
    ▼
/spec (spec-driven-development) ← 正式的技术规格说明
    │
    ▼
/task-plan (planning-and-task-breakdown) ← 拆解为可执行任务

• idea-refine — 上游：当想法还很模糊时，先用 /idea 发散探索
• spec-driven-development — 下游：设计确认后，进入正式规格编写
• planning-and-task-breakdown — 下游：如果设计已经足够具体，可以直接进入任务拆解

关键原则

Red Flags

• 对存在路线分歧或高风险的任务，以“太简单”为由跳过设计
• 用多个问题轰炸用户
• 为凑数量制造没有真实差异的伪方案
• 对明确、局部、可逆任务强制完整设计流程
• 重复确认不会改变路线的内容
• 设计中有 TBD/TODO 就转入实现
• 对不可逆、跨边界或数据安全决策不等用户确认就开始计划
• 提出不相关的重构建议
• 为可能的未来需求过度设计