本文 的 原文 地址

原始的内容，请参考 本文 的 原文 地址

本文 的 原文 地址

尼恩说在前面

在45岁老架构师尼恩的读者交流群（50+人）里，最近不少小伙伴拿到了阿里、滴滴、极兔、有赞、希音、百度、字节、网易、美团这些一线大厂的面试入场券，恭喜各位！

前两天就有个小伙伴面腾讯、 京东、美团、小米等， 都 问到 “你们怎么做AI编程 ？ 只是用了几个 AI插件吗？ ”的场景题 ，小伙伴没有一点概念，导致面试挂了。

小伙伴 没有看过系统化的 答案，回答也不全面 ，so， 面试官不满意 ， 面试挂了。

小伙伴找尼恩复盘， 求助尼恩。

通过这个 文章， 这里 尼恩给大家做一下 系统化、体系化的梳理，写一个系列的文章组成 尼恩编著 《Harness 架构与源码 学习圣经》 深入剖析 Harness AI 平台级 架构的 架构思维与 核心源码，使得大家可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”。

同时，也一并把这个题目以及参考答案，收入咱们的 《尼恩Java面试宝典PDF》V176版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。

尼恩编著 《Harness 架构与源码 学习圣经》

第一章： 什么是 Harness架构？2026年AI核心范式解析 ： Harness架构与Agent工程化

具体文章： 54k+Star 爆火！AI 框架 新王者 Harness Agent 来了！尼恩 来一次Harness穿透式解读

第二章： Harness架构 与 LangChain、LangGraph 三者联动 的底层逻辑

具体文章： Harness架构 与 LangChain、LangGraph 三者联动 的底层逻辑

第三章： DeerFlow 源码 14层Middleware 源码解析 ，又一个 “洋葱责任链模式” 架构思维 的 经典案例

具体文章： DeerFlow 源码 14层Middleware 源码解析 ，又一个 “洋葱责任链模式” 架构思维 的 经典案例

第四章： LangChain 超底层 四大设计模式 Design Patterns ，架构师 的 必备 内功，毒打面试官

具体文章： LangChain 超底层 四大设计模式 Design Patterns ，架构师 的 必备 内功，毒打面试官

第五章：Harness宏观架构：基于 PPAF 思维 & REPL 思维，完成 Lead-Agent和Sub-Agent深度拆解

具体文章： 第五章：Harness宏观架构：基于 PPAF 思维 & REPL 思维，完成 Lead-Agent和Sub-Agent深度拆解

第六章：Harness宏观架构：DeerFlow 2.0 断点续跑机制 架构设计与实现

具体文章： Harness宏观架构：DeerFlow 2.0 断点续跑机制 架构设计与实现

第七章： Harness 平台实战： 用 DeerFlow 构建 一个企业自己的 Manus 平台（ 企业长任务智能体平台）

具体文章： Harness 平台实战： 用 DeerFlow 构建 一个企业自己的 Manus 平台（ 企业长任务智能体平台）

第八章： Harness 超牛逼的 三级记忆架构 上下文+历史分层+事实列表 ！ 落地价值 逆天！！

具体文章： Harness 超牛逼的 三级记忆架构 上下文+历史分层+事实列表 ！ 落地价值 逆天！！

第九章： Harness 顶级架构：DeerFlow 2.0 沙盒 Sandbox 架构设计、Sandbox 源码深度解析（史上最深 、价值 逆天）

具体文章： Harness 顶级架构：DeerFlow 2.0 沙盒 Sandbox 架构设计、Sandbox 源码深度解析（史上最深 、价值 逆天）

第10章： 顶奢RAG架构之, 必不可少的 RAG评估体系：7大核心指标落地优化，让RAG从Demo走向生产

【RAG评估、RAG度量指标】顶奢RAG架构之, 必不可少的 RAG评估体系：7大核心指标落地优化，让RAG从Demo走向生产 full - 技术自由圈

第11章：Harness架构 ： DeerFlow 2.0 的 lead_agent 任务总调度 架构设计与实现解析

Harness架构 ： DeerFlow 2.0 的 lead_agent 任务总调度 架构设计与实现解析

第十二章： Harness 具体应用：AI编程王炸组合：顶级三剑客 OpenSpec 定方向，Superpowers定纪律，Harness定协同

本文

第13章： 深度解析字节跳动DeerFlow 2.0：基于LangGraph的生产级Super Agent驾驭层实现

具体文章： 尼恩还在写， 本周发布

