superpowers验证方法

兄弟们，用 ai 写代码最痛苦的是什么？不是他不会写，而是他乱写。你让他做一个登录功能，他上来给你整五百行代码。环境跑不通，逻辑对不上，改一个 bug 冒出三个新的。为什么？因为它没有流程，没有设计就写代码，没有测试就提交，这跟工地没打地基就盖楼有什么区别？ 今天我要给大家介绍 github 上最硬核的 ai 编程工作流插件，叫 superpowers。 它不是一个工具，它是一套完整的工程规范系统，它把先想清楚再动手写。这个铁律强制写进了 ai 的 底层逻辑。 今天这期视频，我会从入门到精通，完整拆解它的十四个原子技能。它有三个斜杠命令，以及小白和大神分别怎么用。视频最后有全量命令对照表，可以暂停截图保存。 superpowers 到底是什么？ 一句话，他让 ai 像硅谷高级工程师一样工作，他把完整的软件开发流程拆成了十四个独立技能，这些技能不需要你手动调用， ai 会根据你做的事情自动匹配， 你聊需求，它自动启动头脑风暴，你让它写代码，它自动走 tdd 流程。这十四个技能分四大类，第一类，设计类，头脑风暴，也就是 brainstorming， 所有项目的起点。 ai 不 会直接写代码，而是像项目经理一样，一次问你一个问题，你的目标是什么？输入格式是什么？边界条件在哪？它会提出二到三个方案让你选。最后生成一份完整的设计文档 保存到项目里。注意，有一个硬规则，没有通过审核的设计文档， ai 绝对不允许写任何代码。第二类，执行类，一共五个技能，这是最核心的部分。 get walk to 隔离，它会在你的电脑里开辟一个平行宇宙，让 ai 在 影子文件夹里干活，你的主分支永远干净。战术拆解，也就是 writing plans， 把大需求切成每步两到五分钟的微任务，每个任务都有精确的文件路径和验证标准。 子代理，驱动开发，也就是 sub agent driven development， 这是它的王牌功能。 ai 会分列出独立分身去干活。每个任务完成后，还有两轮审查，第一轮查规格是否对齐，设计文档，第二轮查代码质量，单部执行，如果你不放心，可以让 ai 跑一步停一步，每部都等你确认。并行代理，多个互不依赖的任务同时开工，效率翻倍。 第三类，质量类， t d d 测试铁律，先写测试，再写代码，如果代码写在了测试前面， ai 必须删掉代码重写，没有例外。系统化调试。四步，根音分析法，先读报错，再复现，再分析模式，最后才动手修，找不到根音绝对不修。它还有个隐藏武器叫根音回数，能沿着调用链一直追到 bug 的 源头。完成前验证， ai 说搞定了不算数， 必须跑完验证命令，看到绿色通过才算代码审查，每完成一个任务，自动派出审查员，分身，严重级别的问题必须立刻修。第四类，交付类， 完成技能。所有任务完成后， ai 会给你四个选项，本地合并、推送、创建 pr、 保留分支，或者直接丢弃。它会自动验证测试，清理工作空间，自定义技能，你可以把自己的经验写成技能文件，以后 ai 每次都会遵守你的规范，说了这么多，怎么装啊？超级简单！ cloud code， 用户 在终端里输入这条命令， plug in install superpowers， 看到成功提示就完事了。 cursor， 用户在 agent 聊天窗口输入 add plugin superpowers 就 行。 codex， 用户直接跟 codex 说，按照 superpowers 官方文档来操作。 germany c l i 用户输入 germany extensions install， 后面加上仓库地址。 windows 用户注意，一个是你的电脑需要能跑 get 命令就行， 因为 superpowers 的 钩子脚本需要 git bash 来运行。如果你平时能在终端用 git 命令，那就已经装好了。装好之后不需要任何额外配置，重启你的 ai 工具，所有技能就自动加载了。怎么验证？装好了随便说一句，帮我做一个 x x 功能。如果 ai 开始问你问题，而不是直接写代码，那就说明 superpowers 已经生效了。 装好了怎么用？小白只需要记住四个字，聊牌干收！第一步，聊需求。在 ai 工具里直接说我要做一个 x x 功能，比如你可以说帮我做一个混凝土封包， ai 会一个一个问你问题， 就像跟同事聊天一样，回答就行。聊完之后， ai 会生成一份设计文档，保存在你项目的 doc 目录下，你一定要看一眼这份文档，觉得没问题，再往下走。第二步，排计划，看到设计稿没问题，你只需要说根据这个设计写个开发计划。 ai 会把整个功能拆成一个小任务，每个任务二到五分钟，每个任务都有明确的文件路径，具体代码和验证步骤。这时候 ai 会问你用全自动模式还是单步模式？第三步，开工。 如果你说全自动， ai 就 启动只代理驱动模式，它会自动创建一个隔离的工作空间，然后分裂出独立分身去干活。每个分身只做一个任务，做完之后还有两轮审查，你在整个过程里可以什么都不管。如果你想亲自把控，就说单步模式， ai 跑一步停一步，每步都要你确认。第四步，验收所有任务完成测试全率之后， ai 会问你怎么处理这些代码。 你有四个选项，本地、合并、推送、创建 pr， 先保留或者丢弃。选完之后，它会自动清理临时文件，干干净净交到你手里，就是这么简单。聊、排、干、搜，四步搞定，四步流程掌握了，接下来是进阶内容。首先， superpowers 提供了三个直接的斜杠命令， 你可以随时手动触发斜杠 brainstorm， 直接启动头脑风暴，不用先描述需求，斜杠 right plan 直接进入计划编写模式，斜杠 execute plan 直接开始执行已有的计划。然后是大神级别的用法。第一招， visual companion 格式化伴侣做前端 ui 或者页面设计的时候，头脑风暴会自动问你要不要预览效果。 如果你同意，他会在本地起一个服务器，把设计稿、布局对比图直接展示出来。你可以点击选择你喜欢的方案， ai 会读取你的选择继续推进。这个功能做前端的时候超级好用。第二招，并行代理。如果你有多个互不依赖的任务，比如修三个不同模块的 bug， 你 可以说并行处理这些问题。 ai 会同时派出多个分身各自独立干活， 三个问题同时解决，效率翻倍。但注意，如果任务之间有依赖关系，就不能并行。第三招，系统化调试遇到 bug， 不要跟 ai 说帮我修一下，而是说用系统化调试来查这个问题。 ai 会走严格的四步流程，仔细读报错、稳定、附件问题， 对比正常代码找差异，先写测试再修。如果修了三次还没好， ai 会主动质疑架构设计，而不是继续瞎改。第四招，自定义技能。你在 dot cloud slash skills 目录下创建一个 s k i a l 文件，把你的经验写进去。比如你总结了一套钢结构焊缝检测规范，写成技能文件后，以后 ai 每次做相关项目都会自动遵守你的规范，相当于把你的专业知识变成了 ai 的 能力。第五招，模型选择策略 子代理模式下简单任务， ai 会用便宜快速的模型，复杂任务自动切换到强力模型，你什么都不用管。总结一下 superpowers 的 核心理念就一句话， 先想清楚再动手写他把硅谷最成熟的工程规范变成了自动化的工作流，让你的 ai 编程从碰运气变成走流程。现在我把所有内容整理成了这份 superpowers 实战红宝书，大家可以暂停截图保存，用好 superpowers， 你 的 ai 编程质量会有质的飞跃。我们下期视频不见不散！

用 cloud code 做项目，如果你只装两个插件，装这两个就够了。 g stack 和 superpowers， 一个管方向，一个管质量，两个搭在一起，就是一套完整的 ai 增强开发闭环。这期我们讲这两个如何结合使用，有点一加一大于二的感觉。先说 g stack， 这是 y c 总裁 gary tham 开源的一套虚拟工程团队二十三个斜杠命令，每个命令对应一个专业角色。 office hours 是 y c 合伙人，帮你诊断产品方向。 u a 是 测试主管，用真实浏览器帮你验收， ship 是 发布工程师帮你推代码上线。一句话总结， g stack 管的是方向、验证和交付。再说 superpowers， 这是一套强制工程纪律框架，十四个技能覆盖编码全流程。它有几个铁律，写代码前必须 bring storming， 不 写测试，不准写实现代码找不到根音就不许修 bug。 背后是一个百分之九十四 pr 拒绝率的开源项目，对代码质量极其严格。 一句话总结， superpowers 管的是思考质量和纪律，一个管方向和交付，一个管思考和质量能力边界几乎没有重叠。这就是为什么他们搭在一起效果这么好，为什么说这两个搭配好。三个层面看，互补。第一，能力不重叠。 g stack 解决的是做什么，做成什么样，怎么上线的问题。 superpowers 解决的是怎么把代码写好的问题，一个是产品视角，一个是工程视角。第二，触发机制互补。 g stack 是 你主动输入斜杠命令来触发，比如你输入 q a， 它就启动测试。 superpowers 是 自动触发的， agent 检测到适用场景就会启动， 你不需要手动调用，一个主动，一个自动，不会抢同一个出发点。第三，覆盖范围互补， stack 覆盖产品全生命周期，从需求诊断到上线监控， superpowers 覆盖编码全流程，从需求经验到代码审查，两个拼在一起，就是一个完整的从想法到上线的闭环。但在讲具体怎么用之前，先说一个核心观点。 用这套工具链，我发现一个规律，前期花时间把想法想清楚，把方案审清楚，把任务拆清楚，比后面花时间写代码更重要。简单说就是百分之二十的思考，决定百分之八十的结果。 好，接下来告诉你具体怎么搭配用。第一个，再想清楚。这一步，你用 brainstorming 把需求理清楚之后，别急着动手写代码，先丢给 auto plan， 让它从产品、设计、工程三个角度帮你挑毛病。很多时候你自己觉得想清楚了，一审查才发现漏了东西。第二个，再拆任务这一步， writing plans 把大需求拆成小任务之后，我习惯再跑一遍 plan review。 因为拆任务的时候容易只看表面，忽略底层的价格问题，数据怎么流转，状态怎么切换，异常怎么处理，这些细节不提前想清楚，后面一定会反攻。第三个，再验证。这一步也是我踩坑最多的地方， t d d 跑通了，单元测试全率你以为没问题了？但一打开浏览器看真实页面布局歪了，接口超时了，手机端溢出了。所以 t d d 之后一定要接 q a， 让真实浏览器帮你跑一遍完整流程， 光看测试报告是不够的。第四个，在排查问题这一步， superpowers 的 调试能帮你定位到大概哪里出了问题。但如果涉及到页面渲染、网络请求这些，你就需要 g stack investigate 了，它能打开浏览器，看到真实的 do m 结构和控制台报错比光看代码猜问题靠谱的多。第五个，在收尾发布这一步， superpowers 帮你把分支整理好，测试跑完，代码审查通过，然后 shift 接手，自动同步主干推代码，创建 pr， 你 只管确认剩下的它来。当然不是每个任务都要走完整流程，实际开发中我一般是这么判断的，如果就是改个小 bug， 调个配置，直接改就行， 改完看一眼效果就够了。不用 brainstorming， 也不用 plan review， 杀鸡不用牛刀。如果是新功能或者比较明确的重构，我会在动手之前先 brainstorming 想清楚，写个短 plan， 做完之后跑一遍 q a 验证。只有跨模块的大改动，新架构，这种才走完整闭环。 从头到尾全套流程，该审查审查，该测试测试不审任何一。核心原则就是按需组合，不要过度流程化，该严格的时候严格，该快速的时候快速。最后一个实操要点， c l a u d e m d 配置不配，这个等于装了白装。在项目的 c l a u d m d 里，要用分区来管理两个插件的分工，比如浏览器操作全部走 g stack 的 browse， 编码流程全部走 superpowers 的 自动触发，把模糊的指令映射到确定的技能行为就变得可预测。具体怎么配置，我觉得应该你把这两个的仓库给到 ai， 跟他一起交流，最后写出这一个文档才是最适合你的，因为每个人的情况不一样， 跟 ai 交流之后，把你的情况给到 ai， 这样他才能给你指导出最适合你的这个文档。最后分享一个我自己的心得， gustak 和 superpowers 这套搭配用下来，最大的体会是，你作为人的核心价值不在于写代码，而在于前期的思考、审查和规划。用 brainstorming 把模糊想法变清晰，用 auto plan 从多个视角审查方案，用 writing plans 拆成可执行的微任务。这些前期工作做好之后，后面的编码测试部署，设好流程，让 ai 自己跑就行。花时间思考比花时间写代码更值。

