AI编程新范式:这套＂超能力＂系统让你的开发效率翻10倍

开源链接在文末👇

求一波关注：

最近在GitHub上发现一个宝藏项目，看完之后我直呼"卧槽，这也太强了"。这不是又一个AI编程工具那么简单，而是一套完整的AI编码工作流系统，让你的AI助手从"提词器"进化成"项目经理+架构师+资深工程师"的合体。

说实话，一开始我还挺怀疑的。市面上AI编程工具已经够多了，从Copilot到Cursor再到各种IDE插件，还能玩出什么新花样？但这个东西真不一样——它不是简单帮你补全代码，而是建立了一套完整的开发方法论。

核心理念：别让AI瞎写代码

这个项目的核心逻辑非常清晰：在写代码之前，必须先搞清楚到底要做什么。听起来很朴素对吧？但实际开发中有多少人真的做到了？

传统AI编程的痛点是：你跟AI说"给我写个用户认证功能"，它就开始噼里啪啦输出代码。但问题是：

• 你要的是什么类型的认证？JWT？Session？OAuth？
• 需要哪些权限控制？RBAC？ABAC？
• 密码加密用什么？bcrypt？argon2？
• 要不要支持多租户？

AI大概率会按它的理解来写，要么做多了（过度设计），要么做少了（漏掉边界情况）。等代码跑起来发现不对，又要重来，浪费时间。

这个系统的解决方案是：先强制进入"头脑风暴"阶段。

第一步：头脑风暴——让AI学会追问

这个技能的触发时机很明确：任何创造性工作之前——创建功能、构建组件、添加功能、修改行为。重点是"任何"两个字，意味着没有例外。

具体流程是这样的：

AI首先会检查项目的当前状态（文件、文档、最近提交），然后一次只问一个问题。注意是一次，不是一堆问题轰炸。比如想做一个用户认证功能，它可能先问：

"这个用户认证需要支持哪些方式？A) 用户名+密码 B) 邮箱+验证码 C) 第三方登录（如Google/微信）D) 以上都需要"

你选了D，它接着问：

"第三方登录需要集成哪些平台？A) 只Google B) 只微信 C) Google和微信都要 D) 其他平台请说明"

这种多选题的方式既降低了你的回答门槛，又能让AI快速理解需求。如果是开放性问题，它也会保持简洁，一次只挖深一个维度。

等你把需求聊清楚了，AI开始提方案。它不会直接给你一个最终设计，而是先提出2-3种不同方案，说明各自的优缺点，然后给出它的推荐和理由。比如：

"针对你的需求，我考虑了三个方案：
方案A：JWT + Refresh Token，优点是支持多端登录，缺点是token管理复杂
方案B：Session + Redis，优点是实现简单，缺点是服务端依赖状态
方案C：JWT + 本地存储，优点是无状态，缺点是安全性较低

我推荐方案A，因为..."

等到你确认方案后，AI开始输出设计文档。这里有个细节：它不会一次性甩给你几千字的文档，而是分成200-300字的小段，每段都问你"这样对吗？"。分段内容包括：架构设计、组件划分、数据流、错误处理、测试策略等。

这种渐进式验证的好处是，一旦某个方向错了，能立即发现，不用等全部写完了再改。

设计确定后，AI会自动保存设计文档到 docs/plans/YYYY-MM-DD-<topic>-design.md，然后提交到git。这个细节很重要——设计本身也是项目资产。

第二步：编写计划——把需求拆成原子任务

有了设计文档，接下来进入计划编写阶段。这个阶段的目标是：创建一个足够详细的实施计划，详细到什么程度？假设实施者是一个"没有上下文、品味一般、不写测试、只管写代码"的初级工程师，他也能照着做。

这个技能在项目文档里写得非常明白："Assume they are a skilled developer, but know almost nothing about our toolset or problem domain."（假设他们是熟练的开发者，但几乎不了解我们的工具链或问题域）。

计划的颗粒度是每个任务2-5分钟，精确到文件路径、完整代码、测试命令、预期输出。比如一个任务可能是：

Task 3: 实现用户注册端点

Files:

• Create: src/api/auth.ts
• Modify: src/api/index.ts:45-52
• Test: tests/api/auth.test.ts

Step 1: Write the failing test

test('user registration with valid email and password', async () => {  const response = await request(app)    .post('/api/auth/register')    .send({ email: 'test@example.com', password: 'secure123' })  expect(response.status).toBe(201)  expect(response.body).toHaveProperty('userId')  expect(response.body).toHaveProperty('token')})

Step 2: Run test to verify it fails
Run: npm test -- tests/api/auth.test.ts -t "user registration with valid email and password"
Expected: FAIL with "Cannot POST /api/auth/register"

Step 3: Write minimal implementation

app.post('/api/auth/register', async (req, res) => {  const { email, password } = req.body  const userId = await createUser(email, password)  const token = generateToken(userId)  res.status(201).json({ userId, token })})

Step 4: Run test to verify it passes
Run: npm test -- tests/api/auth.test.ts -t "user registration with valid email and password"
Expected: PASS

Step 5: Commit

