AI编程进阶| @胡彦斌，你要懂不仅仅是Vibe Coding，还有 ......01 前言近期网络上流传的新闻是：胡

01 前言

近期网络上流传的新闻是：胡彦斌使用 Vibe Coding（凭感觉写代码）模式独立开发了一款名为 "彦火" 的专属粉丝社区 APP，于 2026 年 5 月 30 日正式上线。之前本人也写过一篇知识篇| 未来编程方式—vibe Coding，反响还不错，不过随着自身vibe Coding不断尝试，确实发现一些Vibe Coding不尽人意的地方，不仅彦斌要学，我相信包括我在内的很多使用AI编程工具的伙伴都要学习AI编程的进阶。今天给大家介绍AI进阶工具：OpenSpec + Superpowers + OMO，让AI工具从“随意编码”到“规范开发”的转变。

01 OpenSpec

当 AI 写代码越来越快，你却发现越来越难控制它写了什么——这篇指南帮你从"随性编码"走向"规范驱动"。

你一定经历过这样的场景：让 AI 帮你写一个功能，它三分钟就交出了代码，你一看——功能是有了，但命名风格和项目完全不一致，还顺手重构了你没要求改的模块，甚至悄悄引入了一个你根本不需要的依赖。你改回来，它又偏出去。来回拉扯，比手写还累。

这就是典型的"vibe coding"困境：AI 写代码没有规范约束，需求理解漂移，返工不断。更致命的是，当你让 AI 改核心业务逻辑时，你根本不敢让它直接动——因为一旦改偏，排查成本远超手写。

OpenSpec 正是为了解决这个痛点而生。而它和 Superpowers、Harness/OMO 的组合，标志着 AI 编程从早期的"炼丹术"正式迈入了"工程学"阶段。

一、OpenSpec 是什么

OpenSpec 是由 Fission-AI 开源的规范驱动开发（Spec-Driven Development，SDD）框架，它的核心理念可以用一句话概括：先定规矩，再写代码（Agree before you build）。

传统开发中，我们习惯直接让 AI 开工——"帮我写个用户登录功能"，然后祈祷它理解正确。但 AI 的理解往往和你心里想的有偏差，而偏差在代码层面会被指数级放大。OpenSpec 的做法是：在写代码之前，先让 AI 和你达成共识——把需求变成结构化的规范文档，确认无误后再动手。

维度	传统 Vibe Coding	OpenSpec 规范驱动
需求传递	自然语言一句话	结构化规范文档
确认时机	写完代码再检查	写代码前先确认规范
变更管理	无，AI 随意修改	changes/ 目录隔离变更
返工率	高，反复拉扯	低，一次到位

关键在于：在写代码之前，先让 AI 和你达成共识。这不是多此一举，而是把"返工"的成本前置为"确认"的成本——后者要便宜得多。

二、核心设计：specs/ 与 changes/ 分离

OpenSpec 最精妙的设计在于目录结构的分离。初始化后，项目根目录下会出现 openspec/ 文件夹，内部结构如下：

openspec/
├── specs/          # 已确认的规范（类似 Git 的 main 分支）
│   ├── proposal.md
│   ├── design.md
│   ├── spec.md
│   └── tasks.md
└── changes/        # 正在进行的变更（类似 Git 的 feature 分支）
    └── feature-login/
        ├── proposal.md
        ├── design.md
        ├── spec.md
        └── tasks.md

打个比方：specs/ 就像 Git 的 main 分支，存放的是经过确认、当前生效的规范；changes/ 就像 feature 分支，每个新功能或修改都在独立的子目录中起草，确认后才合并回 specs/。

这个分离至关重要。当 AI 修改某个功能时，它只会操作 changes/ 下的对应目录，不会触碰 specs/ 中已有的其他规范。这就像 Git 的分支隔离——你在 feature 分支上折腾，不会影响 main 分支的稳定性。没有这种隔离，AI 在修改 A 功能时可能悄悄改掉 B 功能的规范，而你浑然不知。

