夜雨聆风近一年时间，AI Coding的能力变化，一次又一次的颠覆着大家的认知，让完全不懂技术的小白也能通过自然语言编程来实现自己的商业化产品，同时也逐步在削弱程序员多年沉淀下来的专业壁垒，甚至很多企业开始重构产研团队的岗位结构。
这足以说明AI Coding的能力已经非常强大，并且逐步走进真实的生产环境，但是问题也从这里开始暴露的，因为对于生产环境而言，需要按照特定的标准规范去实现精准的业务需求，是有协作和质量要求的，而不在是个人许愿式编程。
下面这张图虽然有搞笑和吐槽的成分，但是也真实的表达了当前AI Coding在进入生产级项目时普遍存在的问题。
不知道大家对此是否有同感，反正我这边的感受基本一致，比如：
需求都没理解清楚，就开始瞎写一大坨没用的代码 相同的错误会重复的犯 代码修改范围没有边界约束，不该改的修改了 谎报任务已完成，其实留了一堆TODO（主打一个你又不看我写了啥～） 不遵循项目规范（我有我的风格） 修复Bug不找根因，而是把Bug藏起来！！ 写完代码不做验证就结束任务 ...
我们不得不承认AI确实能显著提升编码效率，但一个容易被忽略的配套事实是：生成速度越快，错误积累的速度也越快，且AI的自主性越强，偏离正确轨道后的修复成本就越高。
AI 代码生成能力很强，但是工程约束没有跟上，这就是AI Coding 进入生产环境后遇到的主要矛盾：
要解决这个矛盾，靠更复杂的提示词和持续对话修复问题的耐心肯定是不行的，最终还是得回归到传统软件开发的那套工程流程。
毕竟这套流程是软件工程领域沉淀那么多年总结下来的，以前是人工写代码，现在轮到AI来写代码，只不过写代码的角色变了，但是代码本身和写代码的原则以及软件工程开发的范式是没有任何改变的。
讲到这里，就要轮到今天要给大家介绍的主角Superpowers了！
Superpowers
我们先看Superpowers是什么？
我的理解是：用一套工程化的流程来约束AI 生成代码，让它始终在正确的轨道上工作。这也是当前大家都在讨论的Harness工程在做的事情，只不过Superpowers更专注在代码生成控制这个环节。
我们先回顾下传统软件开发的工作流程，大致先后按照如下流程执行：需求讲解、需求澄清、方案设计、任务拆分、需求开发、系统化调试、代码审查、结果验收。
而Superpowers做的事情就是把这套传统的工程化流程，拆分成了一系列可以重复使用的Skills，然后通过插件和Hook机制注入到主流的AI Coding Agent中去。相当于在任务执行时增加了一层工作流约束，每个任务都必须按照这套流程来执行。
这样说估计大家仍然很懵，下面我们结合Superpowers仓库源码给大家介绍，当然也不必有心理负担，它的源码其实就是一堆Markdown格式的提示词而已。
从目录可以看出，Superpowers主要提供了一系列的Skills，每个Skill都是经过精心设计，扮演着软件开发工作流的某个环节的角色，来解决当前AI Coding存在的痛点。
下面我们先看几个核心的skill：
brainstorming
当前AI Coding失控的第一个点，需求都没有搞清楚，就直接开始写代码了。这样的结果可想而知，必定会偏离预期。需求模糊时，AI 经常会自己脑补细节、替我们做决定，最后我们还得花时间纠正它，来回沟通很耗精力，也白白浪费 Token。
brainstorming这个Skill相当于在AI 一上来就准备写代码时，提前踩了一脚刹车，先停下来把需求搞清楚、把方案对明白。
它会强制按照如下的流程执行：
自动探索项目上下文信息
对当前用户的需求进行问题澄清，这个环节它会采用苏格拉底式提问，不断的引导我们把需求从模糊变得明明白白，有时候我写的需求提示词已经足够详细了，但是到这一步它仍然会抛出很多让我意想不到但是又非常关键的问题
需求澄清之后，会基于当前项目的情况提出2-3种实现方案，包括每种方案的优缺点，并且还会给出它推荐的方案
用示意图呈现它的设计
编写需求以及实现方案文档
文档写完之后，会进行自我审查，看是否存在遗漏和前后矛盾的点
交给用户确认审核
确认完成后，会在当前项目根目录下面生成当前需求的设计文档，后面的流程基于这份设计文档做展开。
writing-plans
这个Skill的职责就是基于需求设计文档写任务执行计划，它会把计划拆成若干个2-5分钟能完成的TDD小任务，每个任务做得非常细致，包括需要修改哪些文件、代码片段、验证命令、期望结果等。
确保一个不清楚项目上下文信息的人，拿到这份执行计划，也能完成任务开发。这里有个很大的好处就是减少AI后面执行时自由发挥的空间。
下面这张图是使用Superpowers:writing-plans编写的任务计划，大家可以感受一下：
test-driven-development
前面任务计划制定完成后，就轮到具体执行了。
test-driven-development这是Superpowers中最具特色的一个Skill，也是整个工作流程的核心原则，测试驱动开发的范式（TDD），大概意思就是：要先写测试用例，再写代码实现功能；不能先写功能代码，再写测试用例。
TDD核心流程分为三步：
先写失败的测试用例，此时为红灯
再写少量的代码，让测试通过，此时为绿灯
最后进行代码重构，去掉冗余代码、提高可维护、健壮性，同时确保测试仍然通过
Superpowers内部的规则要求非常严格，没有看到失败的测试（红灯），就不能写生产代码。
这里的原因也很简单，如果先写逻辑实现，再补测试用例，就很容易变成验证代码现在实现了什么，故意逃避原本的需求应该是什么。这也是当前AI写代码普遍存在问题。
通过测试先行，会逼着AI先明确：边界是什么、错误情况是什么、功能怎样才算完全正确。始终保持红、绿、重构的节奏，确保最小可验证，避免AI放飞自我，一次性写很多没啥用的代码。
当然，TDD也会让整体的执行时间更长、Token消耗更大，因为它需要不断往复的跟AI交互。
systematic-debugging
AI 修复Bug经常糊弄我们，处理方式治标不治本，或者干脆把bug藏起来。
而systematic-debugging这个Skill会明确要求：没有完成根因调查之前，就不要提出修复方案。
它会要求 Agent 按照如下流程执行：
阅读完整的报错信息 稳定复现问题 检查最近的变更记录 在代码中添加关键诊断日志 沿着数据流往回追踪错误从哪里产生的 找到类似的正常代码做对比
只有形成了明确的假设之后，才会开始最小变更验证。如果三次修复都失败，就不能再继续，要回头质疑假设是否真的成立，甚至是当前的技术架构是否合理。
verification-before-completion
这个Skill主要负责完成前的验收，验收完成是需要有明确的标准和证据的。
不能听AI说已经完成，就相信真的完成了。比如测试通过，那就要看是否运行过测试命令，运行结果是不是全部通过；如果是构建成功，那就要看刚刚是否运行过构建命令，是不是存在报错信息。如果是需求完成，那就要按照需求设计文档逐项检查，而不是只看测试用例是否通过。
以上就是Superpowers提供的一些核心Skill，这里就不完全展开了，感兴趣的同学可以继续自主探索。
自动生效机制
这里有个关键问题，上面这些都是单个Skill，那这些Skill是如何被组织起来形成一条工作流，又是如何被Agent强制执行这条工作流的呢？
我们知道Skill都有一套标准的编写规范，其中SKILL.md文件最为核心，里面有这个Skill的元信息，包括名称、使用场景，每次会话时系统都会自动携带所有Skill的元信息，大模型会自动判断在什么情况下使用哪个Skill。
my-skill/ ├── SKILL.md # 【必选】使用说明 + 元数据 ├── scripts/ # 【可选】可执行代码 ├── references/ # 【可选】参考文档 └── assets/ # 【可选】模板、资源文件 ---name: skill-namedescription: Use when ...---# Skill Title具体流程、硬性规则、检查清单、反模式、示例但仅靠这套Skill的自动加载机制还不够，没法形成强约束，Superpowers这里通过Hook机制在每次会话启动时往系统提示词中强制注入using-superpowers这个Skill中的内容。
using-superpowers这个Skill不是前面介绍的普通业务类型技能，而是一个技能系统的元技能，它的作用是告诉AI：任何任务开始前都要检查是否有相关的Skill，哪怕只有1%的适用性，也必须加载使用，这是没有任何商量的余地。
同时里面也给出了指令的优先级，用户指令优先级最高（包括CLAUDE.md、AGENTS.md、用户输入的请求指令），其次就是Superpowers Skill，最后才是默认的系统提示。
因此，using-superpowers这一层相当于是一个启动器、总的调度规则，而各个Skill的内部也会写明下一步该用哪一个Skill。
所以superpowers其实是靠提示词驱动的工作流编排，通过启动注入+skill 描述触发 + skill 内部交接规则，把整个开发过程串起来的，不需要用户每次手动指定请使用这个流程，这就是Superpowers 自动生效的核心机制。
运作流程
看到这里，大家可能有点懵，为了更清晰的理解，下面我们把这些 Skill 串起来，看看Superpowers 实际的运行流程，这里先看调用流程图。
具体每个步骤做的事情如下表：
 |
