别再让 AI 乱写代码了：用 Superpowers 管住 Coding Agent 的 7 个步骤

你有没有遇到过这种情况？

你只是想让 AI 帮你改一个小功能，结果它上来就改了五六个文件。 你只是让它修一个 bug，它顺手重构了一片代码。 你问它“测试过了吗”，它说“应该没问题”。 你让它解释为什么这么改，它开始讲一堆听起来很合理、但你总觉得哪里不对的理由。

这就是现在很多 AI 编程工具的真实问题：

它们不是不会写代码，而是太容易跳步骤。

需求还没问清楚，就开始实现。 设计还没确认，就开始改架构。 测试还没跑完，就宣布完成。 Review 还没做，就准备提交。

所以我看到 Superpowers 这个项目时，觉得它最有意思的地方不是“让 AI 更会写代码”，而是：

它试图给 Coding Agent 装上一套开发纪律。

Superpowers 是一套给 Coding Agent 使用的软件开发方法论。它基于一组可组合的 skills，让 Claude Code、Codex CLI、Gemini CLI、Cursor、GitHub Copilot CLI 等工具，在合适的场景自动进入正确流程。

简单说，它解决的是一个核心问题：

怎么让 AI 不只是“写得快”，而是“交付得稳”。

今天这篇文章，就用清单体给你拆一下： 如果你想让 AI 编程更靠谱，可以从 Superpowers 里学到这 7 个关键步骤。

1. 开始写代码前，先做 brainstorming

很多人用 AI 编程时，第一句话通常是：

“帮我实现一个登录功能。”

然后 AI 就开始写代码了。

但稍微有经验的开发者都知道，这句话背后其实藏着一堆问题：

• • 用账号密码，还是 OAuth？
• • 需要注册功能吗？
• • Session 放 Cookie，还是用 JWT？
• • 是否接入已有用户表？
• • 登录失败怎么提示？
• • 是否需要权限控制？
• • 是否要支持多端登录？
• • 要不要记住登录状态？

这些问题如果一开始不问清楚，后面代码写得越多，返工越麻烦。

Superpowers 的第一步就是： 遇到创造性工作，不要马上写代码，先进入 brainstorming。

它会先通过对话确认：

• • 用户真正想解决什么问题；
• • 当前需求的边界在哪里；
• • 有哪些可选方案；
• • 每种方案的取舍是什么；
• • 哪些东西现在不该做。

这一步看起来慢，其实是在省时间。

因为 AI 最可怕的不是写得慢，而是方向错了还写得很快。

记住一句话：需求没问清楚之前，AI 写得越快，风险越大。

2. 设计确认后，再写 implementation plan

很多 AI 写代码时有一个坏习惯：

想到哪，写到哪。

刚开始说要加功能，写着写着发现接口不顺，顺手改了 API。 改 API 时发现组件不好用，又顺手重构了组件。 重构组件时发现命名不舒服，又顺手改了一堆变量。

最后你打开 diff 一看：

我只是让你修个按钮，你怎么改了半个项目？

Superpowers 的做法是： 在真正执行前，先写一份明确的 implementation plan。

这份计划不是空泛地写：

1. 1. 实现后端；
2. 2. 实现前端；
3. 3. 添加测试。

而是要尽量具体到：

• • 改哪些文件；
• • 每个文件改什么；
• • 每一步的目标是什么；
• • 用什么测试验证；
• • 哪些事情明确不做。

它甚至要求计划清楚到“一个没有项目背景的初级工程师也能照着执行”。

这其实非常适合 AI。

因为 AI 的自由度越大，越容易发散。 计划越具体，越能把它限制在正确轨道上。

你可以把 implementation plan 理解成 AI 开发前的“施工图”。

没有施工图就开工，最后大概率不是房子盖歪，就是预算爆炸。

3. 用 git worktree 隔离 AI 的工作区

如果你经常让 AI 改代码，建议一定要重视工作区隔离。

因为 AI 改代码有两个特点：

1. 1. 改得快；
2. 2. 有时改得很散。

一旦它在你的主工作区里直接动手，风险就来了：

• • 可能覆盖你正在做的改动；
• • 可能留下半成品文件；
• • 可能同时改多个无关模块；
• • 你想回滚时很难判断哪些该保留。

Superpowers 里有一个重要步骤： 设计确认后，使用 git worktree 创建独立工作区。

这样做的好处很明显：

• • 当前工作区不被污染；
• • 每个任务可以在独立分支里跑；
• • 做错了可以直接丢弃；
• • 多个 Agent 可以并行工作；
• • 最后合并前再统一检查。

这点对复杂任务尤其有用。

比如你想同时让 AI 做：