三、安装与初始化

安装 OpenSpec 非常简单，一条命令搞定：

npm install -g @fission-ai/openspec@latest

安装完成后验证版本：

openspec --version

进入你的项目目录并初始化：

cd your-project
openspec init

初始化过程中，OpenSpec 会让你选择当前使用的 AI 编码工具。它支持 20+ 主流工具，包括 Cursor、Windsurf、Claude Code、GitHub Copilot 等，确保生成的规范能被你的工具正确读取。

💡Windows PowerShell 用户注意：如果遇到执行策略限制，先运行 Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned，再执行 init 命令。

四、OPSX 核心工作流

OpenSpec 的核心工作流由四个命令组成，简称 EPSA 循环：

命令	作用	何时使用
`/opsx:explore`	探索需求，理解上下文	开始新功能前，先让 AI 理解项目现状
`/opsx:propose`	提出变更方案，生成 proposal	需求明确后，让 AI 起草变更提案
`/opsx:apply`	应用变更，将 changes/ 合并到 specs/	方案确认无误，正式写入规范
`/opsx:archive`	归档已完成的变更	功能开发完毕，清理 changes/ 目录

完整的工作流是一条清晰的链路：

explore（探索） → propose（提案） → apply（应用） → archive（归档）

如果你需要更严格的流程控制，可以切换到自定义配置文件，解锁扩展命令：

openspec config profile custom
openspec update

自定义配置下会额外提供 verify（一致性校验）、sync（规范同步）、continue（继续上次中断的流程）三个命令，适合对质量要求更高的团队。

02 Superpowers

一、 Superpowers 是什么

Superpowers 是由 Jesse Vincent（obra）创建的工程化工作流框架（GitHub 200k+ Star，MIT 协议），它的核心理念只有一句话：不信任 AI 的自发性。

你一定遇到过：让 AI 写个功能，它跳过设计直接写代码，跳过测试直接声明完成，甚至悄悄改了不相关的模块。Superpowers 就是为了治这个病——它通过 14 个可组合的 Skill（技能文件），强制 AI 在写任何代码之前，先走完"头脑风暴 → 设计文档 → 任务规划 → TDD → 代码审查"这套标准流程。

没有 Superpowers 的 AI 像一个热情但没纪律的实习生——干活快，但经常跑偏。装上 Superpowers 后，它变成了一个遵循 ISO 9001 质量体系的自动化工厂。

二、安装与配置

# 方式一：通过 Claude Code Plugin Marketplace 安装（推荐）
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
# 方式二：通过 npx skills 工具安装
npm install -g @vercel-labs/skills
npx skills add obra/superpowers
# 方式三：手动安装
git clone https://github.com/obra/superpowers.git ~/.claude/superpowers
ln -s ~/.claude/superpowers/skills ~/.claude/skills/superpowers
安装后重启 AI 代理，Superpowers 的主技能（using-superpowers SKILL.md）会自动注入到每个会话中。它的规则极其强硬：

这意味着 AI 不能"跳过"任何适用的技能——它必须先思考，再动手。

三、核心 Skill 详解

Superpowers 的 14 个 Skill 不是全都要加载。根据任务复杂度，按需选择：

Skill	触发时机	核心规则	你需要它的场景
brainstorming	检测到"我要做 X"	苏格拉底式提问，不提问不设计	需求不明确时，强迫 AI 先问清楚
using-git-worktrees	设计确认后，准备编码	每个变更独立 worktree，主分支不动	防止 AI 直接在 main 上乱改
writing-plans	开始实现前	拆分为 2-5 分钟小任务，每个任务含文件路径+完整代码+验证步骤	防止 AI 一步完成整个功能，夹带私货
subagent-driven-dev	执行任务时	每个子任务启动独立子代理，上下文隔离	大型任务并行执行，避免上下文漂移
test-driven-development	写任何实现代码前	先写失败测试 → 看它失败 → 写最小实现 → 看它通过 → 重构	核心纪律，没有测试的代码直接删除
requesting-code-review	任务完成后	两阶段审查：先审 Spec 合规，再审代码质量	防止 AI 自己审查自己，容易放水
verification-before-completion	声明完成前	必须提供证据（测试通过、lint 通过、构建通过）	防止 AI 说"做完了"但其实没验证