给 ai 一个 superpowers， 它能干嘛呢？哈喽大家好，上期推荐 b m a d 的 时候，很多朋友想了解 superpowers， 这期就带大家来安装一下。首先我们进入 superpowers 的 get 地址，可以看到它的 star 呢，也是有四点五万，比 b m a d 还要抵一点。 同时 qqcode 的 作者呢，也是在这个项目里面参与的，开发 superpowers 和 bm a d 笔呢会更容易上手一点，适合小型项目和小功能的快速迭代与开发。同时它还结合了 git 以及 skills， 能让需求在开发过程中风险更低，理解的更全面。如果你在 b m a d 里当老板，但是还要去做角色，觉得不够爽，就用 superpowers 做一个甩手掌柜，去体验全自动流程的托管吧。大家觉得 superpowers 和 b m a d 比哪个更好用一点呢？欢迎评论区讨论。 superpose 的 安装方法一共有两种，一种呢是使用它的 get 地址，把 get 地址给 g l c 的， 让它自动安装就行了。第二种就是用 g i p 包实现本地安装，我们使用第二种方式点击下载， 下载好后我们把它的这个目录呢复制到 g l c 的 目录里面，在 g l c 的 里面打开一个终端，输入 g l 的， 然后用酷狗的官方迷你去安装一下，选择第一个，选择第三个，我们回车，然后把 superpowers 的 目录拖进来，再点个回车，可以看到它这边已经安装好了，然后这里也是启动状态的。 第二步，安装 so powers 的 基础 skills。 首先我们在它的目录里面可以找到 skills 这个目录，我们点进来可以看到这里有十四个文件夹，这十四个文件夹就是它的基础 skills， 我 们从这里打开一个终端， 输入 code， 然后让它自己安装一下 yes 就 行了，继续 yes， 继续， 可以看到这边已经成功安装了十四个 skills， 这十四个 skills 呢就是它的基础技能包。后续我们在使用 safos 的 时候呢，它会先检查一下这个任务 需要用到哪些 skills， 然后将这些 skills 都启动起来，一起完成这个任务。好了，今天就到这里。

我用了 superpowers 一 段时间之后，最大的感受它不是让 cortex 更快写代码，恰恰相反，它是在让 cortex 不要太快写代码。因为现在 ai coding 里一个常见的问题是，需求还没有澄清，边界还没有确认， 测试还没有想好， cortex 已经开始改文件了。小任务这样做还行，但一旦任务变复杂，这种直接开写的方式很容易出问题。所以这一期我们聊聊 superpowers 到底解决了什么问题。 先简单说一下 superpowers 是 什么，它不是一个单独的 skill， 而是一套给 coding agent 使用的软件开发方法论。在 codex 里面安装很简单，如果 是 codex c r i， 打开 plug ins， 搜索 superpowers， 选择安装就可以了。如果是桌面版的 app， 在 侧边栏 plug ins 或者是那个插件里面找到 superpowers， 点加号安装就可以了。 插件我找到 superpowers 点安装就可以了，因为我已经装过了，所以这边不是加号了。装好之后，它就会作为一组 skills 在 cortex 里面使用。这也是我觉得它很适合 cortex 的 地方。它不是让你每次手动复制一堆 prompt， 而是把一套软件工程流程变成 cortex 可以 按需使用的 skills。 我 理解 superpowers 的 核心就是把 ai coding 拆成 七个顺序执行的步骤。第一步就是头脑风暴，在写代码之前先澄清需求，探索方案，确认边界。第二步就是创建独立工作区，不要直接在当前工作区里乱改， 而是创造一个更安全的独立开发环境。第三步是写实施计划，把任务拆成小步骤，明确要改哪些文件，怎么实现，怎么验证。第四步是指代理开发， 把具体任务交给 subdivision 去执行，让主流程可以更清楚的组织和检查。第五步是 tdd 测试，驱动开发，先考虑怎么证明它是对的，再写实现，而不是先写一堆代码再说。第六步是代码审查，改完不是马上说完成，而是让另一个审查视角检查问题。 第七步是完成分支，最后做验证，收尾、合并或保留分支。所以它的流程不是需求到写代码，而是这一套头脑风暴，到独立工作区域，到实施计划，到代理开发，到 t d d， 到代码审查，再到完成分支，每一步都是一个独立的 skill。 这就是 superpowers 最核心的地方，它把软件工程流程拆成了 ai 可以 执行的一组 skills。 我在 codex 里用下来，感觉它是比较无缝的，尤其是装成插件之后，它不像一个你每次都需要手动调用的命令集合， 更像是给 codex 加了一套开发习惯。比如需求不清楚的时候， codex 会先倾向进头脑风暴，先问问题，探讨边界，确认需求，而不是直接开始改代码。准备实现之前，它会更容易进 writing plans， 设计代码质量时，它会提醒 pdd review 和验证。这就是我觉得就 pos 很 有价值的地方，不是每次靠你提醒 cortex 守流程，而是让 cortex 默认更容易按照工程流程工作。这里也放一个 sdd 的 背景在里面， s d d， 也就是 spec driven development。 规范驱动开发，它的核心思想是不要一上来就写代码，而是先把要做什么说清楚，比如 open spec， 它更偏规范管理，它关注的是把需求变更约定整理成可维护的规范。 spec kit 更偏规范驱动开发流程，它通常会通过一组命令模板，引导 ai 从 需求深层规范计划任务再去实现。而 superpowers 更偏工程纪律和 skills 集合。所以我会这样理解， s d d 解决的是先要把做什么想清楚， superpowers 解决的是做的过程中怎么守流程。最后说一个大家可能关心的问题， token 消耗，而我自己用下来。 superpowers 在 cortex 里的题感是比较轻的，因为它不是每次 都把一大堆规范文档塞进上下文，而是通过一个个 skill 在 需要的时候触发对应流程。当然，它也会消耗 token 头脑风暴，它要讨论需求， writing plans 要写生成计划 review 要读取代码和分析问题， 都不是免费的，但它的消耗更像是按阶段按 skill 触发。而 openstack 和 stackkit 这类的 sdd 工具通常会生成更多的规范计划任务文档，好处呢是结构更完整，坏处是文档越多，后续带入上下文的 token 压力也可能更大。我 之前看到 speckey 的 社区里面有人反馈过类似的问题，有依据里估算，在 cloud code 里，一组 speckey 个 months 可能占用大约十八点六 k 的 tokens， 在 codex c i 的 上下文窗口里面大概占百分之七到百分之十。这个不是官方的 benchmark， 但它说明一件事，流程工具本身也有上下文成本。所以我的判断是， opens back backit 更适合强规范、强文档、强交付约束的任务。 superpowers 更适合日常 ai coding， 因为它更像一层工程流程约束 动成本更低，体感也更自然。所以这一期的结论是， superpowers 不是 给 ai 加超能力，而是给 ai 加工程纪律。它解决的不是 ai 不 会写代码，而是 ai 太容易跳过软件工程流程模型提供能力， superpowers 提供纪律。 下来几期我们会继续拆开看。为什么先要头脑风暴？为什么要写 plans？ 为什么 ai 写代码需要 pdd？ 以及为什么 ai 也需要 code review？ 下一期我们继续。

之前讲 superpowers， 看到很多兄弟们提到了另一个 oh my open code 之后简称 o m o。 于是我马不停蹄给大家伙安排上本期视频，从部署到实测，一条龙服务，总共三个案例，最后再总结下两者的区别，顺手点个收藏关注赞我们发车。 首先打开官网复制这里的安装命令，注意要去 l l m 代理进行粘贴。我依旧选择 open code， 可以 看到先要配置大模型，通通先选到，当然可以按照你订阅的情况先配置好。 我在这里因为 note 版本适配的问题切出去了一次，可以看到 open code 做了优化，它这里明确提示如何回到之前的筛选，从而继续之前的操作。然后我这边选用官网的推荐方式 box 进行安装， 复制这个命令，回到之前的上下文，然后切换到 note。 二十二、看到他通过 npm 局安装棒，然后再来安装 omo， 过程很顺利，最后他是通过查询 obo 的 点节省文件来验证安装结果， 能看到里面多了一个 omo 的 插件配置项。最后就是新手村的介绍环节了， 先象征性的祝贺一下，接下来也就是新手提示，当然也是我们之后需要测评的点，一、使用魔法 auto work， 二、 a 阶的团队。三、项目特性，像 lsp a s t 工具，强制闭环，还有精选 m c p 这些 还在看的兄弟弹幕冒个泡，咱们继续测 o m o 的 核心功能。我们先看第一个案例，需求很简单， 我们主要讲前缀 archwork， the magic word， archwork 也可以简写 u l w， 这是 o m o。 的 灵魂，可以说有了它才会激活 c c fors 核心管家的能力，它会调度所有智能体，让它们各司其职， 而且有关 o m o 的 特性，比如任务强制闭环， m c p 能力都得靠它来启动。所以在我的理解里，前面用上了 o m o， 我 们才开始真正用上了 o m o。 好 的，等我介绍完了， o m o 的 核心能力，就是一个土豆里斯的，然后按顺序执行就好了。 于是我就来点狠的问他为什么多 agent 没用呀， talking 也没消耗呀这些等等的问题，他谄媚的和我说他错了，接下来告诉我他应该怎么做，然后分析为什么会出现这样的情况等等，真的是有理有据，巧舌如簧。 当下我只有一个想法，再测试一下更复杂的任务试试，顺便验证我各方面的配置没有问题。 那我们就提一个更复杂的需求，别忘了最前面的 u l w 这次很快就体现出了多智能体团队，此时我双眼放光，静候佳音，过程中也还是 to do list， 然后写一个一个的文件，让我们直接来看最后的结果。 其实前面的需求细心的小伙伴应该发现了，我都有提到文档官网之类，目的就是为了让它自动触发 config 七 m c p 的 能力， 但试了两次都没成功，我也尝试排查原因，修改相关的配置项，一直无果。最终我还是选择最稳妥的方式， 提示词中添加 use context 七来显示的调用。还好，结果还是令我满意的，他前面先调用了 exa， 后面又触发了 context 七，这部分测试也顺利完成了。最后我们也来看下结果， ok， 从部署到实测，我们完整走了一遍下来，最后我们再来简短的总结一下 o m o 和 superpowers 之间的区别吧。从我们的测试流程不难看出， o m o 偏向于多智能体的协助执行任务，而 superpowers 更偏向于代码的健壮性，靠 t d d 等一系列 skills 让开发流程更加的规范，从根源上避免死删代码。关注我，带你解锁更多好用好玩的！