• • 一个前端交互改动；
• • 一个后端接口补充；
• • 一组测试修复；
• • 一个文档更新。

如果全部堆在一个工作区里，很容易互相干扰。 用 worktree 隔离之后，每条线都更干净。

让 AI 动手前，先给它一个独立沙盒。

4. 实现功能时，坚持 TDD：先写测试，再写代码

AI 编程最容易被忽视的一点是测试。

很多时候它会先写实现，然后再补测试。 更糟的是，有些测试只是为了证明它刚才写的代码“看起来对”。

Superpowers 把 test-driven-development 放进核心流程，强调经典的 RED-GREEN-REFACTOR：

1. 1. 先写一个失败测试；
2. 2. 确认它真的失败；
3. 3. 写最小实现让测试通过；
4. 4. 确认测试通过；
5. 5. 再做必要重构。

为什么这对 AI 特别重要？

因为 AI 很擅长生成“看起来合理”的代码。 但“看起来合理”不等于真的正确。

测试的价值就是把它从语言游戏拉回工程现实。

尤其是 bugfix 场景，TDD 更重要。

正确流程应该是：

1. 1. 先写一个能复现 bug 的测试；
2. 2. 确认测试失败；
3. 3. 再修代码；
4. 4. 确认测试通过；
5. 5. 最后确认没有破坏其他测试。

这样你才知道： 它不是碰巧改动后现象消失，而是真的修到了问题。

AI 可以帮你写代码，但测试要帮你判断它有没有写对。

5. 大任务拆小，让 subagent 分工执行

当任务变大时，一个 Agent 从头干到尾，很容易出现上下文混乱。

比如你让它完成一个完整功能：

• • 修改数据库结构；
• • 增加后端接口；
• • 更新前端页面；
• • 补充测试；
• • 修改文档；
• • 检查边界情况。

如果全部放在一个长对话里，AI 很可能前面答应得很好，后面逐渐忘掉细节。

Superpowers 提供了 subagent-driven-development 的思路：

把大任务拆成多个小任务，每个任务交给新的 subagent 执行。

每个 subagent 只处理一个明确的小目标。 完成后再经过两阶段审查：

1. 1. 是否符合 spec；
2. 2. 代码质量是否过关。

这有点像一个小型工程团队：

• • 主 Agent 像 Tech Lead；
• • 子 Agent 像执行工程师；
• • Review 流程负责把关；
• • 测试负责验收。

这种方式适合比较复杂的开发任务。

但要注意一点： subagent 并不是越多越好。

如果计划没写清楚，派再多 Agent 也只是更快地制造混乱。 所以前面的 brainstorming 和 implementation plan 是前提。

任务越大，越要拆小；拆得越小，AI 越不容易跑偏。

6. 每个阶段都做 code review，而不是最后才看

很多人用 AI 写代码，习惯等它全部写完后再看。

但这有个问题：

等你最后才 Review，问题可能已经叠了好几层。

一个错误设计会影响后端接口。 后端接口又影响前端调用。 前端调用再影响测试。 最后你看到的是一整坨复杂 diff。

Superpowers 里有 requesting-code-review，强调在任务之间做 Review。

也就是说，不是等所有东西都写完才检查，而是在每个关键阶段后检查：

• • 是否符合原始计划；
• • 有没有改动超出范围；
• • 有没有过度抽象；
• • 有没有隐藏风险；
• • 测试是否覆盖关键路径；
• • 有没有明显安全问题；
• • 是否引入维护成本。

这一步非常重要。

因为 AI 的错误往往不是单点错误，而是一路顺着错误假设继续展开。

越早 Review，修复成本越低。

你可以给 AI 一个很简单的规则：

每完成一个独立任务，先停下来 Review，不要自动继续扩大战场。

Review 不是拖慢进度，而是防止错误滚雪球。

7. 完成前必须验证，不要相信“应该可以”

AI 最常见的一句话是：

“现在应该可以正常工作了。”

但工程里，“应该可以”没有意义。

你需要的是证据：

• • 测试有没有跑？
• • 构建有没有过？
• • lint 有没有过？
• • 类型检查有没有过？
• • 页面有没有手动验证？
• • 核心路径有没有跑通？
• • 失败场景有没有覆盖？

Superpowers 里有一个很重要的理念：

Evidence over claims，证据优先于声明。

也就是在宣布完成前，必须先验证。

如果是后端功能，至少要跑相关测试。 如果是前端功能，最好还要实际打开页面验证。 如果是 bugfix，要证明原 bug 已经复现并修复。 如果是重构，要证明行为没有变化。

这一步能过滤掉大量“AI 自信但没验证”的问题。

