sdd流程 superpowers

我用了 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 的 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 的 二点五，这个时候我们就需要引入顾问者模式来做到省钱的同时保证质量。好的这节就到这里，下节我们继续。

上一个视频啊，我讲了一部分，这个 csd 黄金组合，通过 openspec 和 superpower 来实现一个既有项目的重构的工作。 本来打算一个视频把它讲完的，后来发现这个视频太长了，所以还是分成了两部分。今天讲的是下篇啊， 那么接着上篇的内容来讲啊，但是我今天发现下篇的视频还是有点长，有十九分钟啊，所以建议大家点赞加收藏下来慢慢看。 我想能把这个视频看完的人已经超过了百分之九十九的人，我相信你一定前途无量。 好，那我们进入正题。好，我们可以看到 ai， 他 问我们是否要创建一个任务的 md 文件，这里我们选 yes， 可以， 他 可以看到他已经开始工作了，我们创建了相应的一些嗯文档，然后提示我们这里是不是要好进行 调用。这个开始实施，我们这里不选这个 openspec 的 apply， 这个实施我们通过 superpowers 的。 呃，相关那些命令啊，就是 write plans 这个这个命令来 进行这个代码的编辑的相关的一些工作啊。这里提示词我们写了，就是让它阅读一下，对文件夹里的所有的文档，了解其所有的功能， 那么它就开始调用 superpose 的 这个插件，开始进行相应的一些编辑文件了啊， 然后这里它提示我们是采用什么样的一个方式来执行啊？这里我们一般都是选通过子代理的这种形式，这也是它进行推荐的一个模式，这种效率会是最高的，速度也是最快的。 然后他就开始执行这些相应的任务了。我们可以看到这里有十几个任务啊，一共十几个任务，然后有一定的任务是挂起的，现在已经是完成了一个了，是吧？然后他会陆陆续续的完成这些任务， 在这个任务的执行过程中会进行一些提示，让我们进行确认操作啊，我们一般选默认的操作就可以了，默认他第一个都选的是 yes， ta da da da。 现在全部的任务已经执行完毕了，并且他跟我提交了九个 commits。 那 我们去软件上检查一下到底 正不正常，刷新一下。 这个貌似有点问题啊，一直在加载中， 果然报错了。这个超时，我们去后台看看有没有报错 啊。这个 model 没找到啊，应该是依赖包没有。那么让 ai 帮我们处理一下这个问题，把这个错误复制给 ai， 就 复制到这里这里， 然后先告诉他 接口报错请求报错后台报错的日期， 日期为 看他能不能帮我们把这个问题修复好 啊。他要执行这个安装依赖包的命令啊，让我确认一下，我选择 yes。 嗯，这个问题比较明显了，就是说之前他安装是在全机环境的，但是我们的运行是在这个 python 虚拟环境运行的，虚拟环境也安装相应的包，我们选择默认就行。 如果我们不想每次都点确认的话，这里我们可以选择第二个选项，就不要再问我了，我们试一下， ai 回复我们说已经修复了。 那我们试一下浏览器上重新刷新试试 哦，书记是家的下来了，但是这里前阵还报错哦。 同样的去 告诉维安，让他帮我们修复这个 bug。 嗯，我们告诉 a 的 时候，为了让他尽快的去把问题解决的话，我们一般把问题提的更精准一点，比如说刚才提的是什么页面报什么错。 嗯，我们可以这样说，设置页面加载的时候，前端报错。为 大家注意一下，就是 ai 帮我们写完代码之后啊，第一遍一般都会有问题的啊， 不可能第一把就成功了，除非这个模型特别牛逼啊。 这个错误是因为转换数据库导致的啊，这个数据格式的问题，让他帮我们修复吧， 他在修改代码的时候，你看有些报错误的情况，但是他一般都是能够自行解决的， 最后他又告诉我们物理已经修复了，再试一试， 再试一试，点个刷新。哎，这次没有报错了，点一下保存，看能不能保存呢，哎，保存也可以了，这里之前的 ck nine 的 朱书记也迁移过来了，非常好看看历史， 哎，历史出问题了，历史这个是报五百错误，五百错误，看是 这个接口是吧？那我们告诉他这个接口报五百错误。复制链接 历史页面接口请求报五百错误， 看一下我们后台日期有没有报错了，那我们把这个报错日期也照样粘贴给它吧。 后台报错日记， 我们把后台日记告诉他的时候，他可以决定他找问题的时间，嗯，这很快他就给我们修复了这个问题， 我们再来刷新看看页面啊，又可以了，这个效率还是很高啊。这个 ai 啊， 然后最后一个功能，我们试试这个审批能不能审批吧，这个你选，另外选新选一个文件，帮我省阅一下这个文件啊， 正确的解析到这个文件了，说是第一次审批这个合同，然后这文件他也是把它打了个标， 认为是一个咨询服务合同文件类型咨询服务合同， 因为这个是在请求大模型啊，大模型的话可能在加载的话可能会慢一点，现在正常的输出这个结果了， 那么这个重构的这个工作，所有的功能我们都试了一遍，都是正常的。好吧，我想看一下代码 之前我们看的这个叫它封装成 request 的 这个工具包啊，还是装好了 request， 那我们看一下 request 这个文件， request 点开 啊，这里你看有些全集的这个设置，我们都可以在这个文件里面设置，比如超时时间啊， face u r 啊，是吧？然后这个请求的拦截 头肯，比如说你后面我们要加登录的话，在这里都可以加响应的，拦截的话，我们比如说在 啊重试啊，这些都可以在这里做。这样的话有个好处，就是我们如果是想在所有的请求都加一个 load 效果，或者是要加登录认证，或者加重试，都可以在这个 request 里面加就可以了啊， 然后我们其他的页面的相关的，呃，逻辑都不用变啊，这样就做到了一个统一的处理， 非常好。 然后这个功能我们已经验证过没有问题了，那该怎么办呢？我们就可以通过 openstack 的 一个规档的命令， o p s x r k o 啊，就是这个规档就说明我们这个迭代已经完成 这个 archibald 的 操作，它主要是目的是什么？就是把我们原来在这个清机子 opens 这个 openstack 这个目录下面清机子 的这个文件夹，把它移到 archibald 这个这文件夹下面啊，这样其他同事的话都是可以 在这个 ip 五里面看到当时的迭代的设计的思路啊，然后目的啊，以及设详细的设计都可以看得到。 同时 ai 也可以通过读这些文件了解我们整个的项目的一个业务逻辑啊，设计的一个架构区啊，代码的一些相关的一些逻辑都可以在这个里面看到。 刚才我们说了一个啊，开我命令是吧？开我命令的话，这里的话 它让我们选这个 data specs， excel for initial request and statistical storage both new capability this one see them to main specs before a cow 啊，它提示我们要先要同步啊，就是把相关那些更改同步， 那我们就按照它的默认选项选推荐，我们立刻同步，那么你同步一下，回车 我们可以看到它这里把这个变更分解成了两个，一个是五啊，买 circle 的是一个变更，然后这个中装 这个 request 的 这个 gs， 这个空间内两个变更啊，好，这个 ikeo complete， 那 么回到这个工程里面看一看，嗯，全部都放到这个里面里面来了 啊， 然后 spec 这里面只保留了一个规范 spec 文件， 那么这相关的文档更新呢？我们也一并提交到我们的 demo 仓库啊，这样其他人也可以看得到。当然我们也可以在中单里面直接用 get 的 to meet 命令，嗯，也可以让 ai 帮我们提交， 提交相关代码文档， 嗯，他就调用给它的命令帮我们提交。然后之前我们不是修复了几个 bug 吗？他也一块帮我们提交了。 好，已经提交了， 那到这里我们通过 openstack 和 superpowers 两个工具的融合，实现了这个重构的一个工作 啊，再回顾一下啊，这个是出定需求执行这个写这个计划，然后执行这个计划，他就会让我们一步步的选择，最后我们规章提交，最后再提交代码。 那么最后我们做一个总结，首先我们这个是用 openstack 来来探索这个需求和功能啊，结构化的定义这个迭代目标。然后第二通过 superpose 来代码实现啊， 代码实现之后我们要去验证一个个功能，嗯，一个功能之后可能会存在一些 bug， 第一次可能一般都不会成功和验证功能。嗯，如果有问题的话，我们就 告诉他哪里有问题，并且把相关的报错的认知告诉他，以提高他们这个解决 bug 的 一个效率。 最后呢，通过 openstack 的 这个规章啊，把相关那些代码提交了，把那个文档也提交到我们的代码仓库。

