iDWong 头脑风暴：从想法到设计方案
通过自然对话将用户的想法或需求清单转化为完整的设计方案，确认后保存文档，再询问是否生成SRS需求规格说明书。
即使需求看起来很简单，也必须经过此流程。"太简单了不需要设计"是最常见的跳过理由，也是最常见的返工原因。设计可以很短，但必须展示并获得确认。
流程
理解输入 → 澄清问题（逐个） → 提出方案 → 展示设计 → 用户确认 → 保存文档 → 询问是否生成SRS
第一步：理解输入
模式 A：用户描述想法（"我想做 xxx"）
- 探索项目当前上下文（文件、文档等）
- 逐一提问澄清：目的、用户群体、关键功能、约束条件
- 每次只问一个问题，优先给出选项供用户选择
模式 B：用户提供需求清单
- 审查清单，识别：遗漏、模糊、矛盾、边界不清
- 针对问题逐一提问澄清
- 需求清单完整清晰后，才进入方案设计
第二步：提出方案
- 提出 2-3 种实现思路，附上优缺点对比
- 给出明确的推荐方案及理由
- 用对话式语言，不要过于技术化
第三步：展示设计方案
按模块分节展示，覆盖：功能范围与核心模块、界面/交互设计（如适用）、数据结构与流向、关键边界情况处理。
展示完整设计后询问：
"以上是完整的设计方案，请问有什么需要调整的地方吗？"
第四步：确认并保存
用户确认后，先展示任务清单，再逐个执行。
文件命名规范：
prd/planning/{YYYY-MM-DD}-{客户名称}{系统名称}-设计方案-v1.0.md
- 示例：
prd/planning/2026-05-04-PM能源智慧厂区巡检系统-设计方案-v1.0.md - 同名文件已存在时自动递增版本号（v1.1, v1.2...）
- 与 req-doc 技能的命名风格保持一致（日期-客户名称项目名称-文档类型-版本号）
任务清单格式：
| 序号 | 任务名称 | 状态 |
|------|---------|------|
| 1 | 创建文件 - 文档头部 + 项目概述 | [ ] 等待中 |
| 2 | 追加 - 功能范围 | [ ] 等待中 |
| 3 | 追加 - 核心模块设计 | [ ] 等待中 |
| 4 | 追加 - 数据结构与流向 | [ ] 等待中 |
| 5 | 追加 - 边界情况处理 | [ ] 等待中 |
状态标识：[ ] 等待中 → [进行中] → [完成]
执行规则：
- 每次只执行一个任务，执行前更新为 [进行中]，完成后更新为 [完成]，重新展示清单
- 任务1：用 Write 工具创建文件，写入文档头部和项目概述
- 任务2及之后：必须先用 Read 工具读取文件当前内容，再用 Edit 工具追加新内容
- 不 Read 直接 Edit 会报错，必须严格遵守
- 每次追加不超过 150 行，内容过多时拆分为多个任务
- 禁止跳过状态更新，禁止批量执行，禁止一次性写入整个文档
- 每个任务完成后验证文件内容正确，再进入下一个任务
文档结构参考：
---
title: "[系统名称]设计方案"
date: "[日期]"
version: "v1.0"
---
# [系统名称]设计方案
## 一、项目概述
[项目背景、目标、核心价值]
## 二、功能范围
[核心功能模块列表和说明]
## 三、核心模块设计
[每个模块的详细设计：功能说明、交互逻辑、数据流向]
## 四、数据结构与流向
[关键数据实体、数据流转关系]
## 五、边界情况处理
[异常场景、权限控制、特殊业务规则]
第五步：后续行动
保存完成后询问（快速模式下可合并为一句）：
设计文档已保存。接下来：SRS（req-doc）、PRD（prd-writer），或暂不需要？
也可说「快速模式 + PRD」直接出稿。
若选 PRD 且后续要开发 → PRD 确认后须req-docStep F 转 SRS，再page-generator（见../common/prd-to-srs-gate.md）。
- SRS →
req-doc - PRD →
prd-writer（可说「跳过概念版」走快路径；进研发时 Step F） - 否 → 告知可随时生成；歧义时见
AGENTS.md路由与交付模式
关键原则
- 每次只问一个问题，优先给选项
- YAGNI：去掉不必要的功能，保持设计简洁
- 分节展示设计，及时发现偏差，用户有异议时随时回退修改