tiktok 上面啊，将近有二十万人点赞的 superpowers 到底有多厉害？那作为增长速度最快的开源项目之一啊，连 osrbic 官方都把它给收入了。那 superpowers 啊，它不是一个 skill， 而是一套 skill， 共计十四个，是给 ai 用的工作规范，你可以把它想象成它就像是一个严格的监工。动手之前啊，先把方案写出来，看完没有问题， ai 才能开始干。 另外，不仅 cloud codex 能用，主流的 coding agent 它都可以使用它。那很多人就有疑问，那 superpowers 里面有十几个 skill， 我是 要全部装还是只用装其中几个就可以了？那先说结论啊，新手只需要装这四个核心的 skill 就 够用了。第一个， winstorming， 头脑风暴，装了它之后啊， ai 必须先问完你所有的问题， 确认完需求才能开始写代码，再也不会上来就乱写了。第二个， writing plans， 写计划，它会把你的需求啊确成一个一个小任务，每个任务只有两到五分钟，而且会写清楚要改哪个文件，怎么验证对不对。第三个， test driven development 测试驱动开发，听起来很技术啊，其实就是先写验证，再写功能，确保每一步代码都经过了校验，不会写了又挂。第四个 啊，它会逼着 ai 一 步一步分析原因，而不是瞎猜乱改。那这四个也是 superpowers 要集合中安装次数最多的，放心用，不踩坑安装啊，也比较简单，输入这些命令啊就够了。我把它放在评论区置顶，方便你复制。那下期啊，我会介绍另外一个爆火的开源项目， everything cloud code。 关注奇哥啊，教你从零到一学 ai， 解放你的生产线。

欢迎来到 superpowers 深度教程，这是系列第一集，共八集。今天咱们来聊一个事儿， superpowers， 这是一套 ai 编程方法论框架， github 上十五万 star， 一个月暴涨七万 star。 有 人说它是 ai 编程的教科书，有人说它是提示词的终极形态，还有人说它不过是一堆脚本。那么真相到底是什么？这一集，咱们先把它掰开了，揉碎了，搞清楚它到底是个什么东西。 说到这儿，可能有朋友要问了， superpowers 到底是个什么东西？我打个比方你就明白了。你用 ai 编程工具，不管是 cloud code 也好， cursor 也好，你跟他说一句，帮我写个登录功能，他啪啪啪就把代码写出来了。写完了能跑吗？ 大概率能跑。有测试吗？没有。有 review 吗？没有。出了 bug 怎么办？再让它改，改了之后别的地方崩了再让它改，改来改去，最后你自己都搞不清楚到底改了什么。这就是大多数人的 ai 编程现状，全凭运气。 但 superpowers 不 一样，它不是让你更快地写代码，它让你更稳地写代码。简单说， superpowers 是 一套强制纪律，它规定了 ai 编程的七个步骤，每一步都有明确的输入、输出和质量标准。你的 ai 助手装上它之后，不是说想跳步就能跳步的。 说到这儿，这就很关键了。 superpowers 的 核心理念只有四个字，流程优先。不是更快，而是更稳。不是更聪明，而是更守规矩。 可能有人会觉得，这不就是限制 ai 的 能力吗？恰恰相反，正是因为有了纪律， ai 的 能力才能被真正释放出来。你想想， 一个没有纪律的天才和一个有纪律的天才，谁更靠谱？答案不言而喻。那么问题就来了，这七步到底都是什么？咱们来好好梳理一下。第一步， brainstorming 头脑风暴。 在你写任何代码之前， ai 会先问你，你到底想做什么？它不会上来就写代码，而是先帮你把需求想清楚，写成一份设计文档，你确认了它才往下走。第二步， gitworks 工作区隔离。 它会帮你创建一个独立的分支和工作空间，这样你万一搞砸了，主分支丝毫不受影响。第三步， writing plans 写实施计划涉及文档。确认之后，它会把整个工作拆成一个个小任务，每个任务两到五分钟，包含完整的代码命令和预期输出。没有 t b d， 没有 t o d o， 没有类似第几步这种写法， 每个任务都是自包含的。第四步， sub agent driven development 多代理开发。这是 superpowers 最核心的执行方式，它会给每个任务派一个全新的 ai 代理去执行。执行完还有两轮审查，第一轮检查是否符合设计要求， 第二轮检查代码质量，两轮都过了才算完成。第五步， t d d 测试驱动开发不是写完代码再补测试，而是先写测试，看着测试失败，再写最少的代码，让测试通过。 如果你先写了代码，对不起，删掉从头来。第六步， code review 代码审查。每个任务完成后，会自动派遣一个审查代理来检查你的代码， 它不是走过场，是真能发现问题。审查分三个级别， critical 必须立即修， important 必须修完才能继续 minor， 记下来以后再说。第七步， finish branch 完成分支 所有任务，做完测试全部通过。它会给你四个选项，本地合并、推送件、 pr， 先保留或者丢弃。 每个选项都有对应的清理流程。说到这儿，你可能会觉得这流程也太严了吧，没错，就是严，但这套严苛的流程，正是它一个月能涨七万 star 的 原因。因为用过的人都知道，不是慢了，是稳了，再也不用担心 ai 写了一堆代码， 结果到处是 bug， 自己都不知道从哪儿开始修。说到这儿，可能有朋友要问了，十五万 star 这项目到底什么来头？ superpowers 的 作者叫 jesse vincent， 是 一家叫 prime radion 公司的创始人。这个人很有意思，他是 rt 系统的创建者。 rt 你 可能听说过，是一个著名的开源公单系统，他搞了二十多年的开源 superpowers 这个项目一开始就是他自己用 cloud code 写代码的时候发现的问题。 ai 编程工具能力很强，但太随性了，你让他写代码他就写，从不问该不该写。你让他修 bug 他 就修，从不想根音是什么。于是他就开始琢磨，能不能把软件工程的最佳实践变成 ai 必须遵守的规则。这就是 superpowers 的 起源。它不是一个库，不是一个框架， 也不是一个 ide 插件，它是一套方法论，一套让 ai 编程从碰运气变成走流程的方法论。 至于一个月涨七万 star， 说实话，这个数据本身不是重点，重点是为什么这么多人愿意 star 它？答案是，这些人都是被 ai 编程的随机性折磨过的开发者，他们知道 ai 能写代码，但他们也知道，没有纪律的 ai 编程就是在给自己挖坑， superpowers 给了他们一个解决方案，不是更好的工具，而是更好的流程。好了，聊了这么多，咱们来说说最实际的怎么装。 superpowers 目前支持六个平台，咱们一个一个来。第一个， cloud code， 这是官方推荐的方式，也是最简单的。打开 cloud code， 输入一条命令，斜杠 plug ins 杠 official 对， 就这么一条命令。 装完之后重新开一个绘画， superpowers 就 自动生效了。如果你用的是旧版本的 cloud code， 可能需要先注册 marketplace， 输入斜杠 plug in marketplace， add obara 斜杠 superpowers marketplace， 然后再 install。 装完之后怎么验证呢？很简单，开一个新绘画，跟他说帮我做一个功能，如果他先问你你想做什么，而不是直接开始写代码，说明 superpowers 已经生效了。第二个， cursor， 在 cursor agent 聊天界面输入斜杠 add plug in superpowers， 或者在插件市场里搜索 superpowers， 直接安装， 同样很简单。第三个， open ai codex， 这个稍微麻烦一点，不支持自动安装，你需要告诉 codex 去拉取安装说明。具体做法是让 codex 获取 github 上的安装文档，然后按步骤操作。这个 u r l 我 会放在视频简介里。第四个， gemini c l i 输入 gemini extensions install 后面跟 github 仓库地址更新的时候用 gemini extensions update superpowers。 第五个， github copilot c l i 两步，先注册 marketplace， 然后 install。 第六个， open code， 和 codex 类似，也是手动安装，告诉他去拉安装说明就行。 说到这儿，我总结一下验证安装的三种方式，第一种也是最推荐的开心绘画，让他做一个功能，如果他先做 brainstorming， 而不是直接写代码，说明生效了。 第二种，让他帮你 debug 一个问题，如果他先做根音分析，而不是直接改代码，说明 systematic debugging 技能生效了。第三种，直接问他，你知道 superpowers 吗？如果他能说出十四个技能的名字和用途，说明 using superpowers 原技能已经加载了。 说到这儿，咱们来聊最后一个大话题， superpowers 的 十四个技能到底是怎么组织的？这十四个技能不是散乱的，它们组成了一条完整的流水线。咱们按类别来看， 第一类测试相关，包含两个技能， test gun driven， gun development 和 systematic debugging。 tdd 负责保证代码质量， debugging 负责出了问题怎么科学地排查。这两个技能都有自己的铁律， t d d 的 铁律是没有失败测试就不许写代码， debugging 的， 铁律是没有根音调查就不许修 bug。 第二类，协助相关，这是最大的一类，包含九个技能， brainstorming 负责设计， writing plans 负责计划 executing plans 和 subagent 杠 driven 杠 development 负责执行 using 杠 git 杠 work trees 负责工作区管理 requesting 杠 code， 杠 review 和 receiving 杠 code 杠 review 负责代码审查 dispatching 杠 parallel 杠 agents 负责并行任务调度 finishing 杠 a 杠 development 杠 branch 负责收尾。 第三类原技能包含三个技能， using superpowers 是 总调度，它负责判断什么时候该用哪个技能。 writing skills 教你怎么创建自己的技能？ verification 杠 before 杠 completion 是 完成前的最后一道关卡，为之的未成可否止确保所有声称都是经过验证的？说到这儿，这就很关键了， 你可能注意到了，每个技能都有明确的触发条件和不可跳过的步骤，这不是建议，是纪律。 superpowers 的 工作方式是该用的时候自动触发，想跳的时候跳不过去。这就是为什么它能管住 ai， 因为纪律写在了技能里， ai 每次行动前都要先检查，升职充解时多想精晓有没有适用的技能，有就必须用。好了，今天咱们就聊到这儿，咱们来回顾一下今天讲的重点。第一， superpowers 不是 工具，是方法论。它用七步强制工作流，把 ai 编程从碰运气变成走流程。第二，它的核心理念是流程优先，不是更快，而是更稳。十四个技能覆盖了从设计到交付的每一个环节。 第三，安装很简单，六条命令覆盖六大平台，装完之后自动生效，不用额外配置。下一集 咱们要讲的是 superpowers 的 第一个技能， brainstorming。 设计先于代码，这个技能有一个硬门径，没有设计文档就不许写代码。为什么这么严格？实际怎么用？咱们下集好好聊聊，别忘了点赞收藏追更系列，不错过每一集，咱们下期再见！

