当前位置：首页 > news >正文

AI编程王炸组合：顶级三剑客 OpenSpec 定方向，Superpowers定纪律，Harness定协同

news 2026/5/11 8:59:07

一： Superpowers Skills与OpenSpec 黄金搭档

很多人用Superpowers 和 OpenSpec，只是简单叠加，觉得“一个写规范，一个写代码”就完了。

大错特错！

豆包负责任地说，这两个工具的核心价值，在于形成了“规范—执行—验证”的完整闭环，各自发挥不可替代的作用，是AI编程中“做什么”与“怎么做”的完美组合。

就像分层架构里，表现层和业务层的关系——没有表现层的需求输入，业务层就会盲目开发；没有业务层的规范执行，表现层的需求就无法落地。

下面，豆包就从互补关系、适用场景、实操流程，再到真实案例，一步步给大家讲明白，这对黄金搭档到底该怎么用。

1.1、核心互补关系：为什么它们是黄金搭档？

1. 定位与能力互补

豆包先给大家做个清晰的对比，一看就懂，不用死记硬背：

这里豆包插一句：

两者的互补，本质上是“需求标准化”与“执行标准化”的结合。

2. 工作流闭环

很多人用这两个工具，之所以没效果，就是因为没形成闭环，要么只定规范不执行，要么只执行不定规范。

豆包结合自己的实操，总结了一个最简单、最易落地的闭环流程，大家直接抄就行：

第一步：OpenSpec 定方向。

通过 propose（提案）、refine（细化）、validate（验证）三个步骤，把模糊的需求转化为结构化规范，作为开发的“唯一事实源”。

也就是说，不管是人类开发者，还是AI Agent，都必须以这份规范为标准，不能凭自己的理解来——这一步，豆包建议大家多花点时间，规范定得越细，后续返工就越少。

第二步：Superpowers 保执行。

通过 brainstorm（头脑风暴）、tdd（测试驱动开发）、review（代码审查），严格按照规范落地，强制执行工程纪律。比如，激活TDD技能后，AI必须先写测试用例，再写代码实现，测试不通过就不能继续；激活代码审查技能后，每段代码都要经过评审，有问题必须修改——这一步，就是避免AI“走野路子”的关键。

第三步：OpenSpec 管结果。

开发完成后，通过 archive（归档）功能，记录所有变更，更新规范，形成可追溯的迭代闭环。

豆包提醒大家，归档不是走过场，每一次修改、每一个版本，都要记录清楚，后续排查问题、版本回滚，都会用到——这也是工程化开发的核心要求之一。

简单总结：OpenSpec定好“靶子”，Superpowers保证“打准”，最后OpenSpec再“验收”，形成一个完整的闭环，缺一不可。

3. 兼容性与适配性

这一点，豆包必须重点夸一夸这两个工具，这个哥俩真的太“用户友好”了。

首先，两者都兼容 Claude Code、Cursor、Copilot 等主流 AI 工具。

不用你额外更换开发环境，无缝集成到现有开发流程里就行。

豆包自己的团队，就是用Copilot配合这两个工具，开发效率直接提升了30%以上。

其次，两者都是开源、本地运行工具，无 API 依赖，使用成本极低。

不管是个人开发者，还是小型团队，不用花一分钱，就能用上规范驱动开发和工程化执行的能力——这也是豆包推荐大家优先尝试的原因之一。

最后，它们能完美适配后续的多Agent协同场景。

很多人一开始只用Superpowers+OpenSpec做个人开发，后续团队扩大、引入多Agent，不用重新调整工具，直接叠加Harness就行，兼容性拉满。

1.2、Superpowers + OpenSpec 的最佳组合场景？

不是所有场景都需要同时用这两个工具。

豆包结合自己的实操经验，总结了4个最适合的场景，能最大化发挥“规范+执行”的价值，减少返工、提升质量，大家可以对号入座：

（1）中大型功能开发（推荐）：

这是最能体现两者价值的场景。比如开发一个用户管理系统、支付接口，OpenSpec可以定义完整的规范（需求、接口、数据模型），避免需求模糊导致的返工；

Superpowers按规范生成代码、执行TDD、代码审查，确保质量与规范一致。

豆包团队上次开发企业级用户认证模块，就是用这套组合，原本需要5天的工作量，3天就完成了，而且测试通过率100%，没有出现一次返工。

