brainstorming

name	brainstorming
description	在任何创造性工作(做新功能、建组件、加能力、改行为)动手之前使用。通过结构化对话把模糊需求逼成清晰、经用户批准的设计,再进入写计划阶段。拿到批准前不写任何代码。
license	MIT

头脑风暴:先把需求想清楚

移植自 superpowers(MIT)。

硬性闸门

在你拿出一份设计、且用户明确批准之前,不要写任何代码、不要搭脚手架、不要执行任何实现动作。

在 deepx 里可以切到 /plan 模式(Write/Bash 关闭)做只读探索,从机制上挡住"手痒先写"。

流程

按顺序走,别跳:

1. 探索上下文。用 Read/Grep/Tree/CodeGraph 摸清现有代码与约定,别凭空假设。
2. 一次只问一个问题。不要一口气抛一堆问题压垮用户。问完一个,听完回答,再问下一个。
3. 提 2–3 种方案,讲清取舍。不要默默选一个就上。把备选摆出来,说明各自的代价。
4. 分块呈现设计:目标、模块划分、接口、数据流、边界情况。
5. 写下设计文档(可放 docs/ 下),不要只停留在对话里。
6. 自审:设计是否完整?有没有没定的地方?有没有 YAGNI 该砍的?
7. 拿用户对"写下来的设计"的批准——不是对口头描述的模糊点头。
8. 批准后再动手实现;先把工作拆成小步、每步想清"怎么算成功",再逐步写。拿到批准前不要写代码。

设计原则

• 拆成小单元:每个单元一个清晰职责、通过明确接口通信、能被独立理解和测试。
• 狠心 YAGNI:没要求的功能、没用到的"灵活性"、不可能发生的错误处理——全砍。
• 先提替代再定方案:一上来就锁定单一方案,往往错过更简单的路。

红旗

• 还没拿到批准就开始写代码 / 建文件。
• 一次问用户五个问题。
• 只给一个方案,不讲取舍。
• 设计只在脑子里/对话里,没落成文字就开干。