name: brainstorming description: "在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能或修改行为。在实现之前先探索用户意图、需求和设计。" version: "1.0.0" license: MIT metadata: hermes: tags: [design, planning]
头脑风暴：将想法转化为设计
通过自然的协作对话，帮助将想法转化为完整的设计和规格说明。
先判断这个需求需要多少流程，然后沿着对应的路径推进：理解上下文、完善想法、展示设计、获得你的人类伙伴批准。
建立共同理解
头脑风暴的产出，是一份你的人类伙伴能认出来、也能纠正的理解，它扎根于他们想达成的目标。
- 弄清意图。 用需求本身和手头的上下文，判断预期的结果、它是给谁用的、怎样才算成功。缺这些信息时，在提出功能或方案之前，先问一个聚焦于目的或预期用途的问题。知道这是个什么类型的应用，并不能告诉你你的伙伴为什么想要它。补齐缺失的需求，不等于请他们再授权一遍这个任务。
- 把你的理解写回给对方。 用一段简短的说明概括预期结果、相关约束和成功标准，让你的伙伴可以评估。把他们说过的话和你的假设分开写。请他们纠正，并在把它当作设计简报之前吸收他们的回答。
- 把意图带进设计。 在所选路径的设计产出物里保留这份达成一致的理解：架构级工作是书面规格，有界工作和探路是对话里的设计或试探方案。拿这份理解去核对提出的每个功能和技术选择。
当需求本身已经交代了目的和约束，就把这份理解复述出来，而不是再把同样的问题问一遍。说明要简短；要紧的是它准确、以及对方有机会纠正它。
- 探路：你的人类伙伴批准了问题和试探方案。
- 有界：你的人类伙伴批准了对话里的简短设计。
- 架构级：你的人类伙伴审阅并批准了书面规格，然后审阅书面实现计划并选定执行方式。对话中对设计的批准只允许你去写规格；对书面规格的批准只允许你去调用 writing-plans。
一次回复只批准实际呈现给对方的那个阶段。批准一个想法或功能范围，不等于批准还不存在的产出物。从最早一个未完成的阶段接着做；不要把一次批准变成跳过所选路径其余部分的许可。前置条件未完成期间，允许只读地探索项目。
三条路径
在提出第一个问题之前，先给需求分类，并把分类说出来——"这个看起来是有界的，所以我会在这里直接给一份简短设计，而不是写规格文档"——好让你的人类伙伴能纠正你：
- 探路（Spike） — 一个可行性问题（"我们能不能……"、"有没有可能……"、"糙一点没关系"），它的产出是一个答案，不是要留下的代码。用 2-3 句话说明问题和你打算怎么试，得到一个点头，然后用不牺牲正确性的最低成本去弄清楚。不写设计文档，不写规格文件。以建议的形式汇报发现；过程中搭的任何东西都明确标注为一次性的。
- 有界（Bounded） — 对本仓库里已经存在的代码做范围明确的改动：加一个开关、一个小接口、改一个文件的 bug。"知道这是个什么类型的应用"不算数——有界意味着。如果没有现成的流程可改，这个任务就不是有界的。问那些真正重要的澄清问题，给出一份简短设计（几句话到几个短段落），然后。只有在你的人类伙伴对这份设计说"可以"之后，实现才开始——有界任务的批准和架构级任务的批准是同样硬的关卡。不写规格文件，不写实现计划文档。