Skill 选择策略（重要）：不要全量加载 14 个 Skill！全量加载会消耗 ~50K tokens，撑爆上下文窗口，AI 反而表现更差。推荐组合：

组合	包含 Skill	适用场景
最小集（3 个）	TDD、verification、writing-plans	小改动、Bug 修复
推荐集（5 个）	TDD、verification、writing-plans、code-review、brainstorming	日常功能开发
完整集（7 个）	推荐集 + git-worktrees、subagent-dev	大型重构、多模块任务

四、TDD 铁律：RED → GREEN → REFACTOR

Superpowers 最核心的价值就是强制 TDD。它不是"建议你写测试"，而是"不写测试就不让你写代码"。具体流程：

RED 阶段：先写一个一定会失败的测试

// auth.test.js
describe('AuthService', () => {
  it('should register user with valid email and password', async () => {
    const user = await authService.register('test@example.com', 'password123');
    expect(user.email).toBe('test@example.com');
    expect(user.password).not.toBe('password123'); // 必须加密
  });
});
//  运行测试：失败（因为 authService 还不存在）
GREEN 阶段
：写最小的代码让测试通过
// AuthService.js
class AuthService {
  async register(email, password) {
    const password_hash = await bcrypt.hash(password, 10);
    return User.create({ email, password_hash });
  }
}
// 运行测试：通过
REFACTOR 阶段
：在不改变行为的前提下优化代码
// 添加输入验证、错误处理、日志记录
// 运行测试：仍然通过

如果 AI 试图在 RED 之前写实现代码，Superpowers 会直接拦截并删除，强制回到 TDD 流程。这条铁律不可绕过。

五、两阶段代码审查

Superpowers 的代码审查不是走过场，而是分两个独立阶段：

第一阶段：Spec 合规审查——只看"是否满足规范"

需求1：邮箱格式验证 — 已实现，测试覆盖
需求2：密码强度要求 — 已实现，测试覆盖
需求3：Token 刷新机制 — 未实现
审查结果：⚠️ONE_WITH_CONCERNS

第二阶段：代码质量审查——只看"代码写得好不好"

代码规范：符合 ESLint
安全性：密码已加密，SQL 注入已防护
测试覆盖率：92%（目标 ≥80%，通过）
审查结果：APPROVED

两阶段分离的意义：Spec 审查和代码质量审查标准不同，混在一起会导致"一个说满足规格就行，另一个说结构不行要重构"，推进停滞。

六、与 OpenSpec 的协同：三段式流程

OpenSpec 管"做什么"（规范层），Superpowers 管"怎么做"（纪律层）。两者不是简单叠加，而是形成严格的接力关系：

第一阶段：Superpowers 探索性规划

用 Superpowers 的 brainstorm 能力进行需求探索、方案讨论、设计草稿。这个阶段允许自由发散，不急于定型。AI 会主动提问："你要邮箱登录还是手机号登录？""需要第三方登录吗？""密码强度有什么要求？"

第二阶段：OpenSpec 锁定规范

当设计方向明确后，切换到 OpenSpec 流程：/opsx:propose → proposal → design → spec → tasks。把模糊的想法变成精确的规范文档，经人工确认后锁定。这一步的关键是把 brainstorm 的结论"冻结"成契约——AI 后续必须按此执行。

第三阶段：Superpowers 执行编码 → OpenSpec 归档

规范锁定后，回到 Superpowers 执行：TDD 编码、测试、两阶段审查。全部通过后，用 OpenSpec 的 /opsx:archive 归档变更。

三道关卡贯穿始终：

