大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



很多人已经在用 Codex、Claude Code、Cursor，但 AI 会写代码，不等于会按工程流程稳定交付。本文从开发者和团队两个视角，聊聊我为什么把 Superpowers 理解为一套工作流系统，以及它如何让 Agent 先澄清、再设计、再计划、再执行。

这段时间，Codex、Claude Code、Cursor 这类 AI Coding 工具，我基本都在持续用。

如果只看“能不能写代码”，我觉得这个问题已经没有太大讨论价值了。现在的大模型，至少在大部分日常开发场景里，已经足够能写、能改、能查、能补。

真正的问题其实变成了另一件事：

它能不能稳定地按工程流程做事。

我越来越强烈地感觉到，很多 AI Coding 的问题，不是模型不够强，而是它太容易在一个没有被澄清清楚的前提下，快速产出大量“看起来合理”的东西。

这类结果最麻烦的地方，不是“完全不能用”，而是“局部都像对的，但整体方向可能是偏的”。你刚开始会觉得效率很高，过二十分钟、四十分钟之后，才发现返工成本在后面等着你。

这也是我看待 Superpowers 的起点。

它不是一个花哨的 prompt 包，也不是单纯给 Agent 增加几个技能名。更准确地说，我更愿意把它理解成：

给 Coding Agent 补上一层工作流约束。

如果说大模型解决的是“AI 会不会写代码”，那 Superpowers 解决的更像是“AI 能不能像一个靠谱工程师一样，按顺序把事情做对”。

它表面上是技能集合

表面上看，Superpowers 是一组 skills。

但如果只把它理解成“技能集合”，其实会低估它。

它本质上是一套流程系统

我自己现在更倾向于把它看成一套流程系统。它的重点不是某一个 skill 多强，而是这些 skill 串起来之后，会把 Agent 拉进一条更完整的工程链路里。

它真正重要的是主链路

这条链路大致是：

brainstorming -> spec -> writing-plans -> execution -> verification

翻成更直白的话，就是：

• 先把需求和边界说清楚
• 再把设计思路确认清楚
• 再把工作拆成可执行任务
• 再开始动手实现
• 最后用验证来确认它是不是真的完成了

这套顺序本身，并不新鲜。 任何做过工程的人都知道它合理。

问题在于，人知道合理，不代表 Agent 会自动遵守。

Agent 天然偏向“立刻响应”。你一提需求，它就倾向于立刻给出产出。对于简单问题，这当然很爽；但对稍微复杂一点的任务，这种默认行为其实很危险。

所以 Superpowers 真正有价值的地方，不是在发明新原则，而是在强迫 Agent 不要跳步骤。

我觉得 Superpowers 值得认真看，不是因为它让 Agent 更“炫”，而是因为它试图解决一个很实际的问题：

AI 写代码很快，但工程过程经常是断的。

需求没有被真正澄清

所谓“断”，通常首先断在需求澄清这里。

很多时候，我们自己说需求时就是模糊的。人和人协作时，这种模糊会在讨论里慢慢暴露；但和 Agent 协作时，它往往不会先把问题逼出来，而是直接沿着一个它自己推断出来的方向往下写。

设计没有被显式确认

很多需求其实不是“会不会写”的问题，而是“该怎么写才合适”的问题。边界怎么切、是否复用现有结构、要不要增加抽象、怎么控制改动范围，这些都是设计问题。没有这一层，后面的实现再顺，也只是把偏差执行得很完整。

任务没有被拆解

AI 特别擅长一口气给你很多东西，但工程上很多失控，恰恰来自于“给太多”。文件越改越多，意图越来越散，最后 review 都难 review。

验证没有被当成完成的一部分

这点非常常见。模型很容易把“看起来合理”描述成“已经完成”，而工程里最忌讳的，正是这种乐观。

我后来越来越接受一个判断：

AI Coding 真正缺的，不只是更强的模型，而是更强的流程纪律。

Superpowers 就是在补这一层。

如果只抓主干，Superpowers 最值得看的其实就几步。

brainstorming：不让 Agent 直接开写

这是我最认同的一层。

Superpowers 会优先让 Agent 进入 brainstorming，也就是先理解上下文、再澄清目标、再收敛范围，而不是直接开始写代码。

这件事看上去像是“多了一步”，但实际体验里，它经常是在帮你少走很多弯路。