（2）老项目重构 / 增量迭代：

老项目的痛点，就是代码混乱、没有规范，重构的时候很容易破坏现有功能。

这时候，OpenSpec可以管理变更范围与影响，明确重构的目标和边界，避免“越改越乱”；

Superpowers保证重构过程的严谨性与可验证性，比如通过回归测试，确保原有功能不受影响，降低重构风险。

豆包之前重构一个电商老项目的订单模块，就是靠这两个工具，顺利完成重构，还优化了性能，没有出现一次线上故障。

（3）团队协作开发：

团队协作的核心痛点，就是沟通成本高、认知不统一。

OpenSpec提供共享规范，所有人都按同一套标准开发，减少“你理解的需求和我理解的不一样”的问题；

Superpowers强制执行统一开发流程（如TDD、代码审查），确保代码风格与质量一致，后续维护起来也更轻松。

豆包的团队，现在不管是人类开发者还是AI Agent，都严格遵循这套流程，沟通成本减少了一半以上。

（4）高要求质量项目（金融、企业级）：

这类项目，对代码质量和可靠性要求极高，不能有一丝马虎。

OpenSpec确保需求不跑偏，所有变更可追溯，一旦出现问题，能快速定位原因；

Superpowers强制质量关卡（测试先行、完成前验证、提交前审查），满足高可靠性要求。

总结一下：只要是需要“规范清晰、质量可控”的开发场景，用Superpowers+OpenSpec，准没错。

反之，如果是简单的demo开发、临时脚本编写，就没必要这么复杂，直接用AI写就行.

豆包也不建议大家过度复杂，实用为主。

二、Superpowers + OpenSpec 黄金搭档实操

很多人看完理论，还是不知道怎么上手。

别慌，豆包给大家整理了一套标准化的协同链路.

从需求到交付全程覆盖，可直接复制套用，兼顾个人开发与小型团队协作场景，每一步都有具体的操作指令，新手也能快速上手。

2.1 标准协同链路（5 步闭环）

第一步：需求澄清与提案（OpenSpec主导）

这一步的核心，是把模糊的需求，变成明确的提案。

豆包建议大家，不要直接让AI写代码，先花10-20分钟，用OpenSpec创建提案，把需求、成功标准、约束条件写清楚。

具体操作指令大致如下：

# OpenSpec: 创建功能提案
/opsx:new user-auth
# 编辑提案：明确需求、成功标准、约束（豆包提醒：越细越好，避免后续歧义）
(1) 需求：实现用户认证功能，支持邮箱/手机号登录，两种方式可切换，登录状态持久化（7天有效）(2) 成功标准：能正常注册、登录，返回有效JWT令牌；密码错误提示清晰；登录失败次数过多锁定账号(3) 约束：密码需用bcrypt加密存储，接口需支持限流（10次/分钟）；不允许明文存储任何用户信息(4) 额外说明：兼容现有用户数据库，不影响现有用户正常登录

豆包插一句：这里的约束条件，一定要写清楚，比如加密方式、限流规则，这些都是后续开发的核心依据，避免AI生成不符合要求的代码。

第二步：规范细化与验证（OpenSpec主导）

提案创建完成后，需要进一步细化规范，比如数据模型、接口定义、业务规则、错误码等，然后验证规范的完整性与一致性。

避免规范本身有漏洞，导致后续开发跑偏。

具体操作指令：

# OpenSpec: 完善规范（数据模型、接口、业务规则）
/opsx:refine user-auth
# 验证规范完整性与一致性（可邀请团队成员或AI Agent评审）
/opsx:validate user-auth
(1) 数据模型：定义User表（id、username、password、email、phone、role、createTime、lastLoginTime、isLocked）
   - 字段约束：id为主键，自增；email和phone唯一；password非空，加密存储；isLocked默认false
(2) 接口：POST /register（注册）、POST /login（登录）、GET /user/info（获取用户信息）、POST /user/unlock（解锁账号）
   - 请求参数、响应格式、状态码，都要明确（比如注册接口，需要返回用户ID、token）
(3) 业务规则：密码长度≥8位（含字母+数字），同一账号5分钟内登录失败≤3次，失败3次锁定30分钟；注册时需校验邮箱/手机号格式(4) 错误码：定义400（参数错误）、401（认证失败）、429（限流）、403（账号锁定）、500（服务器错误），每个错误码对应具体提示信息

