如果你已经用过 Claude Code、Cursor、Copilot 这类 AI 编程工具，第一次接触 OpenCode，大概率会有两个感受：

第一，它更“野”。
第二，它也更强。

因为 OpenCode 不是一个“封闭式 AI 助手”，而是一套运行在终端里的开源 AI Agent 框架。你可以自己选模型、自己配 Agent、自己定义命令，甚至把它扩成一个“多角色开发团队”。

而当你再装上 oh-my-opencode 之后，它就不只是一个 AI 编程工具了，而更像是一个能拆任务、会并行、懂代码库、能自主推进的大脑。

这篇文章不讲空泛概念，只讲一件事：

怎么把 OpenCode + oh-my-opencode 真正用到日常开发里。

---

一、先说结论：OpenCode 适合什么人？

如果你属于下面这类开发者，OpenCode 会比很多“开箱即用型 AI 工具”更适合你：

• 已经有 AI 编程助手使用经验
• 不满足于单一模型或单一工作流
• 希望 AI 能更深地参与项目理解、重构、审查、文档生成
• 愿意在终端里完成高效率协作
• 想把 AI 从“问答工具”升级成“执行型 Agent”

简单说，OpenCode 更适合进阶用户，不太像给纯小白准备的玩具。

---

二、OpenCode 到底是什么？

OpenCode 是一个运行在终端中的开源 AI 编程 Agent。

它支持 Claude、GPT、Gemini 等大量模型，既能以 TUI 方式使用，也能接 IDE 插件和桌面端。真正让它和很多同类工具拉开差距的，不是“能写代码”，而是下面这几点：

1）它不绑定单一模型

你不用被锁死在某一家模型生态里，可以根据任务自由切换。

2）它是开源的

这意味着很多行为、配置、扩展能力都可控，而不是黑盒。

3）它的核心不是“聊天”，而是“Agent 协作”

这点非常关键。
OpenCode 的强，不在于它像不像聊天机器人，而在于它有没有能力：

• 理解项目结构
• 分派子任务
• 控制工具权限
• 执行 Shell
• 修改文件
• 维护上下文
• 持续推进直到完成

如果你把 Claude Code 理解为“一个很强的单兵”，那 OpenCode 更像是“一个可编排的小型工程团队”。

---

三、安装很简单，但真正该重视的是配置

安装方式常见有三种：

# 官方脚本
curl -fsSL https://opencode.ai/install | bash

# Homebrew
brew install anomalyco/tap/opencode

# Node.js
npm install -g opencode-ai

API Key 也很好配：

export ANTHROPIC_API_KEY="sk-ant-..."

或者直接在 TUI 中通过 /connect 完成授权。

但这里有个经验之谈：

安装不是重点，配置才决定你后面用得顺不顺手。

尤其是模型、插件、全局 AGENTS.md、常用命令模板，这些东西一旦搭好，后面效率会完全不一样。

---

四、真正理解 OpenCode，要先理解它的 Agent 体系

很多人第一次用 OpenCode，会把它当成“终端版聊天助手”。
这其实低估它了。

OpenCode 的核心设计，是 Agent 分层。

---

五、主 Agent 和子 Agent：别再把它当单线程助手用了

1. 主 Agent：你直接对话的对象

主 Agent 类似“当前坐在你面前的工程师”。

默认常见的有两个：

• Build：全工具权限，能读写文件、执行 bash，适合直接开发
• Plan：偏审慎模式，写文件和执行命令通常需要确认，更适合先做方案规划

很多人有个误区，以为 Build 和 Plan 是“模式切换”。

其实不是。

它们本质上是两个独立的主 Agent。
你是在切换角色，不是在切换一个开关。

2. 子 Agent：专项任务助手

子 Agent 更像“专业分工成员”。

常见内置角色包括：

• General：通用执行型子任务助手
• Explore：只读搜索专家，适合代码库扫描、定位调用链、梳理结构

你既可以手动调用它们，也可以让主 Agent 在执行过程中自动调度它们。

这就意味着一件事：

