Superpowers 系列（三）：意图冻结
实现前最大的风险，不是还没有代码，而是目标还没有被共同确认。Agent 会把自己的理解当成需求，把“看起来简单”当成无需设计，把“我先改一点”当成低成本推进。brainstorming 针对的正是这个阶段。
它不是普通头脑风暴，而是一个意图冻结机制：在实现之前，把用户目的、约束、方案取舍和批准状态外化出来。
分级路径解决的是“流程重量”问题
很多团队讨厌流程，是因为流程不分大小。Superpowers 没有把所有请求都塞进同一个模板，而是把任务分成三类：Spike、Bounded、Architectural。
Spike 的输出是探查结论，不是可保留实现。它适合回答“是否可行”。Bounded 适合已有代码流里的小改动，不需要写 spec 文件，但仍要给出短设计并等待批准。Architectural 适合新系统、跨模块变化、接口变更，需要完整设计、spec、自审和计划。这三类路径来自 brainstorming/SKILL.md 的 Three Paths 设计，区别在产物重量，不在批准是否存在。
这个分类的关键不在名字，而在它承认“产物可以轻重不同，批准门禁不能消失”。
| 路径 | 产物形态 | 门禁 |
|---|---|---|
| Spike | 问题和探查计划，最后给建议 | 探查前得到认可，产物标记为 throwaway |
| Bounded | 聊天里的短设计 | 实现前显式批准 |
| Architectural | 分段设计、spec、自审、用户复核 | 设计和 spec 复核后才能写计划 |
这比“所有任务都写长文档”更可用，也比“简单任务随便做”更安全。
升级棘轮防止复杂度被低估
brainstorming 有一个值得单独看的规则：当隐藏复杂度出现时，路径只能升级，不能中途降级。
这个规则处理的是 Agent 常见心理：事情已经做了一半，即使发现比想象复杂，也会倾向于继续推进。继续推进能维持“快完成”的叙事，但会让早期设计承载不了后续影响。
升级棘轮的作用是把复杂度发现变成流程事件：
Bounded -> 发现接口影响或新子系统 -> 停止 -> 升级为 Architectural它不允许 Agent 用“快做完了”压过新事实。只要发现任务影响面超过最初分类，就必须停下来重新分类。这个动作让复杂度暴露成为显式流程事件，而不是被实现进度吞掉。
批准门禁把理解和授权拆开
Agent 理解了需求，不代表用户批准了实现方向。brainstorming 的硬门禁把这两个动作分开。
理解发生在 Agent 内部；设计展示发生在协作界面；批准发生在用户侧。只有批准之后，Agent 才能进入实现或计划。
这个拆分解决了三个问题：
- 用户可以纠正 Agent 的目标解释。
- 方案取舍在实现前暴露，而不是在代码 diff 里暴露。
- 后续计划和测试有一个稳定的目标对象。
最容易被低估的是 Bounded 路径。它不要求 spec 文件，但仍要求短设计和批准。也就是说，Superpowers 的轻量化发生在文档，不发生在授权。
意图冻结不是一次性写死
意图冻结不是说设计永远不能变，而是说变化必须重新进入受控路径。Spike 代码如果要保留，需要重新分类。Bounded 任务如果变复杂，需要升级。Architectural spec 如果用户要求改，需要修改后重新复核。
这背后的设计思想是：变化可以发生，但不能偷偷发生。
在 Superpowers 内部，意图冻结的边界是批准后的 spec 或短设计。后续计划和实现都围绕这份已确认意图展开。如果意图变化，应该回到设计讨论，而不是让实现者在代码里悄悄改目标。
参考资料：
系列导航：