你该用 gsd 还是 superpowers？ 还是说两者都是浪费时间？为了找到答案，我做了个三方对决，测试 superpowers， gsd， 还有原声 cloud code， 我 让它们做一模一样的网页应用，然后从最终成果、消耗的 token 数量以及完成时间来而赢家可能出乎你的意料。 在正式对决之前，我们先快速聊聊 gsd 和 superpowers 到底是什么，怎么工作，以及它们之间有什么不同。 其实 g s d 和 superpowers 师出同门，它们都是架在 cloud code 之上的。编排层会改变 cloud code 处理复杂项目的方式，它们都引入了更完善的规划系统，更完善的测试系统，而且都用紫代理驱动开发来解决上下文衰减问题。 那如果你看他们的实际执行步骤，相似之处就更加明显了。那 superpowers 的 前三步在做什么？就是在他先头脑风暴，再用 gitwork tree， 然后写出方案。 g s d 呢？ g s d 启动新项目，讨论方案，再把方案拆成阶段，他们都是把你的大想法切成小块，变成具体独立的任务，之后交给紫代理去执行。 方案定下来之后， superpower 它进入子代理驱动开发。我一直在提这个普通模式里， cloud code 在 同一个绘画里执行所有操作，上下文窗口越塞越满，而 superpowers 会给每个子代理分配特定任务， 这样它们的上下文窗口基本是干净的，输出质量也会更好。所以这就是 superpowers 的 第四步和第五步。当然还包括测试驱动开发。 psd 这边呢，它只有一步，执行阶段，基本就是把 superpowers 的 第四步和第五步合在了一起，作为它的第四步，然后收尾。 那 superpowers 会请求代码审查，再合并所有内容，它验证工作，然后直接发布，提交代码，创建 pr 为事，所以非常相似。 说到区别呢，其实挺微妙的。 superpowers 特别重视测试驱动开发和红绿重构这套理念。如果你去看 superpowers 里测试驱动开发的具体技能描述，它强调什么？它强调铁律。没有失败的测试就不能写生产代码， 所以每次要为一个功能写代码时，它先写测试，让测试失败，然后再写最少量的代码，让测试通过。 接下来就是红绿重构。如果你想，可以去 github 上看它的 skill 文件链接，我会放在下面。另一方面， g s d 非常强调状态和上下文，它会不断创建 markdown 文件，记录你计划做什么，已经做了什么，以及未来要完成什么，比如 requirements， saying， roadmap， l r m d， 还有各个阶段文件，它把所有东西都写得清清楚楚。 这么做是因为紫代理执行太多，上下文，不断重置，总得有个北极星来告诉我们，现在在哪，要去哪，这就是 gsd 的 思路。不过说实话，这些区别很细微，很多时候还得看实际感觉，我们今天就会看到。另外，我们还会关注每个方案的执行时间和 token 消耗， 因为成本永远是我们要考虑的。安装这些工具很简单， superpowers 就 在 cloud code 的 官方插件库里，你在 cloud code 里输入 slash plugin， 就 能直接看到 superpowers 并安装 gsd 就 更简单了，跑一条命令就能装完所有东西。 那今天这三个对手要做什么测试呢？我们要让他们三个都给我们建议，是我们 ai agency chase ai 的 网站。这个网站需要三个部分， 第一，落地页。这个最简单，我要一个标准落地页，有手评关于我们服务介绍，再加一个线索搜集表单。这里测试的是简单需求，同时也想看看他们的网页设计和技能调用呢？他们会不会主动调用前端设计技能，因为我不会明确告诉他们。第二和第三部分是关于泊客生成器。 第二部分我要一个页面，能展示泊客文章列表，点进去可以阅读基本功能。然后第三部分是真正的泊客生成器本身， 这是一个隐藏的管理后台页面，不要放在导航栏里，我要能输入一个 youtube 视频链接或者文章链接，让它抓取内容，然后用 instagram sdk 基于这些信息生成一篇符合我风格的扑克文章，来源可以是 youtube 视频或者文章， 还要抓取原内容的缩略图或封面图，然后保存成一篇新扑克。为了节省时间，这里不做身份验证，我相信这三个都能用 super bay c i 搞定。 那我还给了他们一个基础技术战，以及一些美学方向上的指导，关键是给他们足够的方向，让我们能在同一标准下评分，但又留出足够的发挥空间，不让他们只是照本宣科。我想看看他们会怎么思考这个提示词，因为我们故意留了一些开放问题，比如到底怎么获取视频字幕， 怎么从 youtube 链接获取缩略图？簿刻生成的系统提示词该怎么写，风格该怎么定，还有要不要调用特定的 cloud code 技能，这些都是我们应该能在 g s d superpowers 和原声 cloud code 之间看到差异的地方。 对了，我的 cloud code 的 大师课上个月刚刚发布，这是从零成为 ai 开发者的最佳途径，尤其适合没有技术背景的人。 我会教你关于这个工具的一切，而且全部围绕真实用力展开。同样重要的是，我每周都会更新课程内容，发布至今已经新增了近三小时的额外内容。你可以在 chsiplus 的 置顶评论里找到课程链接，期待你的加入。 好了，测试开始。这里我有 g s d superpowers 和 cloud code 的 三个窗口，我会明确说明我在哪个标签页，避免大家搞混。而且底部状态栏也会清楚显示当前目录，因为它们都在不同的目录里。 superpowers 这边我们可以看到它加载了 superpowers 头脑风暴技能。 superpowers 的 使用体验很流畅，安装之后会有十四五个技能，自动判断该调用哪个技能。 这和 gsd 有 点不同。 gsd 需要你显示输入斜杠命令，比如在目录里输入 gsd new project。 gsd 是 最先回来的，大概几分钟后就开始提问了，他说我们的需求已经相当完整了， 毕竟我们给了一个相当详细的提示词。嗯，但我喜欢的是他马上就说，哎，这里有几个判断我要做，然后立刻指出了几个我们没写进提示词，但可能是差异化因素的地方。 比如我们没指定落地页上要放哪些服务。他给了四个选项。接着他说明了 youtube 字幕获取和封面图的处理方式，我便让他创建 project md 文件，现在来看 superpowers。 他 一开始问我是否跳过 visual companion offer， 我 说要用这个 offer， 因为这其实是 superpowers 和 gsd 的 一大区别之一，我想看看他的实际效果。然后他马上提出了几个设计决策，特别是关于获取 url 内容的方式。和 gsd 一 样，这也是我们故意留白的部分。 他给了三个选项，列出了优缺点，还给出了推荐。然后他详细拆解了缩略图策略。所以你看，他给出的这些建议比 gsd 更深入一些。同样的情况也出现在服务、设计系统以及错误处理和边界条件上。总体来说，他反馈的所有内容都更加深入， 所以我回复说这看起来不错。不过我还是想先过一遍视觉伴侣，确保前端 aesthetics 没有问题，然后他就生成了视觉伴侣，这也是他最酷的功能之一。 他启动了一个 dv server， 现在问我要选什么样的 aesthetics， 而且给出了实实在在的选项。四个就在我面前。我很喜欢这一点，因为如果只是口头描述，要做什么视觉方案，然后只启动一个 dv server， 展示一个选项，那是一回事。但如果你能一次性看到所有方案就完全不一样了。这是 superpowers 最让我喜欢的功能之一。 不过话说回来，这些方案看起来都很相似，没有一个特别吸引我。要我选的话， warm editorial 最好， electric lime 太扎眼， monochrome 太无聊， linear polish 像廉价 ai 生成物，暂时先选这个，至少视觉上有个样子。 我很喜欢 visual companion 这个功能，告诉 superpowers 我 喜欢选项 c 后，他又给了更多方案，把 aesthetics 的 配色方案拿过去了。 然后现在我们进入了 hero section 的 设计，所以它会继续往下细划网页的每个部分。这是第一个 hero， 第二个更居中一些。第三个这边加了一些元素，还有 split with 的 featured look 这种布局。 说实话，我可能会选类似这样的，然后把这边的东西去掉，因为这部分有点鸡肋，但我喜欢这个作为模板，对吧？我们可以从这里开始， superpowers 的 visual companion 会带你过一遍 landing page 的 每个 section。 后面呢，我们就跳过吧。我想你们已经懂这个意思了。现在 superpowers 已经写好了网站规格文档，让我们去审阅， 我们看一下，没问题就通过。然后他就会调用 writing plan skill 来生成 implementation plan。 这相当于一个粗略的蓝图，告诉他接下来要做什么。这是那份 design spec， 内容非常全面，但你们真正需要关注的是最下面的部分， 即 key judgment cause， 也就是 superpowers 至今替你做的关键决定。若有意义，此处正是反馈之处。他打算用 slash studios 作为隐藏 u r l 在 那里生成播客内容导航标签用 writing 还提到了生成的 voice。 我 以前是 marine pilot， 现在是 ai consultant。 修改很简单，基于 user level cloud memory 自动调整。它还提到安全性。这个 demo 我 们不加认证，它自己也觉得奇怪，说那只能靠 security by obscure， 所以 它也指出来了。那我就告诉 superpowers 看起来没问题，现在它要开始写计划了，你可以看到 skill 正在加载。 在我们和 superpowers 做这些的同时， g s d。 也在执行自己的研究，为制定计划做准备。它并行启动了四个 research， 一个是基础站研究，一个是功能研究，另外两个分别是架构研究和 pitfalls 研究。你可以在这里看到每一个都消耗了大量头肯，七万五，三万三，五万一，六万一。 但思路是，如果你在做比较新颖或者不常见的东西，这些 researcher 长期来看会非常有价值。 不过我们今天要做的，或者说正在做的，其实相当常规。网页设计，播客生成器，这些都是他见过的东西，但我还是让他执行了这些 researcher agents， 主要是为了让测试条件尽量公平，然后他把所有研究结果做了汇总。这里用的是 sonnet 四点六， 所以虽然大部分时间我让 gsd 用 opus 四点六放手去做，但只要是在整合信息，而不是派 agent 去做什么新颖独特的事情时，他就会用更小更便宜的模型来做汇总。那这个四 agent 研究阶段相比 superpowers 来说非常 robust， superpowers 基本不做这些。 那就像我说的三十次 to use 九一 k token 十五分钟，这需要时间。研究做完之后呢，它会定义需求，类似于刚才 superpowers 的 m d 文件。 g s d 呢，也做同样的事儿，但更多，它会生成多个文档， requirements， document， roadmap document 本质上就是把 superpowers 做的事儿拆成了多个文档，包括 roadmap， state， 还有后续的 phases 等等。三十五分钟过去了，你可以看出这确实很花时间。如果我们停下来看看 standard cloud code， 它的计划早就准备好了。我们已经有段时间没让它执行任何操作了， 它总共大概花了五六分钟，我觉得这还算慢的，而 g s d 还在跑三十六分钟了。 it can superpowers taiiyi wenxiu website plan markdown。 既然 g s d 还邀，一会儿才能完成 roadmap 和那一系列文档，我们先回来看看 superpowers， 它刚创建了 website plan 到包含二十八个任务，两千五百行。回到 vs code， 如果我们往下翻， 进入 dos 文件夹，看 implementation plan， 这就是我说的那份儿文档，比 specs 长了大概十倍，内容非常多。 superpowers 给了两种执行选项，一种是 subigent driven 和 g s d 很 像，每个任务有独立的 subigent 和 context window。 但正如文档所说，这有代价，因为二十八个任务大多都很 straightforward， 用 subigent 是 不是有点杀鸡用牛刀，真的有必要吗？第二种是 inline execution， 基本上就是在同一个绘画里完成，需要审阅的时候再暂停，这样会快很多很多。 这种 inline execution 更像 standard cloud code 的 做法就是直接验。既然 superpowers 推荐 inline execution， 那 我们就选这个。然后可以看到 superpowers executing plan， skill loaded， successfully。 现在他要开始干活了。与此同时呢， g s d 也刚好完成了它的宏伟计划， 它创建了 project， md requirements， md， roadmap， md， state， md， cloud， md， 还为所有研究发现建了一个文件夹。 gsd 提出了八个 face， 六十五个 requirements， 就 像之前说的，执行的时候 gsd 非常 rigid， 也可以说是非常清晰。一个 slash command 接一个 slash command， 很机械地一步一步往下走，下一步下一步，下一步下一步。它是分阶段的，而 superpowers 则更 fluid 的 一些。你可以跟它聊着来，它知道什么时候该加载命令，或者你期待它自动加载 skill。 g s d 则更清晰直接。 在我们开始用 gsd 执行之前，记住现在都还支持 planning face， 这些是它 subversion 在 规划和研究阶段消耗的总 token 数。四十五万九千八百六十二。具体要花多少钱呢？这很难说，完全取决于你什么时候用，用什么套餐，但大概是四十六万 token。 规划阶段就这么读，再加上现在显示用了百分之十六，算十五万吧。凑个整， g s d 在 规划阶段大概用了六十万， token， 时间花了大概四十分钟。作为对比， baseline， 也就是 standard cloud code 的 规划阶段大概花了十分钟， token 大 概是五万。呃， superpowers 二十万， g s d 六十万， cloud code 五万。 时间方面， cloud co 十分钟， superpowers 四十分钟， g s d 也大概四十分钟。这是 orchestration layer 和标准 cloud co 之间的一个重大区别。时间成本在 g s d 和 superpowers 的 token 消耗上差距也很大。嗯，因为 g s d 非常重研究， 你也看到了四个并行 subigent。 做大量规划对这次项目来说有必要吗？也许没有，但对大项目来说，这是必要的， token 差距也会存在。不过这只是一个 checkpoint 规划研究阶段，现在 接下来进入执行阶段， cloud code 和 superpowers 都已经开始运行了，我现在也要启动 g s d。 说到 g s d 的 执行阶段，它比其他两个更费神，不像之前做规划和研究时，写完了就能直接让它自己跑，然后我可以离开半小时再回来看节。每个阶段可能都需要你投入一些精力，至少得先启动它， 因为 g s d 会要求你先和它讨论每个阶段，确保你和 cloud code 的 想法完全一致，对吧？你到底希望这个功能实现什么效果？ 你希望最终成品长什么样？他会问的非常非常细。说实话，一方面有点烦，但另一方面，如果项目很复杂，把这些细节搞清楚确实很重要，所以这些都需要你自己权衡。而我们真正要权衡的是这一切到底能不能带来更好的产品。为了节省大家的时间，我不会把 g s d 的 每个阶段都展示出来。 那如果你真想看完整过程，可以去看我之前分享的那个视频，只要明白这一点就行。 g s d 和 superpowers 以及 cloud code 之间最大的区别之一。而到 superpowers 到这一步，它的实现已经完成，总共消耗了二十五万桥头。肯从规划阶段到现在，过了十五分钟，他问我接下来想做什么，并建议保持当前分支不变。 那我就说，行，听你的。然后 superpowers 会返回一个总结，说明它构建了什么，验证了什么，功能正常，还有哪些没法自动验证，需要手动检查或修改的地方，以及它做了哪些判断。那这时候我也会更新一下 api， 让它能真正跑起来。 好了，他们三个终于都执行完了，现在我们来看他们一次性生成的成果，这里分别是 g s d、 superpowers 和。先说一下耗时， g s d 到目前为止花了最长时间，屏幕外我逐个阶段跟他沟通规划执行，说实话，花了一个多小时， g s d。 执行阶段总共消耗了六十万 token， 所以 从最开始的规划阶段 到生成这个一次性成品， g s d 一 共用了一百二十万 token， 耗时一小时四十五分钟。 superpowers 的 执行阶段只额外花了大约五万 token， 十五分钟左右，所以从第一条提示到最终成品 superpowers 总共一小时二十五万 token， 而 cloudco 这边 总共二十万 token， 大 约十五分钟，差距挺惊人的对吧？ gsd 明显最长最重，而基础版 cloud code 最快，这也在意料之中。 那这么多时间和 token 到底值不值呢？我们先看 gsd 的 结果，背景很朴素，基本全是黑色， 非常基础的设计，带点橙色，说实话不算难看，但也不会让你眼前一亮，感觉就是 ai 第一版做出来的标准样子。 我点进泊客页面能看到一些视力内容，也还过得去啊。现在我们来看看泊客生成器那个，但按照他给的链接点进去直接四零四，所以泊客生成器第一遍根本跑不通。 我把问题反馈给 gsd， 他 正在修。趁这个功夫，我们来看看 superpowers 的 成果，这是 superpowers 做出来的页面，前端设计和之前视觉伴侣里看到的基本一致，但说实话也没什么特别的。 cloud code 一 般来说前端设计能力比较一般，除非你给他非常详细的指令，或者加载大量技能，因为我们这次在审美和前端设计方面基本交给他自由发挥。 所谓做出来的东西一看就是 ai 生成的，作为基础。还行吧，这是播客页面，有图片，整个播客结构都在，如果点进 studio 板块，第一遍就能正常运行，能看到生成器界面，我输入一个最近视频的链接， 它就能生成草稿。抓对了，缩略图内容也准确，因为那个视频里我确实讲了 cloud code， obsidian 和 auto research 里的 kodak 这些内容，所以它说到做到，这很好。现在我们来看，基础版 cloud code 的 效果也是很标准的东西， 没什么特别的。说实话，如果我们没给很好的设计指令，这三个的前端设计有很大区别吗？没有，真的没什么区别，你随便告诉我这三个里哪个做了哪个，我根本分不出来。 我们看看博克页面，有一些假文章，看着还行吧，很平淡，没什么亮点，但能用。再看看 studio 博克生成器这部分，结果和 gsd 一 样，跑不通，给了链接四零四，页面找不到，所以和 gsd 一 样，我也让基础版 cloud code 去修这个问题，趁它还在修，我们回来看看 gsd 第二次尝试的结果， 看起来 gsd 已经解决了。我把链接贴进去，看看能不能生成草稿。好，他返回了这个 markdown 格式的草稿。我还挺喜欢这个设计的，可以快速的在线编辑内容，而且内容本身也是准确的，该讲的东西都讲到了，做的不错， 还能看到实时预览，这很好。说实话，我更喜欢 gsd 这种带在线编辑器的实现方式，比 superpowers 更合我意。 我们现在也能在播客页面里看到最终效果了。最后呢，基础版 cloud code 也修好了错误，我们来看一下它的簿客生成器和 superpowers 类似，输入之后呢，它直接自动生成，不像 gsd 那 样给我机会编辑或先看草稿。但它抓对了缩略图， 虽然分辨率有点低，信息都是准确的，这是它在实际簿客页面里的样子。那我们能从这一切里得出什么结论呢？这三个里面到底谁赢了？这场正面对决， 我们先快速回顾一下。总耗时方面，基础版 cloud code 大 约二十分钟， superpowers 大 约一小时， g s d 用了一百零五分钟，也就是一小时四十五分钟。 token 消耗方面， cloud code 大 约二十万， superpowers 二十五万， g s d 则高达一百二十万。这些是客观数据， 主观上来说，它们做出来的东西质量怎么样，我们有特别强烈的偏好吗？其实没有。 如果你选 superpowers 或 gsd， 相比 cloud code， 你 就多花了四十分钟，甚至八十分钟。这可不是小事，因为说实话，如果让我再做一次，你问我今天这三个谁赢了？答案是 cloud code， 而且差距很大，为什么不是因为 token， 而是时间？当然， 这算最差的，但你知道吗？我多了四零甚至八十分钟来改它对比刚做的 gsd， 哪个更好， 或者在一起打磨四十分钟？答案应该很明显吧。所以我的最终观点是什么？我觉得你得有个充分的理由才会去用这些编排层工具。如果今天让我选一个啊，我会选 superpowers。 如果我要做一个不确定 会不会太复杂的任务，对吧？那条谁也不知道在哪里的分界线，我觉得我们可能快接近了。这种时候我会用 superpowers， 因为我知道它不会让我在 token 上大出血，而且我只需要等六十分钟就行。 但如果用 gsd， 我 就得一直守在电脑前，对吧？想充分发挥它的作用，就得走完所有规划流程，既费时又费透肯，所以如果我判断错了，代价就很大。对，这次用 gsd 花那么多时间真的挺难受的，做这期视频的时候，最终结果根本不值得。 所以如果我真的觉得某件事复杂到需要超能力，那好吧，这还能说的过去。 但如果其实没那么复杂，或者就算复杂，我们是不是也能把它拆成不同的功能，然后慢慢往上加？我说的慢，其实比其他方案快多了，因为我直接用现成的 cloud code 比其他选项快的多。 还有一点， gsd 刚出来的时候，我当时也做了一期视频，那时候我挺喜欢 gsd 的， 超能力也一样。这两个东西刚出来的时候，淘捞扣还没有之前这么强。 我知道肯定会有人说 cloud 现在被消弱了，但我要说的不是这个，我说的是 cloud code 的 处理问题的方式，它的脚手架结构，还有整个框架的运行机制都进步了很多。比如说当你有一个大计划要执行时，嗯，他会问你需不需要清空上下文在操作，这以前根本不存在，以前的 cloud code 更容易出现 context raw 这种问题。 gsd 刚出的时候呢，我觉得简直是救星，他处理上下文的方式才对嘛。但现在 cloud code 也引入了很多类似的功能，也就是说，基础版 cloud code 和这些工具之间的差距已经大幅缩小了，同时执行速度上的差距却变得非常大。 速度差异我们没法不谈，二十分钟对六十分钟，还有一百零五分钟，这才是最大的区别，也是你最该看重的。至少我是这么认为的，所以总结来说，少即是多。 我觉得对百分之九十九的使用场景和百分之九十九的用户来说，直接用基础版 cloud code 最合理，就算输出质量没更好，它也更快， 你有更多时去弥补差距，甚至反超这些其他工具。如果你确实在做特别复杂的项目，想要额外的能力，那就用 superpowers， 因为它相对清凉。相比之下， gsd 就 像个庞然大物，用起来感觉不太好。我说实话， superpowers 用起来流畅多了，我直接跟他对话，他就会调用技能，不用像以前那样先输入斜杠清空，再进一个新绘画，太麻烦了。我理解为什么出了 gsd 套 gc 二点零，本来是想解决这些问题的，但结果呢，还是不行，因为你没法用 cloud code max 的 planet， 这意味着我要付离谱的价格，所以也就那样吧。啊，希望这些能帮你理清思路。我觉得坚持用标准版 cloud code 就 完全没问题，把 superpowers 放在后背里，真需要再用啊。技能放在项目级别就行。说实话，很难说你真的需要，除非你在做什么特别疯狂的东西，而且喜欢每一步都有人牵着走。 好啦，就说这么多，像往常一样，评论区告诉我你的想法，很想听听你们怎么用 superpowers 和 g s d 的， 以及我哪里 inevitably 说错了。如果想入手 cloud code master class， 记得去看看，链接在我的主页和置顶评论里。除此之外，咱们下次见。

