OpenCode 不只是一个跑在终端里的编码助手，它还能跟 GitHub、GitLab 这些平台打配合，把 AI 能力直接塞进团队的工作流里。自动化代码审查、智能处理 Issue、团队内分享对话——这些都可以搞定。
1. GitHub 集成
在 GitHub 上用 OpenCode 非常省事——你就在 Issue 或者 Pull Request 的评论里提一句 /opencode 或者 /oc，它马上就在你的 GitHub Actions 运行器里启动任务了。
1.1 能干什么
Issue 分类：有时候 Issue 写得不太清楚，或者重复了，让 OpenCode 先帮你看看，它会理解上下文然后给出解释。处理社区收到的海量 Issue 时特别管用。
直接修 Bug：告诉 OpenCode 去修某个 Issue，它会自己开个新分支、改完代码、直接提交一个 PR。不用你手动操作任何步骤。
安全可控：OpenCode 跑在你自己的 GitHub 运行器上，代码和密钥都在你自己的基础设施里，不会经过任何第三方服务。
1.2 安装配置
两种方式。懒人方式：跑一下 opencode github install，跟着引导走完就行。手动方式：先在 GitHub 上装好 opencode-agent App，然后自己写工作流文件。
工作流文件一般放在 .github/workflows/opencode.yml，几个关键配置：
model：用哪个 AI 模型，格式是provider/model，必填prompt：可以自定义提示词，覆盖默认行为share：是否共享会话，公开仓库默认 truetoken：GitHub 访问 Token，可选
1.3 触发事件
OpenCode 能响应六种 GitHub 事件：
issue_comment 是最常用的——在 Issue 或 PR 上发评论，提到 /opencode 或 /oc 就触发。OpenCode 会读整个讨论上下文，可以创建分支、提交 PR 或者直接回复。
pull_request_review_comment 是针对 PR 里具体代码行的评论。想在某个具体位置讨论代码？这种方式比笼统的 Issue 评论精准多了。
issues 事件在 Issue 创建或修改时自动触发。因为没有评论可以提取指令，这种方式得在工作流里明确写 prompt。
pull_request 事件在 PR 被打开、同步或重新打开时触发，适合做自动化的 PR 审查。
schedule 是定时任务，比如每周一早上跑一次代码扫描。如果希望 OpenCode 能创建分支或 PR，记得给工作流加 contents: write 和 pull-requests: write 权限。
workflow_dispatch 让你从 GitHub Actions 界面手动触发任务，按需跑。
1.4 怎么用
几个常见的例子：
解释 Issue：/opencode explain this issue，OpenCode 会把整个讨论串读一遍然后给你解释清楚。
修 Issue：/opencode fix this，OpenCode 会自己建分支、改代码、提交 PR。
审查具体代码行：在 PR 的 Files 选项卡里直接对代码行评论，比如 /oc add error handling here，OpenCode 会自动拿到文件路径、行号和周围的 diff 上下文。
2. GitLab 集成
OpenCode 支持两种方式和 GitLab 打通：GitLab CI/CD 流水线或者 GitLab Duo。不管哪种，OpenCode 都跑在你自己的 GitLab Runner 上。
2.1 GitLab CI 模式
这种方式把 OpenCode 作为 CI 组件加到常规流水线里，用的是社区做的 nagyv/gitlab-opencode 组件。
几个特点：用自定义配置目录可以为每次调用独立设置功能；CI 组件在后台搞定 OpenCode 的设置，你只需要准备配置和提示词；支持很多输入参数来定制行为。
配置起来分两步：先把 OpenCode 的身份验证 JSON 存为 CI 环境变量（要勾选 Masked and hidden），再在 .gitlab-ci.yml 里引入组件。
2.2 GitLab Duo 模式
GitLab Duo 的玩法是在评论里 @opencode，之后 OpenCode 会在 GitLab CI 流水线里执行任务。功能跟 GitHub 集成差不多：Issue 分类、直接修 Bug、跑在你自己的 GitLab Runner 上。
配置流程稍微复杂一点，需要：配置 GitLab 环境、设置 CI/CD、拿到 AI 提供商的 API 密钥、创建服务账户、配置 CI/CD 变量、最后写流程配置文件。
2.3 怎么用
跟 GitHub 那边差不多：
解释 issue：@opencode explain this issue
修 issue：@opencode fix this，同样会建新分支然后提交合并请求
审查合并请求：@opencode review this merge request
3. 对话分享：团队知识传递
OpenCode 的分享功能可以生成一个公开链接，把对话分享给团队成员或者外部的人。
3.1 怎么工作
分享对话时，OpenCode 会生成一个唯一的公开 URL（格式是 opncd.ai/s/<share-id>），同时把对话历史同步到服务器。拿到链接的人直接打开就能看完整的对话内容。
3.2 三种分享模式
手动模式（默认）：新会话不会自动分享，你要用的时候跑一下 /share 命令就行。系统会生成唯一 URL 并复制到剪贴板。
自动分享：在配置文件里加一句 "share": "auto"，之后每个新对话都会自动生成分享链接。
禁用：设成 "share": "disabled" 就完全关闭分享功能。敏感项目的话，可以把这个配置写到项目的 opencode.json 里再提交到 Git，整个团队都会继承这个设置。
3.3 取消分享
跑一下 /unshare 命令就能停止分享，移除公开访问。系统会删除分享链接以及跟这个对话相关的数据。
4. 隐私与企业级考虑
4.1 数据留存
需要知道的是，共享的对话在取消分享之前会一直可访问。包括完整的对话历史、所有消息和回复，以及会话元数据。这些数据会同步到 OpenCode 的服务器。
4.2 安全建议
- 只分享不包含敏感信息的对话
- 分享前检查一下对话内容
- 协作完了尽快取消分享
- 不要分享包含专有代码或机密数据的对话
- 敏感项目直接在配置里禁用分享
4.3 企业版
企业部署的话，分享功能可以灵活调整：出于安全合规考虑可以完全禁用；可以限制为只有通过 SSO 身份验证的用户才能用；也支持部署到企业自己的基础设施上。
小结
把 OpenCode 集成到团队的开发流程里，代码审查和 Issue 处理的效率能提升不少。GitHub 和 GitLab 的集成方式各有特点：GitHub 通过评论里的简单命令触发，GitLab 支持 CI 组件和 Duo 两种模式。分享功能给团队协作提供了便利，但使用时要注意隐私保护，特别是涉及敏感代码和数据的场景。