[{"data":1,"prerenderedAt":53},["ShallowReactive",2],{"article-156":3},{"code":4,"msg":5,"data":6,"count":14},200,"查询成功",{"id":7,"title":8,"keywords":9,"description":10,"category_id":11,"content":12,"body_html":13,"thumb_up":14,"clicks":15,"sort":14,"remark":13,"status":16,"is_open":16,"is_deleted":14,"is_top":16,"is_recommend":16,"create_time":17,"update_time":17,"image_id":18,"url":13,"member_id":14,"cate_name":19,"prev":20,"next":23,"tags":26,"words":36,"read_time":37,"comments":14,"cover":38,"relevant":39},156,"Superpowers：把 AI 编程从提示词技巧升级成工程流程","Superpowers, AI 编程, Claude Code, Skills, TDD","Superpowers 的价值不在于让 AI 更会写代码，而是把需求澄清、计划拆分、测试验证和系统调试变成可执行流程。本文结合官方资料与项目热度，拆解新手为什么先从 4 个核心 skill 入手，以及团队如何把它落地为可复盘的 AI 编程规范。",16,"## 先说结论\n\nSuperpowers 火起来，表面原因是数字好看：截至 2026-06-28 核对，GitHub API 显示 `obra\u002Fsuperpowers` 约 24 万 stars、2.1 万 forks；Claude 官方插件市场也把它作为 Claude Code 插件展示，安装量已经达到很高量级。\n\n但它真正值得技术团队关注的地方，不是“又多了一个 AI 插件”，而是它把 AI 编程里最容易失控的部分变成了流程：先澄清需求，再写计划，再做验证，遇到问题再系统调试。也就是说，它不是让 AI 获得某个神秘能力，而是给 AI 套上一组工作规范。\n\n如果你是新手，不需要一开始就把十几个 skill 全部研究透。更实际的路径是先掌握 4 个核心工作流：\n\n- `brainstorming`：写代码前先澄清目标、约束和验收标准。\n- `writing-plans`：把需求拆成小任务，明确改哪些文件、怎么验证。\n- `test-driven-development`：先写验证，再写实现，让每一步都有反馈。\n- `systematic-debugging`：遇到 bug 先复现、取证、假设、验证，而不是凭感觉改。\n\n![](https:\u002F\u002Ftp.myong.top\u002Fstorage\u002Fmarkdown\u002F20260628\u002Fbfa8baea8d08f889db08fb0387987f3e.png)\n\n\n这 4 个 skill 覆盖了 AI 编程最核心的闭环：需求、计划、验证、修复。\n\n## 为什么 AI 编程需要“工作规范”\n\n很多人第一次用代码 Agent，会经历一个典型阶段：你给它一个需求，它很快开始改文件、写代码、跑命令，看起来效率很高。但问题也在这里，AI 的执行速度越快，方向错的时候损失越大。\n\n常见翻车点有四类：\n\n1. 需求还没讲清楚，AI 已经开始动手。\n2. 任务拆得太大，中途改了很多文件，但没有阶段性检查。\n3. 没有先定义验证方式，最后只能靠肉眼看代码“像不像对”。\n4. 出 bug 后凭猜测修改，改一处又引出另一处。\n\nSuperpowers 解决的不是“模型智商不够”的问题，而是“工程过程缺少约束”的问题。它的思路很像把资深工程师的工作习惯写成 AI 可执行的规则：什么时候该问问题，什么时候该写计划，什么时候必须先造失败测试，什么时候必须停下来收集证据。\n\n这就是它和普通提示词模板最大的区别。提示词模板通常只影响某一次回答；skill 则更像一段可复用的工作协议，会改变 AI 完成任务的顺序和检查点。\n\n## Superpowers 本质上是什么\n\n准确地说，Superpowers 不是单个 skill，而是一组面向 AI coding agent 的 skills。它覆盖的不是某一种语言或框架，而是软件开发过程里的通用动作：头脑风暴、计划、测试驱动开发、系统性调试、代码审查、并行代理、工作树隔离、分支收尾等。\n\n![](https:\u002F\u002Ftp.myong.top\u002Fstorage\u002Fmarkdown\u002F20260628\u002F225e388a903fe38186fc24f693da4872.png)\n\n\n所以它适合的场景不是“帮我写一个函数”这种一次性小活，而是这些更容易出错的工作：\n\n- 新功能从模糊想法进入实现。\n- 老项目里要改一段有上下游影响的逻辑。\n- Bug 现象复杂，不能靠直觉猜原因。\n- 团队希望 AI 产出的代码有验证证据。\n- 多个 Agent 或多轮会话需要保持一致的工程习惯。\n\n视频里把它类比成“严格监工”是有道理的。更工程化的说法是：它把 AI 的自由发挥压进一个可检查的流水线里。\n\n## 新手为什么先抓这 4 个\n\n### 1. Brainstorming：防止 AI 过早动手\n\n`brainstorming` 的核心价值是把“需求不清”这个风险提前暴露出来。很多 AI 代码问题不是写法问题，而是目标理解错了：用户想要的是修一个边界条件，AI 却顺手重构了模块；用户只想改一个页面，AI 却引入了新状态管理。\n\n一个好的 brainstorming 过程至少要问清楚三件事：\n\n- 目标：这次到底要解决什么问题？\n- 边界：哪些东西不能动，哪些兼容性必须保留？\n- 验收：怎样证明任务完成了？\n\n它不是为了让 AI 无休止提问，而是让 AI 在动手前知道“什么叫做做对”。\n\n### 2. Writing Plans：把大需求切成可检查的小步骤\n\n`writing-plans` 的价值是降低任务跨度。AI 最容易失控的任务，往往是“帮我把这个功能做完”这种大块需求。看起来一句话很简单，实际可能涉及接口、状态、页面、权限、测试、构建和文档。\n\n计划 skill 会把任务拆成小步骤，并写清楚：\n\n- 每一步要改哪些文件。\n- 为什么按这个顺序改。\n- 每一步完成后如何验证。\n- 哪些地方需要人工确认。\n\n视频里提到“每个任务 2 到 5 分钟”，可以理解成一种理想粒度：任务越小，越容易检查；检查越频繁，越不容易在最后才发现方向错了。\n\n### 3. Test Driven Development：先定义证据，再写代码\n\n`test-driven-development` 听起来很技术，但对 AI 编程尤其实用。原因很简单：AI 很擅长写“看起来合理”的代码，却不一定知道这段代码有没有真的覆盖目标行为。\n\nTDD 的顺序是：\n\n1. 先写一个会失败的验证。\n2. 再写最小实现让验证通过。\n3. 最后在验证保护下整理代码。\n\n这里的“测试”不一定永远是单元测试。对不同项目来说，它可以是接口用例、类型检查、脚本断言、端到端流程、甚至是一个能稳定复现问题的最小命令。关键不是测试形式，而是先有可重复的证据。\n\n### 4. Systematic Debugging：不要猜，先取证\n\nAI 修 bug 最大的问题是“行动太快”。它经常看到一个报错，就立刻改最像问题的地方。但复杂 bug 往往不是第一个报错点导致的。\n\n`systematic-debugging` 会强迫流程慢下来：\n\n- 先复现问题。\n- 再收集日志、输入、输出和环境信息。\n- 提出多个可能原因。\n- 一次只验证一个假设。\n- 找到根因后再改代码。\n\n这套流程看似慢，但比连续猜错三次更快。尤其在老项目、生产事故、依赖版本问题、权限问题和并发问题上，它能显著减少“越修越乱”。\n\n## 它对团队的真正价值\n\n如果只把 Superpowers 当作个人效率工具，你会觉得它只是让 AI 多问几句、多写几段计划。但对团队来说，它更重要的价值是形成统一的 AI 协作标准。\n\n团队可以把它落成三条简单规则：\n\n1. 新功能必须先经过 brainstorming 和 writing-plans。\n2. 行为变更必须给出验证方式，能 TDD 就优先 TDD。\n3. Bug 修复必须先复现和定位根因，再提交补丁。\n\n![](https:\u002F\u002Ftp.myong.top\u002Fstorage\u002Fmarkdown\u002F20260628\u002Ff66677c925113d7fcf7829eb971775ab.png)\n\n\n这三条规则能解决一个现实问题：不同成员使用 AI 的习惯差异很大。有的人让 AI 一次改十几个文件，有的人让 AI 不跑测试直接总结完成，有的人遇到 bug 让 AI 连续猜。Superpowers 的作用，就是把这些差异压缩到同一条工程流水线里。\n\n## 常见误区\n\n**误区一：装了 Superpowers，AI 就会自动变强。**  \n不会。它增强的是流程，不是模型能力。模型如果不了解你的代码库，仍然需要读代码、跑测试、看日志。\n\n**误区二：新手只需要“安装 4 个”。**  \n更准确的说法是：新手先练熟这 4 个核心流程。实际安装方式会随不同 Agent 和插件市场变化，有的平台是安装整套插件，再在使用时触发对应 skill。\n\n**误区三：Brainstorming 就是一直问问题。**  \n不是。好的需求澄清要服务于实现，问到目标、边界和验收足够清楚就应该停下。\n\n**误区四：TDD 只适合大团队。**  \n恰好相反，个人使用 AI 时更需要 TDD，因为你没有同事帮你随时审查 AI 生成的代码。最小验证就是你的第二双眼睛。\n\n## 推荐落地路径\n\n个人用户可以按这个顺序练：\n\n1. 先在新功能里使用 `brainstorming`，训练 AI 不要立刻写代码。\n2. 再使用 `writing-plans`，让 AI 把任务拆到你能逐步检查的粒度。\n3. 对核心逻辑启用 `test-driven-development`，把验收标准变成自动验证。\n4. 遇到 bug 时固定使用 `systematic-debugging`，禁止 AI 凭第一感觉改代码。\n\n团队用户可以再往前走一步：把这套流程写进项目的 AI 协作规范里，比如 `AGENTS.md`、`CLAUDE.md` 或仓库文档。这样每个人调用 AI 时，都不是从零开始解释团队习惯，而是复用同一套工程规则。\n\n## 最后\n\nSuperpowers 的爆火说明了一件事：AI 编程的竞争已经不只是“谁的模型更强”，也包括“谁能把模型放进更可靠的工程流程”。\n\n对新手来说，先不要纠结十几个 skill 要不要全部掌握。真正应该先养成的是四个习惯：写代码前问清楚、动手前写计划、实现前有验证、修 bug 时先找根因。\n\n当这四件事变成默认动作，AI 就不再只是一个会写代码的聊天窗口，而更像一个能被流程约束、能被证据检查、能参与工程协作的开发伙伴。\n\n## 参考资料\n\n- GitHub：[`obra\u002Fsuperpowers`](https:\u002F\u002Fgithub.com\u002Fobra\u002Fsuperpowers)\n- GitHub API：[`repos\u002Fobra\u002Fsuperpowers`](https:\u002F\u002Fapi.github.com\u002Frepos\u002Fobra\u002Fsuperpowers)\n- Claude 插件市场：[Superpowers plugin](https:\u002F\u002Fclaude.com\u002Fplugins\u002Fsuperpowers)\n- Anthropic 文档：[Claude Code plugins](https:\u002F\u002Fdocs.anthropic.com\u002Fen\u002Fdocs\u002Fclaude-code\u002Fplugins)\n",null,0,12,1,"2026-06-28 00:41:22",192,"Ai",{"id":21,"title":22},155,"别再把 Codex 当聊天框：把 AI 用成一支可管理的开发队",{"id":24,"title":25},158,"HTTP\u002F3 的 QUIC 基于 UDP，为什么仍然可靠？",[27,29,31,33],{"id":28,"name":19},89,{"id":21,"name":30},"开源项目",{"id":7,"name":32},"工程实践",{"id":34,"name":35},157,"Agent工作",3409,8,"https:\u002F\u002Ftp.myong.top\u002Fstorage\u002Farticle\u002F20260628\u002F8bdcd50c0b35154f898196124260a8dc.png",[40,45,50],{"id":41,"title":42,"create_time":43,"description":44},140,"一文讲透 Agent、RAG、Skill 与 MCP 的区别与联动","2026-04-19 10:34:30","如果你最近关注 AI 开发，一定会被这几个词刷屏：**Agent**、**RAG**、**Skill**、**MCP**。有人说它们是未来，有人说它们是炒作。更让人头疼的是，很多文章混着用，让人一头雾水。",{"id":46,"title":47,"create_time":48,"description":49},154,"Codex 实战技术分享：把 AI 编程助手接入真实工程流","2026-06-22 20:03:56","本文介绍 Codex 在 CLI、IDE、App 和 Cloud 中的使用场景，梳理任务闭环、Prompt 编写、AGENTS.md 与 config.toml 配置、安全边界和团队落地方法，帮助研发团队把 Codex 接入可审阅、可验证的工程流程。",{"id":21,"title":22,"create_time":51,"description":52},"2026-06-25 23:54:55","本文提出一种将 Codex 从“普通聊天框”升级为“可管理的 AI 开发队”的使用方法。核心思路是把一个项目拆成清晰的工作区与独立 Thread，先 Plan 再实现，完成后用 Review 做代码审查，并通过 AGENTS.md、Skills、MCP 和定时任务把规则、流程和重复劳动标准化，从而降低上下文混乱和返工成本",1783431644699]