我的电脑装了上百个 skill， 但其实每天真正在用的就只有这八个，那我把它分成两组，一个是做产品写代码的，一边是搞自媒体的。那我们先说做产品的这一组， 当你想要做点工具啊，网站啊，我都是从 superpowers 这个技能组开始的。那其中有两个 skill， 我 最常用 wordstorming。 那 帮你把想法聊清楚， writing plan 呢？把你的想法拆成可以执行的步骤，那很多时候脑子里面只有一个模糊的想法，一个方向的时候啊， 跟这两个 skill 聊一圈，那思路就会慢慢的顺了。当代码跑起来的时候啊，页面通常不是很好看，那我就会把它丢给 fronten 的 design， 还有 u x or max。 那 让 cloud 重新过一遍排版，配色，交互细节，那就算你不懂设计也没有关系啊，它会自己去判断，最终帮你做出比较好看的页面。那然后呢，我就会用 a v t m c p 来去做自动化测试，那去帮我修改一些细节，它会让 cloud 装成真实的用户，去点你的页面，那看哪里会有问题，那自动的帮你去改。 以前这一步都是我手工在测啊，现在我是直接用这个 m c p 在 跑另一条线啊，是做自媒体，那我查资料的时候，就会用 agent rich 让 carol 的 联网搜索直接整理成我想要的格式。那当稿子写出来之后啊，我几乎避过回门 neither zh 这个 skill， 那 ai 写的句子啊，通顺归通顺啊，那读起来就是没有人味。那这个 skill 专门治这个问题，那过完之后啊，就会自然很多。 那下一步呢？就是 content risk detector， 这是我自己写的一个 skill。 那 在平台发布内容的时候，最怕踩到敏感词被限流，所以我发布前都会用这个 skill 扫一遍，那这样才放心。 最后一个 skill 是 我觉得最有价值 skill creator， 那 它可以把多个 skill 串成一个自定义的工作流。比如我刚才查资料啊，写稿啊， qq 啊检测的这一条内容线，那现在我把它封装成一个 skill， 就 能把整个流程抛起来，你不需要每次一步一步地去调，那你可以让 cloud 按你的方式来工作。 那这八个 skill 两条线基本上覆盖了我百分之九十的日常场景。那你们都在用什么 skill？ 欢迎在评论区分享。

