夜雨聆风你有没有这种经历——让 AI 帮你写代码，它哐哐哐输出了几百行，看起来像模像样，一跑全是坑。最气的是它还擅自给你加了一堆你没要求的功能。
我最近试了一套叫 Superpowers 的方法论，它做的事很简单：不给 AI 乱写的空间。 下面用一个真实案例串讲全过程——给一个习惯打卡小程序加"灵宠养成系统"，从想法到上线。
安装（30 秒）
Claude Code 里跑两条命令：
/plugin marketplace add obra/superpowers-marketplace/plugin install superpowers@superpowers-marketplaceCursor、Gemini CLI、OpenAI Codex 也支持，不赘述。
它逼你先想清楚，再写代码
我最初的描述是："给打卡小程序加一个灵宠，让用户打卡更有动力。"
如果我直接让 AI 开写，出来的东西大概率没法用——因为我自己都没想清楚。
Superpowers 的第一步叫"头脑风暴"：写任何代码之前，AI 必须先通过提问把方案理清楚。 它连问了我七八个问题：
• "灵宠的成长维度是什么——等级、形态、资源？还是三者都有？" • "用户打卡一次，灵宠获得什么？连续打卡有没有额外加成？" • "灵宠进化之后，除了外观变化，功能上有什么不同？"
被连续问到第六七个问题的时候我有点烦了，有一种冲动想说"别问了直接写"。但我忍住了——如果连这个环节都跳，后面的流程等于白建。
事后看，这个环节帮我做了几个关键决策：灵宠放在右下角悬浮，用金币+灵气双资源驱动，四个进化阶段，定位是"陪伴"而非"游戏"。没有这个环节，我大概率会在写到一半的时候不断推翻重来。
把 1200 行代码拆成 20 个 2-5 分钟的小块
这是整个方法论最"反直觉"的环节。
它要求把任务拆成每个 2-5 分钟能完成的小块，每个小块必须包含文件路径、代码内容、验证标准。
AI 把灵宠系统拆出了约 20 个子任务：数据模型、奖励计算、悬浮组件、掉落动画、进化逻辑、拖动交互……
说实话，看到这个拆解结果我有点犹豫。写 1200 行代码我感觉只需要半天，但这个拆解光列出来就花了将近二十分钟。有一瞬间我在想：杀鸡用了牛刀吧？
后来发生的事让我改变了看法——往下看。
AI 自己跑，你只管审批——但状况也不少
计划定好后，Superpowers 启动"子代理驱动开发"：每个子任务分给独立的子代理，写完一个→两级审查（合规+代码质量）→通过才进入下一个。
我作为人做的事：看审查报告，点"通过"或"不过"。
中间出了三次状况：
状况一：动画被打回三次。 子代理写的资源掉落动画，第一个版本在开发者工具上正常，真机上掉帧严重。打回去换了方案才过。如果没有子代理机制，我大概率会"看起来能跑就行"直接放过去。
状况二：审查太死板。 审查系统标记了一条"阻断"级别的警告——"未处理屏幕旋转后的位置重置"。但我的小程序锁定竖屏，根本没有横屏场景。审查把代码规范当成了铁律，不懂产品需求。我需要手动把这条从"阻断"降为"忽略"。
状况三：一个边界值 bug 被自动审查拦截了。 子代理写奖励计算时，连续打卡第 7 天的 1.5 倍加成算错了——把第 7 天当成了第 6 天（indexOf 和 dayIndex 搞混了）。代码质量审查跑了边界值测试，期望输出和实际输出不匹配，亮红灯。
如果没有这个自动审查环节，这个 bug 大概率留到上线。 为什么？因为人类 code review 的注意力放在"逻辑看起来对不对"，不太会逐行验证边界值。但 AI 审查没有这个"惰性"——它真的是每一行都过。
不写测试就想写功能？门都没有
Superpowers 把 TDD 做到了强制级别：先写测试，测试全部红灯，再写代码让它们一个个变绿，最后重构。
最典型的例子是形态进化逻辑。AI 先写了 8 个测试用例，覆盖四个进化阶段、四个边界值、两种异常输入。全部红灯跑一遍，然后子代理开始写 pet-evolution.js，每写一段就跑测试，直到全绿。
最后重构时，把四个 if 改成了一张查表结构，代码从 45 行瘦到 22 行。因为测试全在，重构的时候心里非常有底。
实际效果：这个模块从交付到上线，零逻辑 bug。 相比而言，我不写测试直接写逻辑的模块，平均每个都要返工一到两次。
测试不是负担，是安全带。这个道理听了好多年，被强制要求写之后才真正体会到区别。
代码审查抓出了我永远不会注意到的 bug
评审环节抓出了三个值得说的问题：
拖动方向反了。 手指往右滑，灵宠往左跑。我检查了三遍坐标转换公式，没问题。最后发现是 touchmove 和 click 事件同时被监听——拖动结束后 click 触发，把位置重置了。加了一个 isDragging 标志位解决。这个问题是评审自动标记的，它检测到"同一元素同时监听两个事件且无互斥逻辑"——如果是人看，大概率不会注意到。
API 混用。 灵宠系统混用了微信小程序 API 和浏览器 API（wx.createAnimation vs requestAnimationFrame），评审标记了所有不兼容的调用。
资源文件不存在。 四个进化阶段的图片路径都写了，但文件还没放进去。评审直接标记阻断。这个标记让我没有忘记在提交前把资源补上。
说真的：到底好不好用
灵宠系统从想法到上线，用了差不多一天。其中约 400 行是 AI 直接生成的。
好的方面：
• 不跑偏。 AI 全程没有偏离预定方向。不用这套方法论的时候，AI 写着写着就会自己加戏——比如自动给灵宠加了一个我根本没要求的"战斗系统"。 • 自动审查真的有用。 奖励计算 bug、拖动方向反了、API 兼容性问题——这三个如果没被审查拦截，都会留到上线。 • 测试让你睡得着觉。 进化逻辑零返工不是巧合。
不好的方面：
• 启动成本高。 拆计划那个阶段确实需要耐心。改一个文案、修一个简单 bug，我不会走这套流程，不划算。 • 审查有时候太死板。 前面说的横屏警告就是例子。系统的判断标准是"代码覆盖所有可能场景"，产品需求是"这个场景不存在"——这种矛盾需要人来调和。 • 创作感弱。 用这套方法论，你的角色更像项目经理而非开发者。如果你享受那种"灵感来了狂写一通"的感觉，它会让你觉得窒息。
我的结论：
如果你是一个人写代码且需求简单明确，Superpowers 不一定能让你更快——启动成本可能吃掉效率提升。
但它值回票价的情况也很明确：多人协作需要统一代码质量；功能复杂容易跑偏；你吃过"AI 写了一大坨代码但没法用"的亏。
Superpowers 本质上做了一件事：把 AI 从"聪明的野马"变成"听话的驮马"。 聪明程度没变，但你知道它会往哪儿走。
灵宠上线后，连续三天打开小程序的用户比例比之前高了约 12%。不能说全是 Superpowers 的功劳，但它至少保证了这个功能没有在开发阶段翻车。
