这不是一篇讨伐 Superpowers 的文章。它讨论的是：当 AI 越来越聪明，我们是否还应该让一套为“防止 AI 犯错”而设计的重流程，默认接管每一次开发？我的答案是：不应该。真正需要保留的不是笼子，而是边界、证据和方向。
一切从“轻量替代”开始
RSP 最初叫 Rules, Specs, Plans。
它的目标很简单：我想要一个比 spec-kit 和 OpenSpec 更轻的替代方案。
我认同 Spec 驱动开发的价值。需求不应该只存在于聊天窗口里，设计不能随着上下文压缩消失，任务完成以后也应该留下可以恢复的项目知识。但我不想为了获得这些能力，再引入一套庞大的目录、复杂的状态机和沉重的仪式。
所以早期的 RSP 只关心几件事：
- 用普通 Markdown 保存规则、规格和计划；
- 用单文件 Change 描述一项正在进行的工作；
- 把当前工作、持久事实和已完成历史分开；
- 让人和 AI 都能直接读懂仓库里的状态；
- 不依赖某一个编辑器、模型或平台。
那时的 RSP，本质上还是一个轻量的 Spec 工具。它解决的是“信息放在哪里”，还没有完整回答“日常开发应该怎样推进”。
Matt Skills 填上了日常开发的空白
真正进入日常开发后，我开始大量使用 Matt Pocock 的相关 Skills，同时维护自己的 engineering-flow、local-issues 等工作流。
这套方式很好用。
诊断问题时加载诊断 Skill，需要测试驱动时加载 TDD，需要设计时加载领域建模或代码库设计。每个 Skill 都像一张短小的操作卡片：关注一个问题，给出一组有效提醒，然后把工作交还给 AI。
相比完整框架，这种方式更贴近日常开发。它不要求每一次修改都走同一条流水线，也允许我按任务选择能力。对当时的我来说，它比大型 Spec 系统更灵活，也比只靠一份 AGENTS.md 更可靠。
但使用时间长了以后，问题也出现了。
Matt 风格的 Skills 更像一组优秀的工程习惯，而不是一套完整的项目协议。单个 Skill 可以很清楚，多个 Skill、项目规则、自定义工作流和宿主行为叠加以后，却容易发生漂移：
- 这次先写计划，下次直接实现；
- 一个项目要求测试优先，另一个项目只在出错后补测试；
- 任务、设计、验证和提交分别留下了记录，却没有同一个持久 owner；
- 当前会话知道做到哪里，换一个会话以后却需要重新拼接上下文；
- Skill 可以给建议，但很难稳定区分修改代码、归档、提交、推送和发布这些不同权限。
规则不是不够多，而是缺少一个足够小、足够稳定的骨架，把它们组织起来。
Superpowers 解决了纪律，却带来了流程税
Superpowers 代表了另一个方向：既然 AI 容易跳步、偷懒和过早宣布完成，那就把流程写得更完整、更强制。
它强调先澄清、再规划、按步骤执行、测试、验证、审查和收尾。这些原则本身没有错。事实上，RSP 的实现 Skill 也明确吸收了 Superpowers 中“完成前必须进行新鲜验证”的思想。
问题出在：当整套流程成为所有任务的默认入口，纪律就会变成流程税。
一个边界明确的小改动，可能也要经历一轮完整的讨论、计划和检查。AI 明明已经从仓库中获得了足够证据，却仍然需要按照预设步骤证明自己没有跳步。任务越简单，流程成本占比越高；模型能力越强，这种固定流程带来的摩擦越明显。
更重要的是，重流程经常把“正确地工作”误解为“完整地执行流程”。
但软件开发不是流水线。排障、设计、实现、迁移、发布和一次 CSS 调整，本来就不应该拥有同样的步骤。一个优秀的工作流应该根据风险和证据改变形状，而不是要求所有工作穿过同一个模具。
这也是我最终选择卸载 Superpowers 的原因：不是因为它没有价值，而是因为我不再希望它拥有日常开发的默认接管权。
RSP 3.x：从 Spec 工具变成可恢复的本地工作流
RSP 3.x 的变化，不是给早期 RSP 添加更多命令，而是重新定义它要解决的问题。
RSP 不再只代表 Rules、Specs、Plans，而是 Reliable Software Practice。
它仍然保留轻量的仓库原生产物，但目标已经变成一套完整、可恢复的本地工程工作流：
- 模糊需求先被塑造成有边界的 Change；
- 当前工作拥有明确的 WorkRef 和唯一归属；
- 设计、诊断、TDD、实现、审查和发布文档由独立 Skills 按需参与；
- 当前事实、长期理由、项目指令和完成历史分别写回正确位置；
- 中断后从仓库文件和新鲜证据恢复，而不是依赖某个会话记住一切；
- 修改、归档、提交、推送、发布和人工验收保持不同的权限边界；
- 小任务直接执行，只有长任务、多阶段任务或恢复场景才进入受管流程。
它比 Matt 风格的松散规则更严谨，因为项目状态、工作归属、恢复路径和权限边界都有稳定协议。
它又比 Superpowers 更精简，因为 RSP 不要求每项任务经过一条完整流水线。Change 仍然是单个 Markdown 文件，Group 只有浅层结构，受管协调不是无条件控制器，也不会保存一套隐藏的第二状态。
RSP 约束的是那些真正容易造成漂移的地方：
- 现在到底在做什么；
- 谁拥有这个结果；
- 哪些事实已经被验证；
- 中断以后从哪里继续；
- 哪一步需要新的权限。
至于 AI 应该怎样思考、先读哪几行代码、是否需要写一个临时测试，则交给当前任务、仓库证据和对应 Skill 决定。
AI 越聪明，越不应该被关进笼子
很多 AI 工作流诞生于模型能力更弱的阶段。
那时 AI 容易忘记上下文、跳过验证、擅自扩大范围，也经常在没有证据时宣布完成。给它更多步骤、更严格的检查表，是一种自然的应对方式。
但 AI 的发展速度远快于工作流文档的更新速度。
如果我们把某一代模型的缺陷永久写成所有模型都必须遵守的流程，工作流很快就会从安全网变成天花板。模型已经能理解代码、识别风险、选择验证方式，我们却仍然要求它逐项表演一套为过去能力设计的仪式。
我越来越相信，未来的 AI 工程工作流应该从“控制每一步”转向“引导关键决策”。
需要严格限制的，是不可逆和高风险边界：
- 不覆盖用户已有改动；
- 不在没有授权时提交、推送、发布或部署；
- 不用旧验证冒充当前结果；
- 不把猜测写成持久事实；
- 不在 owner 不明确时继续扩大修改。
而在这些边界之内，应该允许 AI 根据任务规模、代码证据和风险自由选择路径。
好的工作流不是一条铺好的铁轨，而是一张清楚的地图：它告诉 AI 目标在哪里、悬崖在哪里、走过的路如何留下标记，但不规定每一步必须先迈左脚。
所以，你应该卸载 Superpowers 吗？
如果你刚开始使用 AI 编程，或者团队缺少基本工程纪律，Superpowers 仍然是一套很有价值的训练轮。它能让“先理解、再行动、完成前验证”变成稳定习惯。
但如果它已经全局接管你的每一次开发，让简单任务也不断支付流程成本，那么你应该认真考虑卸载它，或者至少取消它的默认激活。
保留其中真正有效的原则，把它们蒸馏成更小的 Skills、项目边界和验证规则；把持久状态交给仓库，把高风险动作交给明确授权，把具体执行重新交还给 AI。
我卸载的不是 Superpowers 的原则，而是它对流程的默认控制权。
RSP 3.x 想做的，正是这件事：不把 AI 关进笼子，而是给它一套可以看见边界、留下证据、随时恢复的本地工作方式。
AI 越来越聪明以后，我们真正需要设计的，不是更坚固的笼子，而是更好的引导。
项目与上游
RSP 不是把某一个上游工作流换个名字重新发布。下面这些项目承担的是不同的研究职责：RSP 从中提取有用机制，再根据自己的单文件 Change、持久 owner、显式权限和低认知负担目标重新实现。除明确声明的适配内容外，它们都不是 RSP 的运行时依赖。
产物模型与工作协议
- Spec Kit：提供 Spec 驱动开发的产物依赖、质量门禁和分层工作流参考。RSP 保留明确的意图、设计、任务和验证归属，但拒绝把多文件 feature 目录和完整工作流引擎作为默认结构。
- OpenSpec：提供“当前事实”和“进行中的变更”分离、变更归档与事实提升的领域模型参考。RSP 从中强化 Specs、Changes 和 Archives 的边界，但坚持单文件 Change 与语义化写回。
- Agent Skills Specification：负责 RSP Skills 的可移植目录、
SKILL.mdfrontmatter 和渐进加载兼容性，不负责定义 RSP 的工程流程。
工程 Discipline Skills
- Matt Pocock Skills：RSP 日常工程能力最主要的蒸馏来源，提供小型、可组合、按需加载的 Discipline Skill 模型。
ask-matt→ RSP Core 的按需能力路由grill-with-docs、grill-me、grilling→rsp-shapecodebase-design、domain-modeling、prototype→rsp-designdiagnosing-bugs→rsp-diagnosetdd→rsp-tddimplement→rsp-implementcode-review→rsp-review
- Superpowers：提供严格验证、Skill 行为测试、独立 TDD/诊断纪律和有边界的子智能体交接参考，同时也是“完整方法默认接管一切”这一设计取舍的对照组。
verification-before-completion→rsp-implement的新鲜验证纪律test-driven-development、systematic-debugging→ TDD 与诊断必须保持独立能力requesting-code-review、subagent-driven-development→ 固定审查范围、明确交接和停止边界
- Compound Engineering：负责候选 Skill 从 beta 到稳定的晋级机制、跨 Skill 输入输出契约、多轮审查与跨宿主行为测试参考。
受管执行与中断恢复
- GSD Core：提供复杂任务的分阶段执行、新鲜上下文智能体、上下文预算和可选高自治控制器参考。RSP 只把这些机制用于符合条件的 Manage 场景，不把完整阶段循环强加给小任务。
- Planning with Files：提供磁盘工作记忆、中断恢复、有界继续和进度证据参考。RSP 明确区分这类临时控制器状态与 Change、Spec、Decision Record 等持久事实。
克制、简化与评估
- Ponytail：提供反过度设计的判断阶梯，以及隔离环境、确定性门禁、成本和上下文开销等 Skill 评估方法。
- Andrej Karpathy Skills：提供“先思考、保持简单、手术式修改、目标驱动”的简洁行为词汇与正反例。它是第三方整理，并非 Andrej Karpathy 的官方仓库。
来源治理与分发
- Antfu Skills：提供手写、生成和 vendored Skills 的来源分类、许可证与 provenance 治理，以及按需加载的目录组织参考。
- Skills CLI：提供跨宿主 Skill 发现、安装、更新、内容哈希、来源锁定和 canonical copy 投影参考。
- OpenAI Plugins：提供 Plugin 作为 Skills、Apps、MCP 和资源的可选分发外壳参考。RSP 不把 Plugin 当作每项能力或项目工作流的默认单位。