企业官网建设流程全解析

1. 先厘清三者的边界：引擎、框架、精简方案

先说结论：OpenCode、OhMyOpenCode、Slim 这三者不是同一类东西，放在一起对比并不是"谁取代谁"，而是"你要在这条链路上选哪一层"。把这个关系看懂了，后面的选型基本不会走偏。

OpenCode 本身是一个开源的终端 AI 编码助手，核心能力是在终端里启动一个交互式的 AI 编程环境，支持多模型（Claude、GPT、国内模型等），能读取项目上下文、多文件编辑、运行命令、管理会话。它的定位类似于 Claude Code、Codex 的命令行形态，但架构上更开放：底层支持多种 provider，配置走 TypeScript 文件，而且自带 skills（技能）机制——可以把常用的提示词流程封装成可复用的 skill，这一点非常像给 AI 助手装了"自定义插件"。

OhMyOpenCode 则是社区里围绕 OpenCode 做的配置增强框架。名字显然是从 Oh My Zsh 顺过来的，做的事情也类似：把散落的配置文件、主题、别名、插件、快捷键统一管理起来，提供一套约定俗成的目录结构和预设方案。装完 OhMyOpenCode 之后，你不需要从零去写opencode.config.ts，也省掉了手搓 keybindings、agent 模板这些重复劳动。

Slim 在这条链路里的角色就更轻了——它是基于 OpenCode 生态做的一个极简出发配置（可以说是配置包/预设），核心思路是"零侵入、无主题、不装多余插件"，只保留最基本的模型接入和终端体验，适合那些不想被框架约束、喜欢自己掌控每一行配置的人。很多用户对 Slim 的反馈是"装完感觉像原生 OpenCode，但快捷键和模型预置又比原生顺手一点"。

所以，如果拿房子来类比：OpenCode 是毛坯房，OhMyOpenCode 是带装修方案的整体软装包，Slim 是只做了水电改造和基础刷白的极简交付。你要哪种，取决于你打算在房子里住多久、愿不愿意自己折腾。

2. 核心差异：配置管理、技能体系、模型接入策略

2.1 配置管理方式

原生 OpenCode 的配置是一个 TypeScript/JSON 文件（opencode.config.ts或opencode.json），所有模型、权限、技能、主题全部写在这里。优点是灵活，几乎没有 OpenCode 能力圈外的死角；缺点是入门门槛高——得先理解它的配置 schema、provider 注册方式、权限声明规则，才能写出顺手的配置。

OhMyOpenCode 的做法是把配置拆分到固定目录里，比如~/.config/opencode/plugins/下面每个插件一个文件夹，各管各的 agent、各管各的 keybindings，主配置只负责拉取和聚合。想加一个功能就从社区复制一个插件目录，想关掉就直接删目录。这种"以目录为单位"的管理方式，对喜欢模块化的人来说非常友好。

Slim 则回到单文件路线，但它的策略是"配置尽量少，但每个字段都经过社区验证"——例如默认就接好 opencode-go 套餐、配置好常见的 ignore 规则（node_modules、dist、.git），内置几个最实用的 skill（比如代码审查、commit message 生成）。它不提供插件机制，但换来的是零依赖、零学习成本。

2.2 Skills 技能体系

这是 OpenCode 生态里最有意思的部分，也是三者拉开差距的关键点。OpenCode 的 skill 就是一个带SKILL.md的目录，里面写了这个技能的触发条件、执行步骤、输出规范。技能可以被用户手动调用，也可以被模型根据上下文自动选择。

原生 OpenCode 支持 skill，但只提供了机制，没有提供内容——你需要自己写。OhMyOpenCode 则内置并管理了一大批社区 skill（比如 semantic-release 流程、数据库迁移脚本生成、Docker 排错），并且支持opencode skill install这样的命令直接从仓库拉取。Slim 的做法是只保留两个绝对通用的技能（code-review 和 commit），其余全部去掉，把选择权交还给用户。

我自己的体会是：技能体系用好了，等于把你的团队规范、个人代码风格、常见套路全部"固化"进 AI 助手。比如你在团队里有一套规范要求所有 PR 描述必须包含测试影响范围，那就可以写一个pr-description技能，让 OpenCode 每次生成 PR 描述都自动带上这个结构。

2.3 模型接入与套餐策略

