CI/CD on Svtter's Blog

OpenCode 的 GitHub Actions 自动化体系：27 个 Workflow 背后的工程实践

Fri, 22 May 2026 10:00:00 +0800

opencode 是一个 16 万 star 的 AI 编码工具，它的 .github/workflows/ 目录下有 27 个 workflow 文件。这个数量在开源项目里不算少，但真正有意思的不是数量，而是这些 workflow 覆盖的范围：从常规的 CI/CD 到 AI 驱动的社区治理，几乎把 GitHub Actions 能做的事情都做了一遍。

这篇文章逐类分析这些 workflow 的设计，讨论这种自动化程度的利弊，以及对我们自己项目的启示。

总览

27 个 workflow 可以分成四类：

类别	数量	作用
CI/测试	4	typecheck、单元测试、e2e、Nix 构建
发布/交付	5	CLI 发布、容器构建、VS Code 插件、GitHub Action 发布
自动化/Bot	16	issue 治理、PR 合规、AI code review、文档更新
文档/其他	2	统计、Discord 通知

16 个自动化 workflow 占了总数的 60%。opencode 不只是用 Actions 来跑测试和发布，而是把社区治理和代码质量审查也交给了自动化系统。

CI/测试：扎实但克制

四个测试相关的 workflow：

typecheck.yml — PR 和 push 到 dev 时跑 bun typecheck。简单直接，没有多余动作。

test.yml — 跨平台测试矩阵（Linux + Windows），跑单元测试和 Playwright e2e。有 concurrency 控制，同一个 PR 的新 commit 会取消旧运行。测试结果生成 JUnit 报告上传为 artifact。

nix-eval.yml — 验证 Nix flake 在四种架构（x86_64-linux, aarch64-linux, x86_64-darwin, aarch64-darwin）下的构建。必选包失败会阻断，可选包失败只是警告。

storybook.yml — UI 组件的 Storybook 构建，只在 storybook/ui 相关文件变更时触发。路径触发避免了不必要的运行。

几个值得注意的设计选择：

concurrency group + cancel-in-progress：多个 workflow 都用了这个模式，同一个 PR 不会堆叠多次运行。对于一个接受大量社区 PR 的项目，这能省下不少 CI 资源。
路径触发：containers.yml 只在容器文件变更时运行，storybook.yml 只在 UI 变更时运行。不是所有东西都全量跑。
混合 Runner 策略：大部分 workflow 使用 Blacksmith 提供的第三方托管 runner（blacksmith-4vcpu-ubuntu-2404、blacksmith-4vcpu-windows-2025）。Blacksmith 是一个兼容 GitHub Actions API 的加速 runner 服务，底层用自建基础设施，比 GitHub 免费 runner 快不少。只有轻量级 bot 任务（close-issues、close-prs、compliance-close、pr-standards、deploy）留在 GitHub 原生的 ubuntu-latest 上。计算密集的编译、测试、发布全走 Blacksmith，简单的脚本任务用 GitHub 原生 runner，按任务负载分配资源。

发布/交付：全平台覆盖

publish.yml 是最复杂的 workflow，一个文件处理了完整的发布流程：

版本号计算
CLI 构建矩阵（多平台多架构）
Windows 代码签名（Azure Signing）
macOS 代码签名（Apple Developer）
Electron 应用构建
npm 发布
GitHub Release 创建
AUR（Arch Linux）发布

一个 workflow 覆盖了 CLI、桌面应用、npm 包、Linux 包的分发。这种"全平台一次发布"的模式对用户友好——无论什么平台都能在同一天拿到新版本。

其他发布 workflow 按产物类型拆分：

publish-github-action.yml — 监听 github-v* tag，发布 GitHub Action 到 Marketplace
publish-vscode.yml — 监听 vscode-v* tag，同时发布到 VS Code Marketplace 和 Open VSX
containers.yml — 多架构容器镜像构建，推送到 GHCR
release-github-action.yml — dev 分支有 github 目录变更时创建预发布

tag 触发是一个好的实践：发布是显式动作，不会因为误推代码就触发。publish.yml 会在 push 到 ci/dev/beta/fix 分支时自动构建 snapshot，但正式发布需要手动 dispatch 或 tag。

自动化/Bot：AI 驱动的社区治理

这是 opencode 最有特色的部分。16 个自动化 workflow 中，多个直接调用了 opencode 自己的 AI 能力来处理社区事务。

Issue 管理

triage.yml — 新 issue 创建时，用 opencode AI 自动分流，添加标签和分类。

