00:00:00当你强迫 AI 编程助手遵守规则时，究竟会发生什么？
00:00:03在使用 Claude 和其他编程助手时，我们都面临着一个共同的难题。
00:00:07它们往往不遵守指令，甚至完全无视 Claude.md 文件。
00:00:11即使我们尝试强推测试驱动开发（TDD），它也只会试图自己去修改测试文件。
00:00:15就在那时，我们发现了这个正在走红的插件，它在短短 24 小时内就获得了 5.8 万颗星。
00:00:21但这恰恰反映了目前 AI 工具领域的炒作周期有多么疯狂。
00:00:25这个插件承诺将严格的软件开发方法论强制引入工作流。
00:00:30但问题在于，它是否真的能兑现这个承诺。
00:00:33我们的团队已经见过类似的工作流，其中大多数最终都被证明只是噱头。
00:00:37因此，我们将这个插件投入到实际工作流中，看看它是否值得应用于真实项目，还是仅仅是炒作。
00:00:43Superpowers 是一款能将传统软件开发方法论强制嵌入到你所使用的 AI IDE 中的插件。
00:00:50现在有些人可能会认为，现有的敏捷框架如 BMAD 和 OpenSpec 已经实现了同样的功能。
00:00:56但这个插件与众不同，因为它不仅仅是用来编写项目规范的代理系统。
00:01:01它是在工作流中对同一种敏捷开发方法的强制执行，并设有严格的关卡，确保代理在当前步骤通过前无法继续。
00:01:10这些关卡是明确的检查点，旨在防止 Claude 偏离预定的指令。
00:01:15该插件的核心理念是 TDD 和系统化的流程，而非盲目猜测。
00:01:20它在声称项目成功前会进行验证，并根据 AI 常见的失败领域量身定制指令以进行修复。
00:01:28在获得用户的“绿灯”信号之前，它绝不会进入下一步。
00:01:32简而言之，它内置了我们之前视频中讨论过的所有最佳实践，无需像以前那样手动设置。
00:01:40因此，该插件强调真正的红绿测试驱动开发，以及我们学习软件开发时接触到的 DRY 和 YAGNI 等编程原则。
00:01:50它适用于所有的 AI 平台。
00:01:52但由于我们的团队正在使用 Claude Code，我们先复制了注册市场命令，并将其添加到我们的项目中，随后从市场安装了该插件。
00:02:02安装完成并重启 Claude Code 后，Superpowers 插件就可以在项目中使用。
00:02:08重启 Claude Code 后，我们给它一个提示词，说我们想构建一个类似 Trello 的项目管理软件。
00:02:15它自动激活了“头脑风暴”技能，并没有盲目猜测需要构建的内容，而是利用该技能首先识别了项目需求。
00:02:24它提出了许多问题来明确应用细节，包括目标用户、技术栈选择，并考虑了每个选择可能带来的问题。
00:02:33比如在选择数据库时，它建议我们的选择可能不合适，会有安全隐患，因为该数据库在浏览器中运行，无法从服务端访问，于是我们进行了更改。
00:02:44它不断完善所有的细节，直到我们对这些方案感到满意。
00:02:48在它与我们确认完所有内容后，下一步是提供三个方案供我们选择其中之一进行实施。
00:02:55于是我们选择了心仪的选项，并在选择的同时提出了修改建议。
00:02:58完成后，它还为我们提供了架构设计。
00:03:02接着它提供了 UX 设计，其中提到了看板的处理方式。
00:03:06它还与我们确认了整个项目的结构。
00:03:09一旦所有的设计获得批准，它就会将所有资料记录在 docs 文件夹中。
00:03:13这就是该插件胜过其他工具的地方，因为它内置了 Git 指令来提交每次更改，而其他框架做不到这一点，需要我们手动强制执行。
00:03:22头脑风暴技能创建完计划后，编写计划技能被激活，它编写了实施方案并进行了提交。
00:03:29该计划将大型应用拆解为更易于实施的子任务。
00:03:33你可能会认为 Claude 内置的“计划模式”本身就能完成这些。
00:03:37但这种规划与 Claude 原生规划的主要区别在于，Claude Code 的规划仅仅是作为代理执行任务的指引。
00:03:44它只会在认为确实有必要时询问关于技术栈的问题，而像 UI 库之类的小决策它会自行决定。
00:03:52相比之下，Superpowers 是一种强制执行，这意味着在当前步骤通过前你无法进行下一步，从而确保计划被真正落实。
00:04:01规划阶段结束后，它询问我们希望如何实施计划，并提供了两个选项，我们选择了“子代理驱动实施”。
00:04:09虽然 Claude 也会自行产生子代理，但子代理驱动实施中的技能有所不同，因为它会自动为每个子代理设置 Git 工作树，确保它们的工作互不干扰。
00:04:20代理需要通过工作树进行隔离才能更好地运作，因为如果它们在同一个目录工作，就会相互覆盖对方的成果。
00:04:28而这正是它原生自动处理的核心功能。
00:04:31一旦规划最终确定，Claude 就会进入实施阶段。
00:04:34它启动一个任务，完成后，会开启一个独立的评审子任务，根据规范来验证实施结果。
00:04:41在提交到 Git 之后，它会使用另一个 Superpowers 技能，即“代码评审员”。
00:04:46只有在之前的代理批准了代码质量后，它才会开始下一个任务，并不断迭代之前的任务直到达标。
00:04:54在每个任务完成、评审并提交到 Git 后，它会确保前置任务完成后再询问我们是直接合并到 main 分支还是创建 PR。
00:05:04于是我们让它快速合并回 main 分支。
00:05:06然后它删除了所有的工作树，并将整个项目提交到了 main 分支中。
00:05:11这个过程会消耗大量的上下文窗口，因为使用了子代理和多种技能。对我们来说，仅一次迭代就消耗了近 50% 的上下文，这意味着使用时必须非常小心。
00:05:24它创建的项目比较简单，具备基本功能。
00:05:27我们希望这些列表能按当前状态排序，即：待办、进行中和已完成。
00:05:32虽然单个卡片已经在那了，但我们还希望这些列表也是可以移动的。
00:05:36于是我们回到 Claude Code 让他处理，但起初它像往常一样在没有使用插件技能的情况下开始操作。
00:05:42这可能是因为消耗了太多的上下文，所以我们不得不提醒它使用 Superpowers 插件。
00:05:48提醒之后，它便像之前那样开始执行任务。
00:05:52在走完所有步骤后，Claude 生成代理在独立的工作树上工作，由于它们原生采用了测试驱动开发方法，这些代理的表现更出色。
00:06:02这些代理会首先为待实施的每个部分编写测试。
00:06:05编写完测试后，它会确保代理在不修改测试用例的前提下编写代码，并保证测试通过。
00:06:13该插件技能使用了强效的提示队列，防止它修改测试本身，基本上封死了 Claude 在试图跳过步骤时找的所有借口。
00:06:23这些队列看起来像是明确的指令，比如“如果有 1% 的机会使用某种技能，就使用它”。
00:06:29这确保了每个任务都以一种规范且结构化的方式完成。
00:06:32需要注意的一点是，这些代理是按顺序执行任务的，因此完成一个任务所需的时间比 Claude 原生方式要长。
00:06:41但由于它执行了严格的准则，这确保了应用程序能按预期工作。
00:06:45正如我们之前提到的，使用此插件时上下文消耗非常快，仅几个任务后就只剩下 5% 的上下文了。
00:06:53因此，在进行任何后续任务之前，我们运行了 compact 命令，这样在 Claude 为下一个任务进行头脑风暴时，我们就不会丢失上下文。
00:07:01压缩对话后，我们输入了关于下一个要实现的功能的提示词，它便以同样的方式开始运作。
00:07:07但这次会话最棒的地方在于，它没有通过猜测来实现功能，而是不断从多个角度提出问题，确保应用是按我们的想法构建的。
00:07:17该插件从各个维度鞭策 Claude，在头脑风暴阶段明确了诸如“列表为空时显示效果”之类的细节。这种微小的细节，Claude 独自处理时很可能会随手猜测一个方案就实施了。
00:07:29现在，更好地使用该插件的指南已在 AI Labs Pro 中提供。
00:07:33对于那些还不了解的人，这是我们最近推出的社区，你可以在那里获得现成的模板，直接应用到本项目及以往所有的项目中。
00:07:42如果你觉得我们的工作有价值并想支持频道，这是最好的方式。链接就在描述中。
00:07:48它的另一个强项是能够进行系统化调试。
00:07:52我们遇到了一个刷新后数据保存失败的 bug，我们给 Claude 发了一个模糊的提示词，没指定 bug 的位置，要求它使用系统化调试来修复。
00:08:01它加载了系统化调试技能来执行任务。该技能的工作被分为四个阶段。
00:08:06第一阶段通过向我们提问来确定根本原因。
00:08:10根据我们的回答，它尝试从我们提供的方向进行调查和追踪，并找到了可能存在问题的正确文件。
00:08:16确定根本原因后，第二阶段侧重于隔离 bug，而第三阶段则是缩小 bug 产生的实际原因范围，以便进行修复。
00:08:25第四阶段是应用修复。它利用整个流程确保调试比盲目翻阅代码库更有条理，并以测试作为修复的收尾。
00:08:35现在，有很多任务并不需要完整的插件工作流，使用它反而会过重。比如当我们只想更改应用的 UI 时，不想为了一个 UI 更改而等待 15 分钟。
00:08:47因此，对于这类不需要完整流程的任务，我们可以用更简单的方式来实现。
00:08:51由于我们对应用的视觉效果没有特定的目标，我们让它改进 UI，并告诉它不要直接进入实施阶段，只进行头脑风暴和规划。
00:09:01它开始进行头脑风暴，并通过询问设计不同方面的细节问题，来确认我们想要的视觉方向。
00:09:08按照提示词的要求，Claude 在完成规划后停止了，随后我们要求它在不使用完整流程的情况下实施该计划。
00:09:15整个应用的 UI 更改时间比流程驱动的方式显著缩短，尽管如此，它仍然以流程所要求的相同格式将更改提交到了 Git。
00:09:25应用从样式极简的基础布局变成了拥有改良配色方案、悬停卡片状态以及整体功能更完善的布局。
00:09:32这正是让该框架具有实用价值的原因。在 Claude 擅长的领域让它自由发挥，而在它容易出错或搞砸实施的情况下，再引入完整的流程管理。
00:09:43视频到这里就结束了。如果你想支持本频道并帮助我们继续制作此类视频，可以通过下方的 Super Thanks 按钮进行捐赠。
00:09:51感谢收看，我们下期再见。