我盯了Superpowers这个项目很久了。在过去一年里AI编程工具层出不穷但真正让人觉得这不是玩具、能扛真实项目的很少Superpowers算一个。8万星标在开源圈子里不是一个随随便便的数字——它意味着成千上万的开发者在生产环境里反复试用、提交反馈、互相补丁最后沉淀出一套能让AI编程不掉链子的工程化协作方案。如果你用Codex、Claude这类助手写代码却发现越改越乱、经常碰坏老功能、代码慢慢变成了不敢动的屎山那这篇文章就是写给你看的。我先把话说清楚Superpowers不是一个让AI自动写完整网站的一键生成器。它更像是一套跑在AI编程助手之上的技能操作系统把零散的提示词变成有边界的技能包把一次性的对话变成有检查点、有验收标准的任务流让AI助手从超强实习生变成能看懂团队规范、按流程办事的协作者。下面我从原理、配置、实战和排错四个角度把我自己的使用记录完整摊开。1. 为什么最后选了Superpowers作为AI编程的底座1.1 AI编程为什么会把代码写成屎山先说现象。很多人第一次用AI编程工具的感受是爽改个函数、补个接口、写个单元测试几分钟搞定。但用着用着就发现不对了同一个功能今天让AI改一遍明天再让它改一遍两次改出来的风格完全不同它在修一个bug的时候悄悄动了周边三个模块的代码跑一次测试全绿但代码审查时发现一堆无意义的格式改动和多余的import。这些问题的根源其实不在模型本身而在于使用方式。聊天式的AI编程是一个无状态的对话窗口每次对话都从零开始模型只能凭当前上下文猜测你的意图和代码库的约定。没有边界、没有验收、没有记忆结果就是靠概率生成代码产生大量认知负担和隐性技术债。用一句行话来说单次对话的AI编程天然具备把工程变成屎山的倾向。1.2 Superpowers的思路给AI装上工程纪律Superpowers解决问题的角度很有意思它不去和模型比谁聪明而是把重点放在流程上。它的核心是一套可复用的技能包skill每个技能包都是一个结构化的Markdown文件里面写明这个技能在什么场景下触发、需要哪些前置信息、执行步骤分几步、每一步的产出是什么、怎么验收、遇到意外怎么回退、哪些文件绝对不能动。你可以把它理解成一个工作习惯模板。资深工程师改代码是有套路的先定位影响范围再列改动清单然后小步修改、随时验证、最后整理diff。Superpowers就是把这种套路固化成AI可以稳定执行的流程。当AI助手每改一个文件之前先读技能包、按步骤执行、在检查点停下来等确认产出的代码质量完全不是一个量级。这一点在多人协作、长期迭代的项目里特别重要——流程一旦跑起来每个人和每个AI的产出都是同一种味道审查成本直线下降。1.3 为什么开源和8万星标反而是最可靠的信号选工程底座工具我个人的一个固执原则是闭源黑盒的工具可以试但不会用来扛核心流程。Superpowers走到8万星标意味着几件事第一它的技能包格式有大量真实项目验证过踩过的坑都变成了文档和模板第二社区贡献了大量针对不同语言、不同框架的现成技能接上就能用第三一旦遇到问题你能看到issue列表、修复记录和替代方案而不是对着一个联系客服的按钮干瞪眼。对工程化协作这件事来说透明度本身就是可靠性的一部分。2. Superpowers的核心机制拆解它是怎么防止屎山的2.1 技能包从提示词到可执行的规范普通AI编程的提示词是零散的写在对话框里下次就没了。Superpowers把它升级成了一种文件资产。比如我在项目里维护了一个代码审查技能包里面的内容大致是这样的结构# skill: code-review ## 触发条件 - 用户要求审查diff / pull request - 改动涉及公共接口或数据迁移 ## 前置检查 1. 获取当前分支与目标分支的diff stat确认改动范围 2. 读取项目根目录的 CONTRIBUTING.md确认代码规范 ## 执行步骤 1. 按模块顺序逐个审查不跳跃 2. 对每处改动给出影响范围分析 3. 列出高风险项公开API签名变化、状态持久化格式变化、并发逻辑 ## 验收标准 - 每个文件的审查结论都有明确依据 - 高风险项必须给出修改建议或回退方案 ## 禁止事项 - 不修改源代码只输出审查结论 - 不凭空猜测调用方行为引用真实代码路径这样的技能包一旦放进团队仓库所有成员和AI助手共享同一套规范。你甚至可以给每个主要目录、每个技术栈、每种任务重构、加功能、修bug、写测试都维护一个技能包。它的价值在于AI的行为从随机发挥变成了贴着规范走。2.2 任务分解一次AI会话变成一张工单Superpowers的第二个关键机制是把一次大任务拆成可验证的小任务。举例来说我让它重构一个老模块的数据库访问层不会直接说重构一下。我会先调用分析技能生成现状报告再调用设计技能给出迁移方案确认后分几步执行每完成一步就停下来让我看diff。整个过程类似把一个大功能拆成PRpull request每个PR边界清晰、可回滚、可审查。你可能会问聊天窗口多轮对话不是也能做到吗区别在于状态持久化。Superpowers会把中间结果写到项目里的工作目录例如.superpowers/state/下存一份任务状态文件记录已经完成的分析、待确认的决策、当前所处的步骤。这样即使中途切换对话、重启工具任务也能从上次断点继续。这点在大工程里极其有价值——长对话超过上下文上限之后聊天式AI基本等于失忆而Superpowers用文件系统充当了AI的长期记忆。2.3 检查点与回滚护栏允许AI犯错但不允许失控AI写代码一定会犯错问题不是让它不犯错而是让错误影响可控。Superpowers的实践里我特别看重检查点checkpoint设计。在每个任务的关键节点它会主动停下输出当前改动摘要和风险提示等你确认之后再继续。同时技能模板里可以定义白名单和黑名单目录白名单是允许改动的位置黑名单是只读位置例如数据库迁移文件、生成器输出目录、第三方依赖锁定文件。这种做法就像给AI划了一条施工红线。它可以有多种实现方式团队里给底层依赖目录建一个只读技能包或者直接在技能模板里声明遇到路径src/generated/下的文件一律不修改。我实际用下来检查点机制是防止屎山最有效的一环——AI的破坏性改动如果能在扩散前被拦下来后续的返工成本会少掉一个数量级。2.4 多Agent协作的上下文缝补真实项目里AI编程不可能永远只有一个人在干活。团队里可能同时有多个AI助手在处理不同模块的任务或者同一个任务里要让不同助手分别承担编码、审查、测试角色。这时候最大的麻烦是上下文隔离每个AI只知道它自己那一段对话不知道其他Agent改了什么。Superpowers的处理方式是以文件为中心的协作。每个Agent产生的决策、需求和约束都写进共享状态文件后续Agent启动时先读取这些文件再开始自己的部分。这跟微服务之间的消息传递有点像不共享内存只共享持久化的数据。我自己的经验是凡是能让多个Agent同时推进的改动必须把接口约定、数据结构、命名规范都提前落到文档里否则并行协作就会退化成互相覆盖反而比一个人慢慢做更慢。3. 新手入门从安装到第一个AI协作任务3.1 5分钟快速接入Superpowers虽然Superpowers的项目规模和配置项不少但接入一个已有项目其实很快。我以最常见的给现有代码库加一套AI编程协作流程为例大致需要四步# 1. 克隆技能库到项目根目录的外部引用目录 git clone https://github.com/你的账号/你的技能库.git .superpowers/skills # 2. 初始化工作目录 mkdir -p .superpowers/state cp .superpowers/skills/_template/skill.example.md .superpowers/state/first-task.md # 3. 在AI助手的配置里声明技能目录路径 # 以支持自定义指令目录的AI编程工具为例在项目配置中增加 # skills_dir: .superpowers/skills这里有个细节容易踩坑技能目录不要和代码混在一起。.superpowers/这个目录是否入库要分清楚——团队共享的技能库和状态模板应该入库但每个开发者本地生成的临时状态文件不应入库。我的做法是skills/和templates/提交进仓库state/和cache/忽略掉。这样规范是统一的但个人工作区是干净的。3.2 新手必看的三个关键配置参数第一次用Superpowers不用急着把所有技能都搬过来。我建议你先配置三个参数跑通一个最小闭环。第一个是模型的服务模式和上下文预算。每个技能步骤的产出结果会被读回来所以上下文消耗比普通对话更快。我给每个任务步骤设了最多读入文件数和文件大小上限超过就强制先做摘要。第二个是自动确认与手动确认的开关。建议在开始阶段全部设为手动确认每个检查点都停下来看diff等你熟悉了技能包节奏再逐步放开。我见过有人一上来就开全自动结果AI连删三个文件都没人发现那种体验绝对不想来第二次。第三个是失败重试策略。技能模板里可以写明遇到编译错误时最多重试两次然后停下报告。我见过不少团队忽略这个结果AI在一个错误上反复横跳十分钟不仅浪费时间还可能把旁边好的文件改坏。这三个参数配好之后你的第一个任务可以选一个低风险的重命名函数练习而不是一上来就让它动核心调度模块。3.3 建立团队共享技能库从一个人用到所有人用当Superpowers在个人项目里跑顺之后下一步就是把它变成团队资产。我的建议是在仓库根目录维护一份技能清单文档列清楚本仓库有哪些技能包、分别由谁维护、变更流程是什么。一份合格的技能清单不会很长但每个技能包都应该有负责人。团队共享技能库有个隐藏好处新人上手速度会明显变快。以前新同事要读代码规范、看历史PR、问老员工这项目怎么跑现在他只需要让AI助手加载对应技能包就能按照团队认可的方式完成任务。这其实就是把隐性的工程知识显性化了AI编程反而成了一种知识管理工具。这个价值往往被人忽略但实际上比少写几行代码重要得多。4. 真实项目里的工程化协作记录4.1 场景一用分步迁移重构一坨历史遗留代码我接手过一个运行多年的后台服务里面有一个订单状态机模块超过两千行各种if嵌套和重复switch。同事们的共识是没人敢动。我拿它当Superpowers的第一个实战对象。流程是这样的第一步让AI用静态分析技能生成一份当前逻辑的文件图谱标出每个函数的入参、出参和调用方第二步我人工确认这份图谱合理再让它给出一个分片迁移计划每次只迁移一个状态分支第三步每个分支迁移完就跑一遍整套单元测试并且生成diff供我审查第四步所有分支迁移结束后再一次性删掉废弃分支。整个过程中最关键的纪律是一次只迁移一个分支绝不让AI顺手做任何重构。你会觉得它明显在压抑自己的表演欲但因为每一步都有明确的检查和回滚点整个过程没有出现过一次改到一半没法回头的情况。最终状态机从两千行降到三百行行为完全没变。这正是我想看到的在真实工程里稳定比炫技值钱得多。4.2 场景二多模块并行开发的节奏控制另一个让我印象深刻的场景是同时推进三个模块的新功能。我把需求文档、接口定义和进度计划都放进了共享状态目录然后给每个模块开了一个独立的工作分支每个分支上让一个AI助手按照对应技能包执行任务。模块之间唯一的耦合点是接口契约我把这个契约固化成JSON Schema并加入测试任何一方的改动只要违反契约测试就会立刻变红。这套做法的好处是不需要一个总指挥官式的Agent来协调一切而是靠契约和测试来自动拦截问题。当然它也有适用条件模块之间的耦合必须足够松。如果你的模块本身就是A调用B、B调用C这种强耦合强行并行只会造成频繁的冲突。我自己用的判断标准是两个模块之间如果超过三处直接调用关系就不适合并行老老实实按依赖顺序一个一个来。4.3 场景三强制测试先行的AI编程爬坡Superpowers社区里有人总结了先写测试再让AI实现的工作流我试用后觉得非常值得推广。它的做法很简单在技能包的最前面规定任何功能开发任务必须先写一个会失败的测试再开始写实现代码。AI助手完成任务后只有当测试从红变绿才算满足验收标准。这个机制之所以有效是因为它把AI说它做完了变成测试证明它做完了。AI在生成代码时经常有一种迷之自信没有测试约束时它会把一个根本没编译过的函数跨模块传下去。有了红灯绿灯的强制门槛代码的可靠性天差地别。我个人的补充是测试先行的技能包还可以加上覆盖率统计如果新代码没有把关键分支覆盖掉AI需要主动补测试再汇报。这样一道流程下来团队对AI产出的信心会肉眼可见地上升。5. 常见问题与排查技巧实录5.1 任务跑到一半上下文爆掉了怎么办这是我被问得最多的问题。对话上下文是有限资源技能步骤越多中间结果越多越容易触顶。我的处理思路有两个方向。第一个是缩小每次处理的范围把大任务拆成更细的技能每个技能只处理一小块输入。第二个是让中间结果不占上下文把模型输出的分析文本直接写入文件后续步骤通过读取文件名来获取信息而不是让助手在对话里重复引用长文本。你可以让AI助手把刚才的分析摘要写到 .superpowers/state/analysis.md然后读取这个文件继续这个习惯能极大延缓上下文触顶。5.2 AI越改越乱怎么快速止损遇到AI突然在修A模块时把B模块的一堆无关文件也改了第一反应是停而不是让它再改回来。我会立刻执行git diff --stat看改动清单如果确认改动越界就直接恢复改动git checkout -- src/module_b/把无关模块的文件恢复到改动前状态然后重新约束技能范围再让它继续。这里有个重要心得不要相信AI的我改好了要看diff。只从对话内容判断是否越界人是看不住的必须依靠git diff和状态文件的记录来对照核实。我甚至会写成一条规范任何AI改动必须生成显式diff并和任务描述中的目标文件一一对应没有对上的改动一律回滚。5.3 团队协作中最容易忽略的价值观对齐最后一个问题不在技术层面而在团队层面。Superpowers再强大也只是把流程固化的工具如果团队成员本身不认可小步提交、频繁审查、测试优先这套价值观那技能包写得再漂亮也是摆设。我经历过一次尴尬的过渡技能库里明明写了不修改生成器输出目录但有个同事为了赶进度给AI写了一条额外指令让它绕过校验直接改文件结果生成逻辑和手工改动互相覆盖花了两天时间修回来。所以我现在做团队接入的时候第一件事不是讲工具怎么用而是讲清楚工具是帮我们守住工程底线的不是让破坏更快发生。这类对齐工作看起来慢实际上是整个工程化协作里回报最高的一环。5.4 问题排查速查表现象常见原因排查方法任务中途断掉AI不继续执行状态文件损坏或步骤标记缺失查看state目录下的任务文件恢复断点步骤修改范围失控技能包没声明黑名单目录检查技能包禁止事项补充目录约束上下文频繁触顶技能粒度太粗、中间结果未落盘拆分技能中间结果写入文件而非对话多个Agent互相覆盖缺少接口契约与分支隔离用JSON Schema做契约测试按模块开分支测试全绿但代码烂测试只覆盖正常路径在技能包里加入覆盖率与边界用例要求这张表我贴在团队Wiki里后续遇到问题都是先对着表检查一遍再决定要不要升级到人工介入。我自己的体会是AI编程的瓶颈早就不是模型能不能写代码而是组织生产节奏的纪律能不能跟上。8万星标意味着这套思路被足够多的人验证过值得你花一个下午认真接一次。如果你准备上手我给一个最直接的建议不要贪多先挑一个小模块、配三个技能包、跑通一次带检查点的重构任务然后把体验拿回团队里讨论。AI编程的未来一定不是人跟AI单挑而是人和AI、AI和AI在一个有秩序的系统里协作。有秩序这件事恰恰是Superpowers这类工具最打动我的地方。
Superpowers实操指南：用技能包和检查点告别AI编程屎山
我盯了Superpowers这个项目很久了。在过去一年里AI编程工具层出不穷但真正让人觉得这不是玩具、能扛真实项目的很少Superpowers算一个。8万星标在开源圈子里不是一个随随便便的数字——它意味着成千上万的开发者在生产环境里反复试用、提交反馈、互相补丁最后沉淀出一套能让AI编程不掉链子的工程化协作方案。如果你用Codex、Claude这类助手写代码却发现越改越乱、经常碰坏老功能、代码慢慢变成了不敢动的屎山那这篇文章就是写给你看的。我先把话说清楚Superpowers不是一个让AI自动写完整网站的一键生成器。它更像是一套跑在AI编程助手之上的技能操作系统把零散的提示词变成有边界的技能包把一次性的对话变成有检查点、有验收标准的任务流让AI助手从超强实习生变成能看懂团队规范、按流程办事的协作者。下面我从原理、配置、实战和排错四个角度把我自己的使用记录完整摊开。1. 为什么最后选了Superpowers作为AI编程的底座1.1 AI编程为什么会把代码写成屎山先说现象。很多人第一次用AI编程工具的感受是爽改个函数、补个接口、写个单元测试几分钟搞定。但用着用着就发现不对了同一个功能今天让AI改一遍明天再让它改一遍两次改出来的风格完全不同它在修一个bug的时候悄悄动了周边三个模块的代码跑一次测试全绿但代码审查时发现一堆无意义的格式改动和多余的import。这些问题的根源其实不在模型本身而在于使用方式。聊天式的AI编程是一个无状态的对话窗口每次对话都从零开始模型只能凭当前上下文猜测你的意图和代码库的约定。没有边界、没有验收、没有记忆结果就是靠概率生成代码产生大量认知负担和隐性技术债。用一句行话来说单次对话的AI编程天然具备把工程变成屎山的倾向。1.2 Superpowers的思路给AI装上工程纪律Superpowers解决问题的角度很有意思它不去和模型比谁聪明而是把重点放在流程上。它的核心是一套可复用的技能包skill每个技能包都是一个结构化的Markdown文件里面写明这个技能在什么场景下触发、需要哪些前置信息、执行步骤分几步、每一步的产出是什么、怎么验收、遇到意外怎么回退、哪些文件绝对不能动。你可以把它理解成一个工作习惯模板。资深工程师改代码是有套路的先定位影响范围再列改动清单然后小步修改、随时验证、最后整理diff。Superpowers就是把这种套路固化成AI可以稳定执行的流程。当AI助手每改一个文件之前先读技能包、按步骤执行、在检查点停下来等确认产出的代码质量完全不是一个量级。这一点在多人协作、长期迭代的项目里特别重要——流程一旦跑起来每个人和每个AI的产出都是同一种味道审查成本直线下降。1.3 为什么开源和8万星标反而是最可靠的信号选工程底座工具我个人的一个固执原则是闭源黑盒的工具可以试但不会用来扛核心流程。Superpowers走到8万星标意味着几件事第一它的技能包格式有大量真实项目验证过踩过的坑都变成了文档和模板第二社区贡献了大量针对不同语言、不同框架的现成技能接上就能用第三一旦遇到问题你能看到issue列表、修复记录和替代方案而不是对着一个联系客服的按钮干瞪眼。对工程化协作这件事来说透明度本身就是可靠性的一部分。2. Superpowers的核心机制拆解它是怎么防止屎山的2.1 技能包从提示词到可执行的规范普通AI编程的提示词是零散的写在对话框里下次就没了。Superpowers把它升级成了一种文件资产。比如我在项目里维护了一个代码审查技能包里面的内容大致是这样的结构# skill: code-review ## 触发条件 - 用户要求审查diff / pull request - 改动涉及公共接口或数据迁移 ## 前置检查 1. 获取当前分支与目标分支的diff stat确认改动范围 2. 读取项目根目录的 CONTRIBUTING.md确认代码规范 ## 执行步骤 1. 按模块顺序逐个审查不跳跃 2. 对每处改动给出影响范围分析 3. 列出高风险项公开API签名变化、状态持久化格式变化、并发逻辑 ## 验收标准 - 每个文件的审查结论都有明确依据 - 高风险项必须给出修改建议或回退方案 ## 禁止事项 - 不修改源代码只输出审查结论 - 不凭空猜测调用方行为引用真实代码路径这样的技能包一旦放进团队仓库所有成员和AI助手共享同一套规范。你甚至可以给每个主要目录、每个技术栈、每种任务重构、加功能、修bug、写测试都维护一个技能包。它的价值在于AI的行为从随机发挥变成了贴着规范走。2.2 任务分解一次AI会话变成一张工单Superpowers的第二个关键机制是把一次大任务拆成可验证的小任务。举例来说我让它重构一个老模块的数据库访问层不会直接说重构一下。我会先调用分析技能生成现状报告再调用设计技能给出迁移方案确认后分几步执行每完成一步就停下来让我看diff。整个过程类似把一个大功能拆成PRpull request每个PR边界清晰、可回滚、可审查。你可能会问聊天窗口多轮对话不是也能做到吗区别在于状态持久化。Superpowers会把中间结果写到项目里的工作目录例如.superpowers/state/下存一份任务状态文件记录已经完成的分析、待确认的决策、当前所处的步骤。这样即使中途切换对话、重启工具任务也能从上次断点继续。这点在大工程里极其有价值——长对话超过上下文上限之后聊天式AI基本等于失忆而Superpowers用文件系统充当了AI的长期记忆。2.3 检查点与回滚护栏允许AI犯错但不允许失控AI写代码一定会犯错问题不是让它不犯错而是让错误影响可控。Superpowers的实践里我特别看重检查点checkpoint设计。在每个任务的关键节点它会主动停下输出当前改动摘要和风险提示等你确认之后再继续。同时技能模板里可以定义白名单和黑名单目录白名单是允许改动的位置黑名单是只读位置例如数据库迁移文件、生成器输出目录、第三方依赖锁定文件。这种做法就像给AI划了一条施工红线。它可以有多种实现方式团队里给底层依赖目录建一个只读技能包或者直接在技能模板里声明遇到路径src/generated/下的文件一律不修改。我实际用下来检查点机制是防止屎山最有效的一环——AI的破坏性改动如果能在扩散前被拦下来后续的返工成本会少掉一个数量级。2.4 多Agent协作的上下文缝补真实项目里AI编程不可能永远只有一个人在干活。团队里可能同时有多个AI助手在处理不同模块的任务或者同一个任务里要让不同助手分别承担编码、审查、测试角色。这时候最大的麻烦是上下文隔离每个AI只知道它自己那一段对话不知道其他Agent改了什么。Superpowers的处理方式是以文件为中心的协作。每个Agent产生的决策、需求和约束都写进共享状态文件后续Agent启动时先读取这些文件再开始自己的部分。这跟微服务之间的消息传递有点像不共享内存只共享持久化的数据。我自己的经验是凡是能让多个Agent同时推进的改动必须把接口约定、数据结构、命名规范都提前落到文档里否则并行协作就会退化成互相覆盖反而比一个人慢慢做更慢。3. 新手入门从安装到第一个AI协作任务3.1 5分钟快速接入Superpowers虽然Superpowers的项目规模和配置项不少但接入一个已有项目其实很快。我以最常见的给现有代码库加一套AI编程协作流程为例大致需要四步# 1. 克隆技能库到项目根目录的外部引用目录 git clone https://github.com/你的账号/你的技能库.git .superpowers/skills # 2. 初始化工作目录 mkdir -p .superpowers/state cp .superpowers/skills/_template/skill.example.md .superpowers/state/first-task.md # 3. 在AI助手的配置里声明技能目录路径 # 以支持自定义指令目录的AI编程工具为例在项目配置中增加 # skills_dir: .superpowers/skills这里有个细节容易踩坑技能目录不要和代码混在一起。.superpowers/这个目录是否入库要分清楚——团队共享的技能库和状态模板应该入库但每个开发者本地生成的临时状态文件不应入库。我的做法是skills/和templates/提交进仓库state/和cache/忽略掉。这样规范是统一的但个人工作区是干净的。3.2 新手必看的三个关键配置参数第一次用Superpowers不用急着把所有技能都搬过来。我建议你先配置三个参数跑通一个最小闭环。第一个是模型的服务模式和上下文预算。每个技能步骤的产出结果会被读回来所以上下文消耗比普通对话更快。我给每个任务步骤设了最多读入文件数和文件大小上限超过就强制先做摘要。第二个是自动确认与手动确认的开关。建议在开始阶段全部设为手动确认每个检查点都停下来看diff等你熟悉了技能包节奏再逐步放开。我见过有人一上来就开全自动结果AI连删三个文件都没人发现那种体验绝对不想来第二次。第三个是失败重试策略。技能模板里可以写明遇到编译错误时最多重试两次然后停下报告。我见过不少团队忽略这个结果AI在一个错误上反复横跳十分钟不仅浪费时间还可能把旁边好的文件改坏。这三个参数配好之后你的第一个任务可以选一个低风险的重命名函数练习而不是一上来就让它动核心调度模块。3.3 建立团队共享技能库从一个人用到所有人用当Superpowers在个人项目里跑顺之后下一步就是把它变成团队资产。我的建议是在仓库根目录维护一份技能清单文档列清楚本仓库有哪些技能包、分别由谁维护、变更流程是什么。一份合格的技能清单不会很长但每个技能包都应该有负责人。团队共享技能库有个隐藏好处新人上手速度会明显变快。以前新同事要读代码规范、看历史PR、问老员工这项目怎么跑现在他只需要让AI助手加载对应技能包就能按照团队认可的方式完成任务。这其实就是把隐性的工程知识显性化了AI编程反而成了一种知识管理工具。这个价值往往被人忽略但实际上比少写几行代码重要得多。4. 真实项目里的工程化协作记录4.1 场景一用分步迁移重构一坨历史遗留代码我接手过一个运行多年的后台服务里面有一个订单状态机模块超过两千行各种if嵌套和重复switch。同事们的共识是没人敢动。我拿它当Superpowers的第一个实战对象。流程是这样的第一步让AI用静态分析技能生成一份当前逻辑的文件图谱标出每个函数的入参、出参和调用方第二步我人工确认这份图谱合理再让它给出一个分片迁移计划每次只迁移一个状态分支第三步每个分支迁移完就跑一遍整套单元测试并且生成diff供我审查第四步所有分支迁移结束后再一次性删掉废弃分支。整个过程中最关键的纪律是一次只迁移一个分支绝不让AI顺手做任何重构。你会觉得它明显在压抑自己的表演欲但因为每一步都有明确的检查和回滚点整个过程没有出现过一次改到一半没法回头的情况。最终状态机从两千行降到三百行行为完全没变。这正是我想看到的在真实工程里稳定比炫技值钱得多。4.2 场景二多模块并行开发的节奏控制另一个让我印象深刻的场景是同时推进三个模块的新功能。我把需求文档、接口定义和进度计划都放进了共享状态目录然后给每个模块开了一个独立的工作分支每个分支上让一个AI助手按照对应技能包执行任务。模块之间唯一的耦合点是接口契约我把这个契约固化成JSON Schema并加入测试任何一方的改动只要违反契约测试就会立刻变红。这套做法的好处是不需要一个总指挥官式的Agent来协调一切而是靠契约和测试来自动拦截问题。当然它也有适用条件模块之间的耦合必须足够松。如果你的模块本身就是A调用B、B调用C这种强耦合强行并行只会造成频繁的冲突。我自己用的判断标准是两个模块之间如果超过三处直接调用关系就不适合并行老老实实按依赖顺序一个一个来。4.3 场景三强制测试先行的AI编程爬坡Superpowers社区里有人总结了先写测试再让AI实现的工作流我试用后觉得非常值得推广。它的做法很简单在技能包的最前面规定任何功能开发任务必须先写一个会失败的测试再开始写实现代码。AI助手完成任务后只有当测试从红变绿才算满足验收标准。这个机制之所以有效是因为它把AI说它做完了变成测试证明它做完了。AI在生成代码时经常有一种迷之自信没有测试约束时它会把一个根本没编译过的函数跨模块传下去。有了红灯绿灯的强制门槛代码的可靠性天差地别。我个人的补充是测试先行的技能包还可以加上覆盖率统计如果新代码没有把关键分支覆盖掉AI需要主动补测试再汇报。这样一道流程下来团队对AI产出的信心会肉眼可见地上升。5. 常见问题与排查技巧实录5.1 任务跑到一半上下文爆掉了怎么办这是我被问得最多的问题。对话上下文是有限资源技能步骤越多中间结果越多越容易触顶。我的处理思路有两个方向。第一个是缩小每次处理的范围把大任务拆成更细的技能每个技能只处理一小块输入。第二个是让中间结果不占上下文把模型输出的分析文本直接写入文件后续步骤通过读取文件名来获取信息而不是让助手在对话里重复引用长文本。你可以让AI助手把刚才的分析摘要写到 .superpowers/state/analysis.md然后读取这个文件继续这个习惯能极大延缓上下文触顶。5.2 AI越改越乱怎么快速止损遇到AI突然在修A模块时把B模块的一堆无关文件也改了第一反应是停而不是让它再改回来。我会立刻执行git diff --stat看改动清单如果确认改动越界就直接恢复改动git checkout -- src/module_b/把无关模块的文件恢复到改动前状态然后重新约束技能范围再让它继续。这里有个重要心得不要相信AI的我改好了要看diff。只从对话内容判断是否越界人是看不住的必须依靠git diff和状态文件的记录来对照核实。我甚至会写成一条规范任何AI改动必须生成显式diff并和任务描述中的目标文件一一对应没有对上的改动一律回滚。5.3 团队协作中最容易忽略的价值观对齐最后一个问题不在技术层面而在团队层面。Superpowers再强大也只是把流程固化的工具如果团队成员本身不认可小步提交、频繁审查、测试优先这套价值观那技能包写得再漂亮也是摆设。我经历过一次尴尬的过渡技能库里明明写了不修改生成器输出目录但有个同事为了赶进度给AI写了一条额外指令让它绕过校验直接改文件结果生成逻辑和手工改动互相覆盖花了两天时间修回来。所以我现在做团队接入的时候第一件事不是讲工具怎么用而是讲清楚工具是帮我们守住工程底线的不是让破坏更快发生。这类对齐工作看起来慢实际上是整个工程化协作里回报最高的一环。5.4 问题排查速查表现象常见原因排查方法任务中途断掉AI不继续执行状态文件损坏或步骤标记缺失查看state目录下的任务文件恢复断点步骤修改范围失控技能包没声明黑名单目录检查技能包禁止事项补充目录约束上下文频繁触顶技能粒度太粗、中间结果未落盘拆分技能中间结果写入文件而非对话多个Agent互相覆盖缺少接口契约与分支隔离用JSON Schema做契约测试按模块开分支测试全绿但代码烂测试只覆盖正常路径在技能包里加入覆盖率与边界用例要求这张表我贴在团队Wiki里后续遇到问题都是先对着表检查一遍再决定要不要升级到人工介入。我自己的体会是AI编程的瓶颈早就不是模型能不能写代码而是组织生产节奏的纪律能不能跟上。8万星标意味着这套思路被足够多的人验证过值得你花一个下午认真接一次。如果你准备上手我给一个最直接的建议不要贪多先挑一个小模块、配三个技能包、跑通一次带检查点的重构任务然后把体验拿回团队里讨论。AI编程的未来一定不是人跟AI单挑而是人和AI、AI和AI在一个有秩序的系统里协作。有秩序这件事恰恰是Superpowers这类工具最打动我的地方。