当 AI 编程遇上工程纪律：OpenCode + OhMyOpenCode + OpenSpec 三位一体实战指南

三个开源项目，三种哲学，一个终极目标——让 AI 真正成为你的工程合伙人，而不是一个会写代码的复读机。

目录

1. 为什么你需要看完这篇文章
2. 三位主角登场
3. OpenCode：终端里的 AI 造物主
4. OhMyOpenCode：给造物主装上指挥棒
5. OpenSpec：开工之前先画图纸
6. 三位一体：完整实战流程
7. 架构全景图
8. 从零搭建你的 AI 工程环境
9. 实战案例：用三件套构建用户认证系统
10. 性能与成本分析
11. 常见陷阱与最佳实践
12. 结语：不是更快的锤子，是一个施工队

为什么你需要看完这篇文章

你大概已经经历过这样的场景：

你对着 Claude、GPT 或 Cursor 说：「帮我加一个用户认证功能」。然后——

• AI 立刻开始写代码，完全没问你要什么认证方式
• 写出来的代码风格和项目完全不搭
• 改了五个文件，但漏改了两个关联模块
• 你说「不对，我要 OAuth」，它道歉之后把之前写的全推翻重来
• 聊天记录关掉之后，没有人知道当初为什么做了这些设计决策

这不是 AI 的错。这是工作流的错。

你缺的不是更强的模型。你缺的是：

1. 一个能精确执行指令的运行时——OpenCode
2. 一套多 Agent 协作的编排系统——OhMyOpenCode
3. 一种先想清楚再动手的规划方法论——OpenSpec

这三个项目组合在一起，构成了我目前见过的最完整的 AI 辅助工程工作流。下面我来详细拆解。

三位主角登场

在深入之前，用一张表快速认识它们：

它们的关系不是替代，而是叠加：

┌─────────────────────────────────────────┐ │ 你的项目 & 代码库 │ │ ┌─────────────────────────────────────┐ │ │ │ OpenSpec 规格层 │ │ │ │ proposal → specs → design → tasks │ │ │ │ ┌─────────────────────────────────┐│ │ │ │ │ OhMyOpenCode 编排层 ││ │ │ │ │ Sisyphus / Oracle / Explore... ││ │ │ │ │ ┌─────────────────────────────┐││ │ │ │ │ │ OpenCode 运行时 │││ │ │ │ │ │ LSP / Shell / 文件操作 │││ │ │ │ │ └─────────────────────────────┘││ │ │ │ └─────────────────────────────────┘│ │ │ └─────────────────────────────────────┘ │ └─────────────────────────────────────────┘

下面逐一深入。

OpenCode：终端里的 AI 造物主

它到底是什么

OpenCode 是一个开源的 AI 编程 Agent，月活开发者 650 万+，GitHub 星标 150K+。它的核心设计理念是：终端优先（Terminal-First），但不局限于终端。

你可以把它理解为「AI 编程的操作系统内核」——它提供了 Agent 运行所需的一切基础能力，但不替你决定工作流。

核心能力一览

# 安装（一行命令）curl-fsSLhttps://opencode.ai/install|bash# 或者npminstall-gopencode-ai# 或者brewinstallanomalyco/tap/opencode

三种使用模式

# 模式 1：终端 TUI（最常用）cdyour-project opencode# 启动交互式终端界面# 模式 2：桌面应用# 下载 macOS / Windows / Linux 桌面客户端# 模式 3：IDE 扩展# 在 VS Code 等 IDE 中使用

一次性运行（适合脚本和自动化）

# 非交互式运行——直接给提示词，获取结果opencode run"分析这个项目的依赖关系，列出可能存在安全漏洞的包"# 指定模型opencode run--modelanthropic/claude-opus-4"重构 auth.ts，使用更清晰的错误处理模式"# 附加文件opencode run--filesrc/auth.ts--filesrc/config.ts"这两个文件有什么潜在的竞态条件？"

无头服务器模式（适合团队和 CI）

# 启动 HTTP API 服务器opencode serve--port4096--hostname127.0.0.1# 或者启动带 Web UI 的服务器opencode web

为什么选择 OpenCode 而不是 Cursor / Copilot

初始化项目

cdyour-project opencode# 在 TUI 中运行/init

/init命令会让 OpenCode 分析你的项目结构，自动生成AGENTS.md文件——这个文件是 Agent 理解你项目的入口点，包含技术栈、目录结构、编码规范等关键上下文。