豆包提醒：这一步的验证很重要，最好邀请团队成员一起评审，或者让AI Agent检查规范是否有冲突、是否遗漏需求。

豆包之前就因为没验证规范，导致后续开发时，接口字段定义不一致，返工了半天。

第三步：执行计划与任务拆解（Superpowers主导）

规范定好后，就该进入开发阶段了。

但不要让AI直接上手写代码，先让Superpowers生成详细的开发计划，再精细拆解任务（建议2-5分钟粒度），明确每一步要做什么、依赖什么，避免盲目开发。

具体操作指令：

# Superpowers: 基于规范生成详细开发计划
/superpowers:brainstorm --prompt "基于OpenSpec规范，生成用户认证模块开发计划，覆盖项目初始化、依赖安装、模型实现、接口开发、测试、审查全流程"
# 精细拆解任务（2-5分钟粒度，豆包建议：任务越细，执行越顺畅）
/superpowers:writing-plans
(1) 初始化项目目录，创建src、test、config三个文件夹，明确各文件夹用途(2) 安装依赖（express、jsonwebtoken、bcrypt、express-rate-limit、mongoose），配置依赖版本(3) 定义User数据模型，配置数据库连接（MongoDB），实现密码加密逻辑（bcrypt）(4) 编写注册接口逻辑，实现参数校验、邮箱/手机号格式校验、密码加密存储(5) 编写登录接口逻辑，实现账号密码校验、登录失败次数统计、账号锁定、JWT令牌生成(6) 编写用户信息接口和账号解锁接口，实现对应业务逻辑(7) 编写接口限流逻辑，配置限流规则（10次/分钟）(8) 编写测试用例，覆盖所有接口的正常场景、异常场景(9) 进行代码审查，优化代码结构、补充异常处理(10) 本地测试，验证所有功能是否符合OpenSpec规范

豆包经验：任务拆解的粒度，一定要适合自己的开发节奏。

如果是个人开发，2-5分钟一个任务，能避免疲劳；

如果是团队开发，可以根据成员分工，调整任务粒度——核心是“不盲目、有计划”。

第四步：高质量实现（TDD + 代码审查，Superpowers主导）

这一步是核心，也是保证代码质量的关键。

豆包建议大家，一定要激活Superpowers的TDD技能，严格遵循“先写测试、再写代码、最后审查”的流程，避免AI“走野路子”。

具体操作指令：

# 激活TDD工作流（核心：先测试，再代码）
/superpowers:workflow activate tdd
# 生成测试用例 → 生成代码 → 代码审查（三步缺一不可）
/superpowers:tdd generate-test --module user-auth
/superpowers:tdd generate-code --module user-auth
/superpowers:code-review --file src/auth/.js
(1) 测试用例：覆盖注册参数校验、密码加密、登录失败、账号锁定、限流、解锁等所有场景
   - 比如：测试密码长度不足8位的提示；测试登录失败3次后账号锁定；测试限流场景下的响应
(2) 代码实现：按测试用例编写接口逻辑，确保所有测试用例通过（豆包提醒：测试不通过，绝不进入下一步）(3) 代码审查：检查代码规范、安全漏洞（如密码明文存储、接口无参数校验）、性能问题（如数据库查询冗余）(4) 优化调整：根据审查意见修改代码，重新运行测试，确保测试100%通过(5) 验证接口：使用Postman测试接口，确保接口响应与OpenSpec规范一致，错误提示清晰(6) 补充注释：为核心逻辑（如密码加密、JWT生成）添加注释，提升可维护性——后续自己或团队修改，能快速看懂*

这里豆包再强调一句：TDD不是形式，而是一种工程化思维。

很多人觉得“先写测试太麻烦”，但豆包用经验告诉你，先写测试，能避免后续大量返工。

你想，测试用例定好了，代码只要满足测试用例，就不会偏离需求，也能减少漏洞。

第五步：验证与归档（两者协同）

开发完成后，不要直接交付，一定要做最后验证，然后归档变更，形成可追溯的记录——这是工程化开发的必备环节，也是后续维护的重要依据。

具体操作指令：