你不必再让一个 Agent 一边找代码、一边分析、一边改文件、一边写文档。
你可以让不同 Agent 各干各的。

这就是 OpenCode 的生产力来源之一。

---

六、一个符号就能提升效率：@ 的两种用法必须熟

在 OpenCode 里，@ 几乎是最高频输入。

但它其实有两种完全不同的作用。

用法一：引用文件

例如：

这段鉴权逻辑有没有问题？@src/middleware/auth.ts

这时 @ 的意思是“把这个文件拉进上下文”。

适合：

• 指定某个文件让 AI 分析
• 精准减少无关上下文
• 避免让 AI 在整个项目里瞎猜

用法二：调用子 Agent

例如：

@explore 找出所有调用了 sendEmail 的地方

这时 @explore 不是文件，而是在点名某个子 Agent 干活。

你甚至可以把两种写法混着用：

@explore 分析 @src/api/ 目录下所有接口的结构

一边指定角色，一边指定范围。

这个组合在实战里非常高效。

---

七、Tab 的真正意义：不是模式切换，而是角色切换

OpenCode 里最容易被误解的快捷键，就是 Tab。

很多人以为它是在切换“Plan 模式”和“Build 模式”，实际上它是在：

切换主 Agent

也就是说，Tab 的本质不是“工作模式切换”，而是“当前接手任务的人变了”。

所以一个更合理的工作流通常是这样的：

场景：先规划，再执行

第一步，切到 Plan Agent：

Tab

输入需求，让它先给方案，不直接动代码。

第二步，你审查方案，确认没有跑偏。

第三步，再切回 Build Agent：

Tab
好，按计划执行。

这套方式特别适合多人协作项目，因为它能显著减少 AI 直接改坏代码的概率。

---

八、TUI 真正常用的不是花哨功能，而是这几类动作

如果你日常真的拿 OpenCode 干活，下面这些命令基本是高频操作。

1）初始化项目记忆：/init

进入项目目录后执行：

opencode

然后在 TUI 里输入：

/init

它会分析项目结构并生成 AGENTS.md。

这份文件非常重要，可以理解成：

AI 在这个项目里的长期记忆说明书

我的建议很明确：

一定提交到 Git。

因为它不是临时文件，而是你团队与 AI 协作的“项目约定”。

---

2）直接执行命令：!

比如：

!git log --oneline -20
!npm test -- --coverage
!cat package.json

这类用法的价值在于，你不需要退出对话再去终端手敲命令，结果会直接进入 AI 上下文。

AI 可以基于测试输出、日志、构建结果继续推理。

这比“复制一段报错再贴回聊天框”流畅得多。

---

3）撤销和重做：/undo、/redo

/undo
/redo

如果你让 Agent 改了代码，发现方向错了，这两个命令非常关键。

但要注意，它依赖 Git 来管理变更。
所以：

项目最好从第一天就放在 Git 仓库里。

---

4）上下文压缩：/compact

大任务做久了，上下文迟早会变重。

这时候不要硬聊，直接：

/compact

它会压缩会话，把关键上下文保留住，减轻 token 压力。

尤其当你在做多轮调试、重构、需求推进时，这个命令几乎是必备的。

---

九、AGENTS.md 是 OpenCode 的灵魂文件，不写等于白用一半

很多人装完 OpenCode 就急着提需求，结果 AI 一会儿用错 ORM，一会儿越层调用，一会儿生成不符合团队规范的代码。

原因很简单：
你没有告诉它项目规则。

AGENTS.md 就是用来解决这个问题的。

你应该在里面写清楚：

• 技术栈
• 构建与测试命令
• 代码规范
• 分层约束
• 异常处理方式
• 团队约定
• 禁止事项

例如：

• ORM 用 jOOQ，不许用 Hibernate
• 所有 public 方法必须写 Javadoc
• Controller 不能直接调 Repository
• 异常统一进 GlobalExceptionHandler
• 禁止循环内查数据库

这类信息对 AI 来说价值极高。

因为 AI 最怕的不是“不会写”，而是“写得不符合你的体系”。