实践感受
这套机制我已经使用了很长一段时间了，它能够避免需求不清导致执行偏差从而反复返工，也能降低大任务执行失控的可能，一次性交付的成功率更高了。
但是Superpowers这套流程也不是万能的，它最大的特点就是重纪律、强流程，整个流程执行下来耗费的时间会更长、Token消耗会更大。对于大任务我觉得是很值得的，但是对于小任务而言，也要强制执行这套流程，就有点过于笨重，尤其是TDD那一套。
TDD在传统软件开发领域只有极少数团队真正做到，主要集中在做基础建设或者底层开发的团队，做业务开发的基本难得一见，即使做了，也是把顺序反过来的，先写代码后补用例。这里面的逻辑是，基建追求稳健，慢一点也无妨，而业务团队追求交付效率，业务逻辑都写不完，哪有时间搞这些啊。因此，TDD这套流程在古法编程时代很难推行下去。
在AI Coding时代，大家还是有思维惯性，不过我觉得TDD这套流程具备普遍使用的条件了，毕竟AI生成代码的速度很快，但是又缺了约束和自我验证。
当然这只是我个人的看法，具体取决于大家团队的风格。如果是追求质量优先，Superpowers这套流程是很值得尝试的。如果觉得过于笨重，也可以选择性安装其中一些Skill来使用，比如只用brainstorming 来进行需求澄清、用writing-plans 来制定任务计划、用systematic-debugging 来查找Bug根因等。
更高级的玩法是，借鉴Superpowers这套机制，结合自己的业务团队需求进行定制化改造。
这里说一个大致的思路，先制定整体的工作协作流程，然后对每个流程节点提炼封装为独立的Skill，在用一个类似using-superpowers 这样的引导技能（bootstrap） 来统一约束整体工作流程，然后借助各个Agent工具的Hook机制，将引导技能强制注入到每轮会话的系统提示词中。从而形成一套适用于AI Coding的强约束的流程。
总结
回到开头提出的核心矛盾，AI 代码生成能力很强，但是工程约束没有跟上。
解决办法是借鉴类似Superpowers的工作流程机制，把软件工程领域成熟的开发范式以及资深工程师脑子里的隐形习惯，变成AI 可以严格执行的显性流程。
先问清楚、再定方案、拆计划、TDD、Bug解决找根因、独立审查、证据先于结论
这些原则非常朴素，但在 AI Coding时代，这些朴素的工程原则反而越来越重要。
好了，今天这篇文章希望对大家有所启发。