OhMyOpenCode：给造物主装上指挥棒

一句话：如果 OpenCode 是 Linux 内核，OhMyOpenCode 就是 Ubuntu

OpenCode 提供了强大的 Agent 基础设施，但一个 Agent 单打独斗在很多场景下是不够的。复杂项目需要：

• 有人做规划（架构师）
• 有人做调研（研究员）
• 有人写代码（工程师）
• 有人审查质量（评审员）

OhMyOpenCode（简称 OmO）就是那个调度这些角色的项目经理。

核心 Agent 矩阵

一个关键词触发全队协作：ultrawork

这是 OhMyOpenCode 最强大的功能。你只需要在提示词中加入ultrawork（或简写ulw），所有 Agent 就会自动激活：

你：ultrawork 帮我实现完整的 JWT 用户认证系统 Sisyphus 会自动： ├── 🔍 派出 Explore × 2-3 个 → 并行搜索项目中的 auth 中间件、路由模式、数据库模型 ├── 📚 派出 Librarian → 查询 JWT 安全最佳实践、OWASP 指南 ├── 🧠 咨询 Oracle → 架构方案评审（只读，不写代码） ├── 📋 创建详细 TODO 列表 ├── ⚡ 将独立任务分配给 deep/unspecified-high Agent 并行执行 ├── ✅ 验证每个步骤的结果（LSP 诊断、构建检查） └── 🔄 如果失败 → 自动恢复、重试、或请求人工介入

意图门控（IntentGate）：读懂你的弦外之音

OhMyOpenCode 的 Sisyphus 不会字面理解你的话然后盲目执行。它有一个意图门控机制：

并行执行的力量

这是传统 AI 工具和 OhMyOpenCode 的本质区别：

传统方式（串行）： ├── 搜索代码库 ──────────── 2 分钟 ├── 搜索文档 ────────────── 2 分钟 ├── 搜索 GitHub 示例 ────── 2 分钟 ├── 分析架构 ────────────── 2 分钟 ├── 开始实现 ────────────── 5 分钟 总计：约 13 分钟 OhMyOpenCode（并行）： ├── 🔍 搜索代码库 ─────────┐ ├── 📚 搜索文档 ───────────┤ 同时进行 ├── 🔗 搜索 GitHub 示例 ───┤ 2 分钟 ├── 🧠 分析架构 ───────────┘ ├── ⚡ 并行实现独立模块 ──── 3 分钟 总计：约 5 分钟（节省 60%+）

世界级工具链

OhMyOpenCode 为每个 Agent 配备了专业级工具：

LSP 精准工具（IDE 级别）：

• lsp_rename—— 全工作区重命名，安全重构
• lsp_goto_definition—— 跳转到定义，精准定位
• lsp_find_references—— 查找所有引用，全面影响分析
• lsp_diagnostics—— 预构建诊断，写完代码即刻发现类型错误

AST 感知搜索与重写：

• 支持 25 种语言的语法树级代码搜索
• 不是简单的文本匹配，而是理解代码结构的精确替换

内置 MCP（Model Context Protocol）：

• Exa—— Web 搜索，获取最新信息
• Context7—— 官方文档查询，获取准确的 API 参考
• Grep.app—— GitHub 代码搜索，学习开源最佳实践

安装与配置

# 前提：已安装 OpenCode# 安装 OhMyOpenCode 插件# 在 opencode.json 中添加：

{"plugin":["oh-my-opencode"]}

或者更详细的配置（oh-my-opencode.json）：

{ "agents": { "sisyphus": { "enabled": true }, "explore": { "enabled": true }, "librarian": { "enabled": true }, "oracle": { "enabled": true } }, "hooks": { "todo-continuation-enforcer": true, "context-window-monitor": true, "comment-checker": true }, "mcps": { "grep_app": { "enabled": true }, "context7": { "enabled": true }, "websearch": { "enabled": true } } }

自我循环直到完成：Ralph Loop

OhMyOpenCode 有一个独特的概念叫Ralph Loop——自我引用循环。当你使用/ulw-loop命令时，Agent 会持续工作直到任务 100% 完成：

你：/ulw-loop 实现完整的 CRUD API 并写好测试 循环过程： 循环 1 → 分析项目 → 创建 TODO → 开始实现 循环 2 → 实现模型和路由 → 运行测试 → 发现 2 个失败 循环 3 → 修复失败的测试 → 重新运行 → 全部通过 循环 4 → 检查代码质量 → 优化错误处理 → 最终验证 循环 5 → 所有 TODO 完成 ✅ → 退出循环