模型接入这块，三者都不是模型本身，而是"怎么配模型"的策略不同：

• 原生 OpenCode：手动配，支持 OpenAI 兼容接口、Anthropic、Google、本地 Ollama 等，你需要在配置文件里写清楚 baseURL、apiKey、model ID。
• OhMyOpenCode：会帮忙预置一批 provider 配置模板，尤其是针对 opencode go 套餐、codex 这类做了优化，基本填个 key 就能跑。
• Slim：默认接 opencode-go 套餐，并针对该套餐的限流特性做了"轻量上下文"优化——减少发送给模型的冗余信息，尽量压低 token 消耗。

这里要特别说一句 opencode go。它是 comsoul（也可能是社区服务）提供的包月制 API 网关，订阅之后可以稳定调用 Claude 等模型，比官网按 Token 计费要省心不少，很多用户的反馈是"一个月额度比按量充值便宜一个数量级"。不过 opencode go 有免费层限制，免费档位只能从 opencode 主应用内部使用，这就牵扯出一个大坑，我在后面的踩坑章节详细讲。

3. 选型决策：你属于哪一类用户，就选哪条路径

3.1 新手 / 场景化用户：选 Slim

如果你还在"要不要用终端 AI 助手"的犹豫期，或者你主要是为了完成具体场景任务（写脚本、生成 commit、解释报错），那 Slim 就是摩擦最小的入口。装完后没有复杂的配置过程，接上 key 就能跑。等用顺手了，觉得需要更多能力，再去升级到 OhMyOpenCode 或者手写原生配置也不迟。

我见过太多人一上来就折腾主题、折腾一堆插件，结果配置了三个小时还没真正开始写代码，最后热情全灭。Slim 这种"能跑就行"的思路，反而是留存率最高的。

3.2 进阶开发者 / 多机器同步：选 OhMyOpenCode

如果你的开发环境要经常在笔记本、台式机、工作机之间切换，或者你希望把 AI 编写规范沉淀成团队资产，OhMyOpenCode 的模块化结构就很值。你可以把整个~/.config/opencode/目录纳入 git 管理，换机器时一条命令恢复所有插件和技能。它的缺点是有一定的概念负担——你得先理解 plugin、agent、skill、keybinding 各自的作用，但学完之后收益非常大。

3.3 资深玩家 / 定制疯魔：选原生 OpenCode

如果你是那种"配置本身就是乐趣"的人，或者项目里有极其特殊的约束（比如所有 AI 操作必须经过自定义审计日志、要接内网模型网关、要和 CI/CD 深度集成），那就直接上原生 OpenCode，从空配置文件开始写。OhMyOpenCode 和 Slim 在这种情况下反而会成为束缚——你为了绕开它们的默认行为，花的精力比从零配置还多。

3.4 混合方案

实际上，大多数人是混合用：用 Slim 的配置作为起点，然后逐步往里面加自己需要的插件或技能；等到配置复杂到一定程度，再迁移到 OhMyOpenCode 的目录结构。OpenCode 的配置是后加载覆盖前加载还是合并，取决于具体实现，但通常社区做法是保留一份"基础配置 + 增量覆盖"。我个人推荐的做法是：先装 Slim，跑通主要工作流，然后把opencode.config.ts里自己新增的部分整理成一个小插件，再决定要不要上 OhMyOpenCode。

4. 实操落地：从安装到跑通主流程

4.1 安装与前置环境

OpenCode 官方推荐通过 npm 安装：

npm install -g opencode

国内用户如果 npm 源慢，可以切到 npmmirror：

npm config set registry https://registry.npmmirror.com npm install -g opencode

安装完成后验证版本：

opencode --version

如果你在 Windows 上运行，这里就有第一个隐藏坑：很多用户反馈node_modules\@opencode\cli\bin\opencode.exe与 Windows 版本不兼容。这个问题多半是 Node 版本过老（低于 18）或者系统缺少 VC++ 运行库导致的。建议装 LTS 版 Node（当前推荐 20.x/22.x），再把 npm 全局 bin 目录加入 PATH。Windows 下终端建议用 PowerShell 7+ 或者 Windows Terminal 里的 WSL2，实测在 cmd 和旧版 PowerShell 5.1 下 ANSI 转义序列识别经常出问题，OpenCode 的输出会变成一堆乱码。