这节我们讲下 ai 时代的需求分析和目标定义，也就是所谓的规范驱动开发。讲完咱们直接实操一下，这是今天大概的内容。 首先我们要意识到一个问题，需求分析阶段和之前完全不一样，之前我们需要把用户需求收集过来，然后再整理翻译细划，现在只需要关注目标和边界约束就行。做一个东西出来也比较简单，但是引入了新的问题，虽然你可以简单的描述，然后交给模型自由发挥，睡一觉就干完了，但干出来东西实际上是不可控的， 也就是我们目前高不高兴面临的困境， i 键的猜不透，或者说猜错了你的意图。还有的话就是 i 的 编码速度实在太快了，如果不控制代码的一个商征，之前我们古法编程的时候，你想弄出一座石山，怎么也得半年，但是 i i 的 话一周就可以。规范驱动开发的核心洞察是把你的意图文档化，让规范成为这个执行的一个依据， 发现问题，解决问题。我们软件行业的方案实在太多了，什么 d d， d d d d d d d d， 今天咱们采用的是 s d d， 写好规范文档，再让 iint 开始开发 s、 d、 d 四个阶段，首先定义我们的目标和边界，然后制定我们的方案，然后把方案拆成小块的任务，最后让 i 干活，我们验收就行了。咱们今天实战的话，先把第一步干了，其他放在后面， 这是可选择工具，现在可选择工具太多了，大多数的话都是整体解决方案。然后咱们今天实战选择的是 superpowers， 如果你是个人开发项目，建议就是 superpowers 或者 gsd， 开放性的问题我就不给大家念了，直接开始今天的这个实战环节， 我们先创建一个文件夹， 我们这次选择的这个实弹工具是 open code 的， 至于为什么是 open code 的， 呃后面选型那节再讲，今天就不过多隐身了。今天我们主要是规范驱动开发的一个实弹，说白了就是生成一个呃规范文件，让 iint 根据规范来干活。我们采用 superpowers 的 涂抹风暴技能帮我们去生成一个规范文件， 这个模型的话要选这个智力高一点直接输入，我想创建。 其实前面已经说了， ai 时代的这个需求分析比较简单，就是把你的这个目标和边界想清楚，说明白。我这里已经已经想好了，就是要采集这个热门的网站，然后放到某个文件夹中，然后我必须支持这个 mini 行，因为我后面需要给 edit 去做一个使用， 这边的话，它会自动帮我们加载 superpowers 的 一个头脑风暴的技能就是这个，可以看一下我们的 skills 的 话，需要一个呃 mini 行，然后同时需要一个 gui， 我 们就不做 gui 应用了， 打就行了，因为呃设置桌面壁纸的话和这个烧录系统是相关的，并且我们有很多别的插件可以去控制，直接就是采集就可以， 可以看到它给我们推荐了一些方案，然后选型这一块的话，我们这个工具使用 brush 这一块的话是这样，这一块这个选型，呃如果说你是个前端开发，或者说呃你有一个外部页面的话，建议使用 node js， 然后如果说你的这个工具涉及到 ai 相关的库的话，建议使用 fast， 如果说你是个存银行工具的话，使用 rest 会比较好一点，当然你也可以按它推荐的来。 这边的话， rest 这个学习曲线已经不是我们自己去写的，无所谓。 下这个归零文件计划的话，我们先不做，放到下一节， 那就看一下它的这个规范文件项目名称、用途、技术段，然后我们的一个核心功能，下载管理、配置管理 很不错，这节就到这里，下节我们做计划和选型。

今天给大家拆解一款真正能解决 ai 编码核心痛点的开源神器 superpowers， 内容我会分成三期慢慢讲 干货，循序渐进，更好吸收。首先，搞懂 superpowers 的 核心定位，它和我们平时用的 ai 编码提示词、普通插件有着本质的区别。我们平时用 cursor、 cloud code 写代码，最头疼的是什么？就是 ai 上来就瞎写， 脱离需求，坐着坐着就跑偏了，哪怕你写了再长的提示词，他也经常不遵守。而 superpowers 不是 给 ai 提建议， 而是给他制定了必须强制执行的工程化开发规则，从根源上规范 ai 的 开发行为。他来自 github 开源项目 obra。 superpowers 用的是最宽松的 mit 开源协议，个人用、商用都完全自由，而且几乎适配了现在所有主流的 ai 编码编辑器， cloud code、 cursor、 github、 co pilot、 codex、 gemini、 cly 全都能原生支持。它的核心运行逻辑非常硬核， 从你启动 ai 编码代理的那一刻起，它就绝对不会让 ai 上来就写代码，而是严格遵循标准化的工程化开发流程，不完成上一步，绝对不会进入下一步，甚至能让 ai 自主连续工作好几个小时，完全不偏离 你最初定的需求，这是普通提示词根本做不到的。先给大家讲它最基础的三大核心步骤，也是所有开发任务的前提。 第一，需求与设计头脑风暴。只要你提了开发需求， ai 会先通过提问把你的模糊想法细化成清晰的需求规范，输出完整的设计文档，必须等你确认了才会进入下一步，从根源避免方向跑偏。第二， get 工作流环境准备设计确认后会自动创建隔离的开发分支，不会污染你的主分支代码，同时完成环境初步开发，环境干净可控。第三， 实现计划拆解，把设计方案拆成两至五分钟就能完成的最小任务，每个任务都有明确的文件路径，实现逻辑验证步骤，彻底避免 ai 过度设计范围蔓延。这三步就已经解决了 ai 开发最常见的三大通电 需求，跑偏环境混乱、过度设计。不过以上这些都只是它的入门功能。 superpowers 真正封神，让 ai 实现自主稳定开发的核心 是后续的子代理驱动开发测试驱动 t d d 全流程审批闭环。下期我详细拆解它到底是怎么让 ai 自主连续工作数小时，同时还能严格保障代码质量的。

这节我们实操一下 superpowers 的 writing plus 技能，你是不是感觉 superpowers 消耗的 tak 有 点多，虽然是执行的时候耗费的 tak， 但其实是因为你的计划没有写好。这节讲一下怎么写计划， superpowers 才能更省 tak。 前一节我们使用 superpowers 的 头脑风暴技能完成了需求分析，产出了项目的规格文档，然后又进行了 i 时代下的基础选型。终于我们可以回到实操环节了，可以回顾一下他帮我们生成的这个规格文档，我们准备做一个编辑工具，然后他需要帮我们从多个源采集这个壁纸，然后我们的形式方式使用的是命令行或者 dy 的 模式。语言的话，我们选择的是 rest， 其他的细节的话我们其实可以都不用看了。在使用 superpowers 编写的计划的技能之前，我们需要知道这个东西写的计划是非常细致的， 它里面是包含了代码实现的，这个时候如果说他实现的代码是错的，那么代价将会是巨大的。经常用 ide 的 编码的大家应该都有感觉，大模型写代码是靠猜的，他不知道的东西，他是根据经验预测最大可能出现的一个写法，当然在小洞场景其实就是没去弄过的地方，那么大概率是会出错的。这个时候如果说我们拿着错误的计划， 嗯，也不能叫逗的计划，应该叫大致正确，方向正确，但是细节实现是错误的计划，然后到了下一个阶段会发生什么就不言而喻了。 先不说最后干活的工作的工程师能不能发现错误，假设执行报错他都能正常修复。那么还有一种是滴滴滴的测试用力都是错的，他所有的努力消耗的所有 test 都是为了满足一个错误的测试用力，就算到时候真的通过了，也是与正确的结果越来越远，浪费了大量的 test， 却实现不了想要的产品。 因此 superpowers 想要用好，并且想要爽 test 计划阶段就不要让它产生错误的误导性的代码。那么回到我们的实战项目，我们这个项目里， it 最容易出错的地方是什么？ 热门的技术站其实都是训练过了的，之前说过我们要做减法，他知道的东西就不用再给他赘述了，上下文多也不是好事情。实际上我们这个实战项目 ai 最容易出错的地方是壁纸源的这个 ipi 规范，这种在电脑上显然没有多少训练数据，他忙写出来的几乎百分之百是错的。 那我们需要怎么做？其实也比较简单，把我们需要对接的这三个源的 ipi 文档放到本地，然后让他看文档就行。之前知乎库呢，也讲到了一个 deep 量子的技能或者服务都是封装的这玩意儿，我们直接用这个命令 在这个窗口里执行的，命令是会填充到 iint 的 上下文内的，这样的话它其实会看到这个命令的帮助。文档 这边它有一个 i p i 文档，实际上是做了防滑的， ok， 执行完了，我们在写计划之前，先让它参考 i p i 文档，修复一下之前的归根键里面的错误部分， 可以看到它这个计划写了两千多行， 具体的计划细节我们就不看了，下节继续让 i i 帮我们执行。计划执行的时候我们会小小的改动一下 superpowers 风格流，这节我们使用的模型还是 五的模型，会选择 mini max 的 二点五，这个时候我们就需要引入顾问者模式来做到省钱的同时保证质量。好的这节就到这里，下节我们继续。

