没有流程的时候，Agent 的产出有一种特别的质感：很快，很整齐，而且错得很彻底。
你说「给博客加一个标签筛选」，十分钟后它给你 400 行代码、一个能跑通的分支、一段漂亮的说明。三天后你发现它做的不是你要的东西——它把筛选做成了搜索框，因为它从没问过你要哪种。
问题不在能力，在它跳过了「确认」这一步。Superpowers 是我用来补这一步的东西：一套可以组合的技能加一条入口规则，专门约束 Agent「先走流程，再动手」。
它做的事情很朴素
它不是又一个 Agent 框架，也不换模型。装好之后，Agent 在收到任务时会先判断「这件事属于哪个流程」，然后按那个流程走：先澄清，再设计，再计划，再实现，最后验证和收尾。
听起来像废话，差别在于它是被写死的规则，而不是靠你每次提醒。
入口那条规则
整个包最能说明性格的是它最开头那段话：
If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.
接着它明确写了「技能检查要在提问之前、看代码之前、查文件之前」。这句话堵掉的是 Agent 最常用的一类借口：先了解上下文。
它防的是合理化，不是能力不足
这套东西里我最喜欢一个叫 Red Flags 的表，列的是「你说这些话时，其实是在给自己找理由跳过流程」。原文几条，翻译过来大意是：
- 「这只是个简单问题」——问题也是任务，先检查。
- 「我需要先看代码才能判断」——看代码的方法也在技能里。
- 「这个技能太重了」——简单的事最容易变复杂。
- 「我记得这个技能」——技能会变，读当前版本。
这些话我在自己身上也见过。它们不是谎言，是「省事的冲动」穿上了理性的外衣。把这层外衣写下来，Agent 就很难再穿它。
七步，每步都要有产物
完整流程是七步，重点不在步数，而在每一步都留下可以检查的东西：
| 步骤 | 留下的产物 |
|---|---|
| 需求澄清 | 一份写清边界与备选方案的设计文档 |
| 隔离工作区 | 独立分支与工作区，测试基线跑过 |
| 编写计划 | 拆到文件级的任务卡，每张带验证方式 |
| 执行计划 | 每个任务可被单独审查的实现 |
| 测试先行 | RED 到 GREEN 的过程证据 |
| 代码审查 | 独立的审查意见，而不是自查 |
| 分支收尾 | 合并、清理或放弃的明确决定 |
这张表最实用的一点是：任何一步没产物，就说明那一步没做。Agent 很擅长「口头完成」，而产物不接受口头。
两条原则顶得上十段提示词
证据优于声明。 说「做完了」不算数，命令输出、截图、测试结果才算。我现在的验收习惯是先看它跑过什么，再看它说了什么。
流程优于猜测。 不确定的时候不要猜，去跑一次。这条对 Agent 尤其重要，因为猜测对它是零成本的——它不需要为猜错付出时间，你需要。
跳过流程的代价
跳过前两步，代价通常不在写代码的那一刻，而在验收的那一刻。
Agent 会给你一个「看起来对」的实现：命名对、分层对、边界没处理。你验收时发现方向偏了，于是回到需求讨论——这一步本来该在写第一行代码之前发生。
我后来把这类返工叫做「延迟的需求会」。它不是白花的钱，是提前透支的时间，最后连本带利还回来。
什么时候该缩短
七步不是宗教。改一个错别字、调一段文案、整理一份素材，走完整流程纯属浪费。规则里也写了更重要的一条：用户的直接指令优先于技能。
我的轻量档只保留两步：写清楚「改哪个文件、怎么验证」，以及做完之后「看输出」。前者防跑偏，后者防自我感动。中间的设计和计划环节，在改动范围小于一个函数时可以省。
判断标准很简单：这次改动如果错了，我是当场能看出来，还是三天后才发现？当场能看出来的，走轻量档；三天后才发现的，老老实实走完。
收尾
流程的价值不是让 Agent 变慢，是把返工成本往前挪。挪到需求讨论阶段，一次对话就能改掉；挪到代码阶段，就是一次重写；挪到上线之后，就是一次事故。
我现在的做法是：小改动靠轻量档，涉及接口、数据结构或者多人协作的改动，一律走完整流程。慢下来的那半小时，基本上都省在后面了。