然后刚才提了这个规范，我，我可以把这个我用我试用了两个工具的规范的这个截图跟大家做个分享，就是我用了这个叫做 superpowers 这个这个事件 先首先跟大家做一个对齐吧，就是就是 ai 为什么代码总是跑偏呢？就是不是 ai 不 够聪明，是缺乏约束，就是缺乏我们用规范来约束它这个整个的一个工作流程，其实真的大部分军事项目来说的话，靠谱比聪明更重要的多。 而 superpower 的 话它定了几个流程呢？第一个是头脑风暴，第二个是设计确认，第三是实现计划执行、开发代码审查，它把整个开发的过程把它提炼成了这几个典型的这个工作步骤啊。 我这里先先安装了这个我我使用的工具是 cloud 扣的，然后先把这个这个插件，它是用的 cloud 扣的一个插件先注册，然后安装，安装了之后我大家可以看到我首先给它做的是一个头脑风暴， 同样方法就是相当于我跟他交流我要做一个什么东西，他会问我一些问题啊？就像那个苏格拉底式的形式，你是不是做成这样啊？你是不是这样他就会跟你反复交流多少次，把这个需求澄清好对齐，好让他再写计划，再写成，把分解成再进行执行。 我比如说我跟他说我想做一个代办事项的应用，代办事项的应用，他他就这样的对应的技能 skill 啊，然后他就帮我分析了，然后就问我，你是想做外部应用还是桌面应用 还是手机应用啊？我就告诉他我要做外部应用，你看这个对话的方式是不是跟我们平时日常工作是很像啊？比如有人给你安排工作，你想做一个软件，其实这个背后的信息量是很大的，就是如果不清楚这个东西，做出来东西就是有可能是 风扭牛马，不急的，是吧？那种就会有不同的这个反沟通，我就跟他说外部应用，然后他又问我， 有些内容是可能用格式化的方式来展现更清晰啊，可以展示界面布局、设计图，颜色方案对比， 想不想问我想不想在浏览器中边看边讨论？我跟他说想，然后他又巴拉巴拉又又问我做了些什么，然后直接就给我启动一个浏览器的网页了，你看， 然后我就通过这个网页就能打开，实时看到我做的这个东西。然后接下来他又跟我说， 浏览其中展示有三种风，三种布局风格啊，然后 a 是 极简菜单栏，二是侧边栏的导航，三是看门式 啊，他就根据他的模型之前学习的经验，他就来让我做选择题啊，到底是怎么布局的，然后我就选了侧边栏的导航的布局， 然后他就跟着我的指令开始做了啊，写下面下面的东西，但是这个过程他现在还是没有开始写代码了， 然后他又问我，这个风格视觉的风格是简约的，深色的还是活泼的啊？然后我给他选了一个叫柔和自然的啊。接下来然后大家又问我需要些什么功能 啊？ a、 b、 c， d， 我 我选，我都要，我就把所有功能都都写上去了 啊，他积极跟我说，因为这个应用它有数据存储嘛，是吧？数据存储，到底这个数据是存到云端还是本地，还是还是在哪里？我就给他说直接存本地就行了啊，不需要上云端，这样我就不用搭一个服务器，我就选了，然后接下来他又 他就跟我确认一下，我选择了侧边栏，如何自然功能呢？还有哪些？然后选择本地，还有跟我做了一个前期的一个确认啊，确认了之后他就开始跟我做方案了啊，技术，技术站选了哪些技术 啊？然后技术还把数据模型都给我设计设计出来了，然后他问我整体这个设计方案是不是符合你的，然后我大概看了一下大差不差，我们 符合，我就回复了符合，然后他就开始给我写了一个这个设计方案的 md 文件啊，但是我去看这个 md 文件的时候，我发现有的那个技术需要调整一下，因为它用的是 react 的 这个技术 啊，这个不符合公司的这个整体的技术要求啊。我们是用的 view 嘛，所以我就手动去改了一下这个文件啊，改了一下，打开打，我把它改成 view 三了， view 三了， 那 vivo 三零。然后我其实啊，我手动去改了，我说我手动去改了这个文件，然后他他识别到了，他识别到了之后，让我感到很很惊讶的是 他把相关联的这个，我技术技术这个把，只是这个技术语言改了一下，他把相关联的功能他都给我给我找出来了啊，你看， 然后他说你想用这个这个，然后他的存储的方案就要变了，原来 view 的 话它是，它是原来 react 的 话，它的状态管理是是 react context 这种方，但是 react 的 话它它肯定那个存储是是不能用的，那它就还提示我是不是换一个这个存储方案，然后我就说换换一种，我接着它就把相关的技术文档给我重新调整了，可以看到。 然后下面就是就是一些确认的操作啊，一些确认的，我跟确认了最后他这个这个询问的这过程，确认方案的过程，确认完了之后，他就开始写计划了， 把刚才这些确认的方案进行了计划的一个拆解， 但是计划了拆，拆解了之后我发现有一个一个比较比较恼火的地方，就是用着用着我那个 token 没有吧？ 我用的是那个 mini max 的 这个 token， 之前是注册了之后送了十五块钱，然后我用了就没有了，我还这个任务还没做完，然后我想继续做，那怎么办呢？我又去充了钱，我又去充了十块钱啊，我又充了十块钱， 充钱十块钱，然后充完之后我又回来跟他说，那继继续啊，继续干活啊，那他他就继续 搞，搞完之后啊，他就把这个计划插进成了十二个任务啊，十二个任务， 然后十个任务，他就依次执行这个任务，嗯，当然这过程中会有些让我确认的一些东西啊，放进一些文件， 然后把任每个任务就不详细讲了， 然后他把那个任务任务做完之后，他才自动进行构建测试一遍啊，这个就算开发完成了， 但开发完之后让我去检查，让我去检查，我就打开网页把它看看，但是我发现一个 bug 啊，就是 这一个左边的这个这个分类啊，我新建了一个分类，我是想建三个分类，叫做工作，生活还有学习这三个分类，但是我建了之后，但是只显示了第一个字，我发现它又出现了一个 bug， 然后我就我就跟他说，我就跟他说侧边栏的分类显示只显示了一个字啊，我希望最多显示四个字，然后超过了字用省略号替代，然后鼠标移到上面时候提示完整的名称。 嗯，我跟他说，但是他就就已他说已修改，他修改了些代码，然后我就看了 还是还是没有实现，但是这个功能都还没开发完，这个钱又没了，而且这个太，所以这个太费头狠了，这个十十块钱，所以这个现在 ai 编程就是 ai， 它每每次你跟输入的字， 还有他每次回复你的都是要花钱的。这个确实这个成本有点高啊，所以为什么之前有的人说每每年要给这个 ai 编程的专项预算呢？所以我刚充了十块钱又没了。 那没办法，为了节约钱嘛，我就只能在我本地上，本地上那个用那个 code code 来来跑自己的模型了啊，但是我把本地的那个欧莱曼的模型跑起来之后调用还调用不了，我发现后来调用不了， 虽然我用了那个叫 light am 的 那个做代理呢，还是调用不了啊。他，他可能是 用不了，所以我就用了那个换了一个工具叫 opencode 的 啊，这个是 cloudcode 的 平替版，相当于因为 cloudcode 它是这个收费的嘛，它它这个模型，所以有个开源的这个 opencode 的 平替版。 这个工具有个好处就是它可以直接选免费的模型，我发现就是它能直接选 kmi 那 个 mini max 的 二点五的那个模那个模型，然后切换了模型之后我又跟他说一遍这个问题，啊啊， 这次它已经很快就给我修好了，虽然这个现在这个 mini max 已经出二点七了，但是二点五的模型还是可以能把这个问题给我解决，还是免费的，挺好啊。 然后我跟他说这个问题之后他还提提示我，他他我提示我怎么去找这个问题啊？他问我， 你是在哪里看到的保存结果啊？让我去看一看这个值有没有保存上，这个提示很好，然后我我就去那去看了一下，确实是 它只保存了第一个字，它 name 只保存了第一个字，然后另外一个字保存到另外一个字上去了，就 color 那 个字上去了啊，颜色那个字上去了啊， 嗯，它给我提提示很好，然后然后我就我就把我找到的这个问题再告诉他，更精准的告诉他，我说你， 我说你，我说我说你，你，我看了一下 local storage 那 那个字啊，然后第二个字是保存的 color 字那种，我把我通过这个提示他的话，他一下就把问题找到了，一下就给我修复了，就完美解决了。嗯，这个 这两个字就完美完美显示出来啊，这个就是我我我亲自这个实验做的，这个通过这个啊， sdd 的 这个这种规范驱动的开发的这个一个具体的工具来试，来试的一个一个项目实验的项目 可以看到就是他整个整个流程是是有些繁琐是吧？可能有的人觉得这个太麻烦了，我们一步步跟他沟通，没有这种一句话的，这个这种这种来的直接来的来的来的爽， 其实这个是虽然我们在前面跟他做交流花的时间，但是就可以避免很多这种反攻的情况啊。前面其实是是值得的，前面投入的时间， 因为如果你只是跟他出模糊的需求，你让大魔仙给你拆盲盒，你开的也是盲盒，你后面你做的东西也达不到你的要求，有可能你中途跟他来回很多遍啊，很多遍都还达不到你要求， 导致你跟他说了很多话，很多话之后，他那个上限已经超过了他，到时候你把前面你跟他说的话忘了，会出现这个问题啊。这，这就是我的一个具体的一个经验的感受，一个分享。

