把整套瀑布式开发流程封装成 skill 后，简单改动也要走需求、方案、测试的完整链路，耗时又烧 token。本文梳理这类重型 skill 的适用边界、常见吐槽背后的真实原因，并给出用 AGENTS.md 自建轻量流程、按需触发子技能、大小任务分流的具体做法与检查清单。
问题：流程很规范，但改一行代码也要十几分钟
AI 编码工具成熟之后，社区里流行起一类"把开发流程固化成技能"的做法：先澄清需求，再写方案文档，再拆任务、写测试，最后才动代码。superpowers 是这类方案里流传较广的一个，它把一整套偏瀑布式的流程打包成可被模型自动调用的 skill。
争议也由此而来。一部分人发现：装上之后哪怕只是改个字段名、调个样式，模型也会按部就班地先出方案、再补测试，一个本来两分钟的事情拖到十几分钟，token 消耗成倍上涨；卸载后只在 AGENTS.md 里写清楚自己的开发习惯，速度立刻回来。另一部分人则认为，正是这套流程让模型在开发过程中留下可追溯的文档，后续扩展功能时有据可依，不至于几个月后只能靠口述需求让模型打补丁，最后堆成屎山。
两种说法都不算错，分歧的核心其实是一件事：任务复杂度与流程重量是否匹配。下面把这类重型 skill 的定位、成本来源和替代做法拆开讲。
重型 skill 本质上在模拟什么
这类工具通常覆盖一条完整链路：需求头脑风暴 → 规格说明 → 实现计划 → 测试先行 → 编码 → 评审。它的隐含假设是：
- 有多个协作者，需要文档对齐；
- 项目要长期维护，历史决策需要留档；
- 代码规范较严，改动必须附带测试。
这些假设在团队项目里成立，但在个人项目、小工具、单人维护的脚本里大部分不成立。当流程被默认注入到每一次对话中，哪怕只改一个判断条件，也要先走一遍"方案评审"，成本自然高得离谱。
觉得"太重"的三个真实原因
1. 固定开销不随任务缩放
流程长度是恒定的，任务难度是浮动的。小改动被套上大流程，多出来的每一步都是纯损耗。
2. 上下文腐败
中间产物（需求稿、方案稿、任务清单）会持续占据上下文窗口，模型容易在自己的文档里绕圈，甚至被早期写下的、后来已经作废的方案带偏，输出质量反而下降。
3. 触发不可控
很多 skill 的匹配范围很宽，几乎任何带"开发"意味的描述都会命中，于是"想直接干"的场景也被拦下来先走流程。想快的时候快不起来，是体验落差最大的地方。
另外一类抱怨和使用体验无关，纯粹是资源问题：跑测试、跑构建时把本地 CPU 长时间拉满，机器卡到无法同时做别的事。这种情况需要从执行环境上解决，而不是调整 prompt。
什么场景仍然值得用
不要一刀切卸载。以下场景重型流程的收益是正的：
- 从 0 到 1 搭建中大型项目或 MVP：需求本身模糊，头脑风暴和规格梳理能显著减少返工；
- 需要交付文档的团队协作：流程产物本身就是交付物；
- 长期维护的核心模块：开发历程文档能让后续重构有依据，这部分价值只有在时间拉长后才显现；
- 监管或规范要求测试覆盖的代码。
判断标准可以简化成一句：这次改动之后，你还会在同一个地方反复改很多次吗？ 会，就走流程；不会，就直接改。
更轻的做法：把工作流写进 AGENTS.md
对个人项目来说，性价比最高的方案往往是把流程约定写进项目根目录的 AGENTS.md（Claude Code 生态里对应 CLAUDE.md），让模型每次都在同一套稳定前提下工作，而不必加载一整套外部技能。
建议至少写清楚这几块：
- 技术栈与目录约定：语言版本、框架、新增文件放在哪；
- 常用命令：安装、启动、构建、测试、lint，一条一条列全；
- 改动分级：什么情况必须先给方案等你确认，什么情况直接动手；
- 测试策略：默认只跑受影响范围的测试，不要求全量；
- 禁止事项：不新建多余文档、不擅自加依赖、不改无关文件、不重排格式；
- 提交规范：分支命名、commit message 格式。
一个最小示例：
## 开发约定
- 单文件或局部小改：直接修改，不需要写方案和测试，改完给出 diff 说明
- 涉及跨模块或新增接口：先给 3 行以内的方案，等我确认再动手
- 新增依赖必须先问
- 测试只跑与改动相关的用例，命令：pnpm test -- <path>
- 不要自动创建 README、CHANGELOG 或总结文档
这类文件的价值在于它描述的是你的习惯，而不是某个作者的工作流。别人写的大型 skill 可以读，用来参考思路，但直接复用通常不划算——它的抽象层级、命名习惯、测试偏好都和你不一样。
折中方案：按需触发而不是全局加载
如果不想完全放弃流程，可以保留能力但改成显式调用：
- 只装最常用的子技能。多数人只保留头脑风暴或需求澄清这一个环节，其余全部关掉。
- 手动指定跳过阶段。在指令里明确"跳过 TDD 和方案，直接实现，最后补最小验证"。
- 不用时禁用插件，而不是留着靠模型自己判断要不要用。
- 一份任务分流表贴在项目里，让模型按表执行，减少每次重新解释。
| 任务类型 | 建议做法 |
|---|---|
| 改文案、改样式、单文件小修 | 直接说需求，不要流程 |
| 单模块 bug 修复 | 直接改 + 最小验证 |
| 一到两天的新功能 | 方案确认（plan 或头脑风暴）后直接实现 |
| 新项目、MVP、大重构 | 完整流程或自建的分阶段流程 |
注意事项
- 模型能力在变，结论会过期。新版本模型对复杂指令的理解更好，外部流程的边际收益在下降，但同时它的默认输出风格也可能变化。任何"装了更快/更慢"的判断，最好自己在固定任务上对比一轮再定，不要照搬别人的结论。
- 文档沉淀的价值不要忽略。如果你做的是要维护一两年的项目，删掉流程前先想清楚：以后靠什么复原当初的设计意图。可以只保留一个极简的决策记录文件。
- 长跑任务换环境而不是换 prompt。跑测试、编译、批量生成把本地机器占满时，调 prompt 没有意义。这类场景可以考虑把长跑任务放到一台常驻的远程 Mac 上执行，远程连接使用，本地继续开发，两者互不干扰——整机放在新加坡机房、按月租用的方案就是其中一种选择，适合需要长时间在线挂着 AI 工具的情况。是否值得取决于你被打断的频率。
- 合规提醒：共享或买卖账号、绕过平台使用限制这类做法带来的封禁与数据风险远大于省下的成本，不建议尝试。
- 时效性：各家插件、技能包和模型版本迭代很快，具体的行为差异请以官方文档和你自己的实测为准。
小结
重型 skill 不是没用，而是不该无条件启用。它解决的是"多人协作 + 长期维护 + 严格规范"的问题，个人项目直接套用，付出的 token 和时间换不回等价收益。更稳的路径是：把开发习惯写进 AGENTS.md，让模型默认走轻量路线；只在真正复杂、需要留档的任务上显式打开完整流程。先按任务分流表跑一周，再决定要不要卸载或保留。