duplicate-issues.yml — 新 issue 创建/编辑时，用 opencode AI 分析是否与已有 issue 重复。同时检查是否遵循了三种 issue 模板之一，是否包含 AI 生成内容。不合规的会被加上 needs:compliance 标签。

compliance-close.yml — 每 30 分钟检查一次，带有 needs:compliance 标签的 issue/PR 如果 2 小时内没有修正，自动关闭。关闭时会根据是 issue 还是 PR 给出不同的提示信息。

close-issues.yml — 每天凌晨 2 点 UTC 关闭过期的 stale issue。

这四层形成了完整的 issue 生命周期管理：

1

新 issue → AI 分流(triage) → 重复/合规检查(duplicate) → 合规宽限期(compliance) → 过期清理(close)

PR 管理

pr-standards.yml 是最长的 workflow 之一，做了两件事：

标题格式检查：强制 conventional commits 格式（feat/fix/refactor/…）
模板合规检查：PR 描述必须包含 issue 引用、变更类型、验证方法等必要章节

不合规的 PR 会被加上 needs:compliance 标签，2 小时后自动关闭。team 成员和 bot 豁免。

pr-management.yml — PR 创建时查重，并为社区贡献者添加标签。

close-prs.yml — 每天晚上 10 点 UTC 关闭超过 1 个月且点赞数不够的 PR。默认阈值是 2 个 reaction，可配置。

AI Code Review

review.yml — 在 PR 评论中输入 /review，opencode AI 会分析代码并在具体的行上留下 review 评论。只对 repo owner/member 开放。

opencode.yml — 在 issue 或 PR 评论中输入 /oc 或 /opencode，触发 opencode AI 进行更通用的交互。

这两个 workflow 展示了"AI 作为协作者"的思路：不是全自动的 code review，而是按需触发，人在回路中做最终决定。

文档与维护

docs-update.yml — 每 12 小时检查最近的 commit，用 opencode AI 判断是否需要更新文档。

generate.yml — push 到 dev 时运行代码生成脚本，自动提交变更。

beta.yml — 每小时同步 beta 分支。

stats.yml — 每天更新下载统计到 STATS.md。

值得借鉴的设计模式

1. 分层治理

opencode 没有把所有自动化塞进一个 workflow，而是按职责拆分。issue 从创建到关闭经过了四个 workflow 的接力处理。每个 workflow 只做一件事，组合起来形成完整的治理链。

这种设计的好处是：

单个 workflow 可以独立修改、禁用，不影响其他环节
每个 workflow 的触发条件、权限范围都是最小化的
出问题时容易定位是哪个环节

2. 合规宽限期

compliance-close.yml 不是检测到不合规就立即关闭，而是给 2 小时的宽限期。这对全球不同时区的贡献者来说是合理的——你可能正好在睡觉的时候提交了一个 issue，醒来发现有时间修正。

3. AI 用在决策点而不是执行点

triage、duplicate 检测、code review 这些都是 AI 做初步判断，人做最终决定。而代码构建、发布这些执行层面的事情完全不用 AI。这是一个务实的分工：AI 擅长模式识别和初步分类，但不擅长精确执行。

4. 显式触发 vs 自动触发

发布用 tag 触发，日常维护用 schedule 触发，社区治理用事件触发。三种触发方式对应三种不同的自动化信任等级：发布需要人工确认，维护可以定时自动，治理需要即时响应。

过度自动化的风险

opencode 的自动化体系很完善，但也有需要注意的地方：

社区门槛：新贡献者提交 issue 需要遵循特定模板，PR 需要符合 conventional commits，否则 2 小时后自动关闭。对于一个 16 万 star 的项目，这种严格是合理的——它能过滤掉大量低质量贡献。但对于小项目，这种程度的自动化会吓跑潜在贡献者。

维护成本：27 个 workflow 意味着 27 个需要维护的自动化脚本。opencode 有专门的自定义 runner 和专用脚本。如果某个 workflow 的逻辑需要调整，维护者需要在 GitHub Actions 的 YAML + 自定义脚本之间来回切换。

AI 的不确定性：duplicate-issues 和 triage 用 AI 做判断，但 AI 可能误判。一个合理的 issue 被标记为 duplicate 并关闭，对贡献者的体验是负面的。opencode 用宽限期和人工复核来缓解这个问题，但风险依然存在。

对我们项目的启示

不是每个项目都需要 27 个 workflow。但 opencode 的分层治理和"AI 在决策点"的思路值得参考：