openspec 和 superpowers 是 当下做 spec coding 非常出名的两个项目。在日常使用过程中，我们一定有组合 skill 的 需求，但问题是，两套 skill 的 技能命令是分散的，没办法自动触发。并且有的部分 skill 我 可能不是那么想用， 比如我更喜欢用 superpowers 的 t d、 d 执行，而不是 openspec 的 apply， 更需要用 openspec 的 archiv 能力规档 spec， 而不是 superpowers 的 一次性 spec。 怎么组合市面上的高斯大项目，让它们自动触发，互相取长补短， 怎么让整个状态扭转更可靠？这些看起来能够实现的点，在实际的开发过程中依然还有很多细节考量。 同时，两个 skill 都会产出 spec 文档，这部分也需要自然地融合在一起。 comet 就是 组合这两者产生的项目 想要做的事很直接，把 openspec 管需求的能力和 superpowers 管实现的能力接到同一条流程里，他不改这两套东西，只做组合调度。先看 openspec 这边，他很擅长管理 spec 的 生命周期， 当前需求放在哪里，变更材料放在哪里，最后怎么归导这条线是很清楚的。所以这对应于 what 部分，也就是要改什么内容。 openspec 能够很好地列出大纲，但其实 openspec 依旧有一些不好用的地方，它的 proposal 和 tasks 能说明要做什么，但不等于已经说明怎么做。 到了工程设计阶段， agent 还要补方案、补边界、补判断画面。中间这个问号就是这个的设计缺口。 openspec 的 需求澄清能力并不是那么强。再看 superpowers， superpowers 补的是 how， 是 怎么去做， 他会先澄清需求，再做深度设计，然后写计划，按 tdd 推进，最后验证和收尾。中间会不断地和用户交互沟通细节。也就是说，他把真正实现时需要的链路拉细了，两者均会产出 spec 文档。 但是如果只靠 markdown， 也会存在另一个问题，任务打勾了不代表阶段状态可靠，人事能够通过，看文档能猜出来，但 agent 下一轮回来不一定能稳定判断现在到底走到哪一步。 所以断点恢复才是核心问题。下一次绘画开始时，通常的断点恢复， agent 会先读文档，再扫代码，然后再推断阶段代码还没写， token 已经花在恢复现场上了。 comet 通过一个清亮的状态机机制来实现断点恢复，要省掉的就是这段重新找路的成本。 comet 的 定位不是再造一套方法论，它更像一条稳定轨道，把 openspec 和 superpowers 放进同一个项目流程里，让两边各做自己擅长的事，并在执行过程中对齐两边产出的文档。 openspec 管需求世界 需求是什么，题案怎么写， spec 怎么变更，最后怎么归党，这些都属于 what， 他 负责把要做的事讲清楚。 superpowers 管执行方法、头脑风暴、技术设计、实现、计划、执行、验证、收尾，这些都属于 how， 他 负责把怎么做拆细。 commit 站在中间，把 what 和 how 接起来。左边是 openspec 的 需求材料， 右边是 superpowers 的 实现方法。下面输出一条 open design build verify or shift 的 流程。 commit 不 替代 open spec， 也不替代 superpowers， 它只负责把阶段状态和 skill 出发点对齐，这样两套能力就不是两堆文档了。 proposal spec， 生命周期、 archive 状态和 brainstorming design， doc execution plan 会进入同一条 shared state， 最后落到出发规则。 open 阶段找 openspec， design 和 build 找 superpowers。 verify 阶段两边一起收口，在对应的阶段真正的触发正确的 skill， 而不是让 ai 产生触发了 skill， 但实际上是 ai 自己写的幻觉。 完整流程可以拆成五个阶段，每一段都有自己的命令和产物，不靠 agent 临场拆下一步。第一段是 comet open， 这里由 openspec 接手，打开 change 生成 proposal design 和 tasks， 先把这次到底要改什么固定住。 第二段是 commit design， openspec 的 产物会交给 superpowers 继续细划，重点不是马上写代码，而是先把边界、方案和风险讲清楚。第三段是 commit build， 这里进入工程实线， plan、 tdd、 subagent 都在这一段接上， 能按计划推进就不要临时乱跑。第四段是 comet verify， 这里 openspec 和 superpowers 会进行同步收缩，一个处理文档，一个处理代码，收尾测试要过，报告要有，需求和实现也要对齐，不是跑完代码就算验证结束。 第五段是 come to archive， 所有的需求变更同步回 main spec， change 进入 archive 状态机补充文档核心状态，这时候 open spec 和 superpowers 产出的文档会进行双向关联，到这里产出的 spec 关联文档才不会留下半截流程。所以需求不是代码写完就结束， task 勾完也不够，真正结束是实现文档和状态都对齐，使用 command 出使化之后，项目会被分成三层平台， skill 放一层，包含了 command 的 核心脚本， opensback 的 change 和状态放一层 superpowers 的 设计文档和计划放一层 斜杠。 comit 是 skill 的 核心入口，用户在使用的时候，不管当前 spec 状态如何，都可以通过这个入口进行工作。他会先检测当前 spec 状态，读取 workflow phase， 然后决定下一步该进哪个阶段。 入口先判断现场，再路由动作。当我们面对长城任务做到一半工具关掉了的情况时， 回来之后不应该重新讲一遍背景，而是直接输入 comet 继续。它会从当前 spec 状态恢复现场，不再需要重新探索项目。 如果项目里有多个活跃 spec 时， comet 会先把它们列出来。当你选择了具体的某一个 change 时，它再进入阶段判断，这样就不会把几个需求的状态混在一起。选定之后，它会定位当前阶段，比如现在是 build 就 从 build 继续，而不是重新扫描项目。 长城任务真正需要的就是这种明确的继续位置，这种设计能够极大的减轻你的使用认知负担。我们拿到 skill 不 再需要记多个命令，而是直接 comit 继续就好。 comit 会帮你把状态记住，帮你把流程走下去。支撑恢复能力的是这个轻量状态机，每个 open spec change 都绑定自己的状态，也就是说状态不是大局混在一起，而是跟着具体的状态。是 workflow 和 face。 workflow 决定走完整流程， hotfix 还是 tweak。 face 决定现在卡在 design， build， verify 还是 archive。 再往下是恢复上下文， design， doc 在 哪？ plan 在 哪？ build mode 是 什么？当前是否在隔离分支里？ 这些字段让 agent 回来后能接上，而不是重新扫。项目验证和归档状态也需要写进去。 verify result， verified at archived， 这些字段不复杂，但足够判断下一步是不是可以继续。关键是状态不能靠 agent 手改。烟雾 commit 要通过脚本写回状态， 只有条件真的满足，阶段才允许流转，这样能减少看起来完成的状态飘逸。 commit guard 脚本就是阶段闸门，它检查文件是否存在， face 是 否匹配 tasks 是 否完成， 条件不满足就 hard stop， 只有带上 apply 才真正更新状态。 com state 脚本提供统一读写接口。 com tm validate 脚本负责校验必填字段，每举直路径引用和未知字段，一个负责改，一个负责查，状态就不容易飘。最后是 coming r shift 的 脚本，它会验证入口状态，同步 spec， 移动 change， 再把 r shift 写成 true。 需要先看效果，也可以走 dryrun preview。 安装过程如图所示，从 npm 安装之后进入你的项目执行。 commit in it commit 采用交互式命令集成，安装步骤非常简单， 说实话会先确认三件事，平台配置、安装范围。 skill 语言，你可以装到当前项目，也可以装到局目录。为了方便理解 commit 的 原理，分发的时候也支持中文或英文， 选择依赖后，相关的 skill 就 会自动就位。 open spec skill、 superpower skill、 comet skill 会部署到选定平台， specs 和 plans 这些工作目录也会一起创建好。 平台分发也交给 comet in it cloud code， cursor codex、 open code， winsole 还有其他 ai coding 平台，都按自己的目录结构放好，你不用手动搬 skill 文件。 除了完整流程，还有 comet、 hotfix， 当 bug 已经明确时，它会跳过完整 brainstorm 和 design， 直接走 open build， verify archive， 适合目标很清楚的修复。第二个是 comet tweak， 文案调整、配置调整、文档修改、 prompt 优化都可以走这条清路径，它比完整流程更清，但仍然保留 comet 的 入口和状态管理。 comet 还有一个价值，它是组合 skill 的 参考 强工具很多，但真实使用时，你常常只需要其中一部分能力，比如 openstack stack 管理、 superpowers 的 tdd 和深度设计，再加上规党能力。难点不是把文档拼在一起，难点是稳定组合嵌套。 skill 要真的触发，不能只是让 agent 看着说明访写文件，状态也要可观察，不能看起来像触发了，实际没有跑多阶段流转。 也不能看起来像触发了，实际没有跑多阶段流转。也不能看起来像触发了，实际没有跑多阶段流转。也不能每一步都靠人提醒，人工接线很容易断。 commit 把必要选择留给用户，把核心推进交给状态机和守护脚本，所以它也是一个参考，实现 skill 调度、状态机、阶段守护、规章自动化，这四块组合起来才是一套能落地的多 skill。 工作流收缩一下 openstack， 让需求有生命周期。 superpowers 让实现有方法论。 commit 把两者接成一条可恢复、可验证、可规党的流程。 从两条命令开始安装 commit， 然后在项目里执行 commit init 初步化之后就可以用斜杠 commit 加你的想法，进入完整流程。最后我想说的是， commit 留下的不是某一个命令，它证明的是一套组合范式，千套 skill。 要真正出发，多阶段流程要能自动流转 状态机和守护脚本，要让这套组合在真实项目里可靠落地。希望大家能从这个项目里学习到好用的知识，一起创造更适合自己的 skill。 接下来我们来看一段时机演示。以我本地的一个项目为例，现在我输入斜杠 compt 为我的项目创建一个电子宠物功能。我们可以看到 comet 触发了 comet open， 在 comet open 中又触发了 open spec 的 explore， 这时候 agent 会根据 explore 的 要求进行一轮项目探索。每一个嵌套 skill 在 真实出发时，都会在 cloud code 中显示 skill 的 打印。这个探索的过程比较长，我们稍微快进一下。探索完毕之后， explore 会进行多轮大碎方向的澄清，这几步需要用户进行反馈。 完成之后会生成 open spec 对 应结构的 proposal、 design、 spec、 task 等文件，并在 changes 目录下创建当前激活的需求。 然后是 comi 的 状态机核心文件出场和状态守护执行。我们可以看到，当 open 阶段完成时， agent 想要退出 open 阶段，会有强制的状态机交易，对于核心文件和状态一定得满足之后才能够进入下一阶段。 这里都 pass 通过之后， comte design 也成功被 comte open 触发了。之后 design 阶段会将 openspec 创建的文档作为上下文传递给 superpowers 进行头脑风暴，更加细化需求之后的步骤我这里不再接着展示了，欢迎大家亲自体验。下面我演示一下阶段活跃检测及断点恢复功能。 当我们在多台电脑上工作或者临时有事离开了，回来之后只需要输入斜杠 commit 继续 commit， 就 能够通过状态文件自动识别当前活跃需求。 我们可以看到不再需要重新大量的探索项目 agent 很 快就知道了当前需求的活跃状态，如果存在多个需求，也会将它们列出来供用户选择。以上就是本期视频的全部内容了，欢迎大家点赞关注 star 本项目，谢谢大家！

这节我们讲下 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 这个学习曲线已经不是我们自己去写的，无所谓。 下这个归零文件计划的话，我们先不做，放到下一节， 那就看一下它的这个规范文件项目名称、用途、技术段，然后我们的一个核心功能，下载管理、配置管理 很不错，这节就到这里，下节我们做计划和选型。

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， 解放你的生产线。

最近，我给一个零基础，完全没有技术背景的朋友，在他的电脑上装了 cloud code 和 six skill。 结果他现在每天工作，白天就抽空构思一下想法，晚上回家花一两个小时就用 web coding 把完整的项目给做出来了。 前两天，他特别空虚地对我说，现在实现 idea 太容易了，大学里的那些编程课好像没有什么必要了。 今天这期，作为一个写了二十年代码的程序员，我直接把初学者最炸最有用的三个 skill 分享给你们。只要装上它们，你 web coding 的 能力就不再只是做一个玩具，而是质的飞跃。点赞收藏，我们直接开始第一个 skill， superpowers。 很多人以为 ai 写代码是我给一句提示词，他图一堆代码给我。如果你这么想，那你永远只能做一些小玩具。科技行业什么最值钱？是 sop， 是 标准化的工作流程。 superpowers 不是 简单的提示词，它是直接给你的 ai 注入了一整套顶级的软件公司方法论。装上它， ai 就 不再只是一个只听指令的打字机，而是瞬间成为全自动运转的技术团队。 在这个生态里，包含了十四个环环相扣的技能。当你抛出一个模糊的想法，他会先出发。 brainstorming。 他 化身产品经理，用苏格拉底的提问帮你把卵脑子里的一团乱麻梳理成专业的设计文档，专治小白的，想不清楚，说不明白。 接着是 writing plans， 它像架构师一样，把大项目拆解成一个一个好落地的小任务。 最觉得是他的 sub agent driving development。 在 执行环节，他会针对每一个小任务，自动派活给不同的 ai 员工，还会严格遵循先写测试，再写代码的红绿重构标准。 他自己可以在那里干好几个小时，绝不跑偏。最后做代码审查，查 bug， 合并代码， 这全都是自动化的流程。听到这里，你可能会问，老哥，这么多高深的概念，我需要学吗？答案是，你完全不需要懂，更不需要管。 你就像一个公司老板一样，你需要亲自去画圆形写代码做测试吗？并不需要，你只需要输入需求，整个团队自己就运行起来了。你只需要坐在那里回答 ai 抛给你的几个确认问题就行。 我朋友就是这样几句话， ai 自己分工，自己设计，全自动帮他搞定了一个 a 股行情复盘系统，这就是 web coding 的 全自动发动机。第二个 skill， front and design 后台逻辑搞定了，那界面怎么办？这个时候，第二个技能 front and design 出马了，它的核心任务是把界面变得好看，彻底干掉你页面上的 ai 位。什么是 ai 位？ 万年不变的默认字体，俗气的紫色渐变，死板的居中排版，大家看了只觉得廉价，但小白又不知道怎么跟 ai 形容，我要高级感， front and design 就是 你的顶级艺术指导。你在写代码之前，它会强制你自己先做设计思考今天的网页，是走复古未来风、极简杂志风，还是旷野工业风，它自己会定基调，你不用费心描述，它会自动调用视觉武器， 抛弃烂大街的字体，换上极具性格的排版，大胆使用留白，甚至给你加上丝滑的滚动 动效和高级的造点纹理，这不仅仅是让你的项目从能跑变为能看，直接把你的野生点子包装成了过目不忘的顶级产品。第三个 skill， chrome dev tools 有了大佬执行，有了神仙颜值，一切就完美了吗？不一定，你的网页可能有 bug， chrome devtools 就是 你的全自动测试工程师。如果说前两个技能给了 ai 大 脑和画笔，那么这个基于谷歌官方 mcp 协议的神器 skill， 就是 直接给 ai 装上了眼睛和手。 以前 ai 写代码是蒙着眼睛跑，出了 bug， 你 得疯狂地复制报错信息给他。现在他能直接接管你的 chrome 浏览器， 他会像真人一样自己打开网页，点击按钮、填表单，走通整个流程。发现不对劲，他会自己去查控制台的红字报错，抓取网络请求，然后自动回去改代码。他甚至还能顺手帮你做一个加载速度和 seo 的 性能体验。 我朋友说整个流程他最震撼的就是这一步。以前听说程序员提 bug 掉头发，现在他就端着茶杯发愣，看着 ai 自己打开页面测试，自己发现错误自己修复，而他什么都不用做。各位新手想提高自己 web coding 的 能力，记住这三换神， superpowers 管大脑执行， frontend 管皮囊审美， chromevtools 管深度体验测试。 现在市场上的 agent skill 成千上百，你不用去焦虑，作为一个写了快二十年代码的程序员，我帮你验过货了。 装上这三个 skill， 再加上你的创造欲，足够你靠 web coding 做出一款商业级的产品。欢迎在评论区告诉我你有什么推荐的 skill， 这里是 acodeem， 我 会持续推荐 skill， 欢迎关注。鸡变藕不变，我们下期再见。