它不会半途而废。这正是取名「Sisyphus（西西弗斯）」的原因——永不停歇地推石头上山，直到山顶。

OpenSpec：开工之前先画图纸

AI 编程最大的问题不是模型能力，是需求模糊

你可能听过这个笑话：

客户：我要一个系统。
开发者：什么系统？
客户：就……一个系统。能用的那种。

这恰恰是大多数人使用 AI 编程工具的方式——丢一句模糊的需求，然后抱怨 AI 产出不符合预期。

OpenSpec 的核心理念：在写任何代码之前，先用结构化的规格描述清楚你要建什么。

什么是规格驱动开发（SDD）

OpenSpec 引入了Spec-Driven Development（SDD）的概念。它的哲学是：

→ 流动的，不是死板的 → 迭代的，不是瀑布式的 → 轻量的，不是沉重的 → 为棕地项目设计，不只是绿地项目 → 从个人项目到企业级都能用

核心工作流：/opsx:propose

# 安装npminstall-gopenspec# 初始化项目openspec init

OpenSpec 的核心是一组工件的流动：

你：/opsx:propose add-dark-mode AI 自动创建： openspec/changes/add-dark-mode/ ├── proposal.md ← 为什么要做？改变什么？ ├── specs/ ← 需求规格和使用场景 ├── design.md ← 技术方案设计 └── tasks.md ← 实现任务清单

然后你可以审查、修改这些文档，确认无误后再让 AI 开始写代码：

你：/opsx:apply AI 开始实现任务： ✓ 1.1 添加主题上下文 Provider ✓ 1.2 创建切换组件 ✓ 2.1 添加 CSS 变量 ✓ 2.2 对接 localStorage 全部任务完成！

你：/opsx:archive AI 归档变更： → 已归档至 openspec/changes/archive/2025-01-23-add-dark-mode/ → 规格已更新。准备下一个功能。

OPSX 命令全景

工件的依赖关系

OpenSpec 的工件形成有向无环图（DAG），依赖关系是赋能器而非门控器：

proposal ──→ specs ──→ design ──→ tasks │ │ │ │ └───────────┴──────────┴──────────┘ 可以随时回来更新任何一个

为什么规格要放在代码库里

这是 OpenSpec 最有洞察力的设计决策之一：

其他工具只在规划阶段使用需求，然后就丢掉了。我们将代码背后的功能需求保留为活文档——这样你永远知道代码应该做什么，而不只是它现在在做什么。

规格文件被提交到 Git，可以：

• 在 PR 中审查和 diff
• 作为新成员的入门文档
• 作为 AI Agent 的持久化上下文（不会因为聊天会话结束而消失）

三位一体：完整实战流程

现在把三个工具串起来。这是一个完整的开发工作流：

流程全景

阶段 1：规划（OpenSpec） │ ├── /opsx:propose "实现用户认证系统" │ ├── proposal.md → 为什么要做 │ ├── specs/ → 需求和场景 │ ├── design.md → 技术方案 │ └── tasks.md → 任务清单 │ ├── 人类审查 & 修改规格 │ ▼ 阶段 2：编排（OhMyOpenCode） │ ├── ultrawork │ ├── Sisyphus 读取 tasks.md → 创建 TODO │ ├── Explore × 3 并行搜索现有代码 │ ├── Librarian 查询文档和最佳实践 │ ├── Oracle 评审架构方案 │ └── 并行委派给多个 deep Agent 执行 │ ▼ 阶段 3：执行（OpenCode 运行时） │ ├── Agent 通过 LSP 精确操作代码 ├── AST-Grep 安全重构 ├── Shell 执行构建和测试 ├── LSP 诊断验证代码质量 │ ▼ 阶段 4：验证 & 归档 │ ├── /opsx:verify 验证实现 ├── /opsx:archive 归档变更 └── Git commit 所有变更（包括规格文件）

一个真实的对话示例

下面是一个使用三件套的完整对话流程：

