Superpowers：给编程 Agent 的完整软件开发方法论
一份面向非程序员的深度拆解：它是什么、解决什么问题、怎么实现的、为什么这样设计、用到了哪些技术与思想。
一、它是什么：一套"强制执行的研发方法论"
先说明一个背景概念。编程 Agent，就是今天写代码用的 AI 助手——Claude Code、Cursor、Codex 这类工具。它们能读懂代码、能改代码、能跑测试，一个人配一个 Agent，效率可以接近一个小团队。
但"会写代码"和"会正确地做软件"是两回事。就像一个人会打字，不等于会写文章；会砌砖，不等于会盖房子。软件工程里真正难的不是"把代码写出来"，而是"在成千上万次改动中，让代码保持正确、可维护、可验证"。这靠的是一整套流程纪律：先想清楚要什么，再设计，再写测试，再实现，再评审，再合并。人类团队靠文化、管理和自律来维持这套纪律；而 AI 助手，天生没有这些东西。
Superpowers（作者 Jesse Vincent，公司 Prime Radiant，MIT 开源）做的，就是把这套"老工程师的流程纪律"编码成一组可组合的技能，再通过一个会话启动引导，确保编程 Agent 从第一句话起就被迫按这套流程工作。项目 README 的第一句话，精确地概括了它：
"Superpowers is a complete software development methodology for your coding agents, built on top of a set of composable skills and some initial instructions that make sure your agent uses them."
这句话里藏着三个关键成分，是理解整个项目的钥匙：
第一，它是"方法论"（methodology），不是某个技巧。 它覆盖从需求到合并的完整生命周期，而不是教一条 prompt 小妙招。第二，它是"可组合的技能"（composable skills），像乐高积木——14 个技能，每个只管一件事，按需拼装成一条流水线。第三，也是最容易被忽略的一点：它不只是"提供"这些技能，还准备了确保 Agent 真的会去用它们的初始指令。注意这个短语——make sure your agent uses them。后面会看到，"确保使用"这件事，是这个项目最精妙、最工程化的部分。
技术层面，它的形态非常朴素：14 个 Markdown 文件，每个是一个技能；一个 SessionStart 钩子；几个辅助脚本。零第三方依赖，跨 13+ 个编程平台（Claude Code、Cursor、Codex、Gemini CLI、GitHub Copilot CLI、Grok、Kimi、Devin、OpenCode、Pi、Hermes 等）原生支持，已被 Claude、Codex、Grok 的官方插件市场收录。
一句话定性：这个项目把"提示词工程"升级成了"行为工程"——它不教你怎么把一句话 prompt 写得更好，而是给 Agent 装了一套强制执行的研发流程。
二、要解决的问题：AI 为什么会把事情做砸
要理解这套方法论，先要理解它对抗的敌人。AI 助手的能力毋庸置疑，但无约束的 Agent 有四个结构性的缺陷——说"结构性"，是因为它们不是"不听话"，而是由大模型的工作方式决定的，几乎无法靠多叮嘱几句来根治。
缺陷一：跳步——它不会"把关"
大模型的本质是"预测下一个词"。给它一个需求，它的天然倾向是顺着往下写，而不是停下来想清楚再动手。所以无约束的 Agent 会：拿到需求直接写代码、不问清楚要什么；测试"应付"或干脆不写；遇到 bug 猜着改，不查病根；把脑补当事实，做了没要求的功能。它像一位过分热情的实习生——会干活，但不问图纸，也不自检。
缺陷二：失忆——它的"工作记忆"很有限
大语言模型一次只能"看见"有限数量的文字（上下文窗口）。对话一长，系统会做压缩（compaction），把早期内容概括掉——好比人的工作记忆有限，事情一多就会忘。问题在于，Agent 的一切指令、进度、上下文都活在对话里，压缩之后，之前的约定和进度可能全部清零。项目文档里记录过一个真实事故：控制器在压缩失忆后，把已经完成的整个任务序列重新派发了一遍——而且它自己并不知道。这比人失忆更麻烦：人不记得会承认，AI 失忆时表现如常，只是做错。
缺陷三：合理化——它很擅长给自己找借口
模型训练让它们"乐于配合"，因此也特别擅长为偷懒辩护。让它别跳过测试，它可能回你："这个很简单，不用测""这次是特例""我记得那个技能"。这不是它坏，而是模型天然会生成"听起来合理的下一步"。一句"请好好测试"是建议，建议管不住行为——它只会被当成语气词忽略掉。
缺陷四：随机——每次运行都不一样
同一个需求，Agent 每次运行的行为都可能不同。结果依赖"当次运气"，由此带来三个后果：不可复现（这次跑得好，下次未必）、不可审计（没人说得清它到底干了什么）、不可改进（没有稳定的过程，就没有改进的抓手）。这三点加在一起，意味着"AI 写代码"看起来像个黑箱赌局。
把四个缺陷放在一起看，结论就很清楚了：
AI 不缺能力，缺方法论。 人的团队靠自律、管理、文化来"把事情做对"；AI 没有这些，只能靠"流程 + 检查点 + 把借口写出来"。这四类缺陷的共同解，就是一套被强制执行的流程——这正是 Superpowers 存在的全部理由。
三、设计哲学：把提示词当作软件来写
大多数人用 AI 的方式是"聊天"：今天说一句，明天再说一遍，说完就忘。Superpowers 的创始人换了一个思路：把提示词当成"要长期维护的软件"来写。这个转变贯穿了整个项目。
普通的提示词是脆弱的。它是一次性的聊天指令，没有版本，没法测试，Agent 不听也没人知道。而如果把它当软件来对待，它就应该具备软件该有的属性：有版本（git 可以记录每次改动、可以回滚）、可 diff（能看出一次改动改了什么）、可测试（能验证它到底有没有用）、可复用（每次会话自动加载，不用重新说一遍）。这就是为什么 Superpowers 的技能是 Markdown 文件而不是别的什么神秘格式——Markdown 既是 AI 天然能读懂的语言，又是人能 diff、能 review、能版本管理的格式。
在这个总体思路之下，是四个思想支柱：
测试先行。 先写"期望"，再写"实现"。测试是对"什么算完成"的定义——先定义目标再干活，才能防止 Agent"感觉对了就收工"。这个原则不只用于写代码，后面会看到，它被推到了极致：连"写技能"本身都要先写测试。
系统化优先（systematic over ad-hoc）。 把流程写下来，不靠临场发挥。再急也要先找病根再下药。普通人和工程师的区别，很多时候就在这一条：普通人靠直觉和运气，工程师靠流程和证据。
复杂度最小化。 YAGNI（You Aren't Gonna Need It，用不上的先不做）加 DRY（Don't Repeat Yourself，不重复造轮子）。这条反直觉地重要：AI 默认会把事情做得过复杂、添加一堆没要求的功能。因为对它来说，"多生成一些内容"几乎零成本，所以必须反向压制。
证据优先（evidence over claims）。 不亲眼看到测试跑通，就不许说"做完了"。AI 默认自我感觉良好，必须强制拿运行输出当证据。
在这四个支柱之上，还有三个决定性的设计选择，它们决定了这个项目的气质。
第一个选择：行为塑造，而非建议。 普通提示词是"请尽量……"，技能是"必须"。元技能（using-superpowers）里有一句原话，语气近乎威胁：
"IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT." （如果某个技能适用于你的任务，你没有选择。你必须用它。）
这不是修辞。技能是强制流程（mandatory workflow），不是可选项。这是"建议"与"约束"之间的分水岭——后者才是能管住行为的。
第二个选择：Red Flags——把借口写进文档。 每个关键技能都带一张"合理化清单"（Red Flags table），显式列出 Agent 会冒出的偷懒念头，以及对应的现实，逐条对照。例如元技能里的两张：
| Agent 的念头 | 现实 |
|---|---|
| "这只是个简单问题" | 问题也是任务。先查技能。 |
| "我需要更多上下文" | 技能检查要排在澄清问题之前。 |
| "让我先探索一下代码库" | 技能会告诉你怎么探索。先查技能。 |
| "这个用不着正式技能" | 只要有技能存在，就用它。 |
| "我记得这个技能" | 技能会演化。去读当前版本。 |
这个机制的心理机制很值得琢磨，放到第 6 节专门展开。先记住结论：它让"偷懒"变成"被抓包"。
第三个选择：刻意使用"human partner"（你的人类伙伴）这个称呼，而不是"the user"（用户）。 全文都是 your human partner、ask your human partner。这是关系建模：把 Agent 定义为协作伙伴，把人类定义为产品负责人。称呼会塑造行为——当 AI 把你当成"伙伴"而不是"客户"时，它更倾向于停下来问你，而不是自作主张。项目官方贡献文档明确写道：这个用词是刻意的，不接受替换。
最后是一条工程底线：零第三方依赖。不依赖任何外部库，意味着跨平台一致、可以安全加载、可以被审计。技能文件是纯文本，任何人打开就能读。这个项目的全部"魔法"，都暴露在阳光下。
四、核心机制：怎么让 Agent"不得不"遵守
这是全项目最精彩的部分。前面说，"确保 Agent 使用这些技能"是设计目标——但怎么保证呢？难道靠说服？当然不是。它靠的是三层物理强制，在 Agent 还没有机会"偷懒"之前，就把流程焊死在它的行为里。
先给非程序员交代三个词：会话，指一次和 AI 的完整对话；技能，指装进 AI 工作环境的一组行为说明书；钩子（hook），指系统里"到点自动触发"的开关，比如"每次对话开始时自动执行某段程序"。
第一层，叫会话启动注入。每次对话一开始——包括重新开始、清理、以及压缩之后——系统自动执行一个钩子，把"技能使用手册"（也就是元技能 using-superpowers 的全文）直接塞进 AI 眼前的文字里。注意这里的措辞：不是让 AI"记住"这份手册，而是每时每刻把它摆在 AI 眼前。这对抗的是"失忆"——既然 AI 的上下文会被压缩清空，那就在每次清空后重新注入，让它永远看得到。这是对"失忆"最粗暴、也最有效的对抗。
第二层，叫元技能。塞进去的不是某个具体技能，而是"技能的技能"——一份告诉 AI"你该怎么使用技能"的总纲。总纲里最重要的规则是："哪怕只有 1% 的可能性有技能适用，你也必须调用技能。"同时附带一张 12 条的"偷懒借口清单"，把 Agent 的推脱话和真相一一对照。铁则是：在开口回应、甚至在说"让我先看看代码"之前，先检查技能——因为技能会告诉它该怎么看代码。
第三层，叫描述匹配、自动触发。每个技能文件头顶都写着"我该在什么情况下使用"（description，格式是 "Use when…"）。系统每接到一个任务，就把任务和所有技能的描述自动匹配，匹配上了就触发。触发之后，Agent 必须当众宣布"我正在使用 XX 技能"，并按技能里的清单逐项打勾执行——流程技能优先（先定方法论），实现技能跟进（再写具体功能）。
三层合起来，是一个闭环：
这段机制里有几个值得单独说的工程细节。
跨平台兼容不是顺带实现的，而是硬工程。 一个钩子，要同时服务 Cursor、Claude Code、Copilot CLI 等不同平台，而它们对"往上下文里塞文字"的接口格式各不相同：Cursor 要下划线命名的 additional_context，Claude Code 要嵌套结构的 hookSpecificOutput，Copilot CLI 要顶层字段 additionalContext。脚本的做法是读取环境变量判断当前平台，再输出对应格式。一行脚本，兼容四种格式。
上下文卫生（context hygiene）是一等公民。 AI 的"眼前"（上下文窗口）是稀缺资源，塞太多会爆。所以这个项目定了一条铁则：大文件写进磁盘，让 AI 按路径读取，而不是粘贴进对话。任务简报、评审材料、进度记录，全部由脚本（task-brief、review-package、sdd-workspace）生成到文件里，主对话里只留一行"去看这个文件"。项目文档里记录过一个真实教训：某次派发子代理的指令膨胀到了 4.2 万字符，其中 99% 是粘贴的历史记录——这正是"上下文污染"的典型形态，用文件传递根治了它。
进度写进文件，而不是写进记忆。 这是对抗"失忆"的第二道保险：每一笔进度、每一个决策，都记在 progress.md 里。压缩之后，AI 靠"文件 + git 历史"恢复进度，而不是靠回想——因为回想不可靠，文件永远在。
五、研发流水线：从想法到上线
把前面说的机制和哲学落到软件开发的日常，就是一条 7 个环节的流水线。用一个盖房子的比喻最好理解：先画图纸（设计）→ 圈出施工场地（隔离）→ 画出施工图（计划）→ 逐个工序施工并验收（执行）→ 全面质检（评审）→ 交付收尾（合并）。
环节 1：头脑风暴——想清楚再动手
第一步不是写代码，而是把"要什么"谈清楚。AI 一次只问一个问题（不连珠炮），提出 2-3 个方案并说清取舍，然后分段展示设计。
它有一个非常实用的设计：给需求分级，决定流程要跑多重。分为三档：
- 探针（Spike）：就是试试行不行（"能不能做到 X？"）。输出是一个答案，不是要保留的代码。
- 有界（Bounded）：改现有代码里的小地方（加一个开关、修一个文件）。问关键问题、用几句话给出设计、人类批准就开工，不写设计文档。
- 架构（Architectural）：新项目或大改动。走完整流程：逐个提问、提 2-3 方案、分段展示设计、写设计文档、人类审阅，然后才转入写计划。
这个分级里有一条铁规矩，是全项目价值观的代表：无论需求多简单，动手之前必须获得人类批准。 所谓"这个太简单了，不用批准"正是 Red Flags 里要击碎的第一条借口。用项目原话说，简单的是流程的"体量"（artifact），从来不是"审批"本身（approval）——审批门永远不降级。还有一条配套规则：隐藏复杂度只能升级、不能降级。中途发现这事其实很难，就必须停下来说清楚，升级到更重的流程；任何情况都不允许"都干到一半了，就降级糊弄过去"。
环节 2：隔离工作区——不打扰别人的工地
批准之后，AI 要在**隔离工作区（git worktree）**里动工——在现有代码旁边另开一块互不干扰的施工场地。改坏了，主线代码毫发无损；验收不合格，整块场地可以直接弃用。没有隔离的话，AI 一旦改坏就是"连坐"，好代码和坏改动搅在一起，返工成本翻倍。
开工前还要做两件事：跑通项目环境，并且确认测试基线是绿的——"我还没改代码，测试就红了，那一定是环境问题，不是我的问题"。这条规则省掉了无数次的冤枉排查。
环节 3：写施工图——拆到"照着抄就行"
接下来把设计文档拆成 2-5 分钟一个的小任务。每个任务都写到"一个零项目上下文、品味可疑、还厌恶测试的初级工程师"都能照着抄的程度：精确的文件路径、完整的代码、验证命令、提交命令，一个不少。任务之间还要声明"接口契约"——上一个任务产出什么名字、什么类型，下一个任务怎么用它。
这里有一条铁律：零占位符。禁止写"待定"、"类似上一个任务"、"加适当的错误处理"——每个步骤都必须有具体内容。为什么这么"啰嗦"？因为 AI 没有"常识"和"项目背景"，只有把一切写死，它才不会自由发挥。计划越具体，执行越稳定。这套技能还自带一份自检清单：检查设计文档里的每一条需求是不是都有对应的任务、全文有没有占位符、前后任务之间的函数名和类型是否一致。
环节 4：子代理驱动开发（SDD）——执行的核心
这是全流程最重的一段，也是技术上最有意思的一段。大白话说，它的做法是：每个任务，派一个"全新的小助手"（子代理）去干。这个子代理不继承主对话的历史——它只看到自己这一个任务，专心不被打扰。而"总指挥"（控制器）留在主会话里，负责协调、评审、记录。
这个设计背后是两条深刻的原理。
原理一：上下文卫生。 为什么派"全新"的子代理？因为主对话经过前几个任务，已经积累了海量历史。如果让一个带满 4 万字历史的子代理去写新任务，它既容易被历史带偏，又浪费昂贵的上下文。全新子代理 + 文件传参（简报、报告都写进文件），等于给每次任务一个干净的工作台。上下文是稀缺资源，而稀缺资源就应该按任务分配，而不是共享。
原理二：评审独立。 每个任务做完，有两道质检：① 是否符合设计文档；② 代码质量如何。评审由一个独立的评审子代理来做，实现者不能自审。为什么？因为写过代码的人（模型）天然会为自己的选择辩护。只有让没写过这份代码的评审者来看，才能真挑出刺。
任务循环里还有几个精巧的机制：
返工上限（5 轮）加"断电器"。 评审不通过就返工，但最多 5 轮。前 3 轮让原实现者改（它上下文还在，改起来快），第 4、5 轮换一个更强的新实现者（说明原来的助手"看不见自己的问题"——换模型 + 换视野，一步到位）。5 轮还不行，就由总指挥裁决并记录：能讲清楚就放过、是误会就归档、有隐患就继续，但不允许无限纠缠。这个"断电器"防止了最昂贵的一种失败——在一条已经走不通的路上反复消耗算力。
模型分级。 简单任务用便宜快速的小模型，集成调试用中等模型，架构设计和最终评审用最强模型，每一级都显式指定。原因有两个：一是省钱，二是快——便宜模型虽然单价低，但往往要多跑两三倍的轮次，总账反而更贵。所以它是"按任务复杂度分级"而非"一律最便宜"。
进度写进 ledger 文件。 每完成一个任务、每次做出裁决，都记进 progress.md。这既是压缩失忆后的恢复地图，也是给人类审计的流水账。项目文档里有句话非常值得玩味："提交记录里写着的东西，即使你的上下文再也想不起来，也依然存在。" 信任文件，不信任记忆。
环节 5：代码评审——双向技能
每个任务之间、以及全部完成时，都有独立评审。这个项目把"评审"拆成了两个技能，各管一半：
requesting-code-review（发起评审）：规定了什么时候必须评审（每任务后、大功能完成后、合并前），以及怎么给评审者准备好材料。
receiving-code-review（接受评审）：这个技能很反直觉——它教 AI 怎么正确对待评审意见。不是无脑照单全收（"你说得对，我马上改"），也不是防御性反抗（"这没问题"），而是先验证再实施：看不懂就追问，觉得不对就摆证据，确认有问题才动手。项目原话是："代码评审需要技术判断，而不是情绪表演。"（Code review requires technical evaluation, not emotional performance.）
环节 6：收尾——人类最终拍板
全部任务做完，先跑全量测试——不过关就停下报告，收尾菜单不出现。通过之后，AI 把选项摆到人类面前：合并？发 PR？保留？丢弃？ 然后由人类做出最终决定，AI 负责执行和清理现场。
回头看整条流水线，它的节奏感非常明确：该 AI 自主时放手（每个任务全自动、无人值守），该人类决策时停下（设计批准、合并决定）。中间的高频质检交给自动化的评审子代理，而关键节点永远保留人类审批。
六、贯穿全程的两道"铁律"：TDD 与系统化调试
如果说前面的流水线是"怎么走"，那这两道铁律就是"什么时候不能走"。它们是全项目行为设计的精华，值得单独拆开看。
它们的共同模板
每个关键技能都长成同一个样子，这是刻意的模板：
- Iron Law（铁律）：一句不可谈判的禁令。
- When to Use（使用范围）：明确什么时候该用、什么情况下可以豁免（豁免必须问人类）。
- Red Flags（借口清单）：AI 会找的借口 + 对应的现实，逐条对照。
- 惩罚性措辞："违反规则的文字，就是违反规则的精神。"（Violating the letter of the rules is violating the spirit of the rules.）
- 明确的流程：一段步骤或一个状态循环。
第一道铁律：测试先行（TDD）
没有先写测试，就不许写正式代码。 NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.
进一步说：先于测试写的代码，删掉重写。 不许"留着当参考"、不许"顺手改改"。为什么这么狠？因为留着就会变成"没有测试保护的可疑代码"，烂摊子就是这么积累出来的。
这道铁律的核心循环是红-绿-重构（Red-Green-Refactor）：
每一步都有个看起来多此一举的检查：写完失败测试，要亲眼确认它失败；写完实现，要亲眼确认它通过。为什么"确认失败"这么重要？因为如果你没看过测试失败，你就不知道它测的是不是对的——也许这个测试碰巧永远是绿的，那它什么都没测到，只是在自我安慰。
更重要的是它背后的语义：测试 = 对"什么算完成"的定义。先写测试，等于先定义目标，AI 才知道自己在干什么，而不是"感觉差不多就收工"。这条铁律对"代码质量"的贡献，其实远不如它对"行为塑造"的贡献大——它强制 AI 在动手写实现之前，先想清楚验收标准。
第二道铁律：系统化调试
没找到病根，就不许下药。 NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST.
修症状（表面问题）看着快，但病会复发。而且越急越要系统化——乱撞比慢慢查慢得多。这道铁律专门对抗 AI 最典型的坏习惯：看到报错就猜着改。它的流程是四个阶段：
值得注意的是第二阶段"找模式"——先别急着分析坏代码，去代码库里找"相似的、能跑通的代码"，对照它是怎么写的。这一条非常实用：大部分 bug 的解法，就藏在项目里已经工作正常的代码里。而第四阶段"验证"则和整个项目"证据优先"的哲学呼应：不拿到运行输出，就不许声称修好了。
为什么这套真的有效：行为工程的原理
现在可以回答第 3 节留下的问题了：Red Flags 表、极端措辞、检查点，这些设计为什么真的能管住 AI？答案藏在"行为工程"（behavioral engineering）四个字里。
关键认知：AI 不是"不听话"，而是天生倾向走捷径。 大模型的设计目标就是"生成看起来合理的下一句"，它并不天然包含"自我审视"这一环。所以它一定会试图跳过流程——这不是缺陷，是它的工作方式。聪明的做法不是跟它对抗，而是顺着它的工作方式，把"走捷径"的代价抬高到它不愿付出。
具体有三种手段：
第一，借口清单（Red Flags）——把捷径的名字写出来。 当清单上白纸黑字写着"这很简单，不用正式技能 → 不对，有技能就要用"，AI 在冒出这个念头时，会先撞见自己被识破的证据。心理学上这近似"公开承诺效应"：当一个人（或模型）知道自己想走的路被明确标注为"你正在合理化"，继续走的行为就会变得困难。被点名的捷径，就不再是捷径。
第二，极端措辞——抬高违反成本。 "ABSOLUTELY MUST"（绝对必须）、"Delete means delete"（删掉就是删掉）、"Period."（到此为止）。这些措辞不是暴躁，是刻意设计的"摩擦感"。它们让 AI 在选择偷懒时，多一层"我违反了明确的禁令"的心理成本。
第三，检查点——把"随便做做"变成"过不了关"。 每个阶段都是一个"要么通过、要么重来"的门。测试没红就不能写实现，病根没找到就不能下药。这套检查点纪律，把"感觉做得差不多"这种主观判断，替换成了客观的、可验证的门槛。
七、元层：怎么保证方法本身可靠
前面讲的都是"用这套方法管理 AI"，但还有一层更高级的问题：这套方法本身，凭什么可信？ 答案是这个项目最超前的地方——它把自己也当成要开发的软件来对待。写技能，用的也是 TDD。
Writing Skills：对"流程文档"做 TDD
核心主张一句话："如果你没看过 AI 在没有这条规矩时怎么乱来，你就不知道这条规矩有没有用。"
它的开发循环和写代码的 TDD 完全同构：
先设计一系列"刁钻场景"（比如用户说"这个太简单了，直接做"，或者"先帮我看看代码"），派一个子代理去执行；然后看没有技能时，Agent 会怎样乱来——这是基线。写了技能之后，再看同一批场景下 Agent 是否遵守。不遵守，就修技能。技能不是写出来的，是测出来的。 这也解释了为什么项目要求"技能改动必须附 before/after 评估证据"——没有测试的改动，分不出好坏。
评估体系：真实终端 + AI 裁判
技能的评估不只靠模拟，还有一套真实环境测试（独立仓库 superpowers-evals）。它用 drill 框架驱动真实的终端会话——真的打开 Claude Code、Codex、Gemini CLI，把设计好的场景跑一遍，然后用一个 LLM 裁判判断"技能有没有被正确执行"。不 mock，全真实。这类"技能行为合规"测试跑在 evals/ 目录，而插件基础设施（钩子、脚本）跑在 tests/ 目录，两类分开。
社区治理：把"人机协作的边界"也写进规则
这个项目还有个很特别的细节：它的贡献指南（CLAUDE.md）开篇就告诉来投稿的 AI 助手，这个仓库的 PR 被拒率高达 94%——其中大量是没读守则、批量投稿的"AI 垃圾稿"。为此它立了几条规矩：PR 必须填全模板、必须先搜索有没有人做过同样的工作、必须公开作者身份（用的是哪个模型、哪个工具、哪个版本），技能改动必须带评估证据。
这件事很耐人寻味。它说明 Superpowers 不仅把研发流程工程化了，连"如何防止 AI 投稿污染"这件事本身也工程化了——把"人机协作的边界"写成仓库规则，写进 AI 会读到的那份文件里。一个管理 AI 的项目，最懂 AI 会怎么钻空子。
八、总结：三个对普通人也有用的启示
Superpowers 把"资深工程师的流程纪律"工程化成可组合技能，再通过会话启动注入，让它们成为 Agent 的默认行为。不靠自觉，靠机制。 拆开它的每一个设计，可以看到三条通用的、不局限于编程的启示。
启示一：提示词工程 → 行为工程。 约束 AI 靠的不是"更会说话"的提示词，而是流程、检查点、以及把借口写出来。如果你想管住任何 AI，别反复叮嘱，先给它一套"过不了关就别想往前走"的规则。这个思路对任何在用 AI 的团队都有直接借鉴价值。
启示二：上下文是稀缺资源，重要状态要外部化。 AI 的记忆有限而且会丢，所以进度、决策、标准都必须落到文件里，而不是留在对话里。这对人也是一样的道理——好记性不如烂笔头，团队协作把约定写下来，才不用靠互相猜。
启示三：人类审批是特性，不是 bug。 该 AI 自主时放手，该人类决策时停下。信任边界设计得好，AI 才敢被你托付几小时的无人值守；边界不清晰，AI 要么乱来，要么被你的每条指令绑死。好的 AI 协作，是把"放手"和"收手"都写清楚。
为什么值得关注？因为它证明了**"AI 写代码"可以不是玄学**——把流程纪律工程化之后，结果是可复现、可审计、可改进的。一个思想贯穿到底：TDD 一切，连写技能都要先写测试。方法论与具体工具解耦，跨 13+ 平台通用，开源、零依赖、MIT，任何人都能拿去用、去改造。它现在还是这个领域的少数派，但它代表的方向——用软件工程的方式去管理 AI 的行为——几乎可以确定是下一个十年的主流。
资源：GitHub 仓库 obra/superpowers · 发布博客 blog.fsck.com · 评估仓库 superpowers-evals · 社区 Discord。
本文基于仓库源码与文档撰写，未引用任何虚构数据。