ai 写代码很快，但也真的很容易跑偏。 k 号上面有个很火的开源项目 super power， 收藏了十八万颗星。它的思路啊，很简单，让 ai 编程更可控， 不是靠你把 power 写得像论文一样，而是把工作流程嵌进去，有点像之前 bmac 和 openstack 这样的 sdd 规范编程。 也跟 coco 的 harness engineering 驾驭工程啊类似，用流程管住 ai， 而不是简单的靠几句提示词。它也支持主流的 ai 编程工具 coco 啊。 curses 核心是把十几套和工作流相关的 skills， 把开发前的头脑风暴，需求分析写实施计划，再到分布执行指导你拆任务整条链路啊，全部串起来，质量和调试这块呢，还有 tdd 的 红绿灯节奏， watchchain 的 这种隔离的试做，以及验证和代码审查都写到了流程里面，说白了就是在解决光靠 prom 很 难把 ai 约束到可靠的这种问题。 那网上吹的这么火啊，我就拿重构这种硬核来测一下，因为重构就要肯懂旧的代码，又要吐出大量的新的结构，这比从零到一写代码或者纯做代码阅读理解啊都麻烦很多。我分别使用像 codis 加 gpt 五点四， ctrl 加 ops 四点七，以及 clocal 加 minimax， 几乎用上最强的模型来对我的这个简单的工作时间记录器进行重构。原技术框架是用 html 加 css 加 js 三件套写成的， 现在改成 miui 三。我相信啊，用了 superpower 啊，这个效果应该会好很多。我们来看一看实际的效果。纳尼？这是 cvt 加 gbt 五点四做出来的配色啊，挺丑的， 而且很多按键的功能都失效了，这是 ctrl 加 alt 四点七模型做出来的，基本的功能啊，都能用，但是啊，界面真的是不敢恭维啊，这是拷扣做的 哎，界面还原度还可以，但是呢，按钮也全都失效了，真的是妥妥的 ai 编程大翻车现场啊。可以看出，在这个项目的重构上，用最好的 ai 工具加最好的模型， 大家呢，做过 pos， 也没有发生什么好的质变，同样的活呢，换个中等水平的工程师啊，往往还能做的个框架。所以我有个不太成熟的结论就是现在的 ai 编程框架未必抬得起来上限， 但更多时候是在台下线，就不一定会给你加分，但至少不会帮你减分。那你也让 ai 概括重做的活吗？有没有哪种框架或打法实战里面呢？真的发生了质变？欢迎来聊聊。

今天我想用一套可以直接在团队跑起来的方法，讲清楚一件事，为什么同样用 ai 写代码，有的人在堆垃圾系统，有的人却在稳定交付？差别不在模型，而在流程。一是什么？从对话写代码到工程化流水线？很多人现在写代码是这样的 一个需求，问 ai 生成代码修改，再问再改，看起来很快，但结果通常是，代码能好，架构是断，系统是不可维护的。问题本质不是 ai 不 够聪明，而是你没有一条确定的生产流程。真正的方式是反过来，先定规范，再出方案，再拆任务，最后执行交付。这背后对应一套工具体系， expected 负责规范和设计， superpowers 负责执行和约束， openspec 负责存量系统引进， b m a d 负责多角色协调。二、为什么不做工程化 ai 必然失控？你在使用 ai 时，一定遇到过三种情况，刚定的规则， ai， 下一个就忘了。刚做好的结构，下一次生成就会推翻同一个需求，每次代码风格都不一样。问题不在模型， 而在缺少约束系统。 ai 天然有三个特性，容易遗忘、容易扩展过度、容易上下文漂移。所以必须用工程方式管住它，不是靠更好的提示词，而是靠更强的流程约束。 三、怎么做一套可以直接落地的完整流程？下面这套流程可以直接在团队执行。第一步，项目出手话先做出手话， specify in it 系统会生成一个目录点， s， p， e， c， f， y 斜杠。这个目录的意义很关键，它不是存代码，而是存工程记忆。里面建议固定三个文件， spec dot mb， plan dot mb， tasks dot mb。 第二步，定义需求输入命令 specit specify。 后面跟业务描述。例如，实现用户注册接口。这一步只做四件事，用户怎么用？输入输出是什么？边界条件是什么？验收标准是什么？这一阶段有一个硬约束，任何人都不能写代码。第三步，生成技术方案， 执行 spikit 计划。这一阶段关注的是结构，而不是实现输出，必须明确涉及哪些文件，数据结构怎么设计接口如何拆分，有哪些风险点。这一阶段的核心作用是锁定边界，防止 ai 扩散实现范围。第四步，任务拆解，执行 spikit tasks。 这一阶段非常关键， ai 会生成任务列表，要求必须满足三个条件，每个任务五分钟内可完成。每个任务只涉及一个文件，每个任务可独立验证。设立创建 control。 定义有二类型， 实现 create view 方法、编辑单元测试。这个阶段的本质是把一个功能拆成很多小动作。第五步，执行阶段进入执行阶段后，规则完全改变， 每次只执行一个任务。例如执行 task 点 md 中第一个任务，同时必须满足四条规则，先写测试，再写代码，只改当前文件，不允许扩展功能。执行过程中禁止做三件事，不能重新设计，不能跳任务，不能修改非任务文件。这里的核心控制逻辑是让 ai 不 做判断，只做执行。 第六步，隔离执行环境，每个功能建议使用独立分支， get work tree， add feature x x x。 这样做的原因很简单，上下文越长， ai 越容易失控。 第七步，代码审批执行完后必须做 review， 调用 request in code review 输出要求严重问题，一般问题优化。建议，这一阶段的意义是让 ai 同时具备开发能力加审计能力。第八步，规章 执行 openspec archive 作用是把本次规范和代码绑定，避免文档和代码脱节。四、工具组合建议不同场景直接这样选。新项目从零到一 specit 加 superpowers， 老系统改造 openspec 加 superpowers， 强监管行业 b m a d 多角色体系，个人快速开发，轻量任务流。 五、本质变化是什么？ ai 编程真正的变化不是工具升级，而是开发方式从人控制代码变成规则控制， ai 从随机生成 变成可预测交付。 ai 编程的分水岭不是你会不会写提示词，而是你有没有一套工程化流程。当代码不再靠灵感生成，而是靠流程驱动时，系统才真正开始稳定运行， ai 才真正开始变成生产力。

大家好，我是小鱼 ai 研究员，本期我来分享 web coding 博克实战第四期， 让 ai 写代码也可以懂规矩，用 superpowers 驱动软件工程规范落地，从随性写代码到标准化工程开发的质变。 好，那我们先来进行上期回顾，主要上期解决了哪些问题？通过引入 clone 的 点 md 文件，统一了代码风格、视觉样式和交互逻辑，为团队的合作开发建立了明确统一的标准。二、也留了挑战。尽管 clone md 统一了代码结果，但它无法管控开发流程， 这成为了我们在 web coding 实践中遗留的挑战，也是我们今天需要解决的核心问题。 下面我们看一下这些挑战具体表现为 ai 开发过程中的五大乱象，它们严重影响了项目的长期健康。一、跳过设计直接进行编码。 ai 被授于模糊需求后立即编码，缺乏前期架构设计，导致代码结构混乱，后期难以扩展。二、无标准化任务拆解，将复杂需求一次性抛给 ai， 导致深层的代码庞大且饱和度高，最终造成迭代过程不可控，项目风险剧增。三、缺失测试开发流程。 ai 只负责实现功能，几乎不编辑，测试用力导致系统稳定性无法保证，回归测试成本高。四、无专业的代码审核机制。 ai 生成代码被直接采纳使用，缺乏有效的人工审核和规范，可能导致代码中包含荣誉逻辑和潜在的 安全漏洞。五、长期迭代。一、项目失控。上述问题不断累积，导致技术债台高筑，代码库变得臃肿，最终项目将变得不可维护，甚至需要花费大量成本推倒重来。 好，那针对上一页提到的 ai 开发乱象问题，我们可以通过引入 superpowers 推动开发模式升级，遵循规范按标准的软件工程流程开发，最终形成全链路管控闭环。那什么是 superpowers 呢？是 ai 编码的开发方法论的封装， 核心价值不在于具体的某个技术，而在于将成熟的软件工程实践，比如 t、 d、 d 设计评选、净化驱动、严格审查固化为 ai 可执行的 skill 流程，解决 ai 不 讨论就直接开写代码根本性问题。 好，下面我们看一下如何使用 superpowers 进行重塑开发流程呢？ superpowers 作为一套标准化的软件工程方法论，是如何引导 ai 重塑开发流程的呢？它将强制 ai 严格遵循以下标准流程，一、需求梳理。二、设计频审。三、任务拆解。四、 t、 d、 d 开发五、代码审核六、调试修复七、接待收尾。 通过以上标准流程，我们就能从根源上解决 ai 无需开发随意编码问题，让 web coding 真正具备正规软件工程的属性。下面我们看一下如何实现零配置一键安装 好。我们这里主要介绍 coco 的 一个安装环境，我们可以在 coco 的 终端输入下面的命令，按回车执行就可以实现一键安装。安装完成后，新建绘画会自动加载，所谓工程化的能力不需要我们去手动开启好，安装完成之后会自动激活， ai 会自动遵循并应用新的工程化流程，不需要我们去输入额外的指令进行出发。 接下来将通过两个实战案例，直观展示并应用新的工程化流程与代码质量的显著变化。 案例一，未使用 super force 案例二，使用了 super force。 好， 下面我们看具体的案例。我们先打开扑克的源码，可以看到当前项目功能比较基础，只有静态页面和模拟数据， 整个项目的代码逻辑全部集中在 app 点 view 这一个核心文件里面。 接下来我们启动本地服务进行预览，页面可以看到终端正常输出的地址，我们打开链接进入到泊客首页， 然后我们进入详情页，页面能够正常展示，然后泊客整体运行没有什么问题。接下来我们打开 close code 的 终端，来查看一下已经安装的插件， 可以看到并没有安装 superpowers 的 插件，然后我们输入指令帮我实现评论功能。基于 v o e 三加 local storage 输入完成回车 ai 会自动进行编码开发，我们只需要等待开发完成就可以了。 好，大约等待三分钟左右， ai 已经完成了评论功能的开发， 然后我们输入五幺七三访问一下。呃，看起来这个服务并没有成功启动， 我们停止一下重新启动，然后点击访问链接，切换五幺七四的这个地址，访问页面可以看到能够正常访问。 接下来我们进入详情，可以看到评论的内容，然后我们输入内容提交测试，评论可以正常发布，不过目前仅支持基础的评论， 还缺少评论回复功能，整体评论功能还不算完整。接下来我们打开 app 点未有文件， 然后我们找到评论的功能代码实现，可以看到 ai 自动生成的评论代码，这段代码存在明显的问题，所有逻辑全部放在一个文件中，没有做模块化的拆分，这会造成代码的饱和度高，给后续维护和迭代造成麻烦。 接下来我们就来演示一下 superpowers 插件的实战用法。首先打开 github， 复制 cloud code 插件的一键安装指令，然后我们在终端会车执行，这里我们选择第一种用户作用于的方式进行安装，然后等待安装完成， 安装成功后，我们在终端输入斜杠命令， 帮我实现评论功能，基于 vivo u 三加 local storage 回车，这样 ai 就 会自动触发需求的梳理流程， ai 会通过交互式提问的方式帮我们一步步完善开发需求，我们只需要一次选择就可以了。 好，我们可以看到。第一个问题，评论的数据结构，这里我们选择 a。 呃，简洁版的实现方式，只保存内容，还有评论的时间，我们选择答案，然后回车就可以了。 第二个问题，评论的输入方式，这里我们选择推荐的 b， 输入 b 回车就可以了。 好。第三个问题，回复的功能，我们选择 b， 需要 好。第四个问题，评论区的位置，我们选择推荐的方式 a。 第五个问题，实现方式，这里我们也选择推荐的答案 b， 原因是符合 code code 减 md 的 工程结构规范。第六个问题，现场回复的数据结构，这里我们选择推荐的 a。 完成六道问题选择后， ai 收起了信息，会自动生成两套方案，这里推荐我们选择方案 a， 然后需要我们输入是否符合预期，这里我们输入符合预期并且回车， 这时候 ai 就 会按照标准的开发规范自动生成完整的设计文档和实施计划文档。那么等等待文档都创建完成后， 可以看到现在已经在帮我们写入设计文档。好，设计文档已经写完，并且提交下面，呃，去写入实施计划文档。 呃，计划文档现在也写入成功。现在 ai 需要让我们选择执行的方式，分别是子代理执行和当前绘画两种方式，这里我们选择子代理的方式执行。 可以看到现在 ai 自动帮我们拆解了五个的开发任务，同时启动了多任务的开发，下面就开始全程自动化的开发，我们只需要等待开发完成之后去验证一下。 再等待了大概十分钟左右，所有自动化开发任务就已经全部执行完毕了。 好，接下来 ai 会让我们进行选择，询问我们下一步要进行的操作。这里给出了我们四个选项，一，呃，将本地的分支合并回主分支。二， 推送并创建拉取请求。三，保持分支的原样，后续我们自行处理。四，放弃本次的开发工作。那这里我们会选择呃，第三种方式，到这里整套的 ai 自动化开发流程就完整走完了，这里选择三。 然后 ai 会输出最终完成的进度信息，可以看到五个开发任务已经全部完成，接下来我会开始逐项验收。首先先启动项目的服务，我们打开地址，通过浏览器访问 好，我们进入到文章的详情，滑动到底部，这里我们可以看到并没有看到评论功能。呃，我们先打开一下控制台，看一下是否存在报错的问题，这里可以看到不存在报错。那么回到 kol 的 终端， 向 ai 描述，我打开了文章的详情页，没有看到评论的内容，然后让他检查一下组建注册的问题。 这里我们回车， 大家告诉我们找到问题了，并提示问题的原因确实是因为组建导入注册了失败导致无法使用。 嗯，现在正在进行修复。 好，已经修复完成了，提示我们要刷新页面重新看一下。好，我们重新进入详情页面哦，刷新一下， 然后打开详情页面，滑动到底部再看一下。呃，还是没有看到评论功能，控制台也没有报错。 好，那我们继续让 glotcode 的 帮我们进行排查问题。我们将最新情况描述给 glotcode 的 终端，刷新页面以后还是没有看到评论的内容， 然后建议可以给当前的评论代码去增加日期来辅助调试定位问题，然后告诉他我们在控制台没有看到具体的错误信息。 好，我们回车，让 ai 帮我们来排查问题， 我们可以期待一下这次能不能彻底修复这个问题。好， ai 告诉我们他找到了根本的问题，是因为 app 点 view 使用的是选项式的 api， 然后下面开始进行修复。好，那么等待修复完成，期待一下。 好， ai 告诉我们已经修复完成了，现在我们需要刷新页面来确认一下。 好，我们先进入详情页面，滑动到底部看一下。哎，这次确实修复了，我们可以看到评论的内容，但是控制台有错误信息，那我们现在需要修复这个错误。 在可洛克的终端，我们告诉他我们看到了评论的内容，但是控制台出现了错误信息，然后我们需要将错误的信息立即告诉他， ai 继续分析错误信息。 好，哎，回复我们，他找到问题了， 并且已经修复完成了，我们现在在刷新页面试一下，看一下是否有报错信息了。好，我们现在进入详情页面看一下。啊，可以看到控制台没有错误信息了。现在我们输入评论内容，点击提交评论。 呃，点击提交以后出现了新的错误信息。好，我们将错误信息复制。呃，回到 close code， 然后描述我们在提交评论时 出现了新的错误信息，将错误设置粘贴给 ai， 等待 ai 这次帮我们彻底修复 好。 ai 告诉我们已经修复完成了，我们再刷新一下页面验证一下。 好，我们打开消息页面，然后重新输入评论的内容，点击提交。 ok， 现在正常评论成功了。 好，下面我们测试一下回复的功能，输入回复的内容，点击提交。 好，我们再继续提交，可以看到回复的功能是正常的。好，接下来我们需要返回博客列表，切换其他文章，测试一下，确认评论数据不会跨文章展示。 好，这里可以看到没有跨文章展示的问题，每个文章对应的评论呃，都已经进行了隔离。 好，目前几个问题基本上已经全部修复完毕，已经达到我们预期的开发效果了。 好，下面我们介绍一下用好 superpowers 的 三大黄金法则。原则一，拒绝冇余 简单场景不滥用全流程。比如我们要进行文案修改、 css 样式微调等轻量化的任务，就无需使用完整的流程，直接修改就可以了，目的就是避免流程冇余，保证开发效率。原则二，装体联动就是使用 superpowers 与 cloud 点 m d 相辅相成，深度联动，实现标准化的 ai 工程开发。原则三，严守门槛， 严禁跳过设计阶段，设计评选是核心门槛，必须严格执行。好，下面我们来总结一下，主要从四点。一、核心价值并非提速，而是质变。本次升级的核心价值不是为了让 ai 写的更快，而是为了让 ai 开发变得更加专业，这是效率之上的维度。升级二，从 ai 辅助写代码到 ai 标准化软件工程， 成功将软件工程的体系化、结构化的核心思想深度注入到 ai 开发流程中，完成开发模式的办事愿圈。三，彻底告别也如此。开发百度过去 随意拼凑、依赖个人能力的无序开发模式，建立了一套可复制、可执行的标准化操作规规范。四、具备完整的商用工程属性，让项目真正具备了智能化、标准化、易维护的商业及工程属性，为产品的长期迭代与规模化发展奠基了基础。好，本期就分享到这里，下期见，拜拜！