git add src/api/auth.ts src/api/index.ts tests/api/auth.test.tsgit commit -m "feat: implement user registration endpoint"

看到了吗？每个步骤都精确到命令和预期结果，不给你留"猜"的空间。而且严格遵守TDD（测试驱动开发）流程：先写失败的测试，看着它失败，写最简单的代码让它通过，提交。

计划完成后，AI会问你："准备好开始实施了吗？"这时候它已经为你准备好了一个隔离的工作环境。

第三步：Git Worktrees——隔离的开发空间

在开始写代码之前，这个系统会先创建一个独立的git工作树（worktree）。简单来说，就是在不切换分支的情况下，为你的功能开发创建一个干净的工作目录。

这样做的好处显而易见：

• 不会影响主分支的代码
• 可以随时切换到其他分支处理紧急问题
• 开发完成后的清理更简单

创建完worktree后，系统会自动运行项目设置命令，确保依赖安装完成、测试通过。这个"干净状态"的验证很重要，如果基线就有问题，后面的一切都可能出问题。

第四步：子代理驱动开发——多AI协作

这是整个系统最精彩的部分之一。它不是让一个AI从头写到尾，而是让多个"子代理"分工协作，每个子代理只负责一个小任务，写完之后经过双重审查才能标记完成。

具体流程是这样的：

1. 分发任务给实施者子代理
   ：每个任务都是一个新的子代理，带着完整的任务描述开始工作
2. 实施者提问
   ：子代理如果在实施过程中有不明白的地方，会主动提问，拿到答案后继续工作
3. 自我审查
   ：完成代码后，子代理会先进行自我审查，检查是否满足规范
4. 规范符合性审查
   ：第一个审查者子代理会从"怀疑主义"角度出发，严格检查实现是否完全符合计划——包括有没有做多了、做少了
5. 代码质量审查
   ：只有规范审查通过后，才会进入代码质量审查，检查代码是否干净、测试是否充分、可维护性如何
6. 循环迭代
   ：如果审查发现问题，实施者需要修复，然后重新审查，直到通过
7. 标记完成
   ：在TodoWrite中标记任务完成，然后继续下一个任务

所有任务完成后，还有一个最终的全面代码审查，确保整个实现的一致性和质量。

这种"新鲜代理+双重审查"的模式有几个明显优势：

• 每个子代理的注意力高度集中
• 没有上下文污染（前一个任务的思考不会影响后一个）
• 双重审查既保证了符合规范，又保证了代码质量
• 迭代速度很快，因为不需要人类频繁介入

第五步：测试驱动开发——红绿重构循环

在实施过程中，系统强制执行严格的TDD流程。这不是建议，是强制。

红绿重构循环是这个技能的核心：

RED（红）：写失败的测试
先写一个测试，描述期望的行为。测试的名字要清晰，一个测试只验证一个行为，而且要用真实代码而不是mock（除非不可避免）。比如：

test('password must be at least 8 characters', async () => {  const result = await validatePassword('short')  expect(result.isValid).toBe(false)  expect(result.error).toBe('Password too short')})

验证RED：看着测试失败
这一步是强制的，不能跳过。运行测试，确认：

• 测试确实失败了（不是报错）
• 失败的原因是功能缺失（不是写错了测试）
• 失败信息是预期的

如果测试直接通过了，说明你在测试已存在的功能，测试白写了。如果测试报错（语法错误等），先修复错误再运行。

GREEN（绿）：写最少的代码
写最简单的代码让测试通过。不要做任何优化、不要加任何额外功能、不要重构其他代码。比如：

function validatePassword(password: string) {  if (password.length < 8) {    return { isValid: false, error: 'Password too short' }  }  return { isValid: true }}

就这么简单，刚好让测试通过，不多不少。

验证GREEN：看着测试通过
再次运行测试，确认：

• 测试通过了
• 其他测试还是通过的
• 没有新的错误或警告

REFACTOR（重构）：清理代码
只有在这一步才进行重构——消除重复、改善命名、提取辅助函数。但前提是保持所有测试绿色，不能添加新功能。

然后继续下一个测试，循环往复。

这套流程的核心原则是："If you didn't watch the test fail, you don't know if it tests the right thing"（如果你没看着测试失败，你就不知道它测的是不是对的东西）。

第六步：系统化调试——四阶段流程

遇到bug怎么办？不要猜，不要试，用系统化方法。

这个技能要求在尝试任何修复之前，必须先完成四个阶段：

阶段1：根本原因调查

• 仔细读错误信息和堆栈跟踪
• 确认能否稳定复现
• 检查最近的变更
• 对于多组件系统，添加诊断日志

对于多组件系统（比如CI→构建→签名，或API→服务→数据库），系统要求在每个组件边界添加诊断日志，确认数据在哪里出了问题，然后再针对具体组件进行深入调查。

阶段2：假设形成
基于收集的证据，形成假设。可以有多个假设，按可能性排序。

阶段3：假设验证
设计一个实验来验证假设。注意：不是修复，是验证。实验必须能明确区分"假设成立"和"假设不成立"两种情况。

阶段4：修复和验证
只有在确认根本原因后，才能进行修复。修复后要运行完整测试，确保没有引入新问题。

