方案头脑风暴 · brainstorm-spec

二次开发：本技能改编自 superpowers 的 brainstorming（MIT © 2025 Jesse Vincent），在保留其核心方法论基础上，升级为「提示词 + 可执行 CLI」双形态。署名见本目录 NOTICE.md 与仓库 THIRD_PARTY_NOTICES.md。

这个技能做什么

通过协作对话（或命令行单轮），把一个还很模糊的想法——"我想做个活动""这个流程想改改""要不要上新功能"——收敛成一份结构完整、用户可审批的设计规格书。

核心立场：先想清楚，再动手。在任何交付动作之前，先做路径分级、澄清问题、比较方案、逐节确认设计，并把结论落盘为 YYYY-MM-DD-主题-design.md。未经用户明确批准，不进入交付动作（HARD-GATE）。

适用于中文业务语境：产品需求梳理、活动立项、方案选型、流程改造、会议纪要后的方向对齐。

输入要求

• 必填：一段想法描述——你想做什么、为什么做、给谁用。可以是几句口语、一段需求草稿、或一次讨论的纪要。
• 可选：已有约束（预算、时间、人手、必须兼容的现状）、成功标准、参考案例。
• 信息不足时不要替用户做主：对话形态一次只问一个问题补齐；命令行形态把缺口列入"待确认问题清单"，并在对应处标注"（待确认）"。

输出结构（模板见 scripts/templates/brainstorm-spec.template.md）

1. 目标与背景：复述对需求的理解——要解决什么问题、为谁、成功标准是什么；明确区分"用户已说的"与"我的假设"。
2. 路径分级判断：Spike（可行性试探）/ Bounded（已有体系内小改）/ Architectural（新项目或大改，走完整流程），附判断理由，并声明用户可否决。
3. 候选方案对比：2–3 个方案，表格列出做法、优点、代价/风险，并给出明确推荐与一句话理由。
4. 推荐方案设计（实施要点）：分节呈现——流程/模块如何拆、各方如何协作、异常与兜底怎么处理；每节按复杂度伸缩篇幅。
5. 风险与待确认问题清单：依赖、预算、时间风险；以及信息缺口（统一标注"（待确认）"）。
6. 四项自检结果：占位符扫描 / 内部一致性 / 范围是否过大 / 歧义检查，逐项给结论。
7. 审批门（HARD-GATE）：明示"本规格书未经批准不得进入交付动作"，留待用户批复。

工作流程

形态一：交互式对话（默认，适合人在回路中）

1. 先复述理解：用一小段话总结你理解的目标、约束、成功标准，区分事实与假设，邀请用户纠正。用户已说清的部分不要重复追问。
2. 路径分级并大声宣布：第一次提问之前，先说明"这看起来是 Bounded，所以我直接在这里给你一个简短方案，而不是写完整规格书"，给用户推翻的机会。
   • Spike：只是一个可行性问题（"能不能……""这样做可行吗""先快速试试就行"），产出是结论而不是要保留的方案。用 2–3 句话说清要验证的问题和怎么试，点头后用最小成本验证，结论以建议形式回报；试过的东西标记为"一次性"。
   • Bounded：在已有体系内、范围清晰的小改——一个新规则、一个小活动、一份一页纸流程。问真正关键的澄清问题，在对话里给出简短设计（几句话到几段短文字），然后停下来等明确同意。不写规格书文件。
   • Architectural：新项目、新子系统、或会改变协作接口的大改。走完整流程：提问 → 提方案 → 分节设计 → 落盘规格书 → 自检 → 用户评审。
3. 一次只问一个澄清问题：每条消息只问一个问题；能出选择题就出选择题；聚焦目的、约束、成功标准。
4. 提 2–3 个方案：带权衡和推荐，推荐方案放最前面并说明理由；用 YAGNI 原则砍掉每个方案里不必要的部分。
5. 分节呈现设计，逐节确认：每讲完一节问"这部分对吗"，不对就回去改。
6. 落盘：Architectural 路径把确认过的设计写到 YYYY-MM-DD-主题-design.md。
7. 四项自检：写完后以新鲜眼光检查——有没有 TBD/TODO 占位？各节有没有自相矛盾？范围大不大要不要拆？每条需求会不会有两种解读？发现就就地修。
8. 用户评审门：请用户评审写好的规格书，要改就改完重新自检；用户批准后才谈后续动作。

形态二：命令行单轮收敛（适合批处理 / 无人在回路）

批处理做不到"一次只问一个问题"，所以 scripts/draft_brainstorm_spec.py 把一轮想法描述一次性收敛成完整规格书草稿：路径分级判断 → 2–3 方案对比（各带权衡与推荐）→ 推荐方案实施要点 → 风险与待确认问题清单 → 四项自检结果。缺口一律进"待确认问题清单"并在正文标注"（待确认）"。草稿不等于批准：CLI 输出末尾保留审批门提示，交付后仍需用户过目批准。

质量规则（必须遵守）

• 先复述、再提问：任何方案之前先把理解写出来邀请纠正；用户已给的信息不要重复要。
• 一次只问一个问题（对话形态）：偏好选择题；一条消息塞多个问题等于没有聚焦。
• 推荐必须给理由：2–3 个方案不能只罗列，要带权衡、带明确首推。
• HARD-GATE：未经用户批准，不得进入任何交付动作（立项落地、资源申请、排期、对外沟通）。批准的是"当前这一步"，不是后续所有步骤。
• 棘轮只升不降：中途发现隐藏复杂度，必须停下来升级路径（Bounded→Architectural）；没有任何理由可以中途降级。拿不准走哪条路时，走更重的那条。
• 不要假装"太简单不用批"：再小的改动也要走完所选路径的审批；Spike 的产出是结论，把验证产物直接当正式方案是一个新任务，要重新分级。
• 不确定就标注"（待确认）"：不编造预算、人手、数据、外部依赖。
• YAGNI：每个方案都砍掉当前目标不需要的部分。

边界与异常处理

• 想法过大（如"做一个带社群、商城、数据看板的平台"）：先别急着抠细节，立即指出需要拆分成若干子项目——各自是什么、什么关系、什么顺序——然后只对第一个子项目走完整设计流程；每个子项目单独一份规格书。
• 拿不准路径：选更重的路径。把"我先算成 Bounded 跳过规格书"本身就是疑虑信号。
• Spike 验证完想保留成果：那是一个新任务，重新分级、重新走审批，不能默认继承 Spike 的批准。
• 信息严重不足：对话形态继续一次一问；CLI 形态在规格书"待确认问题清单"中列全，并在正文相应位置标注"（待确认）"。
• 已有体系存在历史问题（流程臃肿、职责缠绕）：可以在设计中纳入针对性的小整改，但不做与当前目标无关的大规模重构。

与脚本配合

• 批量 / 命令行场景：scripts/draft_brainstorm_spec.py（纯标准库，一条命令把想法描述收敛成完整规格书草稿）。
• 交互式场景：直接按上文"形态一"执行，脚本只负责把最终确认的设计落盘。
• 自定义模板：复制 scripts/templates/brainstorm-spec.template.md 修改后使用。