WSL2 也是一个值得考虑的路径，很多人在 WSL2 里跑 OpenCode 比原生 Windows 顺畅很多，文件监视、shell 交互这些底层操作更接近 Linux 语义，少踩不少跨平台兼容性的坑。

4.2 配置核心模型接入

安装后第一件事是接入可用的模型。以opencode-go为例，社区通用做法是把 key 配置到环境变量里，避免 key 明文写在配置文件中。比如：

export OPENCODE_GO_API_KEY="你的key"

然后在opencode.config.ts里注册 provider。Slim 的做法比较省心，它已经把 opencode-go 预设好了，你只需要在首次启动时按提示填入 key 即可。

如果你的团队有内网模型（比如部署了 vLLM 或 Ollama），OpenCode 也可以接，baseURL 指向内网地址，模型列表由服务端暴露。这里提一句：局域网访问问题也是高频问题，默认 OpenCode Web 界面可能只监听localhost，无法从其他设备访问。需要改监听地址时，可以在启动参数里指定 host：

opencode --hostname 0.0.0.0

但要注意，暴露到局域网意味着没有鉴权，内网环境要做好信任隔离，不要随便开。

4.3 安装并验证 skill

OpenCode 的 skill 机制是我认为它区别于其他终端 AI 工具的 "护城河" 功能。安装一个 skill 很简单，从远程仓库拉取到本地技能目录即可：

opencode skill install <skill-name>

如果没有现成的技能仓库，也可以自己创建一个技能目录，结构大致如下：

~/.config/opencode/skills/ └── code-review/ ├── SKILL.md └── reference/ └── checklist.md

SKILL.md里写清楚技能名称、触发场景、执行流程。举一个具体例子：做代码审查技能时，SKILL.md 中定义"当用户要求 review 代码时，先读取 git diff，再按安全漏洞、逻辑错误、性能问题、可维护性四个维度输出结论"。然后你在对话里说"帮我 review 一下这次改动"，OpenCode 的模型就会自动加载这个技能，按既定流程执行。

技能的威力在于：它不是一条固定的 prompt，而是把工作流、参考文档、检查清单都封装在一起。哪怕你换了不同的底层模型，技能输出的格式和步骤也基本稳定。这一点在团队协作时非常值钱——因为每个人的 OpenCode 可以共享同一套技能，保证产出风格统一。

4.4 查看 Token 消耗和会话管理

跑起来之后，很多人关心的是 token 消耗。OpenCode 会在会话中记录每次请求的输入/输出 token 数，你在界面里可以直接看到本次会话累计消耗。如果你想看更细的数据，可以在配置里开启审计日志，把每次 API 调用的元信息写到本地文件，方便月底对账。opencode-go 这类套餐服务一般也在后台提供消耗明细页，两边数据对比着看，就能知道本地统计和服务端统计的差异主要来自哪部分（一般是多轮工具调用的隐藏 token）。

会话管理方面，OpenCode 支持恢复归档对话。这个功能和你想的不太一样：它不会把对话无限期保留，而是按会话快照方式存储，超过一定时间或者主动 archive 之后，对话会进入归档区，web 界面里可以找回。如果找不到已经归档的对话，检查一下是不是切了目录或者环境变量指向了不同的数据目录。

5. 踩坑实录：免费层限制、Windows 兼容、技能不生效

5.1 免费层限制的完整排查链路

很多用户第一次启动 opencode 时，会遇到这样一段错误提示：

error from provider (console): opencode's free tier can only be used from within opencode

这个报错翻译过来是：当前模型默认走了 opencode 自带的免费额度，但免费额度只允许在 opencode 主应用内部使用。也就是说，如果你是在其他客户端（比如 IDE 插件、Web 界面、第三方脚本）里调 opencode 的接口，默认配置下就会撞上这个限制。

排查思路按以下顺序来：

1. 检查你当前运行的是不是 opencode 官方 CLI 本体。如果你是在 VSCode 插件或桌面版里触发的，免费层大概率不可用。
2. 检查配置里是否显式指定了 provider 和 model。如果 model 留空或填的是opencode/free之类的默认值，那就是触发免费层了。你需要把它改成自己的 key 对应的模型 ID。
3. 检查环境变量。OPENCODE_API_KEY如果没设或者设成了free，也会走免费层。设置成自己的付费 key 之后问题消失。
4. 如果你确实订阅了 opencode-go，确认baseURL指向的是 go 服务的地址，不是默认地址。两者 baseURL 不同，填错了就会回退到免费层逻辑。

