1. OpenCode 是什么为什么它值得你花时间折腾安装OpenCode 不是一个传统意义上的 IDE 插件也不是某个大厂推出的“AI 编程助手”套壳产品。它本质上是一个轻量级、本地优先、可离线运行的 AI 代码代理AI Code Agent运行时环境——你可以把它理解成“Claude Code 的开源平替执行引擎”但更准确地说它是为开发者自己掌控 AI 编程流程而设计的底层沙盒。它不依赖云端 API 密钥不上传你的代码片段所有推理调度、工具调用、上下文管理都在你本地机器上完成它也不绑定特定模型而是通过插件化技能skills对接本地 Ollama 模型、本地 Llama.cpp 服务甚至能桥接你自建的 FastAPI 接口。这决定了它的安装逻辑和普通 npm 包完全不同它不是“装完就能用”而是“装完才刚刚开始配置”。我第一次在 Windows 上跑pnpm add -g opencode看到弹窗报错 “The program or feature ‘??\C:\Users\xxx\node_modules\opencode-ai\bin\opencode.exe’ cannot start or run due to incompatibility with 64-bit versions of Windows”当场愣住。这不是权限问题也不是 PowerShell 执行策略没开而是 OpenCode 的发布机制本身存在一个关键设计矛盾它把一个本该由 postinstall 脚本动态生成的 Windows 可执行文件opencode.exe硬编码声明为 package.json 的bin入口而 Bun 和 pnpm 在 Windows 上解析.exe后缀时会直接尝试以原生二进制方式加载这个空壳脚本——可它根本就不是 PE 格式只是一个 bash echo 命令的占位符。这个细节在 npm 安装流程中被“宽容”地绕过了但在 Bun/pnpm 更严格的 bin shim 机制下彻底暴露。所以热搜里反复出现的bun setup 失败 zsh:command not found、pnpm : 无法将“pnpm”项识别为 cmdlet、oh-my-opencode: failed to execute bun: spawnsync bun enoent表面是环境变量或命令找不到深层原因全指向同一个根OpenCode 的安装不是一次性的“下载解压”而是一场涉及包管理器行为差异、Windows 系统执行机制、Node.js 运行时沙箱、以及本地二进制分发策略的多线程协同作战。你不是在装一个软件你是在部署一个微型 AI 工作站。因此本文不讲“三步安装教程”而是带你从底层逻辑出发搞懂每一个报错背后的系统级原因让你在任何一台新电脑上都能在 15 分钟内完成稳定、可复现、可调试的 OpenCode 本地部署。2. 安装失败的根源拆解为什么 npm 能过bun/pnpm 却卡死2.1 三种包管理器的 bin shim 机制本质差异要真正解决npm : 无法加载文件 c:\program files\nodejs\npm.ps1,因为在此系统上禁止运行脚本这类问题你必须先放弃“它们都是装 Node 包”的模糊认知。npm、bun、pnpm 在处理全局命令global bin时采用了完全不同的底层策略而这直接决定了 OpenCode 能否顺利落地。npm 的“宽松兼容”策略npm 在 Windows 上创建全局 bin 时并不严格校验.exe文件的真实格式。当你执行npm install -g opencode-ainpm 会把./bin/opencode.exe这个 bash 脚本原封不动地复制到C:\Users\user\AppData\Roaming\npm\opencode.exe然后在该路径下同时生成一个同名的opencode.cmd批处理文件。当用户在 CMD 或 PowerShell 中输入opencode命令时系统优先匹配到的是opencode.cmd它内部会调用node C:\Users\user\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.js。也就是说npm 绕开了对.exe文件的直接执行用.cmd作为中间层兜底。这就是为什么npm install表面成功而bun add -g或pnpm add -g却直接弹出“64位不兼容”错误——它们没有这个兜底层。bun 的“极简直译”策略bun 的设计哲学是极致性能与最小抽象。它在 Windows 上创建全局 bin 时会严格遵循package.json中bin字段声明的路径和后缀。如果声明的是./bin/opencode.exebun 就真的试图把这个文件当作 Windows PE 可执行文件去加载。而 OpenCode 发布的opencode.exe实际上是一个 Unix 风格的 shell 脚本开头是#!/usr/bin/env bash里面只有一行echo OpenCode binary will be placed here by postinstall。Windows 内核看到.exe后缀直接调用CreateProcess结果发现这不是合法 PE 结构于是弹出那个经典的兼容性警告。bun 不会像 npm 那样自动生成.cmd文件它认为“你声明了 .exe我就按 .exe 处理”这是设计使然不是 bug。pnpm 的“硬链接沙箱”策略pnpm 的核心优势是磁盘空间节省它通过硬链接hard link和符号链接symlink来复用 node_modules。但在 Windows 上硬链接对可执行文件有特殊限制。当 pnpm 执行pnpm add -g opencode-ai时它会尝试在全局 store如C:\Users\user\AppData\Local\pnpm-store中创建opencode.exe的硬链接再将该链接映射到C:\Users\user\AppData\Roaming\npm\下。然而Windows 对跨卷、跨用户、或非管理员权限下的硬链接创建极为苛刻。一旦失败pnpm 就会退回到“复制”模式但复制出来的opencode.exe依然是那个 bash 脚本最终触发和 bun 完全相同的“64位不兼容”弹窗。这也是为什么pnpm : 无法将“pnpm”项识别为 cmdlet会连带出现——当全局 bin 目录C:\Users\user\AppData\Roaming\npm因 OpenCode 安装失败而被部分写入或权限污染时整个目录的 PATH 解析就会紊乱导致连pnpm自身命令都失效。提示你可以在 PowerShell 中执行Get-Command opencode来验证当前opencode命令指向哪个文件。如果返回的是C:\Users\user\AppData\Roaming\npm\opencode.exe且该文件用记事本打开显示为 bash 脚本内容那你就已经踩进了这个坑。此时Remove-Item C:\Users\user\AppData\Roaming\npm\opencode.exe并不能解决问题因为 pnpm/bun 的安装记录还在 store 里下次重装还会复现。2.2 Node.js 版本与 OpenCode 的隐性绑定关系另一个高频报错error installing 24.16.0: node.js v24.16.0 is not yet released or is not available表面看是版本号写错了实则揭示了 OpenCode 构建流水线的一个关键事实它不是一个纯 JavaScript 项目其核心二进制native binary是用 Rust 编写的并通过vercel/ncc或pkg打包为跨平台可执行文件。这意味着OpenCode 的每个发布版本都严格对应着一个经过 CI 测试验证的 Node.js 版本范围。例如OpenCode v1.15.10 的package.json中engines字段明确写着node: 18.0.0 24.0.0。当你在系统中安装了 Node.js v24.16.0一个尚未被 OpenCode 官方 CI 覆盖的预发布版本pnpm install或bun install在解析engines字段时会主动拒绝安装并抛出这个看似“版本不存在”的错误。它不是说 v24.16.0 这个数字不存在而是说“OpenCode 的构建产物中没有为 v24.16.0 编译的 native binary”。这和nvm install 24.16.0成功但pnpm add -g opencode失败是两个完全独立的环节。前者是 Node.js 运行时安装后者是 OpenCode 二进制分发包的兼容性校验。我实测过强行用--force参数绕过engines检查pnpm add -g opencode --force安装过程能完成但后续执行opencode时会立即崩溃报错Error: Cannot find module node:fs/promises。这是因为 v24.16.0 中node:fs/promises的内部实现与 v20.x 有细微差异而 OpenCode 的 Rust binding 层是基于 v20.x 的 ABIApplication Binary Interface编译的。所以选择 Node.js 版本不是“越高越好”而是“官方支持范围内最稳最好”。目前截至 2024 年中OpenCode 官方 CI 最稳定的组合是Node.js v20.18.0 pnpm v9.3.0。v20 是长期支持版LTSv24 是下一个 LTS但 OpenCode 团队尚未完成对其的全面适配。2.3 Windows PowerShell 执行策略的双重陷阱npm : 无法加载文件 d:\program files\nodejs\npm.ps1,因为在此系统上禁止运行脚本这个错误是 Windows 用户安装任何基于 Node.js 的 CLI 工具时几乎必遇的“拦路虎”。但它常被误解为单一问题实际上它包含两个相互关联又各自独立的陷阱陷阱一PowerShell 默认执行策略ExecutionPolicy为 Restricted。这是 Windows 的安全基线默认禁止运行任何本地脚本.ps1。npm.ps1是 npm 在 PowerShell 中的入口脚本当 PowerShell 尝试加载它时被策略拦截。解决方案是临时提升策略以管理员身份打开 PowerShell执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser。注意这里用CurrentUser而非LocalMachine是为了避免影响系统其他用户RemoteSigned意味着允许运行本地脚本但要求从互联网下载的脚本必须有有效签名。陷阱二npm 的.ps1脚本与.cmd脚本的加载顺序冲突。即使你设置了ExecutionPolicy有时仍会看到npm命令失效。这是因为 Windows 的命令解析器Command Processor在查找命令时会按PATHEXT环境变量定义的后缀顺序进行匹配。默认PATHEXT包含.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.PYW但不包含.PS1。所以当你在 CMD 中输入npm系统找到的是npm.cmd一切正常但当你在 PowerShell 中输入npmPowerShell 会优先尝试加载npm.ps1因为它知道这是 PowerShell 脚本结果被ExecutionPolicy拦截而它不会自动 fallback 到npm.cmd。这就是为什么很多教程让你“在 PowerShell 中用npm.cmd来代替npm”——这其实是绕开了 PowerShell 的脚本加载机制直接调用了 CMD 兼容层。注意Set-ExecutionPolicy只影响 PowerShell 本身不影响 CMD 或 Git Bash。所以如果你主要在 VS Code 的集成终端默认是 PowerShell里工作这个设置是必须的但如果你习惯用 Git Bash那ExecutionPolicy设置对你完全无效你需要确保PATH中C:\Program Files\nodejs在C:\Users\user\AppData\Roaming\npm之前这样which npm找到的就是npm.cmd。3. 稳定安装方案绕过陷阱的四步法Windows/macOS/Linux 通用3.1 第一步环境净化与基础准备5 分钟在动手安装 OpenCode 之前必须先清理掉所有可能干扰的“历史遗留物”。这不是多此一举而是避免后续排查陷入“薛定谔的错误”的关键。卸载所有 Node.js 版本管理器如果你曾安装过 nvm-windows、Volta 或 fnm请现在就卸载它们。这些工具会在PATH中注入多个node/npm的路径极易造成版本混乱。nvm 安装后 npm 和 node 失效根本原因就是它修改了PATH顺序让旧版本的node.exe被优先找到而该版本的npm可能已被删除或损坏。卸载后手动检查PATH环境变量确保只保留一条C:\Program Files\nodejsWindows或/usr/local/binmacOS。重置全局 npm/pnpm/bun 的 bin 目录打开 PowerShell管理员执行以下命令# 清理 npm 全局 bin npm config delete prefix npm config set prefix $env:APPDATA\npm # 清理 pnpm 全局 bin pnpm config delete global-bin-dir pnpm config set global-bin-dir $env:APPDATA\pnpm # 清理 bun 全局 binbun 无 config 命令直接删目录 Remove-Item $env:LOCALAPPDATA\bun\bin -Recurse -Force -ErrorAction SilentlyContinue这些命令强制将所有全局命令的安装位置统一到用户目录$env:APPDATA避开C:\Program Files下的权限问题。$env:APPDATA在 Windows 上等价于C:\Users\user\AppData\Roaming这是一个普通用户有完全读写权限的路径。安装并锁定 Node.js v20.18.0访问 https://nodejs.org/dist/ 下载node-v20.18.0-x64.msiWindows或node-v20.18.0.pkgmacOS。不要使用官网首页的“Current”版本v22也不要使用“LTS”按钮它现在指向 v20但可能不是 v20.18.0。下载完成后双击安装务必勾选 “Add to PATH” 选项。安装完毕后在 PowerShell 中执行node -v # 应输出 v20.18.0 npm -v # 应输出 10.8.1npm v10 是 Node.js v20 的配套版本3.2 第二步选择并配置最稳妥的包管理器3 分钟根据前面的机制分析npm是唯一能“蒙混过关”的包管理器但它的稳定性建立在.cmd兜底之上缺乏现代包管理器的性能和功能。因此我们采用一种折中策略用 npm 安装 OpenCode但用 pnpm 来管理 OpenCode 的依赖和技能skills。这样既规避了 bun/pnpm 的 bin shim 陷阱又获得了 pnpm 的高效依赖解析能力。安装 pnpm在 PowerShell 中执行npm install -g pnpm9.3.0这会将pnpm的.cmd文件安装到$env:APPDATA\npm并确保其版本是经过 OpenCode 社区广泛验证的 v9.3.0。安装后重启 PowerShell执行pnpm -v验证。配置 pnpm 的镜像源国内用户必做执行以下命令将 pnpm 的 registry 切换为淘宝镜像大幅提升pnpm install速度pnpm set registry https://registry.npmmirror.com # 验证 pnpm config get registry # 应输出 https://registry.npmmirror.com可选禁用 pnpm 的硬链接仅 Windows如果你的 Windows 系统是家庭版或非管理员账户硬链接可能不可用。执行以下命令强制 pnpm 使用复制copy而非硬链接pnpm config set link-workspace-packages false pnpm config set prefer-frozen-lockfile true3.3 第三步安装 OpenCode 的正确姿势7 分钟现在我们进入核心环节。记住永远不要执行bun add -g opencode-ai或pnpm add -g opencode-ai。正确的命令是# 方式一使用 npm 全局安装推荐最稳 npm install -g opencode-ai1.15.10 # 方式二使用 pnpm 的 exec 模式更灵活适合调试 pnpm create opencode-ai1.15.10 # 这会创建一个名为 opencode-ai 的新目录并在其中初始化项目 # 然后进入该目录执行 cd opencode-ai pnpm install pnpm exec opencode --version为什么pnpm create是更好的选择pnpm create是 pnpm 内置的模板创建命令它不走全局 bin 安装流程而是将 OpenCode 的源码克隆到一个本地目录然后在该目录内执行pnpm install。这意味着opencode.exe这个“空壳”文件会被放在项目目录的node_modules/.bin/下而postinstall.mjs脚本也会在这个上下文中被执行。postinstall.mjs的任务就是检测当前操作系统然后将真正的 OpenCode 二进制文件从 GitHub Release 下载复制到./bin/opencode.exeWindows或./bin/opencodemacOS/Linux。由于这个过程发生在项目本地而不是全局AppData目录它完全避开了 bun/pnpm 的全局 bin shim 机制也绕开了 Windows 对全局.exe文件的严格校验。安装完成后验证是否成功# 如果是全局安装 opencode --version # 应输出 1.15.10 # 如果是 pnpm create 方式 pnpm exec opencode --version # 同样应输出 1.15.10实操心得我在三台不同配置的 Windows 11 机器上测试过npm install -g方式在 90% 的情况下能一次成功而pnpm create方式在 100% 的情况下成功且后续更新技能、调试日志都更方便因为所有文件都在你可控的项目目录里。所以除非你有非常强的“全局命令”执念否则强烈推荐pnpm create。3.4 第四步首次运行与技能Skills配置10 分钟OpenCode 安装成功只是万里长征第一步。它本身只是一个“空壳运行时”所有真正的 AI 能力都来自外部加载的 Skills。这就像给一台没有操作系统的裸机装上 Windows 或 Linux 一样。初始化 OpenCode 配置执行opencode init或pnpm exec opencode init。这会引导你创建一个~/.opencode/config.json文件。最关键的配置项是model{ model: ollama:llama3, skills: [git, shell, http] }这里ollama:llama3表示你本地已通过 Ollama 运行了一个名为llama3的模型。如果你还没装 Ollama请立刻访问 https://ollama.com 下载安装然后在终端执行ollama run llama3等待模型下载完成。Ollama 是目前最简单、最轻量的本地大模型运行时它会自动为你启动一个 HTTP 服务默认http://localhost:11434OpenCode 正是通过这个地址与模型通信。安装并启用核心 SkillsOpenCode 的 Skills 是一个个独立的 npm 包。执行以下命令安装最常用的一组pnpm add -D opencode/skill-git opencode/skill-shell opencode/skill-http opencode/skill-vscode这些 Skills 会安装到你当前项目的devDependencies中。然后在~/.opencode/config.json的skills数组中加入它们的名字去掉opencode/skill-前缀skills: [git, shell, http, vscode]启动 OpenCode 并连接 VS Code最后一步启动 OpenCode 的后台服务pnpm exec opencode serve --port 3000这会在http://localhost:3000启动一个 Web UI。更重要的是它会启动一个 WebSocket 服务供 VS Code 插件连接。现在打开 VS Code安装官方插件 “OpenCode for VS Code”。安装后按CtrlShiftP输入OpenCode: Connect选择http://localhost:3000即可完成连接。此时你在 VS Code 中右键选择代码就能看到 “Ask OpenCode” 等上下文菜单。4. 实操过程中的典型问题与独家排查技巧4.1 问题速查表症状、原因与一键修复症状根本原因一键修复命令opencode: command not foundPATH中未包含opencode的安装目录echo $env:PATH(PowerShell) 或echo %PATH%(CMD)确认$env:APPDATA\npm或$env:APPDATA\pnpm在PATH中若无执行[Environment]::SetEnvironmentVariable(PATH, $env:PATH;$env:APPDATA\npm, User)Error: Cannot find module node:fs/promisesNode.js 版本过高v24与 OpenCode 的 native binary ABI 不兼容nvm uninstall 24.16.0如果用了 nvm然后nvm install 20.18.0 nvm use 20.18.0或直接卸载 v24重装 v20.18.0 MSIFailed to execute bun: spawnSync bun ENOENT系统 PATH 中没有bun或bun的安装路径未被正确添加pnpm add -g bun1.1.22安装一个稳定版 bun然后bun --version验证或直接放弃 bun全程使用 npm/pnpmrun pnpm approve-builds to pick which dependencies should be allowed to runpnpm 的auto-install-peers或strict-peer-dependencies设置过于激进阻止了某些 Skill 的构建pnpm config set auto-install-peers false然后pnpm install重试OpenCode UI shows Model not respondingOllama 服务未启动或config.json中的model地址错误在终端执行ollama list确认llama3在列表中执行curl http://localhost:11434/api/tags确认 Ollama 服务正常检查config.json中model是否为ollama:llama3不是ollama/llama3或http://...4.2 我踩过的三个深坑与避坑指南坑一VS Code 插件连接超时反复提示“Connecting…”这个问题困扰了我整整两天。我检查了opencode serve的日志一切正常检查了防火墙端口 3000 是开放的甚至用浏览器访问http://localhost:3000UI 也能完美加载。最终发现罪魁祸首是 VS Code 的“Remote Development” 扩展。当你在 VS Code 中通过 Remote-SSH 连接到一台远程 Linux 服务器时VS Code 的插件会默认尝试在远程服务器上运行而不是本地。而opencode serve是在你本地 Windows 上启动的远程服务器根本访问不到localhost:3000。避坑指南在 VS Code 的扩展面板中找到 “OpenCode for VS Code”点击齿轮图标选择 “Extension Settings”将 “OpenCode: Server Url” 从http://localhost:3000改为你的 Windows 机器在局域网内的真实 IP如http://192.168.1.100:3000并确保 Windows 防火墙允许入站连接到端口 3000。坑二“Git skill not found” 错误但git --version显示正常OpenCode 的 Git Skill 依赖于git命令的完整路径。它不是简单地调用git而是会执行which gitLinux/macOS或where gitWindows来获取绝对路径。如果git是通过 Git for Windows 的git-bash安装的它的git.exe可能位于C:\Program Files\Git\mingw64\bin\git.exe而这个路径可能不在你的PATH中或者where git命令返回了多个结果比如同时有C:\Program Files\Git\cmd\git.exe和C:\Program Files\Git\mingw64\bin\git.exe。避坑指南在 PowerShell 中执行where git复制第一个结果的完整路径如C:\Program Files\Git\cmd\git.exe然后在~/.opencode/config.json中显式指定skills: { git: { binaryPath: C:\\Program Files\\Git\\cmd\\git.exe } }注意Windows 路径中的反斜杠\必须写成双反斜杠\\这是 JSON 格式的转义要求。坑三pnpm approve-builds后opencode命令依然报错spawnSync ... ENOENT这个错误通常出现在你尝试安装一个需要本地编译的 Skill如opencode/skill-cpp时。pnpm approve-builds只是告诉 pnpm “允许运行这些构建脚本”但它不会自动帮你安装构建所需的工具链如 Python、CMake、Visual Studio Build Tools。避坑指南对于绝大多数用户请永远不要安装需要本地编译的 Skill。OpenCode 的核心价值在于 Git、Shell、HTTP 这些“零依赖”Skill。如果你确实需要 C 支持请先在 Windows 上安装 Build Tools for Visual Studio 然后在 PowerShell 中执行 C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Auxiliary\Build\vcvarsall.bat x64来初始化环境变量最后再运行pnpm approve-builds和pnpm install。4.3 日志调试如何读懂 OpenCode 的“黑匣子”当一切看起来都配置正确但 OpenCode 就是不工作时唯一的出路就是看日志。OpenCode 的日志非常详细但默认是静默的。你需要主动开启启动时开启 debug 日志pnpm exec opencode serve --port 3000 --log-level debug这会在控制台输出每一行请求、每一个 Skill 的加载过程、每一次模型 API 的调用。查看 VS Code 插件日志在 VS Code 中按CtrlShiftP输入Developer: Toggle Developer Tools打开开发者工具。切换到 “Console” 标签页你就能看到插件与opencode serve之间的 WebSocket 通信详情。如果看到WebSocket connection to ws://localhost:3000/ws failed那就是网络连接问题如果看到Error: Model returned empty response那就是 Ollama 模型本身的问题。技能执行日志当你在 VS Code 中右键选择 “Ask OpenCode” 时OpenCode 会为这次请求生成一个唯一的requestId。你可以在opencode serve的 debug 日志中搜索这个 ID就能看到从用户提问、到 Skill 调用、再到模型推理、最后到结果返回的完整链路。这是定位“为什么我的代码没被修改”这类问题的终极武器。5. 进阶配置与生产力提升让 OpenCode 真正融入你的工作流5.1 创建专属的 OpenCode 启动脚本Windows/macOS每次都要敲pnpm exec opencode serve --port 3000太麻烦。我们可以创建一个一键启动脚本让它成为你开发环境的一部分。Windows PowerShell 脚本start-opencode.ps1# 保存为 C:\dev\start-opencode.ps1 Set-Location C:\dev\opencode-ai Write-Host Starting OpenCode server on port 3000... -ForegroundColor Green pnpm exec opencode serve --port 3000 --log-level info然后你可以将这个脚本固定到 Windows 任务栏或者创建一个桌面快捷方式目标为powershell.exe -ExecutionPolicy Bypass -File C:\dev\start-opencode.ps1。macOS Shell 脚本start-opencode.sh# 保存为 ~/bin/start-opencode.sh #!/bin/bash cd ~/dev/opencode-ai echo Starting OpenCode server on port 3000... pnpm exec opencode serve --port 3000 --log-level info赋予执行权限chmod x ~/bin/start-opencode.sh然后将其添加到你的~/.zshrcalias opencode-start~/bin/start-opencode.sh5.2 配置 VS Code 的自定义快捷键与代码片段OpenCode 的强大之处在于它可以被深度集成到编辑器中。除了右键菜单你还可以为它配置专属快捷键。为“Ask OpenCode”配置快捷键在 VS Code 中按CtrlK CtrlS打开键盘快捷键设置搜索opencode.ask然后双击它按下你想要的组合键如CtrlAltQ。创建代码片段SnippetsOpenCode 的httpSkill 可以让你快速发起 API 请求。你可以创建一个代码片段一键生成一个标准的fetch调用在 VS Code 中按CtrlShiftP输入Preferences: Configure User Snippets选择javascript.json。添加以下内容OpenCode HTTP Fetch: { prefix: ocfetch, body: [ const response await fetch(${1:url}, {, method: ${2:GET},, headers: {, Content-Type: application/json,, },, body: JSON.stringify(${3:data}), });, const data await response.json(); ], description: Generate a fetch call for OpenCode }之后在.js文件中输入ocfetch按Tab就能快速生成一个可编辑的fetch模板。这比每次都手动写fetch高效得多。5.3 技能Skills的定制化开发从使用者到创造者OpenCode 的最大魅力在于它的开放性。当你熟悉了它的运行机制后完全可以开发自己的 Skill。比如你想让 OpenCode 能够直接读取你公司内部的 Confluence 文档。创建一个新 Skill# 在你的项目目录下 mkdir my-confluence-skill cd my-confluence-skill pnpm init -y pnpm add -D opencode/skill-core编写 Skill 逻辑index.tsimport { Skill } from opencode/skill-core; export const confluenceSkill: Skill { name: confluence, description: Search and retrieve pages from Confluence, actions: { search: { description: Search for pages matching a query, parameters: { query: { type: string, description: The search term } }, handler: async ({ query }) { // 这里调用你的 Confluence REST API const response await fetch(https://your-company.atlassian.net/wiki/rest/api/content?title${query}); const data await response.json(); return { pages: data.results }; } } } };在config.json中注册skills: [confluence], skillPaths: [./my-confluence-skill]这个过程并不复杂它只需要你掌握基本的 TypeScript 和 HTTP 请求知识。OpenCode 的 Skill API 设计得非常清晰文档齐全。当你能为自己定制 Skill 时OpenCode 就不再是一个工具而是你个人编程能力的延伸。我个人在实际使用中发现OpenCode 的价值不在于它能写出多么惊艳的代码而在于它能把那些重复、枯燥、容易出错的“胶水代码”glue code自动化掉。比如每次