关卡	规则	意义
设计未确认	不进入 OpenSpec 流程	避免把模糊需求固化成规范
规范未完成	不开始编码	避免基于不确定的规范写代码
无真实测试验证	不算完成	TDD 强制执行 RED-GREEN-REFACTOR 循环

为什么必须合体？ 单独用 OpenSpec：你有了蓝图（WHAT），但施工队（AI）依然可能偷工减料，不知道怎么盖（HOW）。单独用 Superpowers：施工很细，但没有蓝图管控，干完活发现不是业主要的。OpenSpec 管"What"，Superpowers 管"How"，缺一不可。

七、任务粒度控制：2/8 法则

OpenSpec 生成的 tasks.md 是 AI 执行的指令清单。但这里有个常见陷阱：任务粒度太粗，AI 就会在细节处"夹带私货"——用自己偏好的方式填充你没想到的部分。

对比维度	粗粒度任务	细粒度任务
典型写法	"实现用户登录接口"	"在 auth.ts 中创建 login 函数，接收 email 和 password，调用 bcrypt.compare 验证，成功返回 JWT，失败抛出 AuthError"
AI 自由度	高，自行决定实现细节	低，按指令精确执行
夹带私货风险	高	低
返工概率	高	低

2/8 法则的核心洞察：花 20% 的精力升级 tasks 指令，就能获得 80% 的质量提升。具体操作分三步：

第一步：创建 config.yaml

context:
  - "本项目使用 FastAPI + SQLAlchemy"
  - "所有 API 必须包含错误处理中间件"
rules:
  - id: review
    description: "设计完成后必须经过人工审查

第二步：Fork schema，升级 tasks instruction

每个步骤花 2-5 分钟，附上完整的代码示例、命令和预期输出。不要只写"添加路由"，要写"在 routes/user.py 中添加 POST /api/users 路由，请求体 schema 如下……"。

第三步：插入 review artifact

在 design 和 tasks 之间插入审查环节，作为设计到任务转换的关卡。

这三步构成三层防线：

防线	机制	贡献度
源头控制	升级 tasks instruction	80% 质量
过程检查	review + verify 环节	安全网
最终确认	归档前人工检查	兜底保障

日常工作的六阶段流程：explore → propose → 人工检查 → apply → verify → archive。其中"人工检查"不可省略——它是你把控质量的关键节点。

03 Harness/OMO

Harness/OMO 深度解析：多 Agent 协作的编排层

一、为什么需要编排层

OpenSpec 解决了"做什么"，Superpowers 解决了"怎么做"。但当项目大到需要多个 Agent 同时工作时，新问题出现了：

- 前端 Agent 和后端 Agent 同时改 API 接口，一个改了字段名，另一个不知道，合并就炸了

- 三个 Agent 各自理解需求，对同一个"用户认证"的实现完全不同

- Agent 之间互相覆盖代码，A 刚写完，B 又改回去了

这就是 Harness/OMO 存在的意义——它定义"谁来做、怎么协同"。

二、OMO (Oh My OpenAgent) 是什么

OMO（原名 oh-my-opencode）是一个开源的多模型 Agent 编排框架（GitHub 48k+ Star），它的核心能力是把单个 AI 编码代理变成一个协调的虚拟开发团队。

OMO 的架构分三层：

规划层 (Prometheus/Metis)    → 理解需求，拆解任务
编排层 (Atlas)               → 分配任务，协调执行
执行层 (Sisyphus-Junior 等)  → 各司其职，并行干活

它内置了 10+ 专业化 Agent，每个 Agent 有明确的角色和偏好的模型：

三、OpenHarness 是什么

OpenHarness 是 OMO 的底层基础设施（Python 实现），提供 Agent 运行所需的核心能力：