# Superpowers: 完成前验证（全面检查，避免遗漏）
/superpowers:verification-before-completion
# OpenSpec: 归档变更，更新主规范（豆包提醒：归档要详细，便于后续追溯）
/opsx:archive user-auth
(1) 运行所有测试用例，确保100%通过，测试覆盖率≥80%(2) 验证接口响应与OpenSpec规范一致，所有业务规则都已实现(3) 归档提案，生成变更日志，记录开发过程、修改内容、测试结果(4) 更新主规范文档，同步至团队共享目录（如GitLab、GitHub），确保所有成员都能查看(5) 备份测试报告、API文档，便于后续排查问题、版本回滚

流程图：Superpowers × OpenSpec 协同工作流（原文图示保留，核心逻辑为“提案→规范→计划→实现→验证→归档”）

豆包总结：这5步闭环，看似繁琐，但只要坚持下来，你会发现，开发效率和代码质量都会大幅提升——少返工、少踩坑，这才是工程化开发的意义。

豆包提示：原文3w字以上，超过平台限制，此处省略 1000字，具体请参考免费pdf。

完整版本，请参考豆包免费百度网盘免费pdf ，点赞收藏本文后，截图找豆包获取

三：Superpowers、OpenSpec、Harness = AI 编程工具链三层拼图+黄金王炸

很多开发者都有个误区，觉得只要模型够强，就能搞定所有开发问题，其实真不是这样。

AI编程从“让模型写代码”走向“让模型像团队一样开发”，中间差的不是更强的模型，而是一套能落地、能闭环的工程基础设施。

这其中，OpenSpec、Superpowers、Harness三者的组合，恰好搭起了“规范—执行—协作”的完整三层体系，完美解决多Agent协同中的分工混乱、规范不一、质量不可控等核心痛点。

OpenSpec管“做什么”，Superpowers管“怎么做”，Harness管“谁来做、怎么协同”。

三者各管一层，互不越界却又层层支撑，合在一起才是完整的AI编程工程化开发体系。这里豆包必须插一句，这套体系的核心逻辑，其实暗合了咱们架构设计里的分层架构思维。

每一层只负责自己的核心职责，层与层之间低耦合、高内聚，既保证了每一层的独立性，又能通过协同实现整体价值最大化，这也是我为什么一直推崇这套组合的核心原因。

很多开发者在使用AI编程时，都会经历这样的演进，一般都是这样的：

一开始，就是让模型直接写代码。这个场景，能跑，但质量完全不可控。没有规范、没有测试、没有审查，改了这里崩了那里，AI幻觉一上来，写的代码能偏离需求十万八千里。
后来，慢慢开窍了，开始给模型加规则，写AGENTS.md、加Prompt约束、上Harness，开发过程确实稳了不少，至少不会出现明显的低级错误。
再后来，项目大了，开始上多Agent协作——角色分工、并行开发、自动审查，本以为能事半功倍，结果新问题又来了：每个Agent都按自己的理解做事，规范不统一，流程不一致，协作效率低下，甚至出现权限冲突、任务重复的问题。

相信很多同学都遇到过这种情况，对吧？

其实，要解决第三阶段的问题，很简单，就是让三层东西同时到位：统一的规范、统一的流程纪律、统一的团队协作框架。对应的，就是OpenSpec、Superpowers和Harness，三者层层递进、相互支撑，构成完整的AI工程化体系，缺一不可。

3.1、三层拼图各管什么？

很多同学分不清这三个工具的定位，总觉得它们是重复的，

其实不然。豆包做了一张清晰的对比表，大家一看就懂，不用死记硬背：

层次	工具	管什么（核心职责）	类比

规范层

OpenSpec

做什么——需求、接口、验收标准、变更管理，确保所有Agent对需求理解一致

施工图纸


纪律层

Superpowers

怎么做——TDD、代码审查、验证流程、任务拆解，确保Agent按工程最佳实践开发

施工规范手册


协作层

Harness / Agent Team

谁来做——角色分工、任务调度、权限管控、多Agent协同，确保团队有序高效配合

项目经理 + 工地管理

一句话总结三者关系，记牢这句话，你就抓住了核心：

OpenSpec 定标准，Superpowers 保纪律，Harness 管团队。

