⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/gaobieyeluzikaifaClaude-Code--Superpowers--zhuanyejigongchengliucheng/ 「芋道源码」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

vibe coding 在小项目能飞，大项目会塌

Andrej Karpathy 在 2025 年提了个词叫 vibe coding——凭感觉给 prompt，看 AI 跑，不细看，能跑就行。这风格在写一个 demo、跑一个脚本时确实很爽。

国内开发者最近半年几乎都被 AI 编程工具刷屏——Cursor、Trae、通义灵码、CodeBuddy、CodeWhisperer 国内版轮番出新版本，朋友圈里”昨晚 Cursor 帮我 vibe 出一个 SaaS”的截图越来越多。但圈子里也开始有反向声音：vibe 出来的代码，三个月后没人敢碰。这不是工具的问题，是 vibe 这种工作方式本身在生产项目上有天花板。

但 vibe 在生产项目上一定会撞墙：

需求没澄清就动手；
实现方案没人评审；
测试缺位；
改动范围失控。

代码确实能跑。问题是两周后没人敢碰——你让 Claude 加个功能，它顺手改了五个文件，你不知道它改了啥，也不知道它为什么改。

这不是 AI 不行，是流程不行。软件工程那套「需求澄清 → 设计评审 → 拆任务 → TDD → Code Review」不是给人类拖慢速度用的，是用来防止上面这些事的。

Superpowers 是 vibe coding 的反义词——它不让 AI 飞，每一步都打卡。

Superpowers 真正在做的事：把工程纪律塞回 AI

Jesse Vincent（GitHub: obra）在 2025 年 10 月开源的 Claude Code 插件，现在已上官方市场。

它的设计哲学很反潮流：在所有人追求「AI 写得更快」的时候，它要 AI「写得更稳」。具体做法是把软件工程的核心环节做成 20+ 可组合的 Skills——需求澄清、设计评审、任务拆解、TDD、代码审查——每个 Skill 有触发条件、执行流程、产出物，全部走 Git 留痕。

一句话概括：它不教 AI 怎么写好代码，它强制 AI 不能写差。

系统分四层：

层级	职责
用户层	平台无关，支持 Claude Code、Cursor、Codex、OpenCode
框架层	Session Hook 机制，会话开始自动注入技能上下文
执行层	子代理调度，任务隔离、并行
输出层	设计、代码、测试统一走 Git

技能文件是 YAML Frontmatter + Markdown，轻量、可读、可自定义——这意味着你可以自己写 Skill，不是只能用作者那 20 个。

元问题：上下文膨胀让 AI 越写越歪

vibe coding 在大项目上一定会撞上一堵墙——上下文膨胀。

对话轮次越多，模型要处理的历史越长，早期决策一直影响后续。AI 写到第 50 轮还在被第 5 轮的错误判断拖着走，代码质量是一条单调下滑的曲线。

Superpowers 的核心机制叫 Subagent-Driven Development（子代理驱动开发）——每个任务启动一个全新的子代理，只给它当前任务的描述，历史对话不带入。做完之后专门起一个审查子代理做质量检查。

四条铁律：

上下文隔离：每个子代理从空白启动，只接收当前任务；
职责分离：写代码的子代理和审查代码的是两个不同的；
快速重试：审查不通过直接新建子代理，不在原上下文里反复磨；
并行执行：独立任务可以分发给多个子代理同时跑。

理解一下这意味着什么：vibe coding 是「一个 AI 从头跑到尾，越跑越累」；Superpowers 是「每个任务都派一个清醒的新人去做」。

两阶段审查：让 AI 学会挑自己的刺

代码审查最常见的失误是什么？一边讨论代码风格，一边忽略功能缺陷。Superpowers 把这件事拆成两轮——顺序不能颠倒，关注点严格分离：

阶段	只问一件事	通过标准	不看的
第一轮：Spec Review	实现满足需求了吗？	功能点全 / 边界条件处理 / 测试覆盖规范	代码风格、命名、实现细节
第二轮：Quality Review	代码好不好维护？	风格一致 / DRY / 命名清晰 / 不过度工程	功能正确性（已通过 Spec）

把两件事拆开是因为人类做 review 也容易走神——盯着括号位置时会忘了边界条件没处理。让两个不同的子代理各管一件事，至少能逼着 AI 也按这个分工走。

第一轮不通过——不是修补，是直接重做：系统创建一个新的子代理重新执行任务，原代码直接丢弃。

这个机制乍看暴力，逻辑很对：错的实现修补两次还是错的，直接重做反而更省时间。

强制 TDD：AI 不主动写测试，那就别给它选

Superpowers 最反直觉的设计是强制 TDD。

你或许写测试，但你的同事 Claude 大概率不写。它的默认行为是先把功能跑起来，测试是「有空再补」——这不是 AI 偷懒，是训练数据偏差：大部分公开代码本身就没测试。

Superpowers 直接把这件事干掉：每个任务必须先写测试，测试失败之后才允许写实现，实现通过之后才允许重构。RED → GREEN → REFACTOR，循环不能跳。

更狠的是：如果 Claude 检测到代码是在没测试的情况下先写的，会自动删掉让你重来。Jesse Vincent 在博客里写：「跟一个懒得写测试的初级工程师共事的感觉，系统直接把这个习惯掐掉了。」

这是整套 Superpowers 里最有「纪律感」的一节——别的工具劝你写测试，它直接没收你不写测试的权利。