组件	功能	类比
执行循环 (Agent Loop)	流式工具调用、并行执行、Token 计费追踪	工人的手
工具注册表 (Tool Registry)	43 种工具（文件、Shell、搜索、Web、MCP）	工具箱
上下文管理器 (Context Manager)	CLAUDE.md 发现、上下文压缩、会话恢复	工人的记忆
状态存储 (State Store)	持久化记忆、会话历史	工人的笔记本
生命周期钩子 (Lifecycle Hooks)	PreToolUse/PostToolUse 拦截、权限控制	安全护栏
子代理调度 (Subagent Spawning)	派遣子代理、团队注册、后台任务管理	工头

四、安装与配置

# 安装 OMO
curl -s https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/refs/heads/dev/docs/guide/installation.md | bash
# 安装 OpenHarness（底层基础设施）
pip install openharness-ai
# 验证安装
oh --version
配置文件 
opencode.json
 示例：
{
  "agents": {
    "planner": { "model": "claude-opus-4-6", "role": "规划" },
    "frontend": { "model": "gemini-flash", "role": "前端开发" },
    "backend": { "model": "claude-sonnet-4", "role": "后端开发" },
    "reviewer": { "model": "claude-opus-4-6", "role": "代码审查" }
  },
  "orchestration": {
    "ultrawork": true,
    "max_parallel_workers": 5
  }
}

OMO 的核心命令：

命令	作用	场景
`/autopilot`	自动检测意图，编排 19 个 Agent	不确定用什么流程时
`/ultrawork`	启动最多 5 个并行 Worker	大型重构、批量测试生成
`/ralph`	循环"计划→执行→验证→修复"直到任务完成	顽固 Bug 修复
`/team N`	启动 N 个协调 Agent，共享任务列表	多模块并行开发

五、 OMO 的杀手级特性：Hash-Anchored Editing

所有 AI 编码工具都有一个致命问题：AI 试图编辑一行已经变化的代码，编辑失败，重试，再失败——循环烧 Token。OMO 发明了 Hash-Anchored Editing：每行代码生成一个内容哈希指纹，编辑前先检查指纹是否匹配。如果代码已变，自动定位新位置。实测编辑成功率从 6.7% 飙升到 68.3%——10 倍提升。

04 三者协作与分工

一、三者的精确分工

OpenSpec、Superpowers、Harness/OMO 不是三个独立工具的简单叠加，而是形成了一套严密的接力系统。每一层只做一件事，且只信任上一层的输出：

┌─────────────────────────────────────────────────────────┐
│  规范层 (OpenSpec)                                       │
│  输入：模糊的需求                                        │
│  输出：proposal.md + spec.md + tasks.md                  │
│  铁律：没有确认的规范，不进入下一层                       │
├─────────────────────────────────────────────────────────┤
│  纪律层 (Superpowers)                                    │
│  输入：OpenSpec 的 tasks.md（作为执行蓝图）               │
│  输出：经过 TDD 验证的代码 + 两阶段审查报告               │
│  铁律：没有失败测试，不写实现代码                         │
├─────────────────────────────────────────────────────────┤
│  协作层 (Harness/OMO)                                    │
│  输入：OpenSpec 的 spec.md（作为统一规范源）              │
│  输出：多个 Agent 并行执行，互不冲突                      │
│  铁律：所有 Agent 共享同一份 spec，禁止各自理解           │
└─────────────────────────────────────────────────────────┘

二、数据如何流转：一个完整的需求旅程

用一个真实场景走一遍："给电商平台添加订单系统"。

第一站：OpenSpec（规范层）——把模糊变精确

你："添加订单系统"
↓
/opsx:propose "add order system"
↓
AI 生成：
  openspec/changes/add-order-system/
  ├── proposal.md  → 为什么要做、做什么、不做什么
  ├── design.md    → 技术选型（订单状态机、支付回调、库存扣减）
  ├── specs/
  │   ├── order-creation/spec.md   → "系统 SHALL 在创建订单时原子扣减库存"
  │   └── order-payment/spec.md    → "系统 SHALL 在支付超时后自动取消订单"
  └── tasks.md     → 分 3 阶段 12 个任务，每个含文件路径+验证步骤