知乎 app 上最近持续霸榜了两个 cloudco 的 项目， jstark 和 superpowers， 它们之间有什么区别？到底应该怎么选？今天我一分钟给你们讲清楚。先说 jstark， 这是 yc 现任 ceo gary tan 开源的工程套件，他把 cloudco 的 武装成了一个二十三人的虚拟工程团队， 这个团队里包括 ceo、 设计师、工程经理、发布经理等等，串成了一个完整的工程壁环。他说用了这套流程，他的代码开发速度是之前的几百倍。 这里面有个 skill 非常值得推荐 office hours， 他 会模拟 yc 合伙人跟你对话，比如他会逼你把目标用户具体到一个人的名字、职位和痛点， 也会问你最小的本周能收钱的版本是什么，问你有没有坐在用户旁边看他用你的产品用好这个 skill， 能很大程度的防止自嗨式做产品。所以 jstark 解决的是你到底在做什么。 然后再说回 superpowers。 superpowers 做的事情本质上是在给 ai 利军规，它把整个软件开发流程拆成了十四个功能模块， brainstorming、 writing、 plan、 tdd、 code review。 每一个模块都是一套不可绕过的方法论。 他不会直接写代码，他会先问你数据怎么存，接口怎么设计，验收标准是什么。也就是说，他强迫 ai 在 动手之前先把需求想清楚， 并且写代码的阶段。他把大任务会拆成两个到五个小任务，每一个小任务派一个专门的子 agent 实现，再派另一个 agent 做规格审查，然后还会派一个 agent 做代码审查，多个 ai agent 各司其职，互相制衡。 所以 superpowers 解决的是你怎么做才能不翻车。最后用一句话总结，差一点， j stark 确保的是你能做正确的事儿， superpowers 确保的是你正确的做事。这两者完全不冲突，搭配使用才是满级 ai 编程的体验。

代码写完了，测试全率了，审查通过了，然后呢？很多人就停在这里，东西能跑就行，分支留着就留着，下次再说。但 superpowers 告诉你，这不是结束，收尾和闭环才是专业和业余的分水岭。 这是 superpowers 深度教程的最后一集。 e p 八，今天讲最后两个技能， finishing a development branch。 完成开发分支，还有 writing skills 创建你自己的技能。而且咱们会在结尾回顾整个系列的八级内容，给你一张完整的十四技能全景图。 先说第一个技能， finishing a development branch 什么时候触发。当你所有任务都做完了，测试全率，代码审查也通过了， ai 会自动调用这个技能。它不再问你接下来做什么，而是直接给你四个明确的选项， 每个都有对应的清理流程。第一个选项，本地合并，这是最常用的。如果你的分支代码已经准备好进入主分支，选择 merge to main a 哀会先确认没有未提交的更改，然后合并清理工作区适合功能已经完全完成，测试通过，不需要他人审查的场景。第二个选项，推送并建 pr。 如果你的项目有 code review 流程，或者你想让团队成员看看你的改动， 选这个 ai 会促使分支到远程，然后创建 po request 适合多人协助项目，或者你想留一个正式的审查记录。 第三个选项，先保留。如果分支上的工作还没完全做完，或者你在等后端接口，等设计稿确认，但你当前想切换到其他任务，选这个 ai 会把当前状态保存好，让你干净的切走，不留半成品污染工作区， 这里有一个核心铁律，不允许半成品留在工作区。 superpowers 要求你每次结束工作的时候，要么把东西收尾干净， 要么清楚地标记为进行中，但先保留，不能有那种你也不知道这个分支是干嘛的状态。第四个选项，丢弃。如果这个分支的实验方向错了，或者你决定不继续了，选择丢弃， ai 会直接删除分支，清理所有相关的工作区文件， 不纠结、不内耗，干净利落，适合那些试试看但发现走不通的探索分支。这四个选项覆盖了所有收尾场景，关键不是选项多，关键是每次结束工作的时候，你必须选一个，不能什么都不选就跑了， 这就是闭环，每一次打开的工作都有一个明确的关闭动作好。第二个技能， writing skills。 这是 superpowers 十四个技能里最特殊的一个，它不是一个给别人用的工具技能，而是一个教你创造工具的原技能。 当你在 ai 编程中反复做同一类事情，比如每次提交前都要运行某个格式检查， 每次创建新文件都要套用某个模板，每次部署都要执行一串固定命令，这时候你就应该把这个流程写成技能。一个技能由四个部分组成，第一， s、 k、 i、 l l 点 md。 技能的入口文件 定义触发条件，当用户说了什么关键词，或者在什么场景下，这个技能会被自动触发。第二， c l、 a、 u、 d、 e 点 md。 给 ai 的 行为指令包括铁律、工作流步骤，不该做什么。 第三， references 目录放参考资料、文档、规则、文件视力。第四， scripts 目录放可执行的脚本， python 或 shell 都行。创建技能的时候有一个核心铁律，好技能向法律条文精确无歧义，可执行。 你说代码格式要好看， ai 不知道怎么执行，你说用 preiter 默认配置格式化所有 ts 和 t s x 文件， ai 就 知道怎么执行了。定义触发条件有两种方式，一种是关键词触发，用户说了包含某些词的话，既能自动激活。另一种是场景触发， 在某些文件类型被创建或者某些 get 操作发生后，技能自动激活。好的触发条件要精确，但不要太窄，太窄了，技能永远触发不了，太宽了，技能在不该触发的时候也跳出来。 技能的工作流要写成步骤，每一步写清楚在什么条件下执行什么动作，预期的输出是什么，出错了怎么处理。不是写散文，是写操作手册。纸上谈兵，不如看个实力， 咱们来做一个技能，叫代码格式化检查，需求是每次提交代码之前，自动检查所有 type script 文件的格式是否符合 prety 规范。第一步，创建 s k， i， l， l， 点 m d， 开头写出发条件，当用户说格式化检查，检查格式 format check 或者执行 git commit 之前触发本技能。 第二步，写 c l， a， u， d， e， 点 m， d， 这是 ai 的 行为指令。核心铁律写清楚， 只检查不改写，如果格式不对，报告差异，但不要自动修改，除非用户明确要求。工作流分三步，先用 npx printer check 扫描文件，如果发现不符的，列出文件和行号，最后问用户要不要自动修复。 第三步， references 不 需要放，因为这个技能很简单， scripts 可以 放一个 shell 脚本，把 prettier check 的 命令封装好，方便直接调用。 这个例子很小，但它展示了技能的核心，把一段你反复做的事定义成一个结构化的 ai 可以 自动执行的流程。你今天写一个小技能，明天就多了一个不知疲倦的 ai 搭档帮你盯着格式。 最后一步是验证，建完后自己用一次，看看触发是不是准确，工作流是不是顺畅，有没有奇异的地方。好的技能靠迭代不是一蹴而就。好技能讲完了，现在咱们站在终点，回头看看这八级走了多远。 ep 一， 全景认知咱们知道了 superpowers 是 什么，不是工具，是方法论。七步强制工作流十四、技能覆盖从需求到收尾的全链路，核心理念四个字，流程优先。 ep 二， brainstorming 设计先于代码 hard gate 硬门禁，没有设计文档就不许写代码，没有例外。九步清单， 从探索上下文到用户审批，每一步都不可跳过。 e p 三， writing plans 完美实施计划，铁律是 t b d 和 t o d o 一 律禁止考计划向乐高积木，每个步骤完整独立可验证。 e p 四， work trees 加 sub agent 工作区隔离与多代理开发。 get work tree 让每个功能独立运行在一个干净沙箱里。 sub agent 让多个 ai 代理并行干活， 两轮审查才通过。 e p 五， t d d 测试驱动开发红绿重构循环，没有失败的测试就不许写实现代码，先想清楚这个功能要验证什么，再写怎么验证， 最后才写怎么实现。 e p 六， systematic debugging 系统性调试四阶段调查分析、修复验证。没有根音分析就不许动手改 bug 不是 碰运气修，是定位到根音再修。 ep 七， review and verification 代码审查与完成前验证，自动派遣独立的审查代理。 critical， important， minor 三级分类，完成前最后一道关卡 verification before completion ep 八，就是今天分支收尾与技能创建四个收尾选项，保证每次工作都有闭环。 writing skills， 让你从技能的创造者把这八级串起来，就是 superpowers 的 十四技能全景图。 他们不是十四个孤立的工具，而是一条完整的链路，从需求到设计，从设计到计划，从计划到实施， 从实施到测试，从测试到审查，从审查到收尾，每一步都有明确的入口和出口， 每一个环节都有不可跳过的质量关卡。最后了点行而上的 superpowers 的 核心哲学三句话，第一句，不是更快，而是更稳。 ai 已经够快了，你不需要让它更快，你需要让它更可靠。 superpowers 所有技能的目的不是加速 ai 写代码， 而是保证 ai 写的代码是经过思考的，经过验证的，经过审查的。第二句，不是更聪明，而是更守规矩。 ai 已经很聪明了，但他没有判断力，他不知道什么时候该停，什么时候该检查，什么时候该问。 superpowers 给 ai 的 不是更多智商，而是一套什么时候做什么事的纪律，纪律写在技能里，技能就是 ai 的 操作规程。第三句，流程释放能力。 很多人觉得流程是束缚错了，流程不是束缚，流程是释放。当你不需要每次都决定下一步做什么， 当你有一套标准工作流可以依赖，你的大脑就被释放出来，去想真正重要的事情。 需求对不对，设计好不好？方案优不优？流程处理怎么做？你处理做什么和为什么。这三句话就是 superpowers 全部十四技能背后的底层逻辑。 八级十四技能，一条完整的 ai 编程方法练录。如果你是从一 p 一 一路看过来的，现在你已经不是一个用 ai 写代码的人了，你是一个知道怎么让 ai 在 你设定的框架里，按照你定义的流程达到你要求的标准的人。这两者之间的差距就是 professional 和 amateur 的 差距。 superpowers 在 github 上已经有十五万 star， 因为它解决了一个真实的问题， ai 编程的随机性。它不是让你多写代码，是让你少写反攻。当然，这个系列结束了，但你的 superpowers 之旅才刚刚开始， 因为你今天学会了 writing skills， 创建自己的技能。从今天起，你遇到的每一个最好每次都这样的操作，都可以变成你的专属技能。 你的 superpowers 工具集会随着你的工作越来越多，越来越好，别忘了点赞收藏这个系列，如果你觉得有用，分享给那些被 ai 编程随机性折磨的朋友。 superpowers 深度教程八集全部完结，咱们后会有期。