第14章： 基于 PPAF 思维，完成 与 Harness 工程化的 Lead-Agent 和 Sub-Agent 深度拆解.

具体文章： 尼恩还在写， 本周发布

第15章：Harness架构 核心一：断点续跑机制 的 架构设计 与底层源码分析 .

具体文章： 尼恩还在写， 本周发布

第16章：Harness架构 核心二： XXX

具体文章： 尼恩还在写，后续发布

估计有 10章以上，具体请关注技术自由圈。

AI编程王炸 三件套：OpenSpec 定方向，Superpowers定纪律，Harness定协同

用AI写代码 越来越普遍了 ，很多公司都禁止手写代码， 然后， 大家 也遇到太多糟心事儿 。

比如 需求发给ai，但是 结果生成的代码要么偏离预期，要么漏洞百出；

再比如，自己用ai 写代码，还能把控质量，一旦团队上了规模，再加上几个AI Agent 协同，直接乱成一锅粥——分工不明、理解不一。

改来改去返工不断，最后项目延期，老板追问，自己也闹心。

其实，这不是大家能力不行。

也不是AI不够强，核心问题就一个：你的AI编程，用的不工业。

工业级的AI编程， 需要 Superpowers Skills、OpenSpec与Harness的组合逻辑 。

工业级的AI编程，本质上是搭建了“规范—执行—协作”的完整三层体系，刚好对应分层架构的核心思维，每一层各司其职、互不越界，又层层支撑、相辅相成，彻底解决AI编程的核心痛点。

说直白点：

• OpenSpec负责“做什么”，把模糊的需求变成明确的规范，确保所有人（包括AI Agent）都在一个频道上；
• Superpowers负责“怎么做”，用工程化纪律约束AI，避免它“走野路子”，保证代码质量；
• Harness负责“谁来做、怎么协同”，让多Agent像人类团队一样有序配合，不内耗、不冲突。

今天，尼恩就结合自己的实操经验，把这套体系掰开揉碎了讲：

• 从“Superpowers与OpenSpec的黄金搭档”
• 到“三层拼图的完整协同”
• 再到实操工作流、复杂场景案例和落地建议

全程干货，没有废话，无论是个人开发者还是团队，看完都能直接上手，实现开发效率与代码质量的双重提升。

一： Superpowers Skills与OpenSpec 黄金搭档

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

大错特错！

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

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

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

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

1. 定位与能力互补

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

工具	核心定位	解决问题	核心能力
OpenSpec	轻量级规范驱动开发（SDD）框架	需求模糊、AI 幻觉、变更不可追溯、多Agent理解不一致；尼恩见过太多团队，因为没有统一规范，AI写的代码和人类开发者写的代码风格迥异，接口不兼容，最后整合时全是冲突	提案管理、规范沉淀、变更追踪、团队协作、需求验证；简单说，就是把“口头需求”变成“书面标准”，让所有人都有章可循
Superpowers Skills	Claude Code 技能扩展库	执行失控、质量低下、流程不规范、Agent开发“走野路子”；尼恩早期用AI写代码，就遇到过AI不写测试、直接上手撸代码的情况，后期维护的时候，一个小修改就崩掉整个模块	头脑风暴、TDD（测试驱动开发）、代码审查、自动化验证、任务拆解；核心就是给AI“立规矩”，强制它遵循工程最佳实践，不能随心所欲

这里尼恩插一句：

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

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工程化体系，缺一不可。

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

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

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

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

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

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

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

Phase 1：规范定义（OpenSpec 主导）

项目启动后，首先由OpenSpec主导，定义需求、接口、验收标准，生成结构化的spec文档，输出openspec/目录，供所有Agent（及人类开发者）共享，确保大家对“做什么”的理解一致。

尼恩的习惯是，项目一开始，先组织团队（或Agent）梳理需求，把需求、接口、数据模型、验收标准都写进OpenSpec，然后组织评审，确保规范无冲突、覆盖所有需求，这一步做好了，后续开发会少走很多弯路。

Phase 2：分工调度（Harness 主导）

规范定义完成后，由Harness组建Agent Team，通过AGENTS.md明确各Agent的角色与职责；

然后由Team Lead Agent读取OpenSpec的任务列表，将任务拆解后分派给对应角色（如架构师负责架构设计、后端负责接口开发）。

这里尼恩提醒大家，任务拆解要细致，最好拆到2-5分钟粒度，这样Agent执行起来更清晰，也不容易出现任务遗漏。