这节终于到我们胃口定最爽的地方了，一句话就能让 iint 给你们把整个工具做一个出版出来。前几节我们进行了需求分析， i i 选型计划制定就是为了爽这一下， 当然我们在开始执行之前还是有一些准备工作要做。第一个为了能让 i i 自己全自动带货，我们最好一开始就要把可能需要我们 yes 同意的地方让他考虑清楚。改装环境依赖一开始就给弄好，然后我们让他执行个计划，然后去睡觉了，结果早上回来看见一个 yes 嗡嗡在那里等着你，这是最难受的，所以我们直接问他一下。 目前模型这个需求的处理其实不太好，咱们需要给它讲清楚一点，后面模型内发内发简单讲讲应该就行了， 因为 open source 的 对本默认是不限制于白事命令执行的，所以说这个就不用给大家讲了， 这边是由访问，嗯，工作空间以外目录的情况，我们来审核一下。 ok， 他 把驾照改完了，我们在开始执行之前，还要先把 get 仓库出出发一下，有一个 get commit 的 技能，建议大家装一下。提交的规范很重要，就这个技能 你也可以在这个 skills 上面去搜一下它，这个就是我们这个约定式提交啊， 可以看到它是遵循了我们约定式提交的一个规范的，这个提交的规范很重要，真的很重要，无法编程时代和 ai 编程时代都同样重要，当然后续如果说模型变化这一部分的话，到时候拆掉也可以。 这变化的第二步是 int 和 test， 我 们要知道不同的模型能力不同，有的是尖子生能一次做对，但是大部分一般的模型还是会做错，然后慢慢地修正到最终正确的目标。现在还是有一些声音说模型的能力不行的，基本上都是 int 和 test 没有做好。 之前有段时间 iphoshop 炒的很热，说的直来眼，想要把 iphoshop 的 架构做好，把 link 和 text 做好是最基本的。这个要展开讲的话，内容太多了，就不深入了。我们这次实在选择的苏格拉沃斯是 gdp 的， 也就是测速驱动开发， 我们选择的 rest， 这玩意的语法编辑器自带 link， 因为这个项目就是一个教会用的演示项目，就是一个简单的命令行工具，这样就够了。正常如果是外部项目或者说是应用之类的，咱们肯定是要把这块展开来讲一下。 这个时候我们的 edit 已经能自动化的完成工作了，下面我们还要让它保证质量。之前选型的章节，我们讲了 s o r p 的 博克里提到的五个基本工作流和它们在哈密斯房价中的应用。这里需要拓展一个新的文章， 也是 s o r p 的 博克。简而言之就是通过了雇佣者策略，在保证质量的同时降低了我们的一个成本， 这个都撞到我们枪口上了，必须引入我们的工作流程，这样我们才能省钱。 superpowers 实际上默认没有模型的路由功能，所以说我们需要小小的扩展一下，这个时候就体现出 open code 的 优势了，它很好扩展，并 且最重要的是它能同时接多个提供商的模型，这能力是我们选择使用 open code 的 重要原因不只是为了节省成本选型，那接我讲了可可，可可的是裸装最强的可可可的是因为扩展性最好，所以说逻辑上线是最高的，这个其实已经是事实了。如果说你真的不计成本的话，那其实还是可可可的表现要比可可的更好。 选型呢。也有个奥曼 open 的 框架，之前叫做奥曼 open code， 他 做一件事就是选择各个领域的最强模型，然后在对应的任务录入到当前领域最强的模型。这也就意味着，如果说你同时有可乐的 g d kimi g r m 的 套餐，那你会得到一个操作可乐的 open code。 这个奥曼 open 按键的框架也成功被 iso 封印了，这也证明了能同时对接多个触摸屏的模型是非常重要的按键的能力。 虽然奥曼 open 按键的很好，但是它的好是建立在烧钱的基础上的，所以说我们是不用它的。我们选择给 superpowers 拓展一个路由的逻辑，一个孤雁者， 当他的作者发现工作者返回 block 的 时候，带一个顾问，也就是我们的专家模型去处理普通模型处理不了的问题。前一节我们的专家 agent， 也就是 excel 已经出现过有粉丝问怎么配的，其实很简单，就是下面什么都不写， 直接记成 delete， 然后模型的话你配置成一个更强的模型就行了。 讲了这么多，我们终于可以开始执行了， 我们切一个新的闪闪文。 ok， 我 回来计划已经执行完了，我们直接来测试一下。 嗯，提示是不对，这边命令框的提示是要执行这个登录的，我们来试一下，我们把这个 t y 界面打开，怕是， 嗯，前面两个圆默认都是要 ipi k 的， 我们直接选第三个，这个的话没有 k 的 话也是能跑的，筛选条件的话我们都不选。 嗯，这里有问题，他这个这个箭头号是看不见的，然后慢值也没有给我们一个好一点的慢值，我们直接下一步试一下，然后这里什么都不选，直接回测看一下， 可能会有一些问题， 如果我们右上角的网速在跳，它应该是已经在下了，这边已经跳到两到零秒了。嗯，下完了应该还是一个显示的问题，我们直接进来看一下，它 可以看到我们的这个壁纸已经下来了，只不过还是有一些细节需要调整。这个我们放到下节去讲吧，我得去睡觉了，做这个实战视频实在太累了，流量还不如早点，文章直接拿 ai 生成 ppt 的 感觉能听我视频到现在的都是有基础的了，小白应该很难听下来吧。