因为大部分返工，并不是出在实现太差，而是出在一开始就没把问题问清楚。

比如你说“帮我给后台加个批量导出”，一个普通 Agent 可能马上开始补按钮、补接口、补下载逻辑。但一个更受约束的流程会先问：

• 导出的是当前筛选结果，还是全部数据
• 有没有权限限制
• 需要同步导出还是异步任务
• 失败时返回什么粒度的信息
• 是否沿用现有列表页交互模式

这些问题如果不先问，后面写得越快，返工越快。

writing-plans：不让实现变成即兴发挥

设计确认之后，Superpowers 不会直接跳到实现，而是继续走 writing-plans。

这一步的价值，在于它会要求把工作拆到可执行层面，而不是停留在“接下来去实现 XXX 功能”这种空话。

哪些文件改、先写什么测试、验证命令是什么、这一步的预期结果是什么，都会尽量明确。

对我来说，这一步最重要的意义不是“写计划”本身，而是让执行不再依赖即时兴奋和临场发挥。

很多 AI 协作失控，不是因为能力不够，而是因为路径不清楚。

execution：让执行围绕计划，而不是围绕冲动

有了 plan 之后，再进入执行阶段，整个事情就会稳很多。

无论是让子代理分任务执行，还是在当前会话里一步一步推进，本质都一样：不是想到哪写到哪，而是围绕已经确认过的路径往前走。

这一点对于稍微复杂一点的需求特别重要。因为一旦任务里同时存在多个改动点，AI 非常容易“顺手多做一些”。而工程里很多问题，恰恰就坏在这个“顺手”上。

verification-before-completion：没有验证，不算完成

这一层我觉得非常必要。

模型非常擅长组织语言，也非常擅长把“应该没问题”说得像“已经没问题”。如果没有明确的验证要求，很多时候你拿到的是一份语气坚定的推断，而不是一份经过证明的结果。

所以 Superpowers 里有一条我非常认同的约束：

没有新鲜验证证据，就不要宣称完成。

这不是****，这是在防止 AI 协作里最常见的一类幻觉：对结果的过度乐观。

如果你本来就在用 Codex、Claude Code 或 Cursor，那你大概率已经体会过 AI Coding 的爽点，也踩过不少坑。

从开发者视角看，我觉得 Superpowers 最现实的价值有四个。

降低“错误前提下高速产出”的概率

这可能是最核心的一点。

很多时候，Agent 最大的问题不是写得慢，而是写得太快。它在一个错误理解上高速推进时，前二十分钟会让你觉得很顺，后二十分钟才让你意识到前面的方向不对。

Superpowers 的本质，就是尽量在前面把这些偏差暴露出来，而不是等代码铺开后再返工。

让复杂任务更稳

小修小补时，直接对话式 AI Coding 完全够用。

但任务一旦变复杂，真正稀缺的就不再是“能不能生成”，而是“能不能持续保持一致”。需求理解一致、实现路径一致、测试逻辑一致、验收标准一致，这些东西靠模型自己维持，其实并不可靠。

流程约束的意义，就是帮它守住这种一致性。

让协作更容易 review

如果 Agent 一上来就改了一堆文件，没有 spec，没有 plan，也没有中间节点，那后面的 review 会特别吃力。因为你看到的是一坨结果，但看不到这坨结果到底是基于什么理解做出来的。

而有了设计和计划之后，你至少知道：

• 它为什么这么做
• 哪些东西是有意设计，哪些是实现选择
• 哪些范围是确认过的
• 哪些验证是真正跑过的

这会让 review 从“猜它在想什么”，变成“检查它有没有按约定做事”。

让 Agent 更像协作者，而不是代码吐出器

我现在越来越不喜欢把 AI 只当成“高级生成器”。

不是因为它不能生成，而是因为如果你一直只让它做生成，那它很难真正进入工程协作的位置。

一个协作者的价值，不只是写，而是知道什么时候该问、什么时候该停、什么时候该验证、什么时候该提醒你边界风险。

Superpowers 正在尝试把这些行为，变成 Agent 的默认工作方式。

如果站在团队负责人的视角，我觉得 Superpowers 的价值会更明显。

因为团队真正担心的，从来不只是“某个人用 AI 写代码快不快”，而是：

当越来越多人开始用 AI Coding，整个研发过程怎么保持可控。