═══ 阶段 1：用 OpenSpec 规划 ═══ 你：/opsx:propose "为 SaaS 平台实现基于 RBAC 的多租户权限系统" OpenSpec 创建了以下工件： ├── proposal.md │ "当前系统使用简单的角色检查，无法支持多租户场景。 │ 本提案引入 RBAC + 租户隔离，支持细粒度权限控制……" ├── specs/ │ ├── permissions.yaml ← 权限定义 │ ├── roles.yaml ← 角色层级 │ └── scenarios.yaml ← 使用场景 ├── design.md │ "采用中间件模式，在 Express 层注入权限上下文。 │ 租户隔离通过 PostgreSQL RLS (Row Level Security) 实现……" └── tasks.md ├── 1. 数据库迁移（创建角色和权限表） ├── 2. 权限中间件实现 ├── 3. 租户隔离层 ├── 4. API 路由保护 ├── 5. 管理后台界面 └── 6. 集成测试 你：（审查后修改了 design.md，决定用 Redis 缓存权限而非每次查库） ═══ 阶段 2：用 OhMyOpenCode 编排执行 ═══ 你：ultrawork 按照 openspec/changes/rbac-system/tasks.md 实现所有任务 Sisyphus： 🔍 意图识别 → 实现请求，范围明确（有 tasks.md），多模块涉及 📋 创建 TODO 列表： □ Task 1: 数据库迁移（创建角色和权限表） □ Task 2: 权限中间件实现 □ Task 3: 租户隔离层（PostgreSQL RLS） □ Task 4: API 路由保护 □ Task 5: 管理后台界面 □ Task 6: 集成测试 ⚡ 并行派出探索 Agent： → Explore #1: 搜索现有数据库迁移文件和 ORM 配置 → Explore #2: 搜索现有路由定义和中间件注册点 → Explore #3: 搜索前端管理后台的组件结构 ⚡ 并行派出文档 Agent： → Librarian: 查询 PostgreSQL RLS 最佳实践 → Librarian: 查询 Express RBAC 中间件实现模式 ⏳ 等待结果返回…… （结果返回后） 🧠 咨询 Oracle： "基于以下项目上下文和设计方案，评估 RBAC 中间件的最佳实现方式……" ⚡ 并行委派实现任务： → Task 1 → deep Agent（数据库专家） → Task 2 → deep Agent（后端专家） → Task 3 → deep Agent（数据库专家） → Task 4 → deep Agent（后端专家） → Task 5 → visual-engineering Agent（前端专家） → Task 6 → deep Agent（测试专家，依赖 Task 1-4 完成） （所有任务并行执行中……） ✅ Task 1 完成 → LSP 诊断通过 ✅ Task 2 完成 → LSP 诊断通过 ✅ Task 3 完成 → LSP 诊断通过 ✅ Task 4 完成 → LSP 诊断通过 ✅ Task 5 完成 → 构建通过 ✅ Task 6 完成 → 所有测试通过 ═══ 阶段 3：验证 & 归档 ═══ 你：/opsx:verify OpenSpec 对照规格验证实现： ✅ 权限定义与 specs/permissions.yaml 一致 ✅ 角色层级与 specs/roles.yaml 一致 ✅ 所有使用场景的测试通过 ✅ 设计决策与 design.md 匹配 你：/opsx:archive 归档完成 → openspec/changes/archive/rbac-system/ 主规格文件已更新。

架构全景图

