将想法头脑风暴为设计

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

首先对所需流程量进行分类，再按对应路径推进： 理解上下文、明确想法、呈现设计，并获得人类伙伴的批准。

三条路径

在提出第一个问题之前，先对请求进行分类并大声说出分类结论——例如“这看起来范围明确，所以我会在此呈现一个简短的设计，而不是写一份规范”——以便人类伙伴可以否决你的判断：

• Spike（探针）——一个可行性问题（“能否……”、“是否可能……”、“快速粗糙即可”），其产出是一个答案，而不是你要保留的代码。用 2-3 句话呈现问题和你的试探方案，获得点头后，以正确性允许的最低成本去验证。不要设计文档，不要规范文件。以建议的形式汇报结论；任何你构建的内容都标记为可丢弃。
• Bounded（限定）——对仓库中已有代码的良好范围变更：新增一个 flag、一个小型端点、一次单文件修复。仅了解应用类型并不够——“限定”意味着你要修改的流程已经存在可供阅读。如果没有现有流程可改，那么该任务就不是限定的。提出真正重要的澄清问题，在对话中呈现一个简短的设计（几句话到几段短文），然后停下。只有在人类伙伴同意该设计后才能开始实现——限定任务的审批与架构级任务的审批一样是硬关卡。不要规范文件，不要实现计划文档。
• Architectural（架构）——新项目、新子系统、改变组件组合方式或变更他人依赖接口的变更。遵循完整流程：提问、方案、分节设计、书面规范，然后进入 writing-plans 技能。

在两条路径之间犹豫不决时，选择更重的那条。棘轮是单向的：任务中段发现的隐藏复杂度会提升路径——停下来，说明情况，并升级。任务中段不会有降级。

反模式：“太简单以至于不需要审批”

每条路径都以人类伙伴在实现前批准你的意图结束。一个待办列表、一个单函数工具、一项配置变更——设计可能只是对话中的两句话，但你必须呈现并获得批准。“简单”任务正是未审视的假设造成最多浪费工作的地方。随着简单性伸缩的是产物本身，而绝不是审批。

红旗警示