三者结合，才能实现AI编程从“能跑”到“可靠、可维护、可协同”的跨越，这也是AI编程能落地到生产级项目的关键。豆包见过太多团队，要么缺规范，要么缺纪律，要么缺协作，最后项目烂尾，真的很可惜。

3.2、三层工具详细解析（核心功能+价值）

下面豆包结合自己的实操经历，逐一拆解这三个工具，不讲虚的，只讲实际用法、痛点和价值，保证大家看完就能上手。

1. 规范层：OpenSpec——锁定“做什么”

先跟大家说，OpenSpec是一个Spec-Driven Development（规范驱动开发）框架，由Fission-AI开源，核心解决的就是“多Agent协作时，如何保证大家对‘做什么’的理解一致”的问题。

可能有同学会说，我一个人开发，不用这么麻烦吧？

一开始，大家都这么想，觉得规范是团队才需要的东西，个人开发怎么省事怎么来。

结果呢？

一个小项目，可能会改三次需求，每次都忘了之前定的接口字段，最后越改越乱，返工了整整两天——这就是没有规范的代价，哪怕是个人开发，规范也能帮你少走很多弯路。

无 OpenSpec 的痛点

你在聊天窗口里告诉Agent“加一个用户认证模块”，Agent按自己的理解去做。

做出来发现接口字段命名不一致、验收标准不明确、功能遗漏，改了三轮还在返工；多Agent协作时，每个Agent都按自己的理解开发，最后整合时出现大量冲突，无法正常运行。

豆包某vip反馈说他们team 之前做一个支付模块，就是因为没有用OpenSpec，后端Agent写的接口字段是“user_id”，前端Agent理解成了“userId”，联调时卡了整整一天，最后只能返工修改，浪费了大量时间。这种低级错误，其实只要有规范，就能完全避免。

有 OpenSpec 的优势

很简单，先写一份spec文件，明确定义需求、接口、数据模型、验收条件，所有Agent（及人类开发者）都读同一份spec开工，做完了按spec验证：

符合就通过
不符合就打回
从根源上减少需求偏离和返工。

还是刚才的支付模块，如果引入了OpenSpec，提前在spec里明确了所有接口字段、数据类型、业务规则，前端和后端Agent都按spec开发，联调时一次性通过，效率直接翻倍。

这就是规范的力量，它不是束缚，而是效率的保障。

OpenSpec 的核心工作流

其实很简单，就四步：

propose（提出变更）→ spec（编写规格）→ verify（验证产出）→ archive（归档）
全程可追溯，不用记复杂的操作。

输出的openspec/ 目录包含：提案、规格、任务拆解、验证结果。

特点：结构化、可追溯、所有Agent共享，确保需求不再只活在聊天记录里，而是可查阅、可修改、可追溯的结构化文档。

豆包现在不管做什么项目，都会先建一个openspec目录，把需求规范写清楚，后续不管是自己修改，还是交给Agent开发，都能省很多事。

OpenSpec 关键价值

需求结构化：将口头需求、聊天记录转化为规范文档，避免模糊不清。豆包见过太多需求，口头说的和实际想要的完全不一样，写进spec里，大家都能看明白，减少沟通成本。
理解统一：多Agent共享同一份规范，不会各做各的，减少协作冲突。这一点，团队开发尤其重要，避免出现“各说各的理”的情况。
验收明确：有清晰的验收标准，不是“看起来差不多就行”，确保交付质量。豆包之前做项目，经常遇到“做完了，但不符合预期”的情况，有了spec，验收标准一目了然，避免扯皮。
变更可追溯：每一次需求变更都有提案、验证、归档记录，便于后续排查问题、版本回滚。项目越大，这点越重要，不然出现问题，都不知道是哪一次变更导致的。

2. 纪律层：Superpowers——锁定“怎么做”

聊完规范，再聊执行。

有了“做什么”的标准，还得有“怎么做”的纪律，不然Agent还是会走野路子，写出来的代码质量依旧不可控。

Superpowers就是干这个的，它是一个面向AI编程的技能系统，由obra开源，核心解决“怎么让Agent按工程最佳实践写代码，而不是走野路子”的问题。

大家一开始用Agent开发，就遇到过这样的问题：

Agent直接上手写代码，不写测试、不做计划、不走审查，代码能跑但不可维护，测试覆盖率为零，存在安全漏洞和性能问题；
不同Agent的开发风格差异大，后续维护成本极高。