┌──────────────────────────────────────────────────────────────────┐ │ 你的开发工作流 │ │ │ │ ┌──────────── OpenSpec 规格层 ────────────┐ │ │ │ │ │ │ │ openspec/ │ │ │ │ ├── changes/ │ │ │ │ │ └── feature-x/ │ │ │ │ │ ├── proposal.md ← 变更提案 │ │ │ │ │ ├── specs/ ← 需求规格 │ │ │ │ │ ├── design.md ← 技术设计 │ │ │ │ │ └── tasks.md ← 实现任务 │ │ │ │ └── archive/ ← 已归档变更 │ │ │ │ │ │ │ │ 提交到 Git → 团队可审查、可追溯 │ │ │ └─────────────────────────────────────────┘ │ │ │ 任务指令 │ │ ▼ │ │ ┌──────────── OhMyOpenCode 编排层 ────────┐ │ │ │ │ │ │ │ ┌──────────┐ 意图分析 + 任务分解 │ │ │ │ │ Sisyphus │ ──────────────────── │ │ │ │ └────┬─────┘ │ │ │ │ │ 委派任务 │ │ │ │ ├──→ ┌──────────┐ 架构评审 │ │ │ │ │ │ Oracle │ (只读) │ │ │ │ │ └──────────┘ │ │ │ │ ├──→ ┌──────────┐ 代码搜索 │ │ │ │ │ │ Explore │ ×2-5 并行 │ │ │ │ │ └──────────┘ │ │ │ │ ├──→ ┌──────────┐ 文档查询 │ │ │ │ │ │ Librarian│ ×1-3 并行 │ │ │ │ │ └──────────┘ │ │ │ │ ├──→ ┌──────────┐ 规划 │ │ │ │ │ │Prometheus│ 需求访谈 │ │ │ │ │ └──────────┘ │ │ │ │ └──→ ┌──────────┐ 深度执行 │ │ │ │ │Hephaestus│ 自主编码 │ │ │ │ └──────────┘ │ │ │ │ │ │ │ │ 🔄 Ralph Loop → 持续循环直到完成 │ │ │ │ 📋 TODO 追踪 → 每个步骤有据可查 │ │ │ │ ✅ 强制验证 → 没有证据就不算完成 │ │ │ └─────────────────────────────────────────┘ │ │ │ 工具调用 │ │ ▼ │ │ ┌──────────── OpenCode 运行时层 ──────────┐ │ │ │ │ │ │ │ 📁 文件操作 → 读取 / 写入 / 编辑 │ │ │ │ 🔧 Shell 执行 → 构建 / 测试 / 部署 │ │ │ │ 🔍 代码搜索 → grep / glob / 遍历 │ │ │ │ 🧠 LSP 智能 → 定义 / 引用 / 诊断 │ │ │ │ 🌐 网络访问 → 搜索 / 文档 / API │ │ │ │ │ │ │ │ 模型连接：Claude / GPT / Gemini / 本地 │ │ │ │ 会话管理：创建 / 恢复 / 分享 / 并行 │ │ │ └─────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌──────────── 你的项目代码库 ──────────────┐ │ │ │ │ │ │ │ src/ tests/ config/ │ │ │ │ docs/ scripts/ .github/ │ │ │ │ │ │ │ └─────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────┘

从零搭建你的 AI 工程环境

第一步：安装 OpenCode

# macOS / Linux / WSLcurl-fsSLhttps://opencode.ai/install|bash# 或通过 npmnpminstall-gopencode-ai# 或通过 Homebrewbrewinstallanomalyco/tap/opencode# 验证安装opencode--version

第二步：配置 AI 模型

# 交互式配置（推荐）opencode auth login# 或直接编辑配置文件# ~/.local/share/opencode/auth.json

支持的提供商（部分列表）：

第三步：安装 OhMyOpenCode

编辑~/.config/opencode/opencode.json（全局）或项目根目录的.opencode/opencode.json：

{"plugin":["oh-my-opencode"]}

下一次启动opencode时，插件会自动安装。

第四步：安装 OpenSpec

# 需要 Node.js 20+npminstall-gopenspec# 在项目中初始化cdyour-project openspec init

第五步：安装 OpenSpec 的 OpenCode 插件

为了在 OpenCode 中获得更好的 OpenSpec 集成体验（专属规划 Agent）：

{"plugin":["oh-my-opencode","opencode-plugin-openspec"]}

这个插件会添加一个openspec-planAgent，专门用于创建和编辑 OpenSpec 文档，同时防止 AI 在规划阶段就开始写代码。

第六步：初始化项目

cdyour-project opencode# 在 TUI 中运行/init

现在你的环境已经准备就绪。下面来看看实际使用效果。

实战案例：用三件套构建用户认证系统

让我们走一个完整的真实案例。

Step 1：用 OpenSpec 定义你要建什么

在 OpenCode TUI 中：

你：/opsx:propose "为电商平台实现完整的用户认证系统，支持邮箱注册登录、 OAuth 社交登录（Google/GitHub）、JWT Token 管理、以及基于角色的访问控制"

OpenSpec 自动生成：

proposal.md：

# 用户认证系统 ## 背景 当前平台使用硬编码的 admin 账号，无法支持多用户场景。 ## 变更内容 - 实现邮箱 + 密码注册/登录 - 集成 OAuth 2.0 社交登录（Google、GitHub） - JWT access token + refresh token 双 token 方案 - RBAC 角色权限系统（admin / seller / buyer） ## 影响范围 - 新增：auth 模块、user 模型、权限中间件 - 修改：路由注册、数据库迁移 - 依赖：bcryptjs、jsonwebtoken、passport