你有没有发现，同样是用 cloud code， 别人能让它改完整个项目，你却只能让它改一小段代码？差距不在模型，也不在你会不会写提示词，而在于你有没有给 cloud code 装上工作流。 这个新手最容易忽略的题效入口就叫 superpowers。 你 可以把 superpowers 理解成 cloud code 的 工作流增强包。它不是让 ai 突然多会一门语言， 也不是炫技插件，它真正解决的是三个新手痛点，乱开始、乱修改、乱收尾。第一个乱开始，很多新手一上来就说，帮我做个功能，帮我修个 bug， 用 cloud code 还没完全理解项目，就开始写代码。 superpowers 的 价值是把你拉回到工程流程里，先理解需求，先看上下文，先确认边界，再进入实现。 第二个，乱修改， ai 不是 写不出代码，而是很容易越改越偏。比如只改一个按钮，他可能顺手动了布局，只修一个报错，他可能迁出，无关改动。 superpowers 会把流程收住，先分析，再计划，小步修改，最后检查结果， 三个乱收尾。很多人觉得代码写出来就结束了，但真实开发里，最后还要看 def 跑测试，检查有没有破坏原有逻辑。 superpowers 适合新手的地方就在这儿，它提醒你，不要只追求深沉了，而是要追求能验证、能交付、能维护。所以， superpowers 真正强的，不是让 cloud code 变得更花哨，而是让它从一个会写代码的 ai， 变成一个更像工程搭档的执行者。 新手用 cloud code， 先别急着堆复杂提示词，你真正要学的是怎么让 ai 按流程干活，怎么让它少跑篇，怎么让每一次修改都能被验证？ 记住一句话， cloud code 负责能力上线， superpowers 负责使用纪律。把这两个结合起来，你才算真正进入 ai 编程的高校区。如果你刚开始用 cloud code 这一期，建议收藏起来，后面继续拆 cloud code 更多玩法。

小米免费赠身的 token plan 大家都领到了吧？我最近在 open code 里面使用了一下，发现这个非常好，在只要在 open code 里面安装一个这个插件 superpower 在 体验里面就和 code x 和 cloud code 几乎没有什么区别。 大家 tokyo 使用量这个会稍微高一点，可能我感觉欧本扣的同样装了这个 superpower 插件还是会比这个可乐扣的多花个百分之十的 ok 的 样子，但我觉得可以忽略。我算了一下，基本上我现在问他两个问题，他给我消耗了一百万 tokyo， 这样算下来的话基本上一个小问题就是两毛五， 有的时候你如果问题如果太大太发散的话，他可能会花掉你两块钱，两三块钱一个问题。我最近最用了一天，他送我的这个标准套餐我已经用掉了一半。两天吧，其实应该算算算两天， 按照小米的用量的话，我觉得你买 max 才正常够一个月，但它 max 要六七百，其实已经太贵了，我感觉还不如用酷狗 x 呢，大家觉得呢？

你有没有遇到过这种场景，测试一下炸四个地方，登录挂了，接口五百，按钮快照不对，日期时区也错，让一个 ai 一个个查，等到下班都像在排队修水管。 superpowers 里的 dispatching parallel agents， 就是 教 ai 一 件事遇到多个互不相关的问题，不要全塞给一个人查，主 ai 负责分工，每个子 ai 只查一块。 但重点来了，病情不是乱，派人先判断这些问题是不是独立的。如果一堆错误都来自同一个数据库，配置坏了，那就不能拆，先找共同根音。 每个子任务都要写清楚四件事，只看哪个文件要解决，哪个失败不能改什么回来要汇报什么。因为子 ai 没有你的完整上下文，你不给他就只能拆。 比如登录测试失败，就派一个子 ai， 只查登录用户接口五百，就派另一个，只查接口按钮快照不对，日期时区错误也分别查， 边界清楚就不容易互相踩脚。子 ai 回来以后，主 ai 不 能直接说完成，要看每个总结检查有没有改到同一批文件再跑。完整测试并行只是提速，验收才是兜底。 这个仓库技术站其实很轻，核心是 markdown 写的技能说明，再用插件入口接到 cloud code、 codex、 cursor、 open code 这些工具里，它不是复杂应用，而是一套 ai 工作流程。 我还查了相关因素和 pr， 有 人指出一个坑，如果工具要求同一轮消息里发出多个任务才会并行， 那你一轮派一个，其实还是顺序执行。嘴上说并行不代表真的并行。新手最该学的不是炫技，而是三件事，先判断任务能不能拆，给每个任务写清楚边界，最后统一验收，这样 ai 才像团队，不像野马。一句话总结， dispatching parallel agents， 就是 给 ai 装一个项目经理脑子，多个独立问题分头查，统一验收。想看我拿它实战跑一个坏测试仓库评论区扣分工。

今天跟大家分享一个在 a i y coding 社区里面比较火爆的一个 hackney 实践项目，这个项目它在 tiktok 上面已经狂揽了差不多有二十万左右的新标，这个项目叫做 superpowers。 今天我大家一块呃 一块儿拆解一下这个 superpowers 这个项目，介绍一下它大概是解决什么问题，它是怎么实现的。对，最后我会谈谈我对这个项目的一个看法。这个 superpowers 它解决的是什么问题呢？就是我们平时在使用 coding agent 实现我们的项目里面的需求的时候，经常会出现一些 需求没有对齐，然后它实现了之后跟我们的预期不一致啊。另外就是它实现完成了之后会有很多 bug， 它的代码质量或者代码的工程的实现其实不满足我们的要求。像这些问题，我们之前的方案是是通过我们自己跟扣电院的去对齐，把我们这些已经有的一套方法论，多轮的跟 coding agent 进行交互，让他知道我们的一些限制，我们的一些约束，希望他怎么做这件事情。 superpowers 他的解决方案就是他把一些市面上比较成熟的方法论打包成了一个固定的流程，让 coding agent 每次完成你的任务的时候，去强制地让他走这么一个固定的流程， 保证整体的任务的质量和效果的下线。对于 superpowers 来说，它把整体的任务的完成的环节拆成了几个步骤，几个大的阶段。第一个阶段是需求确认阶段，第二个阶段是当需求确认了之后，计划任务的一个阶段，计 划任务之后，它会进入到任务执行的阶段，任务执行阶段之后会有个调试的一个阶段，调试完成了之后会有代码审查的一个阶段，每个阶段里面它都会有不同的方法论内置在这里面，然后给到 code agent， 让 code agent 知道它的实现方式，就是它把这些 方法论都拆成一个一个的 scale， 一 共有十四个 scale。 最后 superpowers 通过一个 bootstrap prompt 把这些 skills 串联起来，在不同的阶段去执行不同的 scale。 这个是大概 superpowers 它的一个一个形态，每次用户在绘画开始之前，他会给 coding agent 的 上下文里面注一条 prompt。 这条 prompt 做的事情就是一个是把我们之前的这个固定的阶段流程固化下来，告诉 coding agent 需要按照这个流程去执行。另外就是它告诉 coding agent 每次在执行任务之前，如果有相关的 scale， 必须要检查是否调用相关的 scale 并且调用。另外它会有一些 prompt 遵循的优先级的规则，比方说用户的明确的指令，它其实是最高优先级的。另外就是 superpowers 的 skill， 再是 coding agent more an assistant prompt。 除了这些之外，它还会有一些针对不同的 coding agent 兼容性的一些提示词，还有一些其他的比较细节的一些规则的 声明。我对 superpowers 这个项目的看法是，它其实解决了复杂任务的场景下面任务的质量和效果的问题，但是在一些比较简单的问题上面，其实没必要用这个项目，一是它会增加你的 topic 的 成本，另外一个是它可能会有过度设计的问题，所以一些简单的任务其实没必要用它来去 来去做 harness。 如果你现在也在想办法怎么样在自己的业务场景里面去搭建自己的 harness 工程实践，我觉得非常有必要去看一下 superpowers 的 云代码，这样你可以对整体的实现方案和实现思路会有个比较清晰的了解。

superpowers 和 g stack 这两个框架最大的价值其实不是让你写代码更快，而是帮你停下来。工具越强大，走错方向的代价就越高。本视频我们会从设计哲学、核心技能体系以及具体的场景选择来对比这两个框架的区别。 superpowers 的 设计哲学非常明确，系统化优于临时性。它不像普通的 ai 工具让你直接写代码，而是像一个严格的导师，强制你在动手前必须经过思考和规划。 他靠四个原则来维持这种强制冷静。通过 t d d 实现测试驱动，要求必须遵循流程，拒绝任何猜测，始终致力于降低复杂度，并且规定只有基于确凿的验证证据才能宣布任务成功。 这十三个技能覆盖了从规划到收尾的全过程。在规划阶段，他通过 brainstorming 进行苏格拉底式的设计细化。进入开发阶段，他强制执行 t d d。 循环和隔离的工作空间。 到了审查调试环节，他要求必须进行四阶段根音分析，并在完成后进行强制验证，防止自欺欺人，最后通过并发工作流合分支管理完成收尾。整个流程的核心就是通过这些检查点确保你不会在写代码的过程中迷失方向。 理解这些流程需要掌握三个基础概念， y h n i。 要求你只实现当前确实需要的功能，拒绝过度设计。 diy 提醒你在发现重复逻辑时及时进行抽象。 而 r i d g r e n r e f a c a g o r 则是 t d d。 的 核心循环，既先写失败测试，再写通过代码，最后进行优化。 g stack 是 由 y c 的 现任 ceo gary tan 开发的一系列开源技能。它的核心理念不是简单的代码生成，而是角色分工加流程治理。 他通过让 ai agent 扮演 ceo、 工程经理、设计师、 qa 和发布工程师等专业角色，把软件开发变成了一个高度专业化的团队协助过程。 gstack 的 体系非常完整，分为思考、开发、测试、发布和反思五个阶段。 它的强大在于每个阶段都有对应的专业角色。比如，在规划阶段， office hours 能帮你重新定义产品。在测试阶段， qo 会在真实的 call 面浏览器里进行测试，并自动生成回归测试。 此外，它还配备了像 codex 这样的第二意见工具，以及 careful 这种安全护栏，确保 ai 在 执行破坏性命令前会发出警告。 g stack 最核心的价值在于两点，首先是 office hours， 它能通过苏格拉底式的提问逼你重新审视产品的必要，帮你重做一个工具，转向解决一个真问题。其次是它的多 ai 交叉审查机制， 当你同时调用 code 进行代码审查，并用 open ai 的 codex 进行对抗性挑战时，如果两个模型都发现了同一个问题，那它几乎可以确定就是一个真问题，这极大地降低了单一模型的无保率。 简单来说， superpowers 是 一个严格的导师，他盯着你的开发流程，确保你走在正确的轨道上。 而 gisk 更像是一个经验丰富的合伙人，他会不断挑战你的产品。假设如果你是刚接触这类框架的初学者，建议从 superpowers 开始跟着他学规范。如果你已经很有经验，追求多项目并行的高效率，那就用 g stack 配合 conductor。 如果你是在创业做产品，都先用 g stack， 利用它的决策能力来验证你的方向。现在的 ai 辅助编码非常方便，但这种所谓的 v 编码很容易让人掉进陷阱。 当你习惯了快速生成几千行代码，会有一种虚假的成就感。但真相是，如果你方向错了，工具越强大，你烧掉的托盘、浪费的时间和产出的错误代码就越多。 你最后不仅没学到东西，更重要的是，你只是拿着一把更锋利的电锯，在疯狂的锯出一棵树。这两个框架真正的价值并不是让你写代码的速度变快，而是把思考变成了强制动作。 他通过头脑风暴逼你回答那些不舒服的问题，通过不断的质疑来挑战你的初试假设，帮你把开发范围收敛到真正的 mvp 最小可行方案上，它本质上是在帮你确保你投入的每一行代码都是在正确的方向上前进。 如果你发现项目已经在盲目推进，请立刻停下来，用 office hours 或者 brainstorming 重新审视一下方向。如果你还没开始，请务必先跑一遍头脑风暴，确认这件事真的值得做。记住，一个想清楚的幺零零型代码，永远比稀里糊涂写出的十零零零型代码更有价值。