我是怎么部署开源 AI 编程助手 OpenCode：并在两个真实场景使用起来的

大家好，我是程序员码歌。用 OpenCode 已经有一段时间了，这篇文章给大家详细分享下安装、配模型，以及两个真实应用场景——内网知识库问答、PR Review代码。

这篇主要讲什么

•OpenCode 是啥，和 Cursor 有啥不同

•怎么装、怎么确认装对

•用 GitHub Copilot 订阅和便宜 API 怎么接 OpenCode

•两个应用场景各起一个 OpenCode 实例

•场景一：文档仓实例，内网 md + Copilot 问答

•场景二：代码仓实例，PR 自动 Review

一、OpenCode 是什么

OpenCode 是开源 AI 编程 Agent，装本机跑，不绑单一模型。默认进终端 TUI，也能opencode run单条执行、opencode serve给别人连。

和 Cursor 不冲突：它偏终端、可换模型、能脚本化。我常用两件事：Tab 切 plan/build（plan 只读，build 改代码），对话里 @文件带上下文。

二、模型怎么选

模型 ID 写成provider/model，如deepseek/deepseek-chat。TUI 里/connect配 Key、/models切换；默认写进opencode.json。

软件免费，模型走你已买的订阅或 API。我主力是GitHub Copilot。

GitHub Copilot： 公司有 Copilot 订阅就能在 OpenCode 里用，不用另买一份 Claude API。TUI 里/connect搜 GitHub Copilot，浏览器打开 github.com/login/device 输入设备码，登完/models选 Copilot 里的模型（部分型号要 Pro+ 套餐，见 Copilot 计划）。

cd your-repoopencode/connect# 选 GitHub Copilot，按提示完成设备码登录/models # 选例如 Claude / GPT 等 Copilot 提供的模型

凭证落在~/.local/share/opencode/auth.json，别提交 Git。默认模型可在opencode.json里写，具体 ID 以/models列表为准。

便宜 API（可选）： PR Review 的 Actions 里我有时用 DeepSeek（按量低），和本机 Copilot 分开。Groq、OpenRouter 也能/connect接上。

我平时的组合：

实例一只@相关 md；实例二才装 GitHub workflow，别混仓。

三、安装

先安装旧版的请先卸载。五条路选一条即可，装完验证方式相同。

验证：opencode --version→opencode进 TUI →/connect→/models有列表 → plan 模式随便问一句。

四、日常怎么用

cd your-repo && opencode

脚本场景：opencode run -m <copilot模型ID> "..."（模型 ID 在/models里看）。多人可opencode serve，别人opencode attach http://IP:4096（各自仍需自己的 Copilot 登录）。

五、两个应用场景，各起一个 OpenCode 实例

这两个场景我没有共用一个 OpenCode 会话或同一个仓库，而是拆成两套实例：各对应一个 Git 仓库、一份AGENTS.md、一套用法。混在一起的坏处是上下文串味——文档问答的 prompt 和 PR Review 的规则打架，权限也不好控（文档实例该只读，代码实例可能要改）。

实例一只放 Markdown 文档，不当业务代码仓用。实例二才装opencode github install、才放opencode-review.yml。两台机器上可以各跑一个serve，端口分开，例如文档4096、代码4097，避免同事 attach 错环境。

下面分别说这两个实例怎么落地。

六、场景一：内网知识库问答（实例一）

我们想把需求文档、API 规范、发布流程这类文档交给 AI 查。

做法是把文档落成 Markdown 放在内网 Git 仓库，OpenCode 接GitHub Copilot，用@只带进相关 md，plan 模式只问不改代码。文档在内网仓，问的时候控制@范围；模型侧走 Copilot，需公司允许用 Copilot 且你有有效订阅。

6.1 文档怎么准备

•从飞书、Confluence 等导出或同步成.md，按主题分目录，例如：

•docs/运维/发布.md

•docs/API/鉴权.md

•一篇文档只讲一件事，标题清楚，比一个大 PDF 好用。

•仓库单独建也行，挂在业务仓的docs/下也行，关键是内网能 clone。

6.2 在文档仓里接上 Copilot

在文档仓（实例一），能访问 GitHub 的开发机上：

cd /path/to/docs-repoopencode

TUI 里：

1./connect→ 选GitHub Copilot

2.终端会给设备码，浏览器打开 github.com/login/devic… 登录授权

3./models选 Copilot 里顺手的模型（我写文档问答常用偏强的那个）

4.Tab 切 plan，避免 Agent 改仓库文件

第一次连完后，以后进仓库一般会自动带上 Copilot。需要固定默认模型时，把/models里看到的 ID 写进opencode.json的model字段即可。

6.3 怎么问才靠谱

好的问法会把范围说死，并@具体文件：

根据 @docs/运维/发布.md，生产环境回滚要几步？只根据文档回答；文档没写就说没有，不要猜。