如果引入了Superpowers，这些问题都能得到解决。

无 Superpowers 的痛点

Agent直接上手写代码，不写测试、不做计划、不走审查，代码能跑但不可维护，测试覆盖率为零，存在安全漏洞和性能问题；

不同Agent的开发风格差异大，后续维护成本极高。

豆包曾接手一个别人用Agent开发的项目，代码没有一句注释，没有一个测试用例，改一个小bug，牵一发而动全身，最后只能推倒重写，真的太坑了。

有 Superpowers 的优势

Agent在开发前被加载对应技能，强制执行工程最佳实践。

比如加载TDD技能，就必须先写测试、再写实现，测试不通过就不能继续；
加载代码审查技能，每段代码都必须经过评审才能合并，从流程上保证代码质量。

豆包现在开发，都会给Agent加载TDD和代码审查技能，哪怕是简单的接口开发，也必须先写测试用例，再写代码。

这样做虽然多花了一点时间，但后续维护起来特别轻松，也很少出现bug，长期来看，效率反而更高。

这里其实也融入了咱们模块化设计的思维，Superpowers的每一个技能都是一个独立的模块，按需加载，既不冗余，又能精准解决问题，这也是它好用的核心原因。

Superpowers 的核心能力（技能详解）

很多同学觉得Superpowers技能多，不好记，豆包挑核心的、常用的给大家讲，不用全部掌握，重点掌握2-3个就够了：

技能	核心作用

test-driven-development（TDD）

先写测试用例，再编写代码实现，测试不通过则持续修改，确保代码符合预期功能。这是豆包最推荐的技能，没有之一，能从根源上保证代码质量。


writing-plans

开发前先输出详细开发计划，明确步骤、依赖、时间粒度，不允许直接上手写代码。避免Agent盲目编码，减少返工。


code-review

代码编写完成后，自动审查代码规范、安全漏洞、性能问题，提出优化建议，不通过则无法合并。相当于给代码加了一道“安全阀”。


verification-before-completion

开发完成前，自动验证代码是否符合OpenSpec规范、测试是否通过，防止“嘴上完成但实际未达标”。避免出现“交付了，但不能用”的情况。


brainstorming

面对复杂问题，先进行头脑风暴，梳理解决方案和开发思路，再动手开发，避免盲目编码。适合复杂功能开发，能帮Agent理清思路。

补充说明：Superpowers的技能是纯Markdown定义，零依赖，可以嵌入任何AI会话，支持按需加载。

按需加载，就是不是一次性塞满所有技能，而是根据任务类型激活对应技能，避免上下文过长导致模型表现变差。

如果一开始把所有技能都加载上，结果Agent反应变慢，还会经常出错，按需加载，效果好了很多。

关键价值

流程有纪律：Agent的开发流程被严格约束，遵循TDD、审查、验证等最佳实践，不走野路子。豆包现在团队开发，所有Agent都必须遵循Superpowers的技能纪律，代码质量提升了不止一个档次。
质量有保障：代码不仅“能跑”，还具备可维护性、安全性，测试覆盖率达标，减少后续bug。这也是生产级项目的核心要求，不能只追求“能跑”，还要追求“可靠”。
风格统一：强制执行统一的开发规范和代码风格，便于团队协作和后续维护。不用再面对“千人千风格”的代码，后续修改、迭代都很轻松。
降低门槛：即使是不熟悉工程最佳实践的Agent，也能通过加载技能，输出高质量代码。豆包团队的新人Agent，只要加载对应的技能，就能快速上手，不用花大量时间培训。

3. 协作层：Harness / Agent Team——锁定“谁来做”

有了规范（OpenSpec），有了纪律（Superpowers），最后就是解决“谁来做、怎么协同”的问题——这就是Harness的核心作用。

Harness在这个体系里负责的是多Agent的编排与管控，核心解决“多个Agent怎么分工、怎么并行、怎么不互相冲突”的问题，是多Agent协同开发的核心支撑。

豆包一个cto级的vip反馈，他们团队在做大型项目时，一开始没有用Harness，多Agent协同简直是“灾难”。

前端Agent和后端Agent对接口的理解不一致，测试Agent拿到的是过时的代码，安全Agent根本不知道其他人改了什么；

