篇一让 AI 守规矩，篇二让 AI 有记忆，但还有一层问题没解决：AI 完成同一类任务的"做法"本身是不稳定的。今天让它排查一个 bug，它一头扎进代码里改；明天类似的 bug 再来一次，它换了另一套思路，改完了事，中间该有的验证环节可能压根没走。规则管的是"不能做什么"，知识库管的是"项目是什么"，但"这类任务该按什么步骤做"，篇一篇二都没覆盖——这是工作方法论的问题。
一、先说痛点
1. 同一类任务，做法每次都不一样
排查一个线上问题，AI 这次直接改了个 if 判断就说修好了，下次遇到类似问题又去翻日志、加断点、写测试重现——不是说这些手段不对，而是完全没有章法，运气好蒙对了，运气不好改出一个新 bug。方法论不固定，结果的可靠性也就没法固定。
2. 需求没搞清楚就直接写代码
让 AI “加个退款功能”，它经常直接开始写 Controller、Service，写完一看才发现理解错了——退款到底是全额退还是支持部分退款，退款后订单状态该怎么变，这些没问清楚就动手，返工成本比多问两句高得多。
3. "做完了"全靠 AI 自己说
AI 说"已经修复"，但没有真的跑一遍测试；说"已经验证过"，但验证的只是代码能编译，不是逻辑对不对。宣称和事实之间没有强制的核对环节，全靠人事后发现问题。
4. 复杂任务缺少分解和检查点
一个稍微复杂点的任务，AI 容易一头做到尾、中途不回头看，出了偏差往往到最后才暴露，这时候已经改了一大堆代码，想回退或者调整方向的成本已经很高了。
二、解决方案：把工作方法论打包成可复用的技能
1. 每个技能只管一件事，别塞进越写越长的规则文件
篇一讲过规则文件不能无限膨胀，工作方法论更是不该往里塞——“怎么做需求澄清”“怎么系统化排查 bug”“怎么写一份靠谱的实施计划”，这些是完整的方法论，不是一两条规则能表达清楚的。合理的做法是把每一套方法论独立打包成一个"技能"模块，职责单一，用的时候整个加载，不用的时候不占上下文。
2. 触发要自动化，不能靠人记得去调用
技能包如果需要人手动敲命令才能触发，等于又把负担丢回给人。更好的设计是给每个技能配一段清晰的"适用场景"描述，AI 自己根据当前对话判断该不该用这个技能——你说"帮我加个功能"，它自己意识到这是需求不明确的场景，主动触发"先澄清"的技能，而不是等你明确说"用一下需求澄清技能"。
3. 技能要能串联成流程，而不是各自孤立
单个技能解决单个环节，但真正的价值在于能不能连起来：先澄清需求，澄清完自动进入"写实施计划"，计划写完自动进入"按计划执行、每个任务验证一次"。技能之间知道"我完成之后该交给谁"，才能撑起一整条从"提需求"到"交付代码"的流水线，而不是一堆互不相关的独立工具。
4. 别每个项目重新发明一遍，直接复用现成的技能库
这套"需求澄清 → 写计划 → 执行 → 验证"的方法论不是什么项目专属的秘密，业界已经有沉淀好的实现。superpowers（github.com/obra/superpowers，作者 Jesse Vincent，MIT 协议）就是一个真实的开源技能库，把 TDD、系统化调试、需求澄清（brainstorming）、写实施计划、按计划执行、代码评审等一整套方法论打包成可安装的技能包，覆盖 Claude Code、Codex、Cursor、Gemini CLI 等主流 AI 编码工具。下面教程直接用它落地。
三、动手教程：给 acme-order-service 装一套标准工作流程
步骤 1：一条指令安装
在 Cursor 的 Agent 对话框里直接输入：
/add-plugin superpowers
其他工具（Claude Code、Codex 等）也各有一条对应的安装指令，装好之后不需要额外配置，技能会在合适的场景自动触发。
步骤 2：看看技能长什么样
装完之后打开插件目录，会看到类似这样的结构：
superpowers/
└── skills/
├── brainstorming/
│ └── SKILL.md
├── writing-plans/
│ └── SKILL.md
├── systematic-debugging/
│ ├── SKILL.md
│ └── root-cause-tracing.md # 补充参考资料，非必需
└── …
每个技能的核心就是一份 SKILL.md，最上面是 YAML frontmatter：
—
name: brainstorming
description: "You MUST use this before any creative work – creating features, building components, adding functionality, or modifying behavior."
—
# Brainstorming Ideas Into Designs
…（具体的方法论步骤）
description 这一句话是关键——AI 会拿当前对话场景去匹配每个技能的 description，判断要不要主动用它，不需要你手动点名。
步骤 3：触发一次真实流程
在 acme-order-service 项目里跟 AI 说：“帮我加一个退款功能”。装了 superpowers 之后，正常情况下它不会立刻开始写代码，而是先问退款是全额还是部分、退款后订单状态怎么流转——这就是 brainstorming 技能被自动触发的表现。等需求澄清完、你确认设计之后，它才会转入写实施计划，再进入实际编码。跟没装技能包时"一上来就写"对比一下，能直接感受到差别。
步骤 4：写一个项目专属的自定义技能
superpowers 提供的是通用方法论，项目里如果有自己的专属流程，也可以照着同样的格式自己写一个。比如给 acme-order-service 写一个最小的自定义技能：
—
name: acme-refund-check
description: "Use when implementing or modifying refund-related logic in acme-order-service, to make sure the order state transition rules are respected."
—
# 退款功能开发检查清单
修改退款相关逻辑前，必须：
1. 确认退款是否会触发订单状态变更，变更方向是否符合状态机的单向流转规则
2. 检查是否存在部分退款场景，部分退款和全额退款的处理逻辑不能混用
3. 修改完成后运行订单模块的单元测试，不允许仅凭代码编译通过就认为完成
步骤 5：验证是否真的会被自动触发
新开一个对话（清空上下文，模拟"下一次会话"），同样说"给退款功能加一个新的校验规则"，观察 AI 是否主动提到了状态机流转规则或者部分退款场景——如果提到了，说明这个自定义技能已经在生效；如果没有，通常是 description 写得不够具体，需要让触发场景更明确。
自动触发并不总是可靠——description 匹配是概率性的，上下文一复杂，AI 可能直接开写代码。想稳定触发 superpowers（或某个具体技能），在提示词里把场景说清楚，必要时直接点名技能：
帮我给 acme-order-service 加一个退款功能。
先用 brainstorming 技能做需求澄清，不要直接写代码。
用 systematic-debugging 技能排查：订单取消后库存没有释放。
先找根因，确认之前再改代码。
用 brainstorming 澄清需求，确认设计后写实现计划（writing-plans），
但不要走 TDD，改完 compile 通过就行。
几条实用原则：
- 任务类型要对上 description：说"加个功能 / 改行为"比说"帮我看看"更容易命中 brainstorming；说"排查 bug / 测试失败"更容易命中 systematic-debugging。
- 点名比暗示稳：using-superpowers 技能要求 AI “只要有 1% 可能就要加载技能”，但执行时仍会偷懒；你在提示词里写上技能名，等于把用户意图提到最高优先级（superpowers 自己也规定：用户明确指令 > 技能默认行为）。
- 自定义技能更要具体：步骤 4 的 acme-refund-check 如果 description 只写 “refund”，太宽；写成 “when implementing or modifying refund-related logic in acme-order-service” 这种带项目名 + 动作的描述，命中率会高很多。
额外补充：一直开着 superpowers 的代价，以及怎么只用其中一部分
superpowers 的设计目标是复杂功能从需求到交付走完整方法论，不是给每个小改动都套同一套流程。插件常驻开着，常见副作用包括：
| Token 消耗明显变大 | 每个技能被触发时会整份加载 SKILL.md（有的还带参考资料）；using-superpowers 还要求"只要有 1% 可能就先去查技能"，对话开头往往多好几轮技能探测。 |
| 小改动拖很久 | 改一行配置、修个 typo，也可能被 brainstorming 拉去做需求澄清、写设计文档，再被 writing-plans / test-driven-development 接上写计划、先写测试——对简单任务来说过重。 |
| 测试流程你不想走时很难停 | 技能链默认是：澄清 → 计划 → TDD 实现 → verification-before-completion 验证。你不想要其中某几步，得在对话里明确说，否则 AI 会按技能里的 HARD-GATE 硬走。 |
| 子 agent / 多轮评审更耗时 | subagent-driven-development 等技能会拆任务、派子 agent、做检查点——质量更好，但等待时间和对话轮次都更长。 |
不是让你卸掉 superpowers，而是按任务分级用：
1. 复杂功能（推荐全套）
新模块、跨多文件、业务规则不清——让技能链自然跑：brainstorming → writing-plans → 执行 → 验证。提示词可以很简短，让插件自己判断。
2. 中等任务（点名 + 裁剪）
在提示词里写清"用哪些、不用哪些"（用户指令优先级最高）：
用 brainstorming 先澄清退款规则，设计确认后直接实现。
跳过 TDD，不要写 design doc 到 docs/superpowers/specs/，改完 compile 即可。
3. 琐碎修改（绕开或覆盖）
改注释、调配置、一行 bugfix——在 AGENTS.md 里加一条元规则，和 superpowers 并存：
## 与 superpowers 的分工
– 改 typo、单行修复、纯配置调整：直接改，不触发 brainstorming / TDD / writing-plans
– 新功能、行为变更、多文件重构：必须走 brainstorming 澄清后再实现
也可以在对话开头直接说：“这是单行修复，跳过 superpowers 全套流程。”
4. 只想用 brainstorming
三种做法，从轻到重：
- 每次点名（最省事）：先用 brainstorming 技能，澄清完我确认再写代码，不要自动进入 writing-plans
- 项目规则收窄（推荐）：在 AGENTS.md 写清楚哪些场景才允许触发后续技能，等于给 superpowers 加"刹车"
- 只拆一个技能（进阶）：从 superpowers/skills/brainstorming/ 把 SKILL.md 复制到你自己的技能目录（或写成项目内 .cursor/rules/ 规则），不装整套插件——只带走需求澄清，不带 TDD 和子 agent 流水线
和篇二一样的结论：工具是模块，不是宗教。superpowers 的价值在于复杂任务有章可循；简单任务强行走全流程，反而浪费 token 和时间。用提示词点名、用 AGENTS.md 划边界、必要时只拆单个技能——三种方式可以组合，按你和团队的节奏来。
步骤 6：跟规则、知识库分好工，别互相重复
篇一讲过"统一入口"，这个原则在技能包这一层同样适用：技能包里不要重复抄 AGENTS.md 里已经写过的命名规范和安全红线，也不要把项目背景知识整段搬进技能文件——那些内容各自有该待的地方。技能包只负责"做这类任务该按什么流程走"，具体的约束交给规则文件，具体的项目事实交给知识库，三者互相引用，而不是互相重复。
小结
三篇下来，实际上是在搭一个三层体系：规则文件回答"不能做什么"，知识库回答"项目是什么、为什么这么设计"，技能包回答"这类任务该按什么步骤做"。三层各管一块，谁也别越界重复谁的内容。下一篇会把这三层串起来，走一次端到端的真实场景，看它们具体是怎么协同工作的。