从 issue 模板开始：如果项目开始收到大量重复或低质量 issue，先加模板和 duplicate 检查，而不是手动处理每一个。
合规检查用宽限期：自动关闭不合规贡献时，始终给一个宽限期。
AI 用于分类不用于执行：让 AI 帮你分流 issue、检查 PR 格式，但不要让 AI 自动合并代码或发布版本。
发布用 tag 触发：这是最安全的做法。自动发布的 snapshot 可以接受，正式版本需要人工确认。
按需添加：先有痛点再加自动化。opencode 的 27 个 workflow 不是一天建成的，是随着社区规模增长逐步增加的。

总结

opencode 的 GitHub Actions 体系展示了大型开源项目的自动化实践：CI/CD 覆盖全平台发布，社区治理用多层 workflow 接力处理，AI 被用在分流和审查等决策环节。这套系统的核心不是技术复杂度，而是"分层、宽限、显式触发"这三个原则。对于自己的项目，不需要照搬 27 个 workflow，但这些原则可以直接用上。

使用 OpenCode + GLM-5 实现 GitHub PR 自动代码审查

Mon, 26 Jan 2026 00:00:00 +0000

大模型会磨洋工，需要另一个 agent 或 AI 来监督。

最近在项目中集成了 OpenCode 的 AI 代码审查功能，使用智谱 AI 的 GLM-5 模型自动 review PR 代码。本文记录完整的集成过程和踩过的坑。

背景

项目需要一个自动化的代码审查机制：

当 PR 创建或更新时，自动触发 AI 审查
AI 只提供 review 建议，不修改代码
将审查结果以 comment 形式添加到 PR 中

技术选型

OpenCode

OpenCode 是一个开源的 AI coding agent，支持：

多种 LLM 提供商（OpenAI、Anthropic、智谱等）
GitHub/GitLab 集成
在 CI 环境中运行

GLM-5 Coding Plan

选择智谱 AI 的 GLM Coding Plan 原因：

专为 AI 编程优化，支持 OpenCode
价格实惠（$3/月起）
国内访问稳定

TL;DR

如果只是想快速引入 code review，不需要处理权限、凭据等配置，可以直接使用封装好的 action。这是最快引入 code review 的方法，review 结果是中文：

1
2
3
4
5
6
7
8


- name: Run OpenCode review
 uses: Svtter/opencode-actions/review@v1
 with:
 github-token: ${{ secrets.GITHUB_TOKEN }}

 # only one is enough.
 zhipu-api-key: ${{ secrets.ZHIPU_API_KEY }}
 opencode-go-api-key: ${{ secrets.OPENCODE_GO_API_KEY }}

只需要配置对应的 secret 即可使用。

配置详解

1. 确定模型格式

OpenCode 的模型格式为 provider_id/model_id。对于智谱 GLM-5：

配置项	值
环境变量	`ZHIPU_API_KEY`
Model 格式	`zhipuai-coding-plan/glm-5`

2. 创建 Workflow 文件

创建 .github/workflows/opencode-review.yml：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


name: OpenCode PR Review

on:
 pull_request:
 types: [opened, synchronize, reopened, ready_for_review]

jobs:
 review:
 name: AI Code Review
 # 仅在 PR 准备就绪时运行（跳过 draft PR）
 if: github.event.pull_request.draft == false
 runs-on: self-hosted
 permissions:
 id-token: write
 contents: read
 pull-requests: write
 issues: write
 steps:
 - name: Checkout repository
 uses: actions/checkout@v6
 with:
 persist-credentials: true
 token: ${{ secrets.GITHUB_TOKEN }}

 - name: Run OpenCode Review
 uses: anomalyco/opencode/github@latest
 env:
 ZHIPU_API_KEY: ${{ secrets.ZHIPU_API_KEY }}
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 with:
 model: zhipuai-coding-plan/glm-5
 use_github_token: true
 prompt: |
 Review this pull request (read-only mode, DO NOT modify any code):

 Please check:
 - Code quality issues
 - Potential bugs or logic errors
 - Code style consistency
 - Security concerns
 - Performance issues
 - Suggest improvements

 Please respond in Chinese. DO NOT modify any code, only provide review comments.

3. 配置 GitHub Secrets

在仓库 Settings → Secrets and variables → Actions 中添加：

ZHIPU_API_KEY: 从 Z.AI Console 获取

踩坑记录

坑 1: 权限不足 (403 Forbidden)

错误信息：

1

Resource not accessible by integration - https://docs.github.com/rest/issues/comments#create-an-issue-comment

原因：permissions 配置为 read，无法写入 PR comment。

解决：将权限改为 write：

1
2
3


permissions:
 pull-requests: write  # 不是 read
 issues: write  # 不是 read

坑 2: Git 凭据问题