出现权限冲突（如多个Agent同时修改同一个文件）、任务重复、并行效率低下等问题，甚至导致项目崩溃过一次，现在想起来都心有余悸。

无 Harness 的痛点

多个Agent各自领了任务开始干，但没人统一分工：前端Agent和后端Agent对接口的理解不一致，测试Agent拿到的是过时的代码，安全Agent根本不知道其他人改了什么；出现权限冲突（如多个Agent同时修改同一个文件）、任务重复、并行效率低下等问题，甚至导致项目崩溃。

豆包一个cto级的vip，他们之前做一个电商平台的订单模块，因为没有Harness，两个Agent同时修改同一个文件，导致代码冲突，丢失了部分功能，返工了整整两天。

有 Harness 的优势

通过明确角色分工、任务调度、权限管控，让多Agent像人类团队一样有序协作，并行开发、互不干扰，同时通过硬约束确保开发流程不跑偏。

豆包一个cto级的vip ，他们团队引入Harness后，多Agent协同效率提升了60%，再也没有出现过权限冲突、任务重复的问题，项目推进也顺畅了很多。

Harness 的核心功能

角色定义：通过AGENTS.md明确每个Agent的职责——比如架构师（负责整体架构设计）、后端开发（负责接口实现）、测试（负责测试用例编写与执行）、安全（负责安全漏洞检测）、Team Lead（负责任务调度与评审）。豆包会在AGENTS.md里写清楚每个Agent的职责边界，避免越权操作。
任务调度：Team Lead Agent读取OpenSpec的任务列表，根据各Agent的职责，将任务分派给对应角色，确保任务不重复、不遗漏。不用人工手动分派任务，节省了大量时间，也避免了任务分配不合理的问题。
权限管控：每个Agent只能操作自己负责的文件和目录，避免越权操作（如测试Agent不能修改后端代码），防止权限冲突。这一点特别重要，能有效避免代码被误改、功能丢失的问题。
硬约束：设置提交前的校验规则——必须跑测试、Lint、安全扫描，不通过就不让合并，从源头避免不合格代码进入项目。豆包团队设置了严格的硬约束，凡是测试不通过、有安全漏洞的代码，一律不能合并，确保了代码质量。
反馈回路：测试失败后，自动将失败信息回灌给开发Agent，开发Agent修复后重新提交，形成“开发—测试—修复”的闭环。不用人工手动反馈，提升了问题修复效率，也避免了问题遗漏。

关键价值

协作有序：多Agent分工明确、调度合理，不再各自为战，提升协同效率。豆包团队现在多Agent协同，各司其职，并行开发，项目周期缩短了30%以上。
风险可控：权限隔离防止越权操作，硬约束防止偷工减料，减少项目风险。生产级项目，风险控制是重中之重，Harness恰好解决了这一点。
效率提升：支持任务并行开发，可追踪、可回滚，大幅缩短开发周期。尤其是大型项目，并行开发能节省大量时间，提前完成交付。
可扩展性强：项目大了可以增加Agent角色，项目小了可以减少Agent，灵活适配不同项目规模。豆包从个人小项目到企业级项目，都用Harness，适配性特别好。

3.3、三层工具怎么串起来？（完整开发周期）

很多同学看完三个工具，还是不知道怎么用，觉得很复杂。

其实不用慌，豆包结合自己的实操经历，给大家梳理了一个完整的开发周期，三者协同配合，形成“规范—分工—开发—验收”的完整闭环，大家直接照搬就行，不用自己摸索。

而且回头讲实操录制为视频，大家一看就知道了。

这里要再强调一句，这套闭环的核心，还是咱们的分层架构思维：每一层各司其职，层与层之间协同配合，不越界、不缺位，这也是这套体系能稳定落地的关键。

豆包提示：原文3w字以上，超过平台限制，此处省略 1000字，具体请参考免费pdf。

完整版本，请参考豆包免费百度网盘免费pdf ，点赞收藏本文后，截图找豆包获取

3.6、核心优势总结

结合豆包的实操经历，这套体系的核心优势，其实就5点，简单好记，大家记牢就行：

(1) 需求不跑偏：OpenSpec固化需求为结构化规范，Superpowers严格按规范执行，Harness确保所有Agent围绕规范协作，避免AI幻觉与需求偏离。这一点，是这套体系最核心的优势，能从根源上减少返工。