specs/目录：

# specs/auth-flows.yaml注册流程:-用户提交邮箱 + 密码-验证邮箱格式和密码强度-检查邮箱是否已注册-创建用户记录（密码 bcrypt 加密）-发送验证邮件-返回 JWT token登录流程:-用户提交邮箱 + 密码-验证凭据-检查账号状态（是否已验证、是否被封禁）-返回 access token (15min) + refresh token (7d)社交登录:-重定向到 OAuth 提供商-处理回调-首次登录自动创建账号-关联已有账号（通过邮箱匹配）

design.md：

# 技术设计 ## 架构决策 - 认证层使用 Express 中间件模式 - Token 存储使用 httpOnly cookie（防 XSS） - Refresh token 存储在 Redis（支持吊销） - 权限检查使用装饰器模式 ## 数据模型 User { id, email, passwordHash, role, oauthProviders[], status } TokenBlacklist { jti, expiresAt } // Redis ## API 端点 POST /api/auth/register POST /api/auth/login POST /api/auth/refresh POST /api/auth/logout GET /api/auth/google GET /api/auth/github GET /api/auth/me

tasks.md：

# 实现任务 ## 1. 基础设施 - [ ] 1.1 创建 User 数据库模型和迁移 - [ ] 1.2 配置 Redis 连接 - [ ] 1.3 安装和配置依赖 ## 2. 核心认证 - [ ] 2.1 实现注册端点（含验证） - [ ] 2.2 实现登录端点 - [ ] 2.3 实现 JWT token 生成和验证 - [ ] 2.4 实现 refresh token 逻辑 - [ ] 2.5 实现 logout（token 黑名单） ## 3. OAuth 集成 - [ ] 3.1 配置 Passport.js - [ ] 3.2 实现 Google OAuth - [ ] 3.3 实现 GitHub OAuth - [ ] 3.4 处理账号关联 ## 4. 权限系统 - [ ] 4.1 实现 RBAC 中间件 - [ ] 4.2 保护现有路由 ## 5. 测试 - [ ] 5.1 单元测试 - [ ] 5.2 集成测试 - [ ] 5.3 E2E 测试

Step 2：审查并调整

这是关键步骤——人类审查规格文档。修改任何不满意的地方：

• 你觉得 refresh token 7 天太长？改成 24 小时。
• 你不想用 Redis？改成用数据库存储。
• 你需要支持微信登录？在 specs 和 design 里加上。

Step 3：用 OhMyOpenCode 执行

你：ultrawork 按照 openspec/changes/auth-system/tasks.md 实现所有任务

Sisyphus 接管后：

并行探索阶段（约 30 秒）：

→ Explore #1: 搜索 src/models/ —— 了解现有数据模型和 ORM 配置 → Explore #2: 搜索 src/routes/ —— 了解路由注册模式和中间件链 → Explore #3: 搜索 src/middleware/ —— 查看现有中间件结构 → Librarian: 查询 Express + Passport.js 最佳实践 → Librarian: 查询 JWT httpOnly cookie 安全配置

架构咨询（约 1 分钟）：

→ Oracle: "基于以下项目上下文……推荐 token 刷新策略……"

并行实现阶段（约 3-5 分钟）：

→ Task 1.1-1.3 → deep Agent A（数据库和基础设施） → Task 2.1-2.5 → deep Agent B（核心认证逻辑） → Task 3.1-3.4 → deep Agent C（OAuth 集成） → Task 4.1-4.2 → deep Agent D（权限系统） → Task 5.1-5.3 → deep Agent E（测试）—— 等待 Task 1-4 完成

验证阶段：

→ 每个 Agent 完成后自动运行 LSP 诊断 → 所有任务完成后运行 npm test → Sisyphus 逐项检查 TODO 完成情况

Step 4：归档

你：/opsx:verify 你：/opsx:archive

所有变更（包括规格文档）通过 Git 提交，团队成员可以在 PR 中审查规格和代码。

性能与成本分析

时间对比

三件套在复杂任务上的优势来自：并行执行 + 结构化规划 + 减少返工

Token 成本估算

以 Anthropic Claude 为例（价格会变动，请以官网为准）：

对比：一个中级工程师日薪约 ¥500-1500（约 $70-210）。三件套完成同等工作的成本约$5。

开源模型方案（成本趋近于零）