---

十、自定义 Agent 和命令，才是 OpenCode 的上限所在

OpenCode 的可扩展性非常强。

你可以自己定义一个专门做安全审计的 Agent，也可以自定义 /code-review 这样的命令模板。

比如定义一个只读安全审查 Agent，它只负责找：

• SQL 注入
• XSS
• CSRF
• 硬编码密钥
• 权限校验缺失

不负责直接修改文件。

这样做的意义在于：

你不再是“每次重新写提示词”，而是在沉淀“可复用的团队能力”。

换句话说，AI 不再只是聊天工具，而是逐渐变成你们研发流程的一部分。

---

十一、真正让 OpenCode 质变的，是 oh-my-opencode

如果说 OpenCode 只是搭好了地基，
那么 oh-my-opencode 才是把这栋楼盖起来的东西。

它可以理解成一套增强插件，目标只有一个：

把 OpenCode 从“单个 AI 助手”升级成“多角色协作团队”。

安装很简单：

bunx oh-my-opencode install

装完之后，最重要的变化有三类：

• Agent 数量和专业分工大幅增加
• 能做并行任务调度
• 会自动处理更复杂的工作流

而其中最值得记住的，只有一个词：

ulw

---

十二、记住一个词就够了：ulw

ulw 是 ultrawork 的缩写。

你只要在提示词里带上这个词，oh-my-opencode 就会自动进入一种更强的执行状态。

它会倾向于：

• 主动探索代码库
• 自己寻找实现参考
• 并行调用多个子 Agent
• 不轻易中断来问你
• 持续验证结果直到完成

这意味着什么？

意味着你不用每一步都手把手下命令了。

例如下面这些任务，就很适合直接 ulw：

ulw 给 /api/orders 接口增加分页功能，参考 /api/products 的实现方式
ulw 找出所有 N+1 查询问题并修复
ulw 将整个项目的错误处理统一改为 Result 模式
ulw 重构 src/payment/ 为策略模式，对外接口不变

我的建议是：

什么时候用 ulw？

• 任务比较大
• 涉及多个文件
• 你自己都还没完全想清楚从哪开始
• 希望 AI 自主推进

什么时候别急着用 ulw？

• 需求边界不清
• 涉及关键架构决策
• 你想先把方案审一遍

这种场景下，更适合先规划，再执行。

---

十三、oh-my-opencode 不是多几个名字，而是真分工了

安装后会多出一批角色鲜明的 Agent。

比如：

主 Agent

• Sisyphus：默认编排者，适合日常任务和 ulw
• Hephaestus：更适合深度独立执行的大任务
• Prometheus：擅长需求梳理、规划、反问澄清
• Atlas：执行计划型任务

子 Agent

• @oracle：架构顾问、逻辑审查
• @metis：补计划漏洞
• @momus：苛刻质量把关
• @explore：搜索代码库
• @librarian：查文档和最佳实践
• @multimodal-looker：看图还原 UI

这套设计很像一个真实开发团队：

• 有人负责提方案
• 有人负责执行
• 有人负责检查
• 有人负责调研
• 有人负责架构把关

所以它强的不是“模型更聪明”，而是协作方式更像工程化团队。

---

十四、大型需求别硬怼，/start-work 才是正确打开方式

如果任务是跨模块、大功能、涉及架构设计，那最推荐的工作流不是直接一句话梭哈，而是：

第一步：切到 Prometheus

先把需求说清楚，让它像一个资深工程师一样反问你细节。

你把边界、约束、业务规则讲清楚之后，再让它：

好，生成计划。

它会产出计划文件。

第二步：确认计划

这一轮特别重要。
你要看方案有没有漏边界、有没有过度设计、有没有潜在风险。

第三步：执行 /start-work

这时 Atlas 才接管执行。

这个流程适合那种：

• 多模块改动
• 需求复杂
• 不希望边做边跑偏
• 想中断后还能恢复

因为它会保留执行状态，中途断开也能继续。

一句话总结：