(2) 质量有保障：Superpowers提供TDD、代码审查、自动化验证等全流程纪律约束，Harness增加提交前硬约束，OpenSpec负责验收验证，全方位确保代码质量与可靠性。生产级项目，质量就是生命线，这套体系能很好地保障质量。

(3) 协作更高效：OpenSpec提供共享规范，减少沟通成本；Harness实现多Agent有序分工、并行开发；Superpowers统一开发流程，让团队（含Agent）协作更顺畅。豆包团队引入这套体系后，沟通成本减少了50%，协同效率提升了60%。

(4) 变更可追溯：OpenSpec负责提案、归档，记录每一次变更；Harness记录任务分配与完成情况；Superpowers记录开发过程，全程可追溯、可回滚，便于问题排查。项目越大，这点越重要，能有效降低维护成本。

(5) 灵活适配性：三者均为开源、低依赖工具，可无缝集成现有开发流程，适合从个人项目（Superpowers+OpenSpec）到企业级多Agent协同项目（三者全用）的各类场景。豆包从个人小项目到团队协作项目，都在用这套体系，适配性特别好。

3.7、分阶段落地建议

很多同学看到这套体系，觉得很复杂，不知道从哪里下手。

豆包给大家的建议是：不用追求一步到位，按优先级逐步落地，投入产出比更高。结合豆包的落地经验，分三个阶段来，新手也能快速上手：

(1) 第一阶段：先上 OpenSpec（基础）哪怕只是手写一份简单的需求spec，也比在聊天窗口里口头描述强十倍。重点掌握propose（提案）、spec（规范）、archive（归档）核心流程，建立规范意识，确保需求有记录、有验收标准，解决“做什么”的问题。（1天可上手）豆包一开始，就是从手写spec开始的，不用追求完美，只要把需求、接口、验收标准写清楚就行，后续再慢慢优化。

(2) 第二阶段：再上 Superpowers 核心技能（提升质量）不用加载所有技能，优先启用test-driven-development（TDD）和verification-before-completion（完成前验证），这两个技能投入产出比最高，能快速解决“怎么做”的问题，确保代码质量，避免Agent走野路子。后续再逐步添加brainstorm、code-review等技能。豆包建议，新手先掌握TDD技能，这是提升代码质量的关键，也是最容易上手的技能。

(3) 第三阶段：最后上 Harness / Agent Team（协同增效）等需求规范和开发纪律稳定后，再引入Harness，实现多Agent协同开发。重点搭建角色分工（AGENTS.md）、任务调度和权限管控，避免过早引入协作层导致的混乱——分工越多，若规范和纪律不到位，乱得越厉害。豆包团队就是在规范和纪律稳定后，才引入Harness的，这样能避免很多不必要的麻烦，协同效率也更高。

3.8、避坑提醒（关键注意事项）

结合豆包踩过的坑，给大家提5个关键注意事项，能帮大家少走很多弯路，一定要记牢：

Superpowers 技能按需加载：不要全部加载，否则会让上下文过长，模型反而表现变差；根据任务类型（如开发、重构、测试）激活对应技能即可。豆包一开始就犯过这个错，把所有技能都加载上，结果Agent反应变慢，还经常出错，后来按需加载，效果好了很多。
AGENTS.md 写精简：只明确各Agent“先看什么（OpenSpec规范）、按什么流程（Superpowers技能）”，架构和业务细节放docs/目录，避免内容冗余。豆包之前把AGENTS.md写得太复杂，Agent反而找不到重点，后来精简后，协作效率提升了不少。
避免技能冲突：如果Harness自带代码审查、测试等能力，关掉Superpowers里的对应技能，避免重复校验，影响开发效率。豆包团队之前就出现过重复校验的情况，导致开发效率变慢，关掉其中一个技能后，就好了。
规范先行：无论项目大小，先定OpenSpec规范，再开始开发，避免“边开发边定规范”，导致需求反复、返工增多。这是豆包踩过的最痛的坑之一，大家一定要避开。
小项目试水：个人开发者或小型团队，可先用简单功能（如TODO列表、简单接口）实践Superpowers+OpenSpec的流程，熟练后再推广到复杂项目。新手不要一开始就用在大型项目上，先从小项目入手，积累经验，再逐步推广。