AI 写代码飞快，但有多少是”先斩后奏”？
AI 写代码飞快，但有多少是”先斩后奏”？
用 Claude Code、Cursor 这些 AI 编码工具快一年了，有个问题一直困扰我：AI 输出代码的速度越来越快，但它真的理解我想做什么吗？
很多时候，AI 跳过了”想清楚”这一步，直接给出一个看起来能跑的方案。结果呢？代码写完了才发现——功能点对错了，API 设计不对，甚至整个方向都偏了。改一行比重写还痛苦。
这个问题，Superpowers 的 brainstorming skill 试图从根源上解决。
它的核心理念：先说清楚，再动手
brainstorming 是 Superpowers 工作流的第一步，放在”写代码”之前。它的 slogan 很直接：“你必须在任何创造性工作之前使用这个 skill”——无论是做功能、加组件、改行为，都得先过这关。
具体怎么做？它要求 AI 在动手前做三件事：
- 分类任务：先判断这是”探索性 spike”、”bounded 改动”还是”架构级变更”。不同类型走不同流程，但都绕不开”获得人类批准”这一步。
- 问清楚再动手：即使是”加个参数”这种小事，也要在聊天里把设计方案说出来，等你说”可以”才开始写。
- 硬性门槛：文档里有个 规则——在获得批准之前，AI 不能调用任何实现类 skill，不能写代码，不能搭项目框架。
翻译成人话就是：AI 永远不能先斩后奏。
为什么这个设计值得注意？
现在大多数 AI 编码工具强调的是”快”——响应快、生成快、迭代快。但 brainstorming 反其道而行，它在”快”前面加了一个前提：要先确认方向对了，再快。
这个思路其实来自传统软件工程——”Measure twice, cut once”（量两次，切一次）。代码写出来再改，成本远比在设计阶段讨论清楚要高得多。AI 时代尤其如此：AI 生成代码太快了，快到我们更容易冲动接受第一个方案，而不会像以前那样谨慎评估。
brainstorming 强制给这个过程踩一脚刹车。
支持所有主流 AI 编码工具
Superpowers 做了大量适配工作，目前支持：
- Claude Code（官方插件市场）
- OpenAI Codex / Codex CLI
- Cursor
- GitHub Copilot CLI
- Grok Build CLI
- Kimi Code
- Devin CLI
- Gemini CLI
基本上你用哪个 AI 编码工具，都能装上。
适合谁？
如果你一个人用 AI 写小脚本，追求的是速度，那 brainstorming 可能有点”多余”。
但如果你用 AI 做复杂项目开发，或者团队里有人习惯”丢个需求就让 AI 跑起来”——这个 skill 能帮 AI 少走弯路，省下大量返工时间。
它不加速，但它防止南辕北辙。
评论区
登录后可评论。