# Zc Brainstorming And Design

> 方案探索

- Skill: `zmice/zc-brainstorming-and-design` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zmice/zc-brainstorming-and-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zmice/zc-brainstorming-and-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zmice (https://skillmd.com/u/zmice)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zmice/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** — 下游：如果设计已经足够具体，可以直接进入任务拆解

## 关键原则

| 原则 | 说明 |
|------|------|
| 一次一个问题 | 不要用多个问题淹没用户 |
| 多选题优先 | 比开放式问题更容易回答 |
| YAGNI 无情砍 | 移除不必要的功能 |
| 探索替代方案 | 有真实 trade-off 时比较 2-3 种方案 |
| 风险门控 | 只有路线、边界或安全会改变时暂停确认 |
| 灵活回退 | 发现问题随时回去澄清 |

## Red Flags

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