完整工作流：从头脑风暴到合并

七个阶段，每个对应具体技能。

阶段一：Brainstorming（头脑风暴）

这是和普通 AI 编程工具差距最大的地方——它会先停下来问问题。

AI: "这个限流器要做单机的还是分布式的？"
User: "分布式，多个微服务共用"
AI: "限流算法选哪个：固定窗口、滑动窗口、令牌桶、漏桶？"
User: "令牌桶，要平滑流量"
AI: "Key 维度怎么定？按用户、按 IP、按接口，还是组合？"
User: "用户 + 接口"
AI: "存储用 Redis 单实例、集群，还是本地内存兜底？"
...

确认完之后给出 2-3 个实现方案让你选，定完才生成 design.md，分段（200-300 字）让你逐段确认，最后提交到 Git。

这一步看着慢，实际省了大量后期返工——需求没搞清楚就写代码，后面的麻烦只会更多。

阶段二：Git Worktree（环境隔离）

git worktree add ../rate-limit-worktree -b feature/rate-limit
cd ../rate-limit-worktree

允许多个功能在不同目录下并行开发，IDE 不会频繁重索引。

阶段三：Writing Plans（任务拆解）

任务粒度控制在 2-5 分钟，每个任务有明确验证步骤：

## Task: 实现令牌桶算法 (3 分钟)
- 编写 TokenBucket 类，支持 capacity 和 refillRate
- 实现 tryAcquire(tokens) 方法（线程安全）
- 单元测试：突发流量 / 持续低流量 / 超额请求

验证步骤：
- [ ] 测试通过
- [ ] 1 秒内不超过 refillRate 的请求全部成功
- [ ] 并发场景下不出现负数令牌

任务之间尽量减少依赖，方便子代理并行。

阶段四 → 阶段七

简单粗暴：派子代理执行 → 强制 TDD → 两阶段审查 → 通过就下一个，不通过新建子代理重做。所有任务做完，提供选项：合并到主分支 / 生成 GitHub PR / 保留 worktree / 丢弃。清理 worktree，结束。

两种执行模式怎么选

维度	Subagent-Driven Development	Executing Plans
会话模型	当前会话内创建子代理	并行独立会话
上下文	每个子代理全新上下文	批量执行，共享上下文
审查机制	自动两阶段审查循环	人工检查点
执行速度	快（无需等待）	慢（需人工确认）
适用场景	独立、明确的任务	需要中途调整策略的任务
失败处理	自动重试	需人工介入

一句话选型：需求清楚、测试完整就用第一种；探索性开发、要中途换方向就用第二种。

安装方法：官方市场最省心

/plugin install superpowers@claude-plugins-official

或者用作者自己的市场：

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

安装完重启 Claude Code 就能用。

其他平台：

Cursor：Agent chat 里搜 “superpowers”
Codex：让它获取 https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.codex/INSTALL.md 按说明操作
OpenCode：路径换成 .opencode/INSTALL.md
GitHub Copilot CLI / Gemini CLI：见 README

技能速查和触发方式

技能	功能	使用场景
`brainstorming`	逐步澄清需求	需求不明确时
`writing-plans`	任务拆解为可执行步骤	大功能或复杂任务前
`executing-plans`	按计划执行并设检查点	推进既定计划
`test-driven-development`	TDD 红-绿-重构循环	功能实现阶段
`systematic-debugging`	结构化 Bug 根因分析	出现 Bug 或异常
`verification-before-completion`	任务结束前验证	准备提交时
`requesting-code-review`	请求代码审查	提交或合并前
`subagent-driven-development`	用子代理执行任务	需并行处理子任务
`using-git-worktrees`	Git worktree 隔离环境	同时开发多个功能

技能通过关键词自动触发，可以组合使用：

用 TDD 实现订单导出接口，完成后帮我做代码审查

这条同时触发 test-driven-development 和 requesting-code-review。

最后说两句：好用，但很烧 token

vibe coding 没错。在 demo / 原型 / 一次性脚本场景，它是当前最高效的写法——不需要的工程纪律就是浪费。

但生产项目不是 vibe 能扛住的。Superpowers 给的不是「比 vibe 更好的 prompt」，是 vibe 之外的另一条路——把软件工程那套真正起作用的纪律，重新装回 AI 工作流。

不过装之前先说一句很现实的事：Superpowers 真的很烧 token。

子代理隔离 = 每个任务都重载上下文；
两阶段审查 = 同一段代码至少跑三次（实现 → Spec Review → Quality Review，不通过还要重做）；
强制 TDD = 多一倍的测试代码生成。

一个简单功能下来，token 消耗轻松是 vibe coding 的 5-10 倍。在 token 计费越来越紧的当下，这个成本是要算清楚的。

实操建议很简单：

公司报销 / 团队预算够：放心装，长期可维护性的回报远大于 token 成本。
个人自费：先在小项目上试，跑过几次再决定要不要在主力项目上铺开。
vibe 已经能解决的场景：别硬上工程化，Superpowers 是给真正需要纪律的项目用的。

工程化不是免费的午餐——质量提上去的同时账单也跟着上去。想清楚再装。

GitHub 地址：https://github.com/obra/superpowers

芋道源码 —— 纯源码解析博客

告别 Vibe Coding：Claude Code + Superpowers = 顶级架构师开发流程