↓
你审查 proposal.md，确认"非目标"：不做退款、不做拆单
↓
/opsx:apply → 规范锁定，进入执行

第二站：Superpowers（纪律层）——按规范严格执行

Superpowers 读取 tasks.md，开始 TDD 流程：
↓
Task 1.1: 创建 Order 模型
  RED:   先写 test_order_creation.py → 测试失败 ✗
  GREEN: 写最小实现 Order model → 测试通过 ✓
  REFACTOR: 添加索引、优化字段 → 测试仍通过 ✓
↓
Task 1.2: 实现库存原子扣减
  RED:   先写 test_stock_deduction.py → 测试失败 ✗
  GREEN: 用 SELECT FOR UPDATE 实现行锁 → 测试通过 ✓
↓
... 逐任务执行 ...
↓
两阶段审查：
  Spec 审查：对照 spec.md，12 个需求全部覆盖 ✓
  质量审查：覆盖率 91%，无安全漏洞 ✓

第三站：Harness/OMO（协作层）——多 Agent 并行

当订单系统大到需要多人并行时，OMO 接管编排：

OMO 读取 openspec/specs/ 中的 spec.md（统一规范源）
↓
Prometheus（规划 Agent）：拆解为前端/后端/测试三条线
↓
Atlas（编排层）：分配任务
  ├── Frontend Agent (Gemini Flash) → 订单列表页、详情页
  │   └── 读取 spec: order-creation/spec.md → 知道字段有哪些
  ├── Backend Agent (Claude Sonnet) → 订单 CRUD API
  │   └── 读取 spec: order-payment/spec.md → 知道超时逻辑怎么写
  └── Reviewer Agent (Claude Opus) → 代码审查
      └── 对照 spec.md 逐条检查，不是凭感觉审
↓
三个 Agent 产出合并，因为共享同一份 spec，不会"对不上"

三、缺失任何一层的真实后果

缺失层	真实场景	后果
没有 OpenSpec	3 个 Agent 各自理解"订单系统"	前端做了购物车，后端做了支付，测试做了物流——拼不上
没有 Superpowers	Agent 直接写代码，跳过测试	上线后库存扣减出现并发 Bug，超卖 200 单
没有 Harness	多人同时改同一文件	A 刚写完支付回调，B 把接口参数改了，A 的代码全废

四、三层协作的核心原则

原则一：规范是唯一的真相来源

所有 Agent、所有 Skill、所有工具，都以 openspec/specs/ 目录下的 spec.md 为准。不允许任何 Agent "按自己理解"做——理解不一致时，回去改 spec，而不是各自为政。

原则二：每层只信任上一层的输出

Superpowers 不信任 AI 的"自由发挥"，只信任 OpenSpec 的 tasks.md
Harness 不信任 Agent 的"自行理解"，只信任 OpenSpec 的 spec.md
人不信任 AI 的"自我审查"，关键节点必须人工确认

原则三：规范不变、流程不变、团队可弹性扩展

一个人用：OpenSpec + Superpowers 就够
2-3 人小团队：OpenSpec + Superpowers + Git 分支协作
5+ 人团队：OpenSpec + Superpowers + OMO 多 Agent 编排

规范层稳定了需求基线，纪律层保证了执行质量，协作层让团队规模可以灵活伸缩。三层各自独立，但通过 spec.md 这个"合约"紧密耦合

05 场景选择

一、场景选择指南

不是所有场景都需要全套工具。根据项目复杂度和团队规模，选择合适的组合：

场景	推荐工具组合	理由
快速原型验证	OMO	只需快速出活，不需要规范约束
核心业务代码	Superpowers	需要质量保障，但需求明确无需规范管理
团队协作 + 文档沉淀	OpenSpec	规范即文档，保证团队认知一致
生产级项目	OpenSpec + Superpowers + Harness	全链路质量保障
简单 Bug 修复	原生 AI 编码工具	杀鸡不用牛刀
遗留系统重构	OpenSpec + Superpowers	先锁定变更边界，再 TDD 逐步替换

