Superpowers 高度标准化的“工程契约”

在 Superpowers 框架中，“高度标准化的‘工程契约’” 并不是指人类程序员之间签的正式合同，也不是指代码层面的 API 接口（如 Interface/Abstract Class），而是指 “一套强制约束 AI 行为边界、执行顺序与交付标准的‘Prompt 法律’”。

简单来说，它是通过精心设计的工程化文档（通常是项目中的 .md 模板），在 AI 的 Prompt 顶层套上一个“紧箍咒”。它规定了 Agent 在面对任何开发任务时：什么能做、什么绝对不能做、什么阶段必须产出什么证据。

这个“契约”主要由以下三个维度的硬性约束构成：

1. 行为边界契约（Behavioral Boundary）

普通的 AI 编码助手是“极其听话但也极其盲目”的，你让它改 Bug，它抓起代码就改。而 Superpowers 的契约规定了严厉的禁令：

严禁盲猜式调试（No Guessing）： 契约规定，在没有拿到真实的报错日志（Stack Trace）或复现用例之前，Agent 禁止猜测和修改任何一行线上代码。
严禁跳过测试（No Test Skipping）： 代码写完不等于完工。契约规定“没有测试通过的截图/日志作为证据，就视作任务未完成”，Agent 不能口头汇报“我已经改好了”。
一次只做一件事（Single Responsibility）： 严禁在修改 Bug 的同时顺手去重构旁边的代码，或者在头脑风暴时一次性向人类问五个问题。

这类似于软件工程中的 Hard Gates（硬门禁）。Agent 在开发过程中必须像流水线上的工业机器人一样，严格按照物理先后顺序触发状态，绝对不能跳级。

当前阶段	必须产出的契约物（Artifact）	下一步门禁条件
1. Brainstorm	统一的 `Design Spec` (设计说明书)	必须获得人类的 Explicit Confirmation（明确确认）才能解锁下一阶段。
2. Plan	带有依赖关系和检查清单的 `Task List`	必须在隔离的 `git-worktree` 环境中初始化，不能在主分支直接写。
3. Execution	测试用例（RED） $\rightarrow$ 业务代码（GREEN）	必须先看到测试失败，再看到测试成功，完成 TDD（测试驱动开发）闭环。
4. Verification	完工报告 + 全量测试通过日志	必须通过 Main Agent 的双阶段代码评审，否则代码直接原地销毁。

为什么这叫契约？ 因为 Superpowers 将这些步骤写进了 SKILL.md 的系统级提示词中。Agent 如果不生成上一个阶段的契约物，它的上下文里就不会获得执行下一个阶段的“技能工具（Tools）权限”。

这是 Superpowers 最精妙的地方。LLM（大模型）有一个通病：它知道什么是好代码，但它倾向于偷懒（偷工减料、用伪代码代替、省略边缘处理）。

为了打破这种“懒惰契约”，Superpowers 利用了罗伯特·西奥迪尼的心理学说服原则（Persuasion Principles），特别是 “承诺与一致性（Commitment and Consistency）” 原则：

自我身份锁定： 契约文件的开头通常会用极其严肃、高标准的工程语言定义 Agent 的身份（例如：“你是一个拥有 20 年经验、极度严谨、绝对不容忍任何未测试代码合并到主分支的首席软件架构师”）。
行为一致性绑定： 契约通过结构化语言让 LLM 产生一种“认知失调”——如果我是一个完美的架构师，我就绝对不能跳过写测试的步骤。通过这种方式，把原本松散的提示词变成了大模型在逻辑上必须自我遵守的道德和技术契约。

普通 AI 助手的做法：

人类： “帮我实现一个用户注册功能。”
AI： “好的，这是代码：function register()...（噼里啪啦写了一堆，没有处理邮箱重复的报错，没有写测试，甚至代码里还有 // TODO: 后面再补）。”
Superpowers 契约约束下的做法：

人类： “帮我实现一个用户注册功能。”
Agent（触发 brainstorm 契约）： “在写代码前，我需要确认：1. 密码强度的具体规则是什么？2. 邮箱重复时返回 400 还是 409？请先回答这两个问题，我需要更新 Design Spec。”
(得到回答后，自动开辟 git 隔离工作区，先写了一个验证密码强度的测试脚本并运行报错，然后再去写业务代码，最后拿着测试通过的 green log 来向你交卷。)

总结来说：
高度标准化的“工程契约”，就是用工程化的制度（Checklist、隔离区、门禁）和心理学提示词，把不可控的、容易偷懒的 AI，驯化成一个步步留痕、严格遵守工业级开发规范的“完美数字工匠”。