superpowers 这个插件简单说，不是让 codex 多一个代码补全功能，而是给 codex 加了一套工程化工作流程。平时我们用 codex 写代码，经常是直接一句话帮我修这个 bug， 帮我加这个功能。 codex 确实能做，但问题是它有时候会太快动手，需求没理解清楚，项目结构没看完整就开始改代码。小项目还好，到了真实项目里，就容易出现改一处坏三处的问题。 superpowers 解决的就是这个问题，它的核心作用是让 ai 编程不再是想到哪写到哪，而是按照一套流程来做， 比如先分析需求，再拆任务，再写计划，再进入独立分支或 walk tree， 接着写测试、改代码、做 review， 最后跑测试收尾。所以你可以把 codex 理解成一个会写代码的程序员。而 superpowers 就 像是给这个程序员配了一套开发规范。 用在 codex 上最大的价值有三个。第一个是让 codex 不要一上来就乱改，它会更倾向于先思考这个需求到底要改哪里，有没有风险，有没有更简单的方案。 superpowers 这个插件简单说，不是让 codex 多一个代码补全功能，而是给 codex 加了一套工程化工作流程。平时我们用 codex 写代码，经常是直接一句话帮我修这个 bug， 帮我加这个功能。 codex 确实能做，但问题是它有时候会太快动手，需求没理解清楚，项目结构没看完整就开始改代码。小项目还好，到了真实项目里，就容易出现改一处坏三处的问题。 superpowers 解决的就是这个问题，它的核心作用是让 ai 编程不再是想到哪写到哪，而是按照一套流程来做， 比如先分析需求，再拆任务，再写计划，再进入独立分支或 walk tree， 接着写测试、改代码、做 review， 最后跑测试收尾。所以你可以把 codex 理解成一个会写代码的程序员，而 superpowers 就 像是给这个程序员配了一套开发规范。 用在 codex 上最大的价值有三个。第一个是让 codex 不要一上来就乱改，它会更倾向于先思考这个需求到底要改哪里，有没有风险，有没有更简单的方案。这一步对小白尤其有用，因为你不一定能把需求描述得很准确， superpowers 可以 逼 codex 先把问题想清楚。第二个是让 codex 更适合处理真实项目。 如果你只是写一个小脚本，没必要用这么重的流程。但如果你是在开发一个小程序、网页工具、 sas 项目，或者已有代码库里修 bug 加功能，那 superpowers 的 价值就出来了， 它会让 codex 按照更向团队开发的方式来做事，而不是一次性生成一堆代码。 第三个是降低项目被改坏的概率，它会引导 codex 使用独立分支写测试、做代码审查，这样即使 ai 改错了，也不会直接污染主项目，后面还可以通过测试和 review 把问题找出来。 所以 superpowers 和 codex 的 关系不是替代关系，而是增强关系。 codex 负责写代码、跑代码、修 bug， superpowers 负责规范 codex 的 工作方式，让它先规划再执行，最后验证。 如果用一个比喻来说，直接用 codex 就 像请了一个很聪明但有点急的程序员，这一步对小白尤其有用，因为你不一定能把需求描述得很准确。 superpowers 可以 逼 codex 先把问题想清楚。 第二个是让 codex 更适合处理真实项目。如果你只是写一个小脚本，没必要用这么重的流程。但如果你是在开发一个小程序、网页工具、 sas 项目，或者已有代码库里修 bug 加功能，那 superpowers 的 价值就出来了。 它会让 codex 按照更向团队开发的方式来做事，而不是一次性生成一堆代码。 第三个是降低项目被改坏的概率，它会引导 codex 使用独立分支写测试、做代码审查，这样即使 ai 改错了，也不会直接污染主项目，后面还可以通过测试和 review 把问题找出来。 所以， superpowers 和 codex 的 关系不是替代关系，而是增强关系。 codex 负责写代码、跑代码、修 bug， superpowers 负责规范 codex 的 工作方式，让它先规划再执行，最后验证。 如果用一个比喻来说，直接用 codex 就 像请了一个很聪明但有点急的程序员，加上 superpowers， 就 像给这个程序员安排了项目经理、测试流程和 code review。 当然，它也不是所有人都需要。 如果你只是让 codex 写个简单脚本，改几行代码，生成一个 demo， 那 直接用 codex 就 够了。 superpowers 反而可能显得流程太重，速度会慢一点儿。 但如果你经常用 codex 做真实开发，比如改项目、加功能、重构代码、补测试，那 superpowers 就 很适合它不是让 codex 写得更快，而是让 codex 写得更稳。 小白怎么用？可以直接复制这句话给 codex 使用 superpowers 的 流程来完成这个任务。先分析需求和风险，再写执行计划。尽量用测试驱动开发完成后做代码审查，并验证项目是否正常运行。 再简单一点儿也可以说， use superpowers plan first implement with tests review before finishing。 总结一句话， superpowers 不是 codex 的 替代品，而是 codex 的 工程化外挂，让 ai 写代码从能跑变成更稳更可控。 加上 superpowers， 就 像给这个程序员安排了项目经理、测试流程和 code review。 当然，它也不是所有人都需要。如果你只是让 codex 写个简单脚本，改几行代码，生成一个 demo， 那 直接用 codex 就 够了。 superpowers 反而可能显得流程太重，速度会慢一点儿。但如果你经常用 codex 做真实开发，比如改项目、加功能、重构代码、补测试，那 superpowers 就 很适合。它不是让 codex 写得更快，而是让 codex 写得更稳。 小白怎么用？可以直接复制这句话，给 codex 使用 superpowers 的 流程来完成这个任务。先分析需求和风险，再写执行计划。尽量用测试驱动开发完成后做代码审查，并验证项目是否正常运行。 再简单一点儿也可以说， use superpowers plan first implement with tests review before finishing。 总结一句话， superpowers 不是 codex 的 替代品，而是 codex 的 工程化外挂，让 ai 写代码从能跑变成更稳更可控。

大家好，我是小田，今天这期视频会很长，建议大家先收藏，再慢慢看。我想系统性的聊一聊我对 s、 d、 d 的 认知。 现在很多博主都在讲 s、 d、 d 的 方法论，比如怎么写 spec， 怎么写 design、 怎么拆 task， 怎么让 ai 按步骤生成代码。 这些内容当然有价值，但我发现大部分讨论依然停留在怎么做的层面，很少有人真正去拆解为什么 ai 时代的软件开发会开始走向 s、 d、 d 这种方式。 因为如果只学流程，不理解背后的原因，那 s、 d、 d 很 容易被做成一种新的形式主义，多写了很多文档，却没有真正提升 ai 工程能力。所以今天这期内容不准备讲工具教程，也不准备讲模板，而是想从底层认知的角度，系统性地讲透。 s、 d、 d 会围绕五个核心认知点去拆解它为什么出现，它真正解决了什么问题，以及为什么认为它会成为 ai 软件工程里非常重要的一种工程化能力。 第一个认知 s、 d、 d 的 核心是上下文拆解，本质是管理大模型的注意力。很多人理解 s、 d、 d 的 时候，会有两种非常典型的想法， 第一种是一句话需求模式，比如帮我做一个登录功能，帮我加一个订单模块，帮我实现一个会员系统。很多人会觉得 ai 都已经这么强了，为什么不能直接一句话生成完整代码。第二种是更工程化的 plan 模式， 团队已经有完整 p r、 d， 有 架构设计，有详细设计，有接口文档，甚至连数据库结构和流程图都有了。于是又会有人问，既然资料已经这么完整了，为什么不把整个 p r d 架构设计、详细设计一次性全部丢给 ai， 让它直接完成整个功能实现？ 这个问题其实非常关键，因为无论是一句话，需求还是完整 plan 模式，本质上都会遇到同一个问题，大模型的注意力机制。 一句话，需求的问题在于信息不够，模型需要大量自行补全、隐含逻辑。而完整 plan 模式的问题则相反，信息太多太混杂， p r d 里有业务目标，架构设计里有系统边界，详细设计里有模块关系接口，文档里有自断约束，历史代码里还有兼容逻辑和隐性约定。 这些内容都重要，但它们不是同一种。上下文。如果全部混在一起丢给 ai， 模型看似拿到了完整资料，但在具体实现某一个任务时，它未必能稳定判断哪些是当前任务真正相关的信息，哪些是必须遵守的强约束， 哪些只是背景说明，哪些历史逻辑不能破坏，哪些内容应该暂时忽略？这就是大模型注意力机制带来的工程问题。 上下文越大，不代表理解越准，资料越全，不代表实现越稳定。很多时候，信息给的越多，模型反而越容易在混合上下文里抓错重点。 如果你把这些东西全部混在一句自然语言需求里，让大模型直接写代码，表面上它好像理解了，代码也能生成出来。 但问题是，他在实现某个具体功能的时候，不一定能稳定地把正确的信息放到注意力中心。他可能记住了页面交互，却漏了权限边界。他可能写出了接口，却忘了订单状态流转，他可能把代码跑通了，但设计其实是一次性的，后面根本不好扩展。 所以 s d、 d 的 价值不是为了多写几份文档，而是把混乱的需求拆成不同层级、不同用途的上下文。 spec， 让模型知道系统应该表现成什么样。 design， 让模型知道技术上应该怎么组织。 task， 让模型知道这次具体要实现哪一小块。这样模型在写代码的时候，不是在一片信息海里大海捞针，而是拿到当前任务最相关、最精准的上下文。 所以我现在对 s d、 d 的 第一个理解就是， s d、 d 不是 文档驱动开发，它更像是 ai 时代的上下文工程，它真正解决的是怎么让大模型在正确的上下文里做正确的事。第二个认知， spec、 design、 task 这些产物不只是为了当下生成代码，而是为了未来持续迭代。 这是我觉得很多人会忽略的一点。很多人以为写 spec 和 design 就是 为了这一层，其实还是低估了 s d b。 我觉得 s d d 更大的价值在于它把项目里的业务名词、接口、逻辑、设计、决策边界条件、模块关系都沉淀成了可以附用的上下文资产。 如果没有这些资产，每一次新需求来了，你都要重新跟 ai 解释这个业务是什么意思，这个模块为什么这么设计？这个接口之前怎么约定的？这个字段为什么不能改？这个状态为什么要这样流转？你会发现， ai 编程很快会变成一种反复解释、反复修正、反复对齐的过程， 一次两次还好，项目一大，历史逻辑一多，就会非常痛苦。但如果你的项目从一开始就在沉淀 spec、 design、 task， 情况就不一样了，下一次再来一个类似需求。 ai 不是 从零理解项目，而是可以基于已有的上下文资产继续迭代。他能知道之前同类业务是怎么定义的，能知道类似接口是怎么设计的，能知道新的需求应该写入哪个 spec， 影响哪个 design， 拆成哪些 task。 这时候 s、 d、 d 就 不只是帮助你这一次写代码，而是在帮助整个项目形成长期记忆。所以我会把这个点总结成一句话， st、 d 的 产物不是临时提示词，而是项目长期迭代的上下文资产。如果一个团队真的把这些资产维护起来，后面的迭代会越来越快， ai 对 项目的理解也会越来越稳定。 第三个认知，老代码仓库做 s、 d、 d 第一步不是写新需求，而是反向补齐项目认知。这个点特别重要。 很多老项目一开始并没有使用 s、 d、 d 代码，已经写了很多年，模块很多，历史逻辑很多，命名很多，接口也很多。这个时候，如果你直接说我要给这个老项目补一套 s、 d、 d， 其实并不容易。因为老项目最大的问题不是没有代码，而是项目认知散落在各个地方。 所以老仓库引入 s、 d、 d， 第一步不是急着写新需求，而是要先做一件事，反向补齐项目认知。你要先搞清楚这个系统有哪些核心模块，每个模块负责什么核心业务，对象是什么，接口之间怎么调用，数据怎么流转，哪些逻辑是历史原因造成的，哪些地方是不能轻易动的？ 这个过程其实会经历大量的 ai、 多轮交互，甚至是 web coding 式的探索。因为你不是在丛林设计一个新系统，而是在考古一个已经存在的系统。有些认知在代码里，有些在数据库表里，有些在接口命名里，有些在即使提交里，有些甚至只在老开发的脑子里。 这时候，代码图谱类工具就非常重要，比如 gitnexus 这种基于代码图谱的能力，我觉得就很适合放在这个阶段。 传统方式里，我们理解老代码可能会大量依赖 grab、 权威搜索、人工跳转，但这种方式有两个问题，第一，它只是在搜字母串，不是真的理解代码结构。 第二，它很容易把大量无关代码带进上下文，既慢又浪费 token。 而基于代码图谱的方式是先把代码做 a、 s、 t 解析，把类函数调用关系、依赖关系这些结构化信息存进图谱，然后再基于图谱去搜索和调度。 这样带来的好处是非常明显的，它不是简单问这个词在哪里出现过，而是能帮助你更快定位这个函数被谁调用。这个接口影响哪些模块、这个业务对象在哪些地方被使用，这个变更可能牵连哪些代码路径。 而且这种搜索通常会比传统 grab 更准、更快、也更省 token， 因为它不需要把一堆无关文件全部塞给模型，而是可以更精准地把相关代码片段和依赖关系找出来。 更关键的是，如果 gitnexus 还能基于代码图谱生成 wiki， 那 它就不只是搜索工具，而是在帮助老项目生成第一版项目认知资产。这也是为什么我觉得 gitnexus 这类工具值得强推， 不是因为它只是一个搜索工具，而是因为它可能成为老代码仓库，进入 ai 开发时代的基础设施。 第四个认知 s d、 d 会让 ai 从代码生成者变成项目参与者。没有 s d、 d 的 时候，我们很多时候是在把 ai 当成一个代码生成器。我给他一个需求，他给我一段代码，这段代码可能能跑，也可能需要我继续调。 但他对项目的理解往往是临时的。这一次对话里，他知道一点上下文换一个对话，他又忘了换一个功能，他又要重新理解。 这时候 ai 更像一个外包临时工，你每次都要重新交代背景，重新解释规则，重新告诉他哪些地方不能动，而 s d、 d 的 出现会改变这个关系。 当项目里有 spec、 design、 task 这些持续维护的资产时， ai 就 不是每次从零开始，它可以基于项目已有的认知工作。 他知道这个模块为什么存在，他知道之前的设计决策是什么，他知道当前 task 只是整个设计中的一个局部实现，他知道哪些边界条件已经在 spec 里定义过，他知道哪些测试标准不能破坏。这时候 ai 不 再只是帮我写一段代码，他更像是在参与一个项目的持续演进。 当然，他还不是人类工程师，也不能完全替代工程判断，但他已经从一次性的生成工具，变成了一个能基于项目上下文进行协作的参与者。这个变化非常重要， 因为未来 ai 编程拼的可能不是谁单次 prompt 写得更好，而是谁的项目上下文资产更清晰、更可信、更可复用。没有 sdd 的 ai， 很 容易一直停留在你问我答的阶段。有了 sdd 的 ai， 才有可能进入围绕项目持续协助的阶段。 所以我会说，没有 s d d， ai 更像临时工。有了 s d d， ai 才开始接近项目参与者。这不是夸张，而是上下文资产带来的写作方式变化。第五个认知， s d d 的 最终价值是降低团队和 ai 的 写作成本。 很多人会把 s d d 理解成让 ai 一 次写对代码，但我觉得这不是它最终的价值。真实项目里软件开发最大的成本，很多时候不是写代码本身，而是理解成本、沟通成本、维护成本、变更成本。 一个新人加入项目，需要理解历史逻辑。一个老模块要改，需要判断影响范围。一个需求要变，需要重新对齐边界。一个 bug 出现，需要追溯当时为什么这么设计？ ai 参与进来以后，这些问题并没有消失，反而变得更明显。因为 ai 如果没有上下文，它也会误解项目。如果文档过期，它也会被误导。如果设计意图不清楚，它也会写出看起来合理，但不符合项目长期方向的代码。 所以 s d d 的 最终价值是降低人和 ai 一 起协助时的成本。它让产品、开发、测试、 ai 都能围绕同一套上下文资产工作。 spec 让大家知道系统应该做什么。 design， 让大家知道为什么这样设计 task， 让大家知道这次具体要改什么。测试和验收标准让大家知道怎样算作对，这不只是给 ai 看，也是给团队看。 如果维护得好， s d d 会让一个项目的知识不再只藏在某几个人脑子里，也不止散落在代码里，而是沉淀成团队和 ai 都可以共同使用的认知资产。 当然，这里有一个前提， s d d 产物必须是活的。如果代码改了， design 不 更新、需求变了、 spec 不 更新、任务完成了、 task 不 回血，那这些文档很快就会过期，一旦文档不可信，它反而会变成负资产。 所以真正做 s d d， 不是 写完文档就结束，而是要把它当成项目认知的一部分，持续维护，这时候它的价值才会越来越大。我觉得可以这样总结 s d d 不是 为了让这一次代码生成更顺，而是为了降低未来每一次理解、沟通、修改和验证的成本，这才是它真正的长期价值。 最后，总结一下今天讲的这五个认知，其实我想表达的是， s d d 不是 一个简单的 ai 编程流程，也不是为了多写几份文档。 第一，它解决的是大模型注意力问题，让模型在正确上下文里写代码。第二，它沉淀的是长期上下文资产，不只是服务当下这一次生成。 第三，老代码仓库做 s d d 本质上是反向补齐项目认知，这时候 get nex 这类基于代码图谱的工具会非常关键。第四， s d d 会让 ai 从一次性的代码生成者，逐渐变成项目的持续参与者。第五， s d d 的 最终价值是降低团队和 ai 的 长期协助成本。 所以我现在越来越觉得， ai 编程真正的门槛不是会不会写 prompt， 也不是会不会调用某个工具。真正的门槛是你能不能把一个项目的需求设计、代码测试和历史决策组织成 ai， 能持续理解、持续使用、持续迭代的上下文资产。 这才是 s d、 d 背后最值得我们重视的地方。也希望大家不要只是跟风学概念，而是真的去实践，去读代码，去拆需求，去写 spec， 去维护 design， 去体验一次从混乱需求到结构化上下文的过程。 只有经历过这个过程，才会真正理解为什么在 ai 时代，软件开发不是变得不需要工程化了，而是更需要新的工程化方式。

