Claude 写代码前先等一下:这款 brainstorming Skill 给它装了个硬门槛
你有没有过这种经历:让 Claude 帮写一个功能,它”咔咔咔”两分钟就把代码糊出来了,乍一看还挺像那么回事——结果跑起来一堆边界情况没考虑、接口设计跟你想的完全不一样、改起来比从头写还费劲?
这不是 Claude 不行,是它太”急”了。你没让它先想清楚,它就直接动手了。
它给 Claude 加了一道”硬门槛”
obra/superpowers 这个项目里的 brainstorming Skill,就是专门治这个毛病的。它的描述写得相当硬核——
“You MUST use this before any creative work. Do NOT invoke any implementation skill, write any code, scaffold any project… until you have presented a design and the user has approved it.”
翻译一下:只要你让它做点”创作型”的事(新功能、加组件、改行为),它就会先卡住 Claude——不准写一行代码、不准搭项目、不准调任何实现类 Skill,必须先把设计聊清楚、写到 docs 里、commit 到 git,然后等你点头。
听起来很烦对吧?实际上用久了你就发现,这才是真正省时间的姿势。
怎么个”问”法?
它有个流程特别克制:一次只问一个问题。
不是”请告诉我你的需求、约束、成功标准”那种甩锅式提问,而是:
- 先扫一眼当前项目状态(文件、文档、最近的 commit)
- 然后从”这个需求到底要干嘛”开始问
- 能选的就给你多选题,别让你打字
- 一题答完再下一题,答不完就拆细
等把意图、约束、成功信号摸清楚之后,它会提 2-3 个方案做对比,先说它推荐哪个、为什么推荐,再讲其它选项的取舍。
输出不是聊天记录,是文档
最有意思的是这一步:聊完之后它会把整个设计写到 docs/plans/YYYY-MM-DD--design.md,然后 git commit 进仓库。
这意味着啥?意味着你第二天打开项目,这篇设计稿还在那儿——可以作为给团队 review 的素材,也可以作为三个月后”当时为啥这么设计”的考古依据。聊天记录会过期,git 里的 spec 不会。
它还有一道”自审”环节——写完 spec 会回头扫一遍有没有占位符、有没有前后矛盾、有没有模糊地带,发现问题直接改。
跟其它设计类 Skill 怎么搭?
它其实不孤单——superpowers 整个项目有 13 个 Skill 组成一条工作流:
brainstorming→ 出设计稿writing-plans→ 把设计稿拆成可执行的实施步骤test-driven-development→ 严格 RED-GREEN-REFACTOR 写代码systematic-debugging→ 4 阶段定位 bugusing-git-worktrees→ 隔离分支干活verification-before-completion→ 完工前必须跑验证命令拿证据
串起来就是一条”想清楚→拆清楚→写清楚→查清楚”的工程纪律。单装 brainstorming 也行,整套装上更强。
怎么用?
一行命令搞定:
npx skills add https://github.com/obra/superpowers --skill brainstorming
装完之后它会自动挂在”任何创作型请求”前面触发,不用你手动召唤。也可以主动喊一句”let’s brainstorm this feature”让它启动。
支持 Claude Code、Codex CLI、Cursor 这些主流 Coding Agent。
小提醒
它是”硬门槛”不是”建议”——所以装之前心里要有数:
- 纯机械改动(改个变量名、加个 log)也会被它拦下来问两句,这时候会觉得烦
- 你必须真的去看它写的 spec 并认真回复,不能点个 OK 就放行——那样这技能等于白装
- 配合
using-superpowers入口 Skill 一起装会更顺,因为它会在每个新会话开始时就提醒 Claude”记得用 Skill”
但只要你做的是真正的”新功能、新组件、新行为”——尤其是听起来”很简单”的那种——它救的就是这种活。简单活最容易被 Claude 一分钟糊出错的。
GitHub:https://github.com/obra/superpowers/tree/main/skills/brainstorming
GitHub: https://github.com/obra/superpowers/tree/main/skills/brainstorming
评论区
登录后可评论。