推荐的采纳顺序：

1. 先上 OpenSpec——建立规范意识，让 AI 的输出可预期

2. 再学 Superpowers 核心技能——TDD、审查流程，提升代码质量

3. 最后引入 Harness/Agent Team——多 Agent 协作，扩展团队产能

不要一上来就全套上马。工具的学习成本叠加，容易导致团队抵触。循序渐进，每一步都感受到价值，自然就会走向完整的三层架构。

三、工具生态概览

当前主流的 AI 编程工具可以归为三类：

类别	代表工具	特点	与 OpenSpec 集成方式
AI IDE（集成开发环境）	Trae、Cursor、Windsurf	图形界面，深度集成编辑器，支持 MCP 和规则文件	`openspec init` 自动生成 `.trae/`、`.cursor/` 等目录的 slash commands 和规则文件
终端 AI 代理	Claude Code、Codex CLI、Gemini CLI	终端命令行，擅长多文件操作和自动化	`openspec init` 生成 CLAUDE.md、AGENTS.md 等上下文文件，支持 `/opsx:` 系列斜杠命令
多 Agent 编排层	OMO (Oh My OpenAgent)、OpenHarness	协调多个 AI Agent 并行工作，路由不同模型	通过 OpenSpec 规范文档作为各 Agent 的统一输入源

关键点：OpenSpec 已原生支持 20+ 工具，包括 Trae、Cursor、Claude Code、Windsurf、Codex、Gemini CLI 等。对于不支持斜杠命令的工具，OpenSpec 会生成根目录 `AGENTS.md` 文件作为上下文指令。

个人开发者最佳实践：Trae + OpenSpec + Superpowers

适用场景：独立开发者或 2-3 人小团队，日常功能开发和重构。

团队开发最佳实践：Cursor/Claude Code + OpenSpec + OMO

适用场景：5+ 人团队，多特性并行开发，需要多模型协同。

架构设计

规范层 (OpenSpec)          纪律层 (Superpowers)       协作层 (OMO)
─────────────────          ──────────────────          ──────────────────
定义"做什么"                定义"怎么做"               定义"谁来做"
proposal → spec            TDD → 测试 → 审查           多 Agent 并行执行



06 结语

不是工具越多越好，而是知道什么时候用什么。OpenSpec 给你的是一种思维方式：在 AI 替你写代码之前，先替 AI 写好规范。这个顺序的翻转，就是从 vibe coding 到工程化开发的分水岭。

AI 不会取代程序员，但会用工具的迟早会。从 Vibe Coding 到 Spec Coding，就是你和一个成熟架构师之间最大的鸿沟。现在，去给你的项目装上这套动态引擎，把掌控权拿回来。

推荐阅读:

OpenCode 生态铁三角：OpenSpec + Superpowers + OMO，搞懂三者的关系才算真正会用
AI 编程工程化三层基础设施：OpenSpec 管"做什么"，Superpowers 管"怎么做"，Harness 管"谁来做"
Superpowers 搭配 OpenSpec 的三段式流程：从不确定的需求到可落地、可验收、可追溯的成果
Superpowers 完整指南：让 AI 守规矩的工程化工作流框架
OpenSpec 任务粒度控制：2/8 法则与三步配置法
Claude Code Superpowers 与 OpenCode OpenSpec 对比指南
还在让 AI 帮你"写 Bug"？OpenSpec + Superpowers 组合拳让代码确定性提升 10 倍
AI 编程进阶：OpenSpec + Superpowers 组合方案深度使用教程
Claude Code + OpenSpec + Superpowers，AI 协同开发实战详解（从入门到精通）

资料获取:

更多合集文章请关注我的公众号，一起学习一起进步：

AI编程进阶| @胡彦斌，你要懂不仅仅是Vibe Coding，还有 ......