如果你正在使用 cloud code， 却还没装这些 skill， 那 你可能只用了它百分之三十的能力。今天分享七个最值得安装的 skill， 尤其是最后一个，能让 cloud code 从能用的 ai 直接变成懂行的队友。第一个，社区最火的全能 skill superpowers， 它不是单个技能，而是一整套开发全流程 buff， 包含项目规划、代码编辑、 code review 等十几个子技能，能帮你梳理需求、拆分任务、系统化调试，程序员必装，省超多梳理时间。 第二个，文档处理神器， pdf， 它能直接读取、合并、拆分。 pdf 还支持 ocr 扫描件识别，写代码间隙处理文档，不用切换软件， 不管看技术文档还是办公文件都好用。第三个，去 ai 位神器 whoman the zh， 它能把此外综上所述，这类生硬表达换成接地气的人话，写项目文档、副业文案都能少一点模板位， 不容易被看出是 ai 生成。第四个，大项目救星， planning with files， 大 型项目经常中途打断，回来 ai 就 往上下闻。这个 skill 会持久化项目规划，画绘画不丢进度， 特别适合碎片化时间开发。第五个，前端颜值救星， fronten design， 它让 cloud code 写的前端不再是 ai 烂活，而是带着专业设计规范，后端程序员也能做出好看规范。 第六个，代码质量守护神 code review， 它会派多个子 a 证，并行审查代码、找 bug、 查安全漏洞、优化代码规范，每个问题都带知性度评分， 赶项目时不用逐行排查，能大幅减少代码出错率。第七个，压轴神器，也是最能提升体验的 skill creator， 前面六个不够用，它能让你自己定制 skill， 把自己的开发习惯、 重复性工作封装成专属功能，彻底让 ai 适配你的需求。这就是让 cloud code 变成懂行队友的关键。 这七个 skill 覆盖开发全流程文档处理前端优化代码质量，还有能自定义的压咒技能，装完之后你会发现 cloud code 的 能力直接翻倍！收藏起来直接去 skill 商店搜英文名就能安装。关注我，带你了解更多 skill 使用技巧！

欢迎来到 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。 设计先于代码，这个技能有一个硬门径，没有设计文档就不许写代码。为什么这么严格？实际怎么用？咱们下集好好聊聊，别忘了点赞收藏追更系列，不错过每一集，咱们下期再见！

今天跟大家分享一个在 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 的 云代码，这样你可以对整体的实现方案和实现思路会有个比较清晰的了解。