这个流程的核心原则是："NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST"（没有根本原因调查，就不做修复）。

第七步：代码审查——持续的质量把关

在任务之间，系统会自动触发代码审查流程。审查会对比计划，报告问题按严重程度分级：

• Critical（严重）：阻塞进度，必须立即修复
• Major（重要）：建议尽快修复
• Minor（次要）：可以稍后处理

审查不仅检查代码是否符合计划，还会检查是否有潜在的bug、安全问题、性能问题等。

第八步：完成开发分支——收尾工作

所有任务完成后，系统会进行最后的验证：

• 运行完整测试套件
• 检查代码覆盖率
• 清理不必要的文件
• 然后给出选项：合并到主分支、创建PR、保留分支、或丢弃分支

最后会清理worktree，保持工作空间干净。

技能触发机制——自动化的魔法

最神奇的是，所有这些技能都不是手动触发的，而是自动判断是否需要。系统有一个核心规则：

"IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT."

（如果一个技能适用于你的任务，你别无选择，必须使用它。）

这甚至包括1%可能性的情况——只要有可能适用，就必须检查。为了防止"合理化"（比如"这只是个简单问题"、"我先看看代码"、"这个技能太麻烦了"等借口），系统列了一堆"红旗"，让你识别自己在找理由。

技能之间还有优先级顺序：先流程技能（头脑风暴、调试），再实施技能（前端设计、MCP构建）。

实际应用场景

说了这么多，这套系统在什么场景下最有用呢？

场景1：新功能开发
比如你要给一个电商系统添加"优惠券"功能。从头开始，AI会先帮你理清需求：优惠券类型（满减、折扣、买一送一）、适用范围（全店、特定品类、特定商品）、有效期规则、叠加限制、库存控制等。然后生成详细设计，拆分实施计划，自动化实施和审查。

场景2：Bug修复
生产环境出现一个偶发bug，不要急着改代码。让AI引导你进行系统化调试：收集日志、分析错误、验证假设、定位根本原因、修复验证。整个过程有记录可追溯，避免"瞎猫碰死耗子"的修复方式。

场景3：重构现有代码
比如要把一个单体应用拆分成微服务。AI会先和你讨论拆分方案（按业务域？按数据？按功能？），然后制定详细迁移计划，逐步重构，每一步都有测试保障。

场景4：学习新技术栈
你想学习一个新框架，但又怕踩坑。让AI帮你搭建示例项目，按照TDD流程实现各种功能，在代码审查环节解释最佳实践。既写了代码，又学到了知识。

场景5：团队协作标准化
整个团队使用这套系统，自然就会形成统一的开发流程和质量标准。新人加入时，AI会引导他们熟悉整个流程，降低学习成本。

为什么这套系统有效？

我觉得这套系统之所以强大，是因为它抓住了AI编程的本质问题：

AI不是人类的替代品，而是放大器。

如果人类本身的开发流程就是混乱的、随意的、靠拍脑袋决定的，那么再强大的AI也只会放大这种混乱。但如果有一套系统化的、可重复的、有纪律的方法论，AI就能把这个方法论的威力放大到极致。

这套系统的核心哲学是"强制性"——不是建议，不是最佳实践，是强制执行。因为人类太擅长找借口了："这个很简单"、"先这么写后面再改"、"这次特殊处理"。而AI如果被要求"必须遵守规则"，它真的会遵守。

如何使用？

这个系统支持多个平台：Claude Code（内置插件市场）、Codex、OpenCode。

在Claude Code中，安装命令是：

/plugin marketplace add obra/superpowers-marketplace/plugin install superpowers@superpowers-marketplace

安装完成后，会看到三个可用命令：

• /superpowers:brainstorm - 交互式设计优化
• /superpowers:write-plan - 创建实施计划
• /superpowers:execute-plan - 批量执行计划

但其实你不需要手动调用这些命令，因为技能会自动触发。你只需要告诉AI你想做什么，剩下的它会帮你完成。

最后的想法

这篇文章写了3000多字，但其实只是这个项目的冰山一角。项目中还有更多技能和细节，比如条件等待、纵深防御、技能测试方法论等，每一部分都值得深入研究。

我觉得这个项目最大的价值，不是它集成了多少AI能力，而是它建立了一套完整的AI辅助开发方法论。它告诉我们：AI编程不是简单的"让AI帮你写代码"，而是"让AI帮你建立正确的开发流程，然后在正确的流程中帮你写代码"。

如果你经常用AI写代码，或者你对AI编程感兴趣，强烈建议你试试这个系统。它可能会改变你对AI编程的理解。

对了，项目还在持续更新中，最新版本（v4.0.3，2025-12-26）刚加强了技能触发机制，还添加了显式技能请求测试。看来作者还在不断打磨细节。

免责声明

本文内容仅代表作者个人观点，项目可能存在已知或未知的问题，使用前请自行评估风险。开源项目的稳定性和功能不保证100%可靠，请根据实际情况谨慎使用。因使用该项目导致的任何损失，作者不承担责任。建议在重要项目中使用前先进行充分测试。

开源链接：https://github.com/obra/superpowers