如果你使用本地模型（Ollama 等），成本几乎为零，但质量会下降。OhMyOpenCode 支持混合配置：

// oh-my-opencode.json { "agents": { "sisyphus": { "model": "anthropic/claude-opus-4" }, // 主 Agent 用付费模型 "explore": { "model": "ollama/qwen2.5-coder:7b" }, // 搜索用本地模型 "librarian": { "model": "ollama/qwen2.5-coder:7b" }, // 文档搜索用本地模型 "oracle": { "model": "anthropic/claude-opus-4" } // 架构咨询用付费模型 } }

这样可以把成本降到$2 以下，同时保持关键决策的质量。

常见陷阱与最佳实践

🚫 常见陷阱

陷阱 1：跳过规划直接写代码

❌ 你：ultrawork 帮我实现用户认证 → AI 立刻开始写代码，结果不符合预期，反复返工 ✅ 你：/opsx:propose "用户认证" → 审查规格 → ultrawork 实现任务 → 先想清楚再动手，一次做对

陷阱 2：给模糊的需求

❌ 你：优化一下性能 → Sisyphus 不知道你要优化什么，无从下手 ✅ 你：/opsx:propose "优化首页加载性能，目标 LCP < 2s" → 明确的目标，可验证的结果

陷阱 3：不审查规格就执行

❌ 你：/opsx:propose "..." → /opsx:apply → 没有人类审查，规格可能有错，AI 按错误的规格实现 ✅ 你：/opsx:propose "..." → 仔细审查每个工件 → 修改不满意的 → /opsx:apply → 人类把关，AI 执行

陷阱 4：所有任务都用最贵的模型

❌ 所有 Agent 都用 Claude Opus → 成本爆炸，简单任务浪费算力 ✅ 主 Agent 用 Opus，搜索用 Haiku/本地模型，架构咨询用 Opus → 合理分配，成本可控

✅ 最佳实践

实践 1：规格要具体到可验证

# ❌ 太模糊性能优化:让系统变快# ✅ 具体性能优化:目标:-LCP < 2.5s-FID < 100ms-CLS < 0.1验证方式:Lighthouse 评分>90

实践 2：善用 Ralph Loop 处理长任务

你：/ulw-loop 按照 tasks.md 实现所有任务并确保测试通过 Ralph Loop 会持续循环： - 实现任务 - 运行测试 - 修复失败的测试 - 重复直到全部通过

实践 3：用 Prometheus 做复杂规划

当你面对一个特别复杂的功能，不知道从何开始时：

你：/start-work Prometheus 会进入访谈模式： "我需要了解更多细节： 1. 这个功能的主要用户是谁？ 2. 你期望的响应时间是多少？ 3. 是否需要向后兼容现有的 API？ ..."

实践 4：让规格文件成为团队知识库

openspec/ ├── specs/ │ ├── auth.yaml ← 认证系统规格 │ ├── permissions.yaml ← 权限系统规格 │ └── api-contracts.yaml ← API 契约 ├── changes/ │ └── archive/ ← 历史变更记录 └── README.md ← 规格索引 → Git 提交 → 团队可审查 → 新成员的入门文档 → AI 的持久化上下文

实践 5：利用 OpenCode 的会话管理

# 恢复上一次会话opencode-c# 恢复特定会话opencode-sses_abc123# 分享会话链接给同事# 在 TUI 中使用 /share 命令

结语：不是更快的锤子，是一个施工队

传统 AI 编程工具给你的是一把更快的锤子——输入更快、补全更快、生成更快。但如果你在钉错钉子，锤子越快，错得越快。

OpenCode + OhMyOpenCode + OpenSpec 的组合给你的是一个完整的施工队：

• OpenSpec是建筑图纸——确保你建的是对的东西
• OhMyOpenCode是项目经理和施工队——分工明确、并行施工、质量把关
• OpenCode是工具箱——锤子、电钻、测量仪，每样都有

它们各自都是优秀的开源项目（累计 240K+ GitHub Stars），但组合在一起时，产生的效果远大于各部分之和。

这不是一个「AI 写代码更快」的故事。这是一个「AI 像工程师一样工作」的故事。

资源链接

写在最后：如果这篇文章对你有帮助，欢迎分享给你的团队。AI 编程不是一个人的事——当整个团队都理解这套工作流时，协作效率会指数级提升。有问题可以在 GitHub Issues 中讨论，开源社区永远欢迎建设性的反馈。