尽量别这样问：

•「帮我看看需求文档」——范围太大，容易编。

•一上来@整个docs/——上下文爆掉，答案也飘。

文档特别多、单文件很长时，可以opencode mcp add接公司自己的检索 MCP，先搜再@命中段落；文档量不大时，直接@两三个相关 md 就够。

6.4 用 AGENTS.md 卡住边界

在仓库跑一遍/init，或自己写AGENTS.md，我这边至少两条：

•禁止webfetch访问外网。

•回答必须注明依据哪份文档、哪一节；找不到就明确说「文档未记载」。

这样比每次口头提醒稳。

6.5 多人怎么用

文档仓大家各自 clone，在实例一里各自opencode+/connect自己的 Copilot 即可。

若要固定一台「文档问答专用机」，只跑实例一：

cd /path/to/company-docsopencode serve --hostname 0.0.0.0 --port 4096

设OPENCODE_SERVER_PASSWORD。同时opencode attach http://10.x.x.x:4096时，工作目录仍应是文档仓；不要和实例二共用 4096 端口。

七、场景二：Git PR 自动 Review（实例二）

在业务代码仓单独起实例二。PR 有人提上来，让 AI 先扫一遍：明显安全问题、漏测、和规范不一致的地方先留在评论里，人再重点看。OpenCode 官方带 GitHub 集成，可以自动跑在 Actions 里，也可以在 PR 评论里手动喊它。

常见三种用法：

7.1 在代码仓里第一次接入

在业务代码仓根目录（实例二，不要和文档仓混用）：

opencode github install

按向导做完几件事：

1.安装 OpenCode GitHub App 到目标仓库（或组织）。

2.生成.github/workflows/opencode.yml（或 review 专用 workflow）。

3.提示你去仓库Settings → Secrets → Actions加 Key，例如DEEPSEEK_API_KEY。

DeepSeek 按量便宜，我们 PR Review 默认用它；公司有 Azure/Bedrock 就把model和env换成那套。

7.2 PR 自动 Review 的 workflow

我们单独放opencode-review.yml，只在 PR 事件时跑：

name: opencode-reviewon:pull_request:types: [opened, synchronize, reopened, ready_for_review]jobs:review:runs-on: ubuntu-latestpermissions:contents: readpull-requests: readissues: readsteps:- uses: actions/checkout@v6with:persist-credentials: false- uses: anomalyco/opencode/github@latestenv:DEEPSEEK_API_KEY: ${{ secrets.DEEPSEEK_API_KEY }}GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}with:model: deepseek/deepseek-chatuse_github_token: trueprompt: |按仓库 AGENTS.md 的规范 Review 这个 PR：- 安全：注入、权限、密钥是否泄露- 错误处理和边界条件- 测试是否覆盖主要变更只评论你确定的问题，不要凑字数，不要建议风格小事。

pull_request触发且不写 prompt时，OpenCode 也会默认做 Review；我们加上 prompt 是为了对齐仓库里的AGENTS.md。

合并进 main 后，下次有人开 PR 或 push 新 commit，Actions 里会自动跑一遍，评论出现在 PR 对话里。

7.3 PR 里点名某一行改

在 GitHubFiles changed某行下评论：

/oc 这里改成参数化查询，别拼 SQL

OpenCode 会带上文件路径、行号、diff 上下文，比你在总评里泛泛说「注意 SQL」准。如果希望它直接推 commit 到同一 PR，workflow 里要给contents: write（我们初评只读，改代码仍人工合）。

7.4 合并前本地先看

在代码仓开 PR 前，用实例二本地扫 diff：

cd /path/to/app-backendopencode pr 42

会 checkout 到 PR 分支。在同一仓库再起opencode，切plan，例如：

对比当前分支和 main 的 diff，列出 3 个最值得人看的风险点。

比网页里翻 patch 快，尤其适合大 PR。

7.5 踩过的点

•Secrets 别写进仓库，只放 GitHub Actions Secrets。

•permissions 给够：只读 Review 用contents: read；要自动改 PR 再开 write。

•公共仓库注意 OpenCode 的share默认行为，敏感项目关掉或只用私有仓。

•评论太多会吵，prompt 里写「只评确定的」能减废话。

八、一句收尾

有自己真实应用场景想走cli ，内网部署或者想对接业务系统，就值得装。它比直接调用模型api 的区别是，它有编排上下文，能直接指定工作目录，有一套不亚于cursor 、codex的完整agent 机制。

和 OpenSpec、Superpowers 也能配合：前者定任务，后者管流程，OpenCode 负责跑。感兴趣可以看下我之前的文章

OpenSpec 到 Superpowers：AI 编码从说清到做对

别再让 AI 自由发挥了：OpenSpec 才是团队协作不跑偏的关键