OpenSpec、Superpowers 和 Harness：AI 工程化开发的三层拼图

AI 编程从让模型写代码走向让模型像团队一样开发中间差的不是更强的模型而是三层工程基础设施OpenSpec 管做什么Superpowers 管怎么做Harness 管谁来做、怎么协同。三者各管一层合在一起才是完整的工程化开发体系。用 AI 写代码很多人经历过类似的演进一开始是让模型直接写。能跑但质量不可控——没有规范、没有测试、没有审查改了这里崩了那里。后来开始给模型加规则写AGENTS.md、加 Prompt 约束、上 Harness稳了不少。再后来上多 Agent 协作——角色分工、并行开发、自动审查——但新问题又来了每个 Agent 按自己的理解做事规范不统一流程不一致。要解决第三阶段的问题需要三层东西同时到位统一的规范、统一的流程纪律、统一的团队协作框架。对应的就是 OpenSpec、Superpowers 和 Harness。三层各管什么层次工具管什么类比规范层OpenSpec做什么——需求、接口、验收标准施工图纸纪律层Superpowers怎么做——TDD、代码审查、验证流程施工规范手册协作层Harness / Agent Team谁来做——角色分工、任务调度、权限管控项目经理 工地管理一句话关系OpenSpec 定标准Superpowers 保纪律Harness 管团队。OpenSpec规范层——锁定做什么OpenSpec 是一个 Spec-Driven Development规范驱动开发框架由 Fission-AI 开源。它解决的核心问题是多个 Agent 协作时怎么保证大家对做什么的理解一致没有 OpenSpec 的场景你在聊天窗口里告诉 Agent “加一个用户认证模块”Agent 按自己的理解去做。做出来发现接口不对、字段命名不一致、验收标准不明确。改了三轮还在返工。有 OpenSpec 的场景先写一份 spec 文件明确定义需求、接口、数据模型、验收条件。所有 Agent 读同一份 spec 开工做完了按 spec 验证——符合就通过不符合就打回。OpenSpec 的工作流propose提出变更→ spec编写规格→ verify验证产出→ archive归档输出的openspec/目录包含提案、规格、任务拆解、验证结果——结构化、可追溯、所有 Agent 共享。关键价值需求不再只活在聊天记录里而是结构化文档多 Agent 共享同一份规范不会各做各的验收有明确标准不是看起来差不多就行Superpowers纪律层——锁定怎么做Superpowers 是一个面向 AI 编程的技能系统由 obra 开源。它解决的核心问题是怎么让 Agent 按工程最佳实践写代码而不是走野路子没有 Superpowers 的场景Agent 直接上手写代码不写测试、不做计划、不走审查。代码能跑但不可维护测试覆盖率为零。有 Superpowers 的场景Agent 在开发前被加载了 TDD测试驱动开发技能——先写测试、再写实现、实现完了跑测试、不通过就改。代码审查技能确保每段代码都经过评审。验证技能确保不会宣称完成但实际没做。Superpowers 的核心能力技能作用test-driven-development先写测试再写实现不通过就改writing-plans开发前先出计划不允许直接上手code-review代码必须经过评审才能合并verification-before-completion完成前必须验证防止嘴上完成brainstorming复杂问题先头脑风暴再动手技能是纯 Markdown 定义零依赖可以嵌入任何 AI 会话。按需加载——不是一次性塞满而是根据任务类型激活对应技能。关键价值Agent 的开发流程有纪律不是想怎么写就怎么写强制遵循 TDD、审查、验证等工程最佳实践产出质量有保障不只是能跑而是能维护Harness / Agent Team协作层——锁定谁来做Harness 在这个体系里负责的是多 Agent 的编排与管控。它解决的核心问题是多个 Agent 怎么分工、怎么并行、怎么不互相冲突没有 Harness 的场景五个 Agent 各自领了任务开始干但没人统一分工。前端 Agent 和后端 Agent 对接口的理解不一致测试 Agent 拿到的是过时的代码安全 Agent 根本不知道其他人改了什么。有 Harness 的场景角色定义AGENTS.md明确每个 Agent 的职责——架构师、后端、测试、安全、Team Lead任务调度Team Lead Agent 读取 OpenSpec 的任务列表分派给对应角色权限管控每个 Agent 只能操作自己负责的文件和目录硬约束提交前必须跑测试、Lint、安全扫描——不通过就不让合并反馈回路测试失败自动回灌给开发 Agent修复后重新验证关键价值多 Agent 协作有分工、有秩序不是各自为战权限隔离防止越权硬约束防止偷工减料任务可并行、可追踪、可回滚三者怎么串起来一个完整的开发周期走下来大致是这样Phase 1规范 OpenSpec 定义需求、接口、验收标准 → 产出 openspec/ 目录所有 Agent 共享 Phase 2分工 Harness 组建 Agent Team分配角色 → 架构师读 spec 输出架构Team Lead 拆任务分派 Phase 3开发 各 Agent 按 Superpowers 的技能纪律开发 → TDD 写代码、代码审查、完成前验证 Phase 4验收 OpenSpec 验证产出是否符合 spec → 通过则归档不通过则打回调用链条Harness 启动 → 加载AGENTS.md→ Architect Agent 读openspec/specs/→ Superpowers 激活 TDD → Backend Agent 按 spec TDD 写代码 → Reviewer Agent 按 Superpowers 规则评审 → Harness 校验权限、运行钩子 → OpenSpec 验证 → 归档。三层的配合原则是规范不变、流程不变、团队可弹性扩展。OpenSpec 和 Superpowers 定义的是稳定的标准和纪律Harness 定义的是灵活的团队结构和调度策略——项目大了可以加 Agent项目小了可以减但规范和纪律不变。没有这三层会怎样缺什么会出什么问题缺 OpenSpecAgent 各做各的需求理解不一致返工率高缺 SuperpowersAgent 走野路子不写测试、不做审查、代码质量不可控缺 HarnessAgent 协作混乱权限冲突、任务重复、无法并行三个都缺裸模型写代码——能跑但不敢用每次结果不一样反过来三个都有的时候需求有文档、有验收标准OpenSpec开发有纪律、有最佳实践Superpowers协作有分工、有管控、有兜底Harness这才是从 Demo 到生产级的完整跨越。落地建议如果准备在项目里引入这套体系不用一步到位。按优先级来先上 OpenSpec——哪怕只是手写一份需求 spec也比在聊天窗口里口头描述强十倍再上 Superpowers 的核心技能——至少启用test-driven-development和verification-before-completion这两个投入产出比最高最后上 Harness / Agent Team——等需求规范和开发纪律稳定了再上多 Agent 协作否则分工越多乱得越厉害避坑提醒Superpowers 技能不要全部加载按需启用。全加载会让上下文过长模型反而表现变差AGENTS.md写精简——只写先看什么、按什么流程架构和业务细节放docs/如果 Harness 自带代码审查能力关掉 Superpowers 里的对应技能避免重复和冲突结论一句话收尾OpenSpec 锁需求Superpowers 锁纪律Harness 锁协作——三层拼齐AI 才能从写代码的助手变成可靠的开发团队。这不是未来的愿景是现在就能落地的工程实践。OpenSpec、Superpowers 和 Harness 都是开源项目文档齐全可以从最小配置开始用起。关键不在于一步到位而在于知道三层各管什么、缺哪层会出什么问题。本文由本人构思并把控借助 AI 辅助整理成文仅代表个人观点欢迎交流。