Brainstorming

头脑风暴：将想法转化为设计

通过自然的协作对话，帮助将想法转化为完整的设计和规格说明。

先判断这个需求需要多少流程，然后沿着对应的路径推进：理解上下文、完善想法、展示设计、获得你的人类伙伴批准。

建立共同理解

头脑风暴的产出，是一份你的人类伙伴能认出来、也能纠正的理解，它扎根于他们想达成的目标。

1. 弄清意图。 用需求本身和手头的上下文，判断预期的结果、它是给谁用的、怎样才算成功。缺这些信息时，在提出功能或方案之前，先问一个聚焦于目的或预期用途的问题。知道这是个什么类型的应用，并不能告诉你你的伙伴为什么想要它。补齐缺失的需求，不等于请他们再授权一遍这个任务。
2. 把你的理解写回给对方。 用一段简短的说明概括预期结果、相关约束和成功标准，让你的伙伴可以评估。把他们说过的话和你的假设分开写。请他们纠正，并在把它当作设计简报之前吸收他们的回答。
3. 把意图带进设计。 在所选路径的设计产出物里保留这份达成一致的理解：架构级工作是书面规格，有界工作和探路是对话里的设计或试探方案。拿这份理解去核对提出的每个功能和技术选择。

当需求本身已经交代了目的和约束，就把这份理解复述出来，而不是再把同样的问题问一遍。说明要简短；要紧的是它准确、以及对方有机会纠正它。

• 探路：你的人类伙伴批准了问题和试探方案。
• 有界：你的人类伙伴批准了对话里的简短设计。
• 架构级：你的人类伙伴审阅并批准了书面规格，然后审阅书面实现计划并选定执行方式。对话中对设计的批准只允许你去写规格；对书面规格的批准只允许你去调用 writing-plans。

一次回复只批准实际呈现给对方的那个阶段。批准一个想法或功能范围，不等于批准还不存在的产出物。从最早一个未完成的阶段接着做；不要把一次批准变成跳过所选路径其余部分的许可。前置条件未完成期间，允许只读地探索项目。

三条路径

在提出第一个问题之前，先给需求分类，并把分类说出来——"这个看起来是有界的，所以我会在这里直接给一份简短设计，而不是写规格文档"——好让你的人类伙伴能纠正你：

• 探路（Spike） — 一个可行性问题（"我们能不能……"、"有没有可能……"、"糙一点没关系"），它的产出是一个答案，不是要留下的代码。用 2-3 句话说明问题和你打算怎么试，得到一个点头，然后用不牺牲正确性的最低成本去弄清楚。不写设计文档，不写规格文件。以建议的形式汇报发现；过程中搭的任何东西都明确标注为一次性的。
• 有界（Bounded） — 对本仓库里已经存在的代码做范围明确的改动：加一个开关、一个小接口、改一个文件的 bug。"知道这是个什么类型的应用"不算数——有界意味着你要改的那条流程此刻就在仓库里、可以读。如果没有现成的流程可改，这个任务就不是有界的。问那些真正重要的澄清问题，在对话里给出一份简短设计（几句话到几个短段落），然后停下。只有在你的人类伙伴对这份设计说"可以"之后，实现才开始——有界任务的批准和架构级任务的批准是同样硬的关卡。不写规格文件，不写实现计划文档。
• 架构级（Architectural） — 新项目、新子系统，以及会重构组件之间关系、或改动他人依赖的接口的改动。走完整流程：提问、方案对比、分节设计、书面规格，然后交给 writing-plans 技能。

在两条路径之间拿不准时，选更重的那条。这个棘轮只朝一个方向转：任务进行中发现隐藏的复杂度，就升级路径——停下来、说明情况、升上去。任何情况下都不在任务中途降级。

反模式："这个太简单了，不需要批准"

每条路径的终点都是你的人类伙伴在实现之前批准所要求的设计。一个有界改动可能只需要对话里的两句话。一个新的待办事项列表项目是架构级的，需要书面规格和计划交接。按所选路径缩放产出物；在实现之前走完该路径的所有审阅。