同时，要明确每个Agent的职责边界，避免出现分工模糊、互相推诿的情况。

Phase 3：规范开发（Superpowers 主导）

分工完成后，各Agent按Superpowers的技能纪律开展开发：

• 加载TDD技能，先写测试再写实现；加载代码审查技能，确保代码符合规范；
• 加载验证技能，完成前进行自我验证，确保开发过程符合工程最佳实践，且不偏离OpenSpec规范。

在这一步，会给不同角色的Agent加载对应的技能：

• 后端Agent加载TDD、代码审查技能，
• 测试Agent加载验证技能，
• 架构师加载头脑风暴技能，确保每个Agent都能按最佳实践开展工作。

Phase 4：验收归档（三者协同）

开发完成后，进入验收归档阶段，这一步需要三者协同：

• OpenSpec验证产出是否符合spec规范，Harness校验权限、运行提交前硬约束（测试、Lint、安全扫描）；
• 验证通过后，OpenSpec归档变更，更新主规范，生成变更日志；
• Harness记录各Agent的任务完成情况，形成完整的开发记录。

这一步需要 特别重视，因为归档记录不仅能便于后续排查问题、版本回滚，还能为后续类似项目提供参考，积累经验。

3.4 完整调用链条

最后，尼恩给大家梳理一个完整的调用链条，记牢这个链条，就能快速上手三者的协同：

Harness 启动 → 加载 AGENTS.md 定义角色 → Architect Agent 读取 openspec/specs/ 设计架构 → Superpowers 激活对应技能（TDD、代码审查等）→ Backend Agent 按 spec + 技能纪律写代码 → Reviewer Agent 按 Superpowers 规则评审 → Harness 校验权限、运行钩子（测试、Lint）→ OpenSpec 验证产出 → 归档完成。

是不是很清晰？其实不用死记硬背，多实操一次，就能熟练掌握。

3.5 三层配合原则

这里尼恩给大家总结一个核心原则，记牢这个原则，就能灵活应对不同项目场景：

规范不变、流程不变、团队可弹性扩展。

• OpenSpec和Superpowers定义的是稳定的标准和纪律，确保开发质量和需求一致性；
• Harness定义的是灵活的团队结构和调度策略
• 项目大了可以加Agent，项目小了可以减，但规范和纪律始终不变，保证开发流程的稳定性。

三层配合，无论是个人小项目，还是几十人的团队协作项目，规范和纪律始终不变，只根据项目规模调整Agent数量和分工，既保证了代码质量，又提升了灵活性。

聊到这里，相信大家对Superpowers、OpenSpec与Harness的协同体系，已经有了清晰的认识。尼恩再跟大家梳理一下核心要点，同时给大家一些落地建议——毕竟，再好的工具和体系，不能落地都是空谈。

先跟大家说句实话，尼恩一开始引入这套体系时，也遇到过很多问题，比如不知道怎么按需加载Superpowers技能、AGENTS.md写得太冗余、过早引入Harness导致协作混乱等等。后来慢慢摸索、不断优化，才形成了一套可落地的流程，所以大家不用怕踩坑，多实操、多调整，就能熟练掌握。

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.9、结语

最后，尼恩再跟大家聊几句心里话。Superpowers Skills、OpenSpec与Harness的组合，不仅是工具的叠加，更是AI编程理念的升级——从“随机生成代码”到“规范驱动、纪律执行、协同高效”的工程化开发。

OpenSpec锁需求，Superpowers锁纪律，Harness锁协作，三层拼齐，AI才能从“写代码的助手”变成“可靠的开发团队”。这不是未来的愿景，而是现在就能落地的工程实践。

OpenSpec、Superpowers和Harness都是开源项目，文档齐全，可以从最小配置开始用起。关键不在于一步到位，而在于知道三层各管什么、缺哪层会出什么问题，逐步优化、稳步落地。

尼恩从一开始的踩坑无数，到现在能熟练运用这套体系，带领团队高效开发，深刻体会到：AI编程的核心，从来不是模型有多强，而是有没有一套能落地的工程化体系。

无论是个人开发者，还是团队，掌握这套组合拳，都能在AI编程时代占据先机，大幅提升开发效率与代码质量，让AI真正成为高效、可靠的开发伙伴。

最后，尼恩想问大家：你在AI编程中，有没有遇到过需求跑偏、协作混乱的问题？

不妨试试这套体系，相信会给你带来惊喜。

如果大家在落地过程中遇到任何问题，也可以在评论区留言，尼恩会尽力帮大家解答。