ulw 适合“我知道要干什么，直接干”；
/start-work 适合“先把事想清楚，再系统推进”。

---

十五、几个最实用的落地场景

下面这些场景，基本就是日常开发里最常见、也最值得用 OpenCode 的地方。

---

场景 1：快速读懂陌生项目

当你接手一个没见过的仓库时，不要自己先到处翻。

可以直接让 AI 先帮你建立地图：

@explore 找出所有 API 入口点，列出路由和对应 Handler
ulw 分析这个项目的整体架构，重点梳理请求链路，
输出一份给新人的 onboarding 文档

这类任务 AI 的效率非常高。

---

场景 2：做中等复杂度功能

比如要给删除订单加软删除、回收站、恢复能力。
这类需求通常涉及：

• 数据库字段
• 查询逻辑
• 列表过滤
• 页面改造
• 业务状态处理

最佳做法一般是：

1. 用 Plan 或 Prometheus 做方案
2. 审完方案后切 Build 或走 /start-work
3. 最后让 AI 自测和跑验证命令

比一句“帮我做个软删除”直接梭要稳得多。

---

场景 3：只做审查，不改代码

OpenCode 并不只是“写代码工具”，拿来审代码也非常好用。

比如：

@explore 全量扫描 src/api/，找出所有缺少权限校验的接口
@oracle 审查 @src/payment/PaymentService.java，
重点看幂等性、并发安全和异常边界

这种“只分析、不写入”的角色分离，非常适合做预审。

---

场景 4：追复杂 Bug

当你遇到 NPE、链路异常、偶发并发 Bug 时，单纯贴报错往往不够。

这时更好的方式是：

ulw 追踪这个 NPE 的根本原因，从堆栈顶部到数据来源全链路分析，
找到根因后给出修复方案

它会主动去找：

• 报错位置
• 上游调用链
• 数据来源
• 空值进入路径
• 是否是边界条件缺失

这比你手工 grep 效率高很多。

---

场景 5：做大范围重构

例如把支付模块改成策略模式，但对外接口不变，还要保证测试继续通过。

这是 AI 特别能发挥价值的地方，因为它擅长：

• 梳理重复逻辑
• 识别可抽象点
• 统一接口风格
• 分步骤替换

尤其配合 ulw，能省掉大量机械性改动。

---

场景 6：按设计稿还原前端

如果支持截图分析，UI 还原能力会大幅提升。

比如你拖一张图进去后：

@multimodal-looker 分析这张设计稿的布局和样式
按照图中的设计实现 @src/components/Dashboard.tsx

对于中后台页面、营销页、组件布局类需求，这个很实用。

---

十六、我认为最值得照抄的三条使用原则

最后，给你三条真正能提升效果的经验。

原则一：小任务别过度编排，大任务别一句话梭哈

• 改 1~2 个文件：直接做
• 中等任务：先规划再执行
• 大任务：用 ulw 或 /start-work

原则二：把项目规则写进 AGENTS.md，而不是每次重新说

重复说十次，不如沉淀成长期记忆一次。

原则三：让不同 Agent 做不同事

• 搜索交给 @explore
• 架构判断交给 @oracle
• 规划交给 Prometheus
• 自动推进交给 Sisyphus + ulw

不要让一个 Agent 同时扮演所有角色。

---

十七、结语：OpenCode 的价值，不是替你写代码，而是替你组织工作

很多人看 AI 编程工具，只盯着“它能不能生成代码”。

但真正拉开效率差距的，从来不是“生成那几十行代码”的瞬间，而是整个研发过程：

• 如何理解项目
• 如何拆分任务
• 如何审方案
• 如何调用工具
• 如何控制上下文
• 如何并行处理
• 如何验证结果

OpenCode 的厉害之处就在这里。
而 oh-my-opencode，则把这种能力进一步放大成了“团队化协作”。

所以如果你已经过了“拿 AI 补几个函数”的阶段，想往更高阶的工作流走，这套组合非常值得认真用一段时间。

它不是最傻瓜的。
但一旦用顺，确实会越来越离不开。