尤其是生产项目，不要接受这种交付方式：

“我已经完成了，但没有运行测试。”

更好的交付方式应该是：

“我修改了这些文件，跑了这些命令，结果全部通过；这个边界场景我也验证了。”

这才是靠谱的工程交付。

完成不是 AI 说了算，是验证结果说了算。

8. 最后用 finishing 流程收尾

很多 AI 开发任务结束得很草率。

它说“完成了”，然后对话就结束了。 但真正的工程收尾还包括很多事：

• • 当前分支是否干净；
• • 是否还有临时文件；
• • 是否需要开 PR；
• • 是否要合并回主分支；
• • worktree 是否保留；
• • 测试结果是否记录；
• • 用户下一步该做什么。

Superpowers 有 finishing-a-development-branch，用来处理最后收尾。

它会倾向于给出几个明确选项：

• • 合并；
• • 开 PR；
• • 保留当前分支；
• • 丢弃 worktree；
• • 继续补充验证。

这点看起来不起眼，但非常实用。

因为 AI 开发不是写完代码就结束，而是要回到正常工程流程里。

好的 AI 工作流，不只管开头和中间，也要管最后怎么收场。

9. 一张表总结：Superpowers 的 7 步工作法

如果你懒得记全文，可以直接收藏这张清单：

严格来说这里是 8 个动作。 但如果你刚开始用，可以先抓住最关键的 7 个：

先问清楚，写计划，隔离工作区，测试先行，拆小任务，阶段 Review，完成前验证。

只要做到这几件事，AI 编程的稳定性就会明显提升。

10. 什么时候适合用 Superpowers？

Superpowers 不一定适合所有场景。

如果你只是：

• • 改一个错别字；
• • 调整一行配置；
• • 问一个简单概念；
• • 临时写个小脚本；

那完整流程可能显得有点重。

但如果你要做的是：

• • 新功能开发；
• • 复杂 bug 修复；
• • 跨模块重构；
• • 涉及测试的改动；
• • 生产项目里的代码变更；
• • 多 Agent 并行开发；
• • 长期维护项目；

那这套流程就很值得用。

因为这些任务的核心问题不是“代码能不能写出来”，而是：

写出来之后能不能相信。

Superpowers 解决的正是这个问题。

11. 如果你不用 Superpowers，也可以先学这套方法

即使你暂时不安装 Superpowers，也可以把它的方法拿来用。

你可以每次让 AI 写代码前，先按这个模板要求它：

先不要写代码。

请先完成：
1. 用 5 个问题澄清需求；
2. 给出 2–3 个可选方案和取舍；
3. 写一份 implementation plan；
4. 标出会修改哪些文件；
5. 说明测试策略；
6. 等我确认后再开始实现。

实现时，再补一句：

请按 TDD 流程：
1. 先写失败测试；
2. 确认失败原因；
3. 写最小实现；
4. 跑测试验证；
5. 最后再考虑重构。

完成前，再要求：

不要直接说完成。
请列出：
1. 修改了什么；
2. 跑了哪些验证；
3. 验证结果是什么；
4. 还有哪些未验证风险。

这套提示词虽然没有 Superpowers 自动化，但已经能明显降低 AI 跑偏概率。

工具可以不一样，但工程纪律应该一样。

12. 总结：AI 编程真正缺的不是速度，而是流程

最后总结一下。

Superpowers 最值得借鉴的，不是某个具体插件命令，而是背后的方法论。

它提醒我们一件事：

AI 编程的下一阶段，不是单纯比谁写得快，而是比谁交付得稳。

如果你想让 Coding Agent 更靠谱，可以从这 7 个动作开始：

1. 1. 写代码前，先 brainstorming；
2. 2. 动手前，先写 implementation plan；
3. 3. 用 git worktree 隔离工作区；
4. 4. 实现时，坚持 TDD；
5. 5. 大任务拆小，交给 subagent；
6. 6. 每个阶段做 code review；
7. 7. 完成前必须验证；
8. 8. 最后用 finishing 流程收尾。

别让 AI 一上来就写代码。 先让它停一下，想清楚，讲明白，再动手。

这可能就是 AI 编程从“能用”走向“靠谱”的关键一步。

如果你平时也用 Claude Code、Cursor、Codex 或 Gemini CLI，可以试着把这套流程套进去。 有更好用的 AI 编程工作流，也欢迎在评论区补充。

今天的分享就到这里。后续我会持续为大家带来实用的技术干货和前沿的技术资讯。如果你对工具链探索感兴趣，我会在公众号「DevLlama」持续分享前端工程化、构建优化等实战经验，欢迎关注，不要错过任何精彩内容！

支持我们，点赞或分享到朋友圈！