ok， 这就是我们整个的 ai 编程下的规范的软件研发流程，包括啊，头脑风暴，设计思路， spec 文档、 plan 文档，拆解任务，然后 sub agent 的 执行。 大家好，我是双月，今天聊的话题是 ai 编程下的规范的软件研发流程啊，就是使用 ai 编程工具，怎么样更加规范地去 做一些需求，改一些 bug， 而不是说让让这个工具随便来。然后呢，我将结合一个开源项目来去说，就是这个 superpowers， superpowers 呢，它是个开源项目，然后那个 star 已经非常非常多了啊，它是一个 ai 智能体， ai 编程智能体的 skill， skills framework， 就是 技能框架和这个 软件研发的方法论啊，它是一个过程和一个流程，或者一个规范啊，我们我们本节就是讲这个东西啊， 如果说你用 cloud code， 用 cursor， 用 code x， 用任何的 ar 编程工具，你都可以去安装它啊，下面有文档和教程，自己去看着安装就行了啊。 然后今天我们就讲讲我在试用这个 superpowers 这个东西的时候呢，它给我带来的一些呃，感觉非常非常好的东西给大家分享出来啊，主要是这个规范的软件研发流程啊，这么一件事 啊，如果说我们是传统开发，就是 ai 出来之前，我们的流程怎么样呢？一般情况下啊，传统的啊， 先是有一个需求，或者说有一个 bug， 对 吧？有一个 bug， 然后呢有了之后呢，我们就直接开发啊，啊，直接开发啊，然后呢开发完之后呢就提交 测试，然后呢最后就发布了，这是一些不太规范的软件团队，但是不太规范呢，是常态，大家可以关注一下自己的公司，或者说你的认识的朋友或前同事之类的一些公司， 呃，是不是大概就是这这样子的，对吧？我们我们都知道这样的会有很多问题，比如说你这个需求或者 bug， 那 是不是明确，对吧？有的需求呢就是一个简单的文档，有的呢可能 只是口述一下，口口相传啊就完了，也没有付钱，步骤也没有一些量化的标准，对吧？还有就是你开发之前啊，有没有进行一些设计讨论这里的这些东西啊，有没有文档啊？你不要说呃，那个让你做，你就直接写代码对不对？ 然后就是你看完之后有没有进行这个 code review， 就是 c r 啊，就是代码组查啊这一步，然后测试的时候呢，有没有进行这个测试用力的编辑，还有还有测试，比如说单元测试，还是说这个 integration， 就是 那个集成测试，对吧？ 这些过程不一定完全有，如果没有的话呢，就会导致我们人和人之间啊，产品经理，开发测试等等这些角色之间进行大量的沟通，然后呢导致这个效率降低，甚至是反攻，甚至是线上之后呢，发布之后呢，爆发很多的 bug， 对 不对？好 万幸我们这个传统的方式呢，都是人，对吧？人工，人工呢是最智能的，我们可以相互沟通，然后去返工解决问题等等这一些，对吧？所以万幸我们是这个人工的方式，但是如果说我们使用 ai 编程的方式啊 啊， ai 呢，目前虽然是智能，但是呢没有人工这么沟通，团队之间沟通这么的聪明，所以说我们就需要去借助一些东西去规范它的软件研发流程，这样才能让我们的实际执行和工作中才能去真正的去产出价值，否则这个 东西一多，然后一乱一复杂，这一乱套一反攻，这玩意就没法用了，对吧？所以这就是我提到的 ai 编程工具和这个 superpowers 它结合带来的一个价值啊。我们可以具体看一下 它是怎么样的过程啊？首先你在 ar 编程工具里面去安装这个工具呢，它会给你就是安装很多这个 skills 啊，安装很多 skills 这东西安装完之后呢，其实你不用管，你自己写的时候它会主动去调用啊，它就通过主要是通过这个 skills 这个技能的这个方式来去实现的啊。 首先我们在用 ai 抠点的方式，无论是改一个 bug 还是做一个需求的时候，我们肯定第一步我们就要去输入这个 prompt， 就是 给 ai 去输入一个提示词，让它去进行这个任务的执行，对吧？然后基于这个，刚才说这个 super park powers 啊，基于它的啊，基于它的这个过程来说，我们输入提示之后呢，它下一步会干嘛呢？它下一步会给你进行头脑风暴，哎 哎，这个是一个当时第一次用，是一个非常非常惊艳到我的一个事情，就是你输入的提示词不一定完全明确，尤其是我们的人的表达比较随意， 他通过风暴呢，就是会根据你的提示词呢去扩展很多的信息，去完善很多的信息，如果说遇到一些比较模糊的问题呢，他会去，他会去问啊，他会去问你啊，这个应该怎么办？那个应该怎么办？是不是需要这个东西？是不是需要那个东西，对吧？然后他问一堆问题之后呢？最终会形成一个啊，比较系统的 啊设计思路啊，这只是一个大的一个思路，然后去问你是不是 可以啊？你说可以的话呢？它就会形成一个真正的 spec 文档啊，就是一个需求文档，那一个需求文档，或者说一个技术方案设计的文档。然后你看到这一步之后，其实我们的这个， 呃，就是这个 prompt， 一 开始输入的 prompt 到这一步其实就已经明确了啊，就是至少是你这个需求的 范围，或者你这 bug 的 复现步骤，然后呢就已经明确了，对吧？然后怎么样去解决也已经明确了，所以说这个明确，这个很重要，对吧？范围以及方向我们是明确的。 然后接下来呢，这个 superpose 它会生成一个 plan， 就是 计划啊，这个计划也很重要，因为前面这个 spec 文档呢，只是一个需求技术方案 方，方向和范围。 plan 呢？就是具体的一个执行的一个计划啊，这个 plan 可能包含什么东西呢？比如说它可能会拆解这个 task， 可能拆解多个 task， 第一步干嘛？第二步干嘛？第三步干嘛，对吧？怎么样一步一步执行下来？这其中可能还包括，比如说啊，我们的这个， 呃，测试我们应该怎么做？或者说测试用力应该怎么写，然后要进行什么测试？就刚才说的这一堆就已经包含了，对吧？包括这个 c r 应该怎么做？应该朝哪些方向去去去弄，对吧？然后呢，我们如何去验证这个需求，或者说 bug 的 这个结果，对吧？ 它都会把这些去拆分成多个 task， 然后一步一步去执行 plan， 那 肯定就是按照步骤来去执行，第一步干嘛？第二步干嘛？第三步干嘛，对不对？ 所以说我们看一下啊，就是，呃，我们普通的 ai 编程工具，如果说没有用这个 superpowers 的 话，它也会有这个叫做 plan mode， 对 吧？很早就有啊，去年就有， 但是这个 plan mode 呢？我们传统的 plan mode 就是， 呃 plan 加上什么？加上 coding， 就是 加上执行了，对吧？就是比较简单啊，但是呢，在这个 superpowers 看来， 这个 plan mode 它包含头脑风暴啊，然后问模糊问题，设计思路， spike 这个需求或技术方案文档，然后呢，再进行 plan， 再拆解计划 啊，它是完全把它拆分成了四个步骤来执行，拆分的越多，那这个事情就会做的越明确，对不对？ 好的，然后继续啊，这个拆完之后呢，我们就开始执行了，执行的时候呢，一般情况下，一般情况下啊 啊，它会推荐使用这个叫做 sub agents 的 方式去执行，就是多智能体或子智能体的方式去使用， 然后每一个任务去分配一个子智能体去执行，这样的话，保证每个单独的任务都有单独的这个上下文，然后单独的内容，然后不和主任务相互污染，也不和其他任务相互污染。比如开发是一个子智能体 啊，然后测试是一个子智能题，然后 cr 是 一个子子智能题啊，这样子，对吧？啊？比如说呃 coding 的 一个子智能题，然后 cr 子智能题，然后 test 子智能题，对吧？所以这个也是 非常非常关键的一个一个步骤啊，整个步骤完成之后，然后剩下的就已经这个任务就完成了啊，啊，当然这个过程可能会比较慢啊，看你的任务大小，也看你的模型的速度，然后也看你的这个过程中是不是有反攻，比如说这个， 这个 c r 或者这个测试啊，这个测试如果说，呃遇到问题怎么办呢？那可能会重新再给这个库里进行返工，你再你再重新给我改，改完之后呢？重新 c r 重新测试，对吧？这都是有可能的 啊，要看情况，反正我的整体感觉，呃这块还是有点慢的啊，就是有的十分钟，有的二十分钟啊，所以说，呃，这个过程中可以思考再去做点什么别的东西，同同步去进行啊， 然后然后这个就是整个的一个过程啊，其实我们还可以考虑更多的东西啊，比如说啊，我们如果比对大的任务，我们可以考虑进行使用这个 gitwork tree， 然后去隔离这个代码环境啊，比如说， 呃，他这中间如果说没有 get commit 的 话，我们可以要求他啊，就是每一步都进行 get commit 啊。还有就是完成之后呢，我们可以要求他去改一些相关的文档，比如说代码改了，文档没有改，对不对？ ok， 这就是我们整个的 ai 编程下的规范的软件研发流程，包括啊，头脑风暴、设计思路， spec 文档、 plan 文档拆解任务，然后 sub agent 的 执行啊，包括 coding， c r task， 最后呢去完成这个任务， 这就是 superpowers 这个这个框架或者插件带给 ai coding 的 一个价值，同时也能完全覆盖我们之前这个人工的问题啊，然后让它变成 ai coding 的 方式去高效地去完成这个过程。

superpowers 是 目前 getop 上最火的 ai 编程技能库，拿到了超过十七万个 star。 大家用 ai 写代码，最怕的不是它写的慢，而是它写的太快，结果满屏都是 bug， 或者根本不理解你的意图。 其实问题不在于 ai 不 够聪明，而在于它缺乏工程纪律。 superpowers 核心就是给 ai 注入一套专业工程师的肌肉记忆，把规范变成强制执行的技能。接下来的内容，我会带你彻底拆解这套让 ai 变专业的工程流程。 为什么 ai 写出来的代码经常跑不通？其实问题不在于模型不够聪明，而在于它缺乏章法。人类程序员写代码是有肌肉记忆的，我们会先设计再规划，边做边测， 但 ai 默认只会接到指令就写。 jesse vincent 发现，要让 ai 真正好用，关键不在于堆算力，而在于给它注入一套工程规范，也就是所谓的 skills。 这套技能库才是赋予 ai 编程超能力的本质。 微软 amplifier 框架的联合作者 sam shillis 提出了一个很有意思的概念，叫复合团队。他认为，如果一个团队只是单纯的在用 cloud 或者抠拍了写代码，那生产力的提升是非常有限的。 真正实现爆发式增长的团队，是在做一种递归的工作。他们给 ai 构建了一套框架，让 ai 拥有了建造工具的能力， 也就是说，让 ai 自己去写工具，然后永久使用这些工具。 superpowers 实际上就是这种模型驱动行为思路的具体实现。 superpowers 之所以能跑通，是因为它背后有一套极其严苛的底层逻辑， 这套逻辑不是给 ai 的 建议，而是强制执行的铁律。第一是 t d d， 也就是测试驱动，要求必须先写测试，再写代码。第二是系统化，遇到 bug 不 能靠猜，必须走固定的根音分析流程。 第三是降低复杂度，始终坚持 i a g n i 原则，不写多余的代码。第四是证据驱动，所有的修复必须经过验证。 这套原则的核心就是用硬性的工程纪律去对抗 ai 的 随机性。进入流程的第一站是头脑风暴。在任何新功能开始之前， ai 不 会直接上手写代码，而是先做三件事，读文档、了解背景，通过提问来澄清需求，最后给出几个带权衡分析的设计方案。 这里有一个非常关键的机制，叫做 hldgt。 简单来说，这就是一个强制关卡，只要你没有在书面上批准这个设计方案， ai 就 绝对不允许写一行代码，哪怕你觉得这个需求再简单。这一步就是为了掐断那些因为假设错误而导致的无效开发。 设计方案批准后，下一步就是利用 get 工作树来管理开发环境， ai 会自动为每个新功能创建一个独立的 get 工作区。这样做最大的好处就是环境隔离，它能让 ai 在 不同的分支上并行推进任务。比如一个分支在做登录功能，另一个分支在做评论功能， 两者完全是井水不犯河水的状态，绝对不会因为代码冲突而互相干扰。有了设计文档，接下来就要把蓝图变成施工图，也就是写实施计划。这一步的核心是把设计方案拆解成一个个原子级的任务，这些任务必须非常细，希望每个任务在二到五分钟内就能做完。 而且任务描述必须极其精确，要指明具体的文件路径和代码位置，不能留任何猜测的空间。你可以把这些任务想象成是发给一个技术很强，但完全不了解这个项目的初级工程师去执行的指令，必须让他闭着眼睛都能作对。 有了计划后，进入最精彩的环节。紫代理驱动开发 ai 不 再是一个人埋头苦干，而是把任务分发给一个个全新的紫代理。为什么要这么做？因为长对话会导致上下文污染， ai 会被之前的错误信息带偏。 通过给每个任务分配一个干净独立的上下文，能确保执行的精准度。每个子代理干完活还要经过两轮严格审查。第一轮看规格，看代码符不符合计划。第二轮看质量，看命名和错误处理行不行，如果不合格，直接打回程度。 第五步是 t d d， 也就是测试。驱动开发在 superpowers 的 流程里，这不仅是建议，更是铁律。 流程非常简单，先进入 red 阶段，写一个最小化的测试，让它必须失败。然后进入 green 阶段，只写最少的代码，让测试通过，绝对不准写任何未来可能用到的代码。最后是 refactor， 在 测试通过的基础上优化结构。记住，如果你在看到测试失败之前就写了产品代码，唯一的做法就是全部删掉，从头开始。 任务完成后，流程会自动进入审查和决策阶段。第六步是代码审查， ai 会调用专门的审查子代理，把问题分成严重、重要和次要三个等级。如果是严重问题，流程会直接堵塞，必须修复。通过审查后进入第七步，也就是完成开发分支。 这时候 ai 会验证所有测试，然后把选择权交给你，是合并到主分支推送 p r， 还是保留分支稍后处理，或者是直接丢弃这个分支，一切由你决定。回头看， superpowers 为什么能跑通？因为它把所有的工程建议都变成了强制执行。 它通过 h r， d， g， a t 强制你进行设计，通过紫带里隔离来防止上下文污染。甚至连编辑新技能的过程 都要遵循 tdd 的 逻辑进行压力测试。他不是在教 ai 怎么写代码，而是在用一套严密的工程逻辑把 ai 的 随机性关进笼子里。当这种纪律变成了一种可执行的技能， ai 才会从一个乱写代码的助手变成真正的超级搭档。 这套技能库非常完整，它从四个维度覆盖了整个开发生命周期。首先是测试类，负责 tdd 和修复验证。 其次是调试类，提供系统化的根音分析。第三是协助类，这是规模最大的部分，包含了从头脑风暴计划拆解到子弹里驱动、 get 管理和代码审查的所有环节。 最后还有原类技能，教你如何编辑自己的新技能。可以说，只要涉及到工程规范的地方， superpowers 都有对应的技能可以调用。如果你想尝试这套方案，可以根据你目前使用的工具直接安装。 比如 cloud code 用户可以直接用插件命令安装。 go pilot 用户在 marketplace 里搜索即可。 caster 用户也非常简单，直接输入添加插件指令就行。最后，我想说， ai 编程的瓶颈从来不是智力，而是工程纪律。当你学会给 ai 装上这套纪律，它才会真正成为你的超级搭档。