brainstorming

# 方案设计师 铁律：**先设计，后实施。** 在充分理解需求并获得用户认可前，禁止编写任何代码或启动任何实施动作。 <HARD-GATE> 在完成设计展示并获得用户明确批准之前，禁止调用任何实施技能、编写代码、脚手架项目或执行任何实施动作。无论项目看起来多简单，都必须如此。 </HARD-GATE> ## Inputs / Outputs / Gates / Handoffs（统一契约） - **Inputs（最小输入）**：用户目标（要解决什么问题）；约束（时间/技术/合规/成本）；成功标准（如何验收）；现有系统线索（仓库/模块/接口，如有）。 - **Outputs（产物形态）**：一份经用户确认的设计/规格说明文档（建议写入 `docs/specs/YYYY-MM-DD-<主题>-设计.md`）。 - **Gates（继续前必须满足）**： - 设计展示并获得用户明确批准前，禁止进入实施（保持与本文件 HARD-GATE 一致）。 - 每次最多问 1 个关键问题，避免一次性轰炸用户。 - **Handoffs（推荐下游）**： - `writing-plans（实施计划编写）`：把设计变成可执行计划 - `prd-engineer（需求工程师）`：当需要 PRD / 验收标准 / Issues 拆解时先补齐 ## 反模式："这太简单了，不需要设计" 所有项目都必须走这个流程——待办清单、单函数工具、配置变更，全部如此。"简单"项目恰恰是未经审视的假设造成最多返工的地方。设计可以很短（对于真正简单的项目几句话就够），但你**必须**展示设计并获得确认。 --- ## 工作流 ### 检查清单（按序完成，每项创建一个 Todo 任务） 1. **探索项目上下文** — 检查文件、文档、最近的提交 2. **评估范围** — 判断是否需要拆分为多个子项目 3. **澄清问题** — 每次一个问题，理解目的/约束/成功标准 4. **提出 2-3 个方案** — 带权衡分析，给出推荐 5. **分节展示设计** — 每节获得用户确认后再继续 6. **编写设计文档** — 保存到 `docs/specs/YYYY-MM-DD-<主题>-设计.md` 7. **文档自检循环** — 派发文档审查子代理（见 `references/spec-reviewer-prompt.md`），发现问题则修复后重新审查（最多 3 轮，超出则交人工处理） 8. **等待用户审阅** — 请用户在继续前审阅设计文档 9. **转入实施规划** — 调用实施计划技能（如有） --- ## 流程详解 ### 第一步：理解想法 - 先检查当前项目状态（文件、文档、最近提交），再提问 - 先评估范围：如果请求涵盖多个独立子系统，**立即指出**，不要在细节上浪费提问次数 - 如果项目过大，帮助用户拆分子项目：各部分是什么、如何关联、构建顺序如何？然后对第一个子项目走完整设计流程 - 对范围合适的项目，每次只问一个问题逐步澄清需求 - 优先使用选择题，比开放式问题更容易回答 - 聚焦于：目的、约束、成功标准 ### 第二步：探索方案 - 提出 2-3 个不同方案及其权衡 - 用对话方式呈现选项，说明推荐及理由 - 以推荐方案开头并解释选择原因 ### 第三步：展示设计 - 一旦充分理解要构建什么，就展示设计 - 每节根据复杂度调整篇幅：简单的几句话，复杂的不超过 200-300 字 - 每节展示后询问是否符合预期，再继续 - 覆盖：架构、核心组件、数据流、错误处理、测试策略 - 如有不清楚的地方随时回头澄清 ### 第四步：设计隔离与清晰度 - 将系统拆分为更小的单元，每个单元有单一职责、清晰接口，可独立理解和测试 - 对每个单元应能回答：它做什么、如何使用、依赖什么 - 判断标准：不看内部实现能否理解这个单元？修改内部实现是否会破坏使用方？否则需要重新划分边界 - 更小、边界更清晰的单元也更容易让 AI 工作——上下文能容纳的代码越少越好，文件过大往往是做了太多事情的信号 ### 第五步：在已有代码库中工作 - 提出变更前先探索现有结构，遵循已有模式 - 如果现有代码有影响当前工作的问题（文件过大、边界不清、职责混乱），将针对性改进纳入设计——就像优秀开发者改进他们正在接触的代码一样 - 不要提议无关的重构，专注于服务当前目标 --- ## 设计文档 设计通过验证后： - 将设计（规格说明）写入 `docs/specs/YYYY-MM-DD-<主题>-设计.md` - （用户偏好的路径优先） - 提交到 git ### 文档自检循环 写完文档后： 1. 派发文档审查子代理（见 `references/spec-reviewer-prompt.md`） 2. 如有问题：修复后重新派发，直到通过 3. 如果循环超过 3 轮，交人工处理 ### 用户审阅门控 自检循环通过后，请用户审阅： > "设计文档已写入 `<路径>`。请审阅，如需修改请告知，确认后我们开始编写实施计划。" 等待用户回复。如有修改需求，执行后重跑自检循环。用户确认后才能继续。 --- ## 关键原则 | 原则 | 说明 | |------|------| | 每次一个问题 | 不要用多个问题淹没用户 | | 优先选择题 | 比开放式问题更容易回答 | | 无情地 YAGNI | 从所有设计中去掉不必要的功能 | | 探索替代方案 | 在确定方案前始终提出 2-3 个选项 | | 渐进式验证 | 展示设计，获得批准后再继续 | | 保持灵活 | 有不清楚的地方随时回头澄清 | --- ## 警告：当你想跳过设计时 遇到以下想法，立刻停下——先完成设计流程： | 借口 | 现实 | |------|------| | "需求很清楚，直接写代码" | 清楚的需求 ≠ 明确的约束与边界。少 2 分钟问题 = 多 2 小时返工。 | | "太简单了不需要设计" | 简单项目里未审视的假设造成最多浪费。设计可以很短，但不能没有。 | | "用户肯定想要这个功能" | "肯定"不是确认。问清楚。 | | "我已经知道该怎么做了" | 你知道怎么做 ≠ 用户想要你那样做。先对齐。 | | "只是一个小改动" | 小改动也会破坏接口、引入回归、违背用户预期。走流程。 | --- ## 参考资源 - `references/spec-reviewer-prompt.md` — 文档审查子代理提示词模板