整个过程我实测下来的核心结论是：报错本身不是故障，而是一个 "安全提示"——它防止你把 opencode 的免费额度通过二次封装转给其他人用。所以你只需要确认自己的调用链路用的是正规的、绑定了 key 的 provider 即可绕过。

5.2 Windows 环境下的 shell 选择

OpenCode 在 Windows 下需要调用 shell 执行命令，这一步选不好 shell，会出现各种玄学问题：命令执行了一半卡住、输出不刷新、脚本里的 ANSI 颜色全是转义符。我试过 Windows 自带的 cmd、PowerShell 5.1、PowerShell 7、Git Bash、WSL2 之后，结论如下：

如果你在纯 Windows 环境，我的建议是至少装 PowerShell 7，并把pwsh设为 OpenCode 的默认 shell。在配置里可以指定：

// opencode.config.ts 示例 shell: "pwsh -NoLogo",

另外注意 Windows 上的路径风格，OpenCode 传给你的脚本如果有C:\Users\...这类路径，在正则匹配时反斜杠要转义。很多"技能明明写了规则却不生效"的问题，最后都查出来是路径分隔符写错了。

5.3 技能装完却不触发的三个高频原因

技能目录写在~/.config/opencode/skills/下，目录名和SKILL.md里的name字段必须保持一致，这一点官方文档有提但很容易被忽略。不一致的时候，技能列表里能看到它，但模型永远不会主动选中它。

第二个原因是技能里的触发条件写得太窄。比如你把description写成"当用户提到 code review 时"，但如果用户实际说的是"帮我看看这次改动有没有问题"，不含"code review"字样，技能就不会触发。正确做法是在描述里写清楚你能处理的任务类型，而不是只写一个触发关键词。你可以多写几个同义场景：review、检查、代码问题、diff 分析等等。

第三个常见坑是模型不支持自动技能调用。部分模型（尤其是一些轻量模型或者走兼容接口的模型）没有启用 tool calling 能力，技能列表加载了，但模型根本没有选择技能的能力。这时候表现为"配置都对、日志也有加载记录，但行为没有任何变化"。解决办法：换成支持工具调用的模型，或者在对话里手动指定技能名称（一般用#skill-name或默认的调用方式，具体看 OpenCode 版本文档）。

5.4 本地 Web 界面局域网访问问题

OpenCode 的 Web 界面默认绑定在 localhost，想在同一局域网的其他设备上访问（比如用平板、手机查看会话或者远程控制），直接改 hostname 为0.0.0.0即可。但要注意，新版和旧版的参数名可能不一样，有的版本是--host，有的版本是--hostname。建议先跑opencode --help看当前版本的参数说明。

另外，如果你改了监听地址，Web 界面的 API 鉴权也要关注。在没有登录鉴权的实现下，局域网内任何人都能访问你的会话甚至执行指令，这在办公网络下是安全风险。稳妥的做法是：只在受信任的 VLAN 下开启0.0.0.0，或者用 ssh 隧道来替代直接暴露端口。

6. 我对三者的最终建议

折腾 OpenCode 生态这么久，我的核心感受是：工具链的价值不在于"功能最多"，而在于"和你的使用习惯匹配"。

如果你问我个人的话，我现在的组合是：Slim 作为基准配置，然后手工加了两个我自己写的 skill（一个用于 commit message 规范，一个用于接口文档生成）。我不需要 OhMyOpenCode 那么多的插件，因为我的使用场景相对固定；但我也没停留在纯原生配置，因为 Slim 帮我省掉了第一轮踩坑的时间。如果你的需求是快速跑起来干活，Slim 是最短路径；如果你要做多机同步、团队规范化，那么 OhMyOpenCode 的模块化结构会让你后面省心很多；如果真的有什么极其特殊的定制需求，那别犹豫，直接原生 OpenCode。

工具是服务于工作流的。把精力花在真正产生价值的地方——写代码、审查代码、沉淀规范——而不是花在"配置界面好不好看"上。这是我折腾这一圈之后最想对你说的话。