它把个人技巧变成团队流程

现在很多团队对 AI Coding 的依赖，其实建立在少数人会不会写 prompt、会不会引导模型、会不会自己补流程意识上。

这种方式的上限当然可以很高，但问题也很明显：它难复制、难推广、难沉淀。

而 Superpowers 这类东西的价值，在于它尝试把“个人经验”转成“团队流程”。 一旦方法变成流程，组织才有可能稳定复用。

它增强了交付过程的可审查性

团队协作里，最怕的是结果来得很快，但过程完全不可见。

如果 AI 的产出中间没有 spec、没有计划、没有清晰的验证节点，那你其实很难判断：

• 这段代码是不是建立在正确理解上
• 它是不是偷偷扩大了改动范围
• 这个实现有没有跳过某些风险点
• “完成”这个判断到底有没有证据

有了流程文档和中间节点后，团队管理的抓手会明显多很多。

它让效率和秩序不再对立

我觉得很多团队现在对 AI 的犹豫，本质上不是不想提效，而是担心提效之后秩序会塌。

Superpowers 的意义，不是牺牲效率换秩序，而是试图在两者之间找到一个更工程化的平衡点。

直接开写时，默认前提已经被定义完了

举个很普通的例子。

假设现在有个需求：给后台用户列表增加“批量禁用”功能。

如果直接让 Agent 开写，它大概率会很快开始：

• 改列表勾选
• 加批量按钮
• 补后端接口
• 加操作提示

这些动作本身没有错，但这条路径的问题在于，它默认“问题已经定义完了”。

可现实里，很多关键点其实还没确认，比如：

• 谁可以批量禁用
• 是否允许禁用自己
• 部分失败时返回什么
• 需不需要日志
• 是同步执行还是异步任务
• 是否要遵循现有批量操作模式

如果这些点没有先谈清楚，后面的实现就很容易变成“写得没问题，但不是要的那个问题”。

按 Superpowers 推进时，先收敛问题，再开始实现

而如果按 Superpowers 的方式推进，路径通常会变成：

先 brainstorming，把范围、约束、成功标准收敛出来；
再写 spec，把设计边界明确下来；
再写 plan，把任务拆清楚；
最后再执行实现。

这条路径未必在前五分钟看上去最快，但它通常会让你在后面少付出很多返工成本。

从个人开发者视角看，它减少的是返工；从团队视角看，它增加的是可控性。 这两件事本质上其实是一回事。

不要一上来就研究全部 skill

如果你想尝试 Superpowers，我反而不建议你一开始就把所有 skill 都研究一遍。

最好的方式，是拿一个真实需求跑一遍

更好的方式是，直接拿一个真实需求去跑一遍。

比如：

• 给现有页面加一个业务功能
• 修一个带上下文依赖的 bug
• 针对某个模块做一次受控的结构调整
• 做一个需要前后端配合的小改动

你真正要观察的是流程有没有发生

关键不是需求多复杂，而是你要观察它是不是把 Agent 带进了这样一条路径：

• 先澄清，而不是立刻开写
• 先设计，而不是直接默认实现
• 先拆解，而不是一口气全做
• 先验证，再宣称完成

如果这些事情真的发生了，那你就已经开始感受到 Superpowers 的价值了。

对我来说，它最重要的意义从来不是“多了几个 skill 名”，而是它在不断提醒 Agent：

先把事情想对，再把事情做快。

我不觉得 Superpowers 是银弹。

需求本身混乱、代码库本身失控、团队没有验证意识的时候，再好的流程系统也不可能替你兜底。它也不会把一个普通模型瞬间变成顶级工程师。

但我确实觉得，它代表了一个非常值得重视的方向：

AI Coding 的下一步，不只是模型更强，而是流程更完整。

过去我们总在比较模型能力，比较谁生成得更快、谁补代码更准、谁上下文更长。这些当然重要，但它们解决的更多是“会不会做”。

而在真实研发里，另一个同样重要的问题是：是不是按正确顺序在做。

我现在越来越相信，未来真正拉开差距的，未必只是模型本身，而是我们有没有能力给模型补上工程流程这一层。

从这个角度看，Superpowers 的价值，不是让 AI 更冲动地写代码，而是让 AI 更有纪律地参与交付。

这件事，在我看来，比“再多生成几百行代码”重要得多。