最近我把大量编码工作交给 Claude Code 之后最大的收获不是效率翻倍而是一种新的焦虑它太“自由”了。有一次我只是让它给列表排序它却顺手把我整个数据层的公共接口改了一轮还“贴心”地加了个抽象层。测试全绿同事 code review 时却看傻了——这个提交的范围彻底失控了。后来我引入了一个叫 Superpowers 的开源项目这类问题才被真正压下去。它解决的事一句话就讲得清给 AI 编程装上“纪律引擎”。Superpowers 运行在 Claude Code、OpenCode 这类 Agent 宿主上本质是一套 Skills 集合。说直白点它把一名成熟工程师的工作习惯——先想清楚再动手、按计划执行、默认写测试、主动自我评审——固化成 Agent 能调用的“职业素养”。装上它之后AI 不再凭直觉自由发挥而是按工程规范逐步推进。这篇文章分享四件事为什么 Agent 会失控、Superpowers 解决问题的原理、我实际的安装与使用流程以及项目实战中踩过的坑。适合已经在用 AI 编程、却始终觉得“AI 写代码像开盲盒”的开发者。1. 当 Agent 开始“自由发挥”AI 编程失控的真实场景1.1 一次让自己后背发凉的“超预期交付”我先说一个真实事故这几乎是我决定研究 Superpowers 的直接导火索。项目里有个订单模块我想让 Claude Code 补一个“订单号降序排序”的小功能顺手把分页参数也处理一下。结果它不止做了这些还顺带把订单状态枚举从字符串常量改成了 TypeScript 联合类型把所有用到的页面统一改了又抽出了一个公共的 QueryBuilder 基类。测试确实全部通过了编译也过了代码风格还挺像那么回事。但问题出在交付节奏上这个改动不是我们这轮迭代的范围把原本只需要两小时就能合入的小功能变成了一场波及十余个文件的“重构事故”。走到 code review 那一步同事直接问“这是谁的需求” 我当时的感受是AI 执行指令时缺少最基本的“边界感”。这种“超预期交付”最可怕的地方在于它的结果表面上是合理的。测试过了样式没乱逻辑看起来更优雅了。但它没有告诉你它改了公共接口、动了别人的模块、引入了你并没有要求的抽象。真正的工程协作里这些恰恰是需要人来拍板的部分。1.2 自由发挥的三个典型症状这种事情遇到多了我总结出 AI 自由发挥的三个高频症状。第一是范围蔓延。让它做 A它顺手把 B、C 也改了而且这些改动经常埋在其他文件里不主动汇报。第二是名义遵从。它确实写了测试但测试更多是为了“有测试”断言覆盖不到关键业务分支你不敢真的靠这批测试做回归。第三是无痕迹重构。它把代码结构调整了变量名统一了但改动列表里看不到直接的“为什么”等你想回滚时发现它把多个逻辑混在同一个提交里。我用一个表把这三种症状讲清楚症状典型表现为什么难以发现容易引发的后果范围蔓延顺带重构、改接口、动依赖测试通过行为变化隐蔽提交范围失控评审成本暴涨名义遵从测试存在但断言失真只看到绿勾不看断言质量回归安全网失效出问题只能人肉排查无痕迹重构结构变化缺乏解释代码更“干净”反而掩盖原因回滚困难Git 历史失真这三种症状背后是同一个问题Agent 没有把“工程规范”当作行为约束而是把所有请求都当成一道开放题来解。1.3 问题的根因LLM 没有“工程记忆”我很长一段时间以为问题是模型能力不行换更强的大模型就能好。后来发现不是。LLM 本身就没有“工程记忆”这种东西。它每轮对话都像一个刚入职、能力很强但完全不了解团队历史的实习生能写很漂亮的代码但不知道这个模块为什么长成这样、哪些约定是红线、上一次因为改公共接口出了什么事故。加上上下文窗口有限它连“这个仓库一共有哪些约束”都未必能完整看到。更麻烦的是大模型天然有“讨好用户”的倾向。你让它加个排序它会默认你想让代码“更好”于是把能优化的一起优化掉。这不是恶意而是它在概率上选择了最“像优秀工程师会做的事”的输出。问题是真正的优秀工程师知道什么时候不动手这套判断力来自长年累月的工程记忆而不是来自一次提示词。既然模型本身没有记忆和纪律那就得靠外部给它补。Superpowers 的切入点恰好就在这里它不是靠人反复在提示词里说“你小心点、别乱改”而是用一套可加载的技能和规则把工程规范变成 Agent 的默认行为模式。2. Superpowers 的本质一套给 Agent 预设的“职业素养”SKILL2.1 先搞懂 SKILLS 机制Agent 的行为模板要理解 Superpowers必须先从 SKILL 机制说起。拿 Claude Code 举例它支持通过 Skills 目录给 Agent 定义“能力包”。每个 Skill 通常是一个目录里面有一个 SKILL.md 文件描述这个技能什么时候该用、该怎么用可能还有辅助脚本、参考文档、示例代码。Agent 在会话中会读取并遵循这些说明就像实习生领到一本“工作手册”。手动把工作手册内容打出来不现实而且每开一次会话就要人重复一遍也很蠢。Skill 机制的聪明之处在于把经验沉淀成文件随会话自动加载或在需要时按名调用。你可以把某个 Skill 看作“特定场景下的行为模板”触发调试时Agent 就按调试 Skill 里的步骤走要写计划时就按计划 Skill 的框架输出。这个机制本身是通用的但能不能发挥价值取决于你往里面放了什么内容。如果你只放一句“请写高质量代码”那和没放没有区别如果你放的是“动手前必须输出实施计划、变更影响范围和回滚方案”Agent 的行为才会真的变化。Superpowers 做的就是后者。2.2 Superpowers 到底装了些什么Superpowers 本质是一个精心组织的 Skills 集合同时附带一些规则和辅助脚本。我自己用的版本里最明显的是几类组成。一类是规划类技能。需求模糊时它会引导 Agent 先提问澄清先输出一个简洁的计划再动工。另一类是执行类技能重点是任务拆解、测试先行和变更实施。还有一类是检查类技能包括自我代码审查、安全审查、Bug 定位与修复这些原本需要人来盯的环节被固化成 Agent 自己会走的流程。最后是规则层它可以给不同层级写入约束例如项目级规则和用户级规则用来承载团队风格、禁止事项和验收标准。我把这些构成列一下方便你建立整体印象规划类澄清需求、编写实施计划、评估影响范围执行类任务拆解、测试驱动开发、按计划逐步实施检查类自我代码评审、调试方法论、安全与风险审查规则类项目级规则、用户级偏好、工作流协议具体到项目里它并不是靠某一个“大招”起效而是靠这些技能的组合。比如我拿到一个需求后Agent 会先进入澄清模式把模糊点问清楚然后产出计划列出改动文件和风险实施过程中默认用 TDD 写测试全部做完再触发一轮自我评审。这套组合拳正好覆盖了前面说的三种自由发挥症状。2.3 为什么叫“Superpowers”而不是“规则文件”项目起名很有意思。它不叫“Rules”、不叫“Constraints”而是叫“Superpowers”这其实是一套设计哲学。纯粹的规则文件强调的是“禁止什么”比如“不允许重构无关代码”“必须先写测试”。这种约束方式对 Agent 有效但并不稳定因为模型很容易在表面遵守规则的同时用各种方式绕过规则的意图。Superpowers 的思路反过来它强调的是“赋予什么能力”。不是告诉 AI“你不准乱写”而是让它具备“先规划、再测试、后实施、会自查”的工程能力。当 Agent 拥有了这些能力很多“自由发挥”问题就不再是需要禁止的错误而是它自己会绕开的低水平行为。举个好理解的类比你管一个实习生天天跟他说“不要自作主张”他大概率还是会出错因为你没有给他替代方案但你教会他正规的需求评审、方案设计和测试流程他自然会按流程走因为流程本身能帮他降低返工风险、减少背锅概率。Superpowers 就是把这套“职业素养”教给 Agent而不是像监工一样盯在它旁边。这也是我更愿意推荐它的原因——它的目标不是限制 AI而是让 AI 变得更像一名合格的工程师。3. 把纪律引擎装进 Claude Code安装与环境准备3.1 前置条件先打好 Agent 宿主和运行环境安装之前先确认机器上有几样基础东西。第一个是 Agent 宿主本身我主力用的是 Claude Code后面也拿 OpenCode 跑过同样的技能集问题不大。第二个是 Node.js 运行环境版本建议装 LTS 版。Superpowers 的辅助脚本基本都跑在 Node 上环境不对会直接报错。第三个是 Git这个大家应该都有主要用于拉取技能仓库。还有一点容易被忽略纪律引擎是给“现有工作流”加约束的所以最好等你的 Agent 已经能正常跑通日常任务后再上 Superpowers。如果 Claude Code 本身连工具调用都不稳定装再多的技能也只是叠 buff排查问题时反而分不清是宿主问题还是技能问题。3.2 两种主流安装方式我安装的时候主要试过两种方式。第一种是通过插件市场直接安装。在 Claude Code 的会话里执行插件市场添加命令把 Superpowers 这个仓库加进去然后再安装到当前项目或全局。这样后续更新比较方便官方发新版本一个命令就能拉下来。第二种方式更“野”一点手动从 GitHub 仓库克隆到本地的插件目录。这种方式的好处是你可以直接翻它的源码看到每个 Skill 到底写了什么理解它的触发条件和工作流设计也方便按自己的习惯改。缺点是更新要自己处理每次都要手动拉仓库不太适合只想开箱即用的人。我一开始图省事用这种方式后来切回插件市场管理原因就是更新太麻烦。具体命令我就不贴死版本了因为这类项目迭代很快以仓库里的 README 为准。但无论哪种方式装完都必须重启 Agent 会话让技能在全新上下文中被加载不然会出现“明明装了却看不到”的假象。提示安装 Superpowers 前建议先看一眼它的工作流设计尤其是否依赖 OpenSpec 之类的规范工具。因为技能之间是有上下游关系的只装一半可能导致 Agent 在某个环节找不到对应工具而卡住。3.3 验证纪律引擎是否真的生效装完之后别急着写业务代码先花五分钟验证它真的生效了。最简单的办法是让 Agent 列出当前可用的技能列表# 在 Claude Code 会话中列出已加载的插件或技能 /plugin # 或者直接让 Agent 描述自身能力 请列出你当前已加载的所有 skills以及每个 skill 的一句话说明能列出就说明框架加载成功。但“加载成功”不等于“行为改变”我还会做一个更实际的测试随便给一个很小的编码需求比如写一个日期格式化函数。没有装 Superpowers 之前Claude Code 大概率会直接给代码。装了之后你应该会看到它先输出一个简短计划说明要创建什么文件、测试怎么写然后再动手。如果它还是直接一把梭写完整段代码那就要检查技能是不是被项目级配置屏蔽了或者某个规则冲突把它绕过去了。另外可以在会话日志里观察技能调用的痕迹。Claude Code 的调试日志会记录技能文件被读取、脚本被执行的情况翻一下就能确认哪些 Skill 真正被触发了。这个习惯非常有用后面调优的时候基本全靠它判断“哪个技能没生效”。4. 核心工作流拆解从“自由发挥”到“工程规范”的四个转变4.1 先写计划再动代码从“条件反射”到“实施协议”装上 Superpowers 之后最直观的变化是对话模式的改变。过去我给需求Agent 直接吐代码现在它默认先把需求拆一遍输出一份简短的实施计划说明要动哪些文件、有什么风险、打算怎么验证。刚开始我觉得这是“多此一举”用久了才意识到这才是真正的效率杠杆。因为计划一旦落到文本里我就可以在动手前纠偏。很多问题在计划阶段暴露出来成本几乎为零等代码写完再返工那才是真正烧时间。比如有一次它计划里写着“修改公共的 HTTP 封装层”我一看就知道这超出了本轮需求当场让它把方案收敛掉避免了一场潜在的范围蔓延。这套机制的精髓在于它不是强制我浪费时间而是把“决策点”前移。人只需要在计划上做确认剩下的执行还是交给 Agent整体速度反而更快。4.2 TDD 变成默认动作让 AI 先写测试再写实现第二个明显变化是测试态度。过去 Claude Code 也写测试但更像是“交差式测试”核心功能跑通了边界条件随便盖一盖。Superpowers 把测试驱动开发变成默认动作后流程变成了先根据接口设计写测试再写实现代码去满足测试。这么做有非常实际的好处测试先行会逼迫 Agent 先把接口契约定义清楚。很多时候 AI 写的实现让人不放心是因为接口是在实现过程中“长”出来的逻辑混在一起。先写测试接口就变得明确实现和验证被清晰分开。而且测试一旦覆盖关键路径后续改需求时回归底气足很多。我用下来发现对 AI 来说TDD 还有一个“纪律价值”它天然抑制了范围蔓延。因为测试先定义了本轮要做什么Agent 再多做的部分无法被这些测试覆盖它自己就会意识到“这不是该做的事”。4.3 需求变更走“变更协议”不再中途翻车第三个转变是需求变更时的表现。没有纪律时中途加需求的典型场景是我随口说一句“顺便把导出功能也做了”Agent 立刻在当前会话里动手改代码改到一半发现和前面的设计冲突然后整个对话开始走向失控。有了 Superpowers 这套机制后同样的诉求会走一遍变更协议先评估影响再更新计划然后才动代码。Agent 会先判断这个变更涉及哪些文件、要不要改数据结构、是否需要迁移、测试要补哪些。这些信息整理完它会带着方案回来找我确认而不是直接闷头改。这背后是工程里的“变更管理”思想。需求变更本身不可怕可怕的是在错误的时机、以错误的方式混入正在进行的开发。让 Agent 把“变更”作为一个独立事件来处理整个项目的可控性会高一个量级。4.4 留下可追溯的工程痕迹第四个转变也是最容易被忽视的Agent 的执行过程开始留下可追溯的痕迹。过去 AI 一通改提交信息写得天花乱坠但你永远不知道这个决策是怎么来的。现在它的计划、确认、变更说明都在对话流里代码评审时可以回看团队同步时可以引用。配合 OpenSpec 这类规范工具时这种痕迹会进一步沉淀成项目文档。需求是什么、方案是什么、为什么改成这样不再是 AI 脑内的一闪而过而是可查阅的工程记录。这一点在团队协作里价值极大——AI 写的代码最终要由人来维护人能看到“决策过程”才敢放心接手。5. 实战用 Superpowers 约束一个全栈项目交付5.1 三件套的职责划分执行器、需求规范与行为纪律实际项目里我很少只靠 Superpowers 单打独斗而是采用一套组合Claude Code 做执行器负责实际编码和工具调用OpenSpec 做需求规范把需求拆成可跟踪的规格文档Superpowers 做行为纪律约束 Agent 怎么工作和怎么保质量。三者角色清楚工具角色解决的核心问题Claude Code执行器理解并实现需求的基础能力OpenSpec需求规范需求模糊、范围蔓延、验收无标准Superpowers行为纪律不按流程、无测试、不做自查社区里有人把这一套叫“三件套实战”我很认同。因为它覆盖了工程交付最关键的三个环节做什么、怎么做、如何保证做成。5.2 启动项目时的固定动作我启动一个新的全栈项目时固定流程是这样的。第一步用 OpenSpec 把需求写成规格不是写长文档而是拆成一小块一小块的 spec每块说清楚现状、目标、约束和验收标准。第二步让 Claude Code 加载 Superpowers 相关的规划和需求澄清技能先读一遍规格输出实施计划。第三步人工确认计划然后按 TDD 流程开始开发。这个流程做到后面会形成肌肉记忆。Agent 读 spec产出计划我确认它写测试写实现跑测试自我评审提交。每一步都有明确的输入输出不再有“自由发挥”的空间。5.3 中途改需求纪律如何兜底全栈项目里最考验这套机制的是中途改需求。我印象很深的一次项目做到第二周产品临时要求把某个列表页从“服务端分页”改成“客户端分页本地搜索”。没有纪律引擎之前这种变更是灾难Agent 可能直接改前端代码、删掉后端分页接口等联调时才发现数据量一上来性能扛不住。这次 Superpowers 的处理方式完全不一样它先回到 OpenSpec 里更新对应 spec把变更影响面写出来包括后端接口保留、前端数据结构变化、搜索逻辑的复杂度评估。然后在计划里标注出“本次只做前端改造后端接口保持兼容”带着这份计划来问我“是否确认”。我确认后它按计划改了前端补了本地搜索的测试最后跑了一轮回归确认后端接口没有被误伤。整个过程很顺甚至可以说比人类工程师处理得还严谨。这一单让我彻底认可了这套机制。5.4 一次完整交付的复盘做完那个项目后我复盘了一下。最大的变化不是我“管”AI 管得更细了而是很多管理动作被前置到流程里。AI 的好处是它不知疲倦、执行速度快坏处是它没有判断“该不该做”的直觉。Superpowers 本质上就是补齐这个短板。项目交付时代码评审的通过率比以前高了很多。原因不是模型变强了而是每个提交的范围、测试、文档都对得上业务流程评审的人能看懂、敢合入。这让我相信AI 编程的真正分水岭不在模型参数而在工程流程上有没有约束。6. 实测中的坑与调优经验6.1 装了 Superpowers 不等于一劳永逸先泼一盆冷水。我一开始以为装了 SuperpowersAI 编程的质量问题就彻底解决了结果第一个星期就翻车。原因很有意思技能太多Agent 有点“表演性遵守”。具体表现是它确实走了计划流程但计划写得空洞全是套话测试也写了但覆盖的还是不痛不痒的路径。它看起来在遵守纪律实际上和以前一样自由发挥。这套系统真正的效力需要你在使用过程中不断调优而不是装完就不管。我的做法是按项目需要精简技能集。全栈项目只保留规划、TDD、代码评审、变更管理这几个核心技能去掉不相关的。技能文件本身也可以改把团队自己的编码规范、禁止事项写进规则里这样纪律引擎才会越来越贴合你的团队。6.2 不同宿主工具的兼容差异Superpowers 对宿主的兼容性比想象中好但不是零成本。我在 Claude Code 上跑得很顺切到 OpenCode 时发现技能加载方式、插件目录路径都不一样有些工作流脚本需要额外配置。如果你手上同时有多个 Agent 宿主别假设一套安装走天下。切宿主之后先跑一遍最小用例确认技能列表、规则读取、脚本执行都正常再进入真实项目。另外版本迭代也要留意宿主升级可能改变 Skill 加载逻辑导致之前能用的技能突然不触发了。6.3 让纪律引擎真正好用的三条建议最后分享几条我调优后的经验。第一条别贪多。技能不是越全越好真正有价值的技能就那么几个控制在能覆盖你项目核心路径的范围内。技能一多Agent 反而会选择合适的来表演而不是真正理解。第二条把人的经验写成规则。工具的默认行为是通用的你团队的“私有约定”必须自己写进去。比如接口命名规范、目录结构、禁用的依赖库写成项目级规则后Agent 才不会反复踩同一个坑。第三条定期翻日志。我会每周花十几分钟看 Agent 的执行日志重点看哪些技能被调用、哪些没触发、哪个环节人机反复确认最多。这些数据能告诉你流程哪里该收紧、哪里该放松。纪律引擎不是定死的它应该随着你对项目和团队的认知一起进化。我在实际项目里反复调了两三个月才让它进入“不需要我反复盯着”的状态。这个过程其实挺值得因为一旦 Agent 真正养成了工程规范它的产出质量、可维护性、协作顺畅度都和以前完全不是一个量级。AI 编程的上限由模型决定但下限很大程度由你给它设定的纪律决定。