自动化 on Svtter's Blog

我在 GitHub 上遇到一个 AI bot——它读了我的 issue，理解了问题，然后自己提了个 PR

Sat, 23 May 2026 18:00:00 +0800

昨天在 Oh My Pi（OMP）仓库经历了一件让我震惊的事：一个 AI bot 不只是回复了我的 issue，它在理解了问题之后，自己去翻了源码，开了一个 PR。整个过程不到 5 分钟。

不过后来我重新验证了 API 行为，发现我最初的 issue 描述其实有误——模型并没有"停止思考"。这件事后来变成了一个更好的教训：AI bot 和我都在同一个错误上达成了共识。

起因

我在用 OMP（一个终端 AI coding agent）的时候注意到 Ctrl+T 隐藏 thinking blocks 时，会同时设置 hideThinkingSummary，这个字段会影响 API 请求参数。我当时认为这不只是"不显示"，而是"模型不再思考"。于是开了 issue #1313。

事后查证 API 文档发现，这个判断是错误的：

Anthropic 的 thinking.display: "omitted" — 模型仍在服务端完整执行 extended thinking，只是 thinking 内容不返回给客户端
OpenAI 的 reasoningSummary: null — 同理，reasoning 仍然发生，只是 summary 不返回

模型输出质量不会因为 hideThinkingSummary 而下降。用户的 Ctrl+T 操作不会"关掉大脑"。

实际的耦合问题只是设计层面的不清晰（同一个快捷键对不同 provider 行为不同），而不是质量退化的 bug。Issue 最终被关闭了。

roboomp 的第一次回复

Issue 发出去几秒钟后，一个叫 roboomp 的 bot 自动回复了。不是那种"感谢反馈，已转发产品团队"的模板废话。它直接告诉我：

这个功能大部分已经存在了——hideThinkingBlock 设置、Ctrl+T 快捷键、渲染路径
缺的只是 CLI 启动参数
有一个设计决策需要 maintainer 定夺：hideThinkingBlock 和 hideThinkingSummary 的耦合

而且它给出了精确的文件名和行号：settings-schema.ts:663、input-controller.ts:755、stream.ts:583,697。

这不是搜索拼出来的，它真的读了代码。

我指出设计问题

我回复了一条评论，说这个耦合在设计上不够清晰：

用户按 Ctrl+T 本意是减少视觉噪音，但 hideThinkingSummary 会改变 API 请求参数，虽然不影响模型质量，但行为超出了用户预期
“不想看推理过程"和"不想让推理内容传回来"是两件不同的事，不应该绑在一起
对不同 provider 效果还不一样（MiniMax 关不掉，Anthropic/OpenAI 能关），同一个快捷键行为不一致

我还补充了引入这个耦合的 commit 历史，方便追溯。

它自己开了个 PR

然后发生了让我惊讶的事——roboomp 连续回复了两条评论，并直接开了一个 PR：#1314。

PR 的改动：0 addition, 3 deletion。只删了三行：

sdk.ts:1860 — agent 初始化时不再把 hideThinkingBlock 赋给 hideThinkingSummary
input-controller.ts:758 — Ctrl+T handler 里不再联动
selector-controller.ts:273 — 设置 UI 同理

PR 描述里完整写了 repro 步骤、根因分析、修复方案。它还确认了我提供的 commit archaeology——45bd444 就是引入这个耦合的那个 commit。

后来我发现问题没那么严重

提交 issue 和评论时，我和 roboomp 都认为 hideThinkingSummary 会"关掉思考”，导致模型质量下降。但仔细查证 API 行为后，事实并非如此：

模型仍然在服务端完整执行 extended thinking
只是 thinking 内容不传输回客户端（省带宽）
模型输出质量和开启 thinking 时完全一样

所以 hideThinkingBlock → hideThinkingSummary 的耦合，本质上是"你不看的内容就不传给你"——一个合理的优化，只是设计上不够透明。我和 roboomp 都把它当成了 bug，实际上只是设计风格问题。Issue #1313 已关闭。

这件事比原先的"发现 bug"更有意思：AI bot 读了我的错误分析，没有质疑，直接沿着错误前提推下去开了 PR。它和我犯了同一个错。

为什么这件事让我震惊

“AI 能写代码"不是新闻。Copilot、Claude Code、Cursor 都能写代码。但这次不一样的地方在于：

完整的闭环

整个流程是零人工的：

我开 issue → bot 读代码库，给出现有实现状态
我提出设计疑虑 → bot 理解了我的观点
它自己定位到耦合引入的 commit，开了一个只删 3 行的 PR

从 issue 到 PR，没有人类在中间做任何事。

它知道该等

第一条回复里它说"Holding on implementation until a maintainer weighs in on the coupling question”——它知道这是一个需要判断的设计决策，不应该擅自行动。但当我把耦合问题讲清楚后，它判断不再需要等，直接开 PR。

修复是最小化的

0 addition / 3 deletion。它理解了最小修复是什么，没有重构、没有加抽象、没有画蛇添足。很多人类开发者都做不到这一点。

但它没有验证前提

roboomp 和我一样，接受了"隐藏 thinking = 禁用 thinking"这个错误前提，然后在此基础上做了完整的分析和修复。它的代码分析能力很强（精确定位到三个耦合点），但没有独立验证 issue 描述的事实是否成立。这和很多人类开发者一样——看到描述合理的问题就直接动手修，不先确认问题是否真实存在。

roboomp 是什么

roboomp 是 OMP 仓库维护者 can1357 部署的一个 AI bot。它不是 GitHub Actions workflow（我翻了 CI 配置确认了），而是一个独立的服务端 agent：

监听 GitHub Webhook 事件（issue 创建、评论等）
通过 GitHub API 读源码，理解代码结构
用 LLM 分析上下文，自主决策下一步——评论、打 label、开 PR

从 can1357 的 GitHub profile 看，这人做 hypervisor / 逆向工程出身（ByePg、NoVmp、NtRays），现在在做 AI agent 平台（agentx、hindsight）。roboomp 大概率是他把代码理解能力做得特别深的产物。

这个项目没有开源。

有类似的开源项目吗

找了一圈，目前最接近的有：

项目	说明
optio (962⭐)	AI coding agent 的 workflow 编排，task → merged PR
claude-code-github-agent	Hook 40+ GitHub events，自动 triage / review / fix，架构最像 roboomp
software-factory	Issue/PR 驱动的自动开发系统

但说实话，没有一个做到 roboomp 这个水准。大部分还停留在"接 webhook → 调 LLM → 贴评论"的阶段。能自主读源码、理解代码结构、参与设计讨论、做精准修复的，roboomp 是我看到的第一个。

意味着什么

这次经历让我对 AI coding agent 有了两层认识。

能力面：roboomp 展示的能力——读代码、理解上下文、参与讨论、做最小修复——本质上就是一个 junior maintainer 在做的事。如果每个开源项目都能部署一个这样的 bot，maintainer 就能把时间集中在架构决策和社区建设上。

局限面：AI bot 会沿着用户给出的前提往下推演，但不会独立验证前提是否正确。这次我和 roboomp 都犯了同一个错误——认为 hideThinkingSummary 会降低模型质量。bot 的代码定位能力很强，但在事实核查上和人类一样容易"先入为主"。

这对使用 AI 工具的人来说是个重要提醒：AI 能精确地执行错误的分析。它会完美地修一个不存在的 bug。代码改得对不对是一回事，改得该不该是另一回事。

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，但这些原则可以直接用上。

CLI 是更高效的开发工作流

Fri, 06 Mar 2026 00:00:00 +0800

CLI 是更高效的开发工作流

Codex Windows 客户端是一个不错的 AI 编程工具。但用了一段时间后，我开始意识到一件事：每次都要打开窗口、手动建任务、逐条对话，才能推进一个工作流。这不是效率，这是在用鼠标模拟思维。

这篇文章不是在批评 Codex，而是想聊一个更根本的问题：对于开发者来说，CLI 在结构上就是比 GUI 更高效的工作方式。

GUI 的认知负担

GUI 的认知负担来自两层。

第一层是操作层：你需要记住功能在哪个菜单、按钮叫什么名字、流程分几步。界面设计得越复杂，这个负担就越重。

第二层是信息层：GUI 处理信息的方式是"搜索 + 查看细节"。你搜索定位到一条记录，点进去看详情，返回，再搜下一条。每一次钻取都是一次上下文切换，思维的连续性被不断打断。

处理十条 issue 反馈，你要在列表视图和详情视图之间切换二十次。这种碎片化的信息处理方式，消耗的不只是时间，还有注意力。

CLI 把信息变成流

CLI 的信息架构是线性的、流式的。数据直接在你面前流过，处理逻辑在同一行里表达完毕：

1

gh issue list | grep "crash" | xargs -I {} gh issue view {}

没有界面跳转，没有上下文切换。你的思维可以一直停留在问题本身，而不是停留在"怎么操作这个工具"上。

更重要的是，CLI 的操作可以写进脚本，脚本可以提交进代码库，代码库可以被团队共享。你的工作流本身变成了可版本化的资产。

批量处理：规模化的起点

假设你有一批用户反馈需要处理。在 GUI 里，你的流程是：打开工具，粘贴反馈，手动描述问题，创建 issue，再下一条。

在 CLI 里：

1

cat feedbacks.txt | parse_feedback | gh issue create --batch

GUI 里需要一个小时的工作，CLI 里是几秒钟的脚本。这不是操作习惯的差异，这是处理规模的差异。

并行修复：从串行到并发

批量创建 issue 只是起点。真正的效率差距在修复阶段。

GUI 工具是串行的——你跟它对话，等它回答，确认结果，再下一步。即使工具本身再强大，交互模式把你锁死在单线程里。

Claude Code 支持启动并行 subagent，结合 git worktree，每个 agent 在独立的工作目录里处理一个 issue，互不干扰：

1
2
3
4


for issue in $(gh issue list --json number -q '.[].number'); do
 git worktree add ./fix-$issue -b fix/issue-$issue
 claude --subagent --worktree ./fix-$issue --issue $issue &
done

每个 subagent 独立完成：理解问题、修改代码、提交 PR。整个流程不需要你盯着任何一个窗口。

十个 issue 同时在修复，时间复杂度从 O(n) 变成接近 O(1)。GUI 工具在这里的天花板是显而易见的——你无法同时操作十个对话窗口，而 CLI 的并行是操作系统级别的原语，没有上限。

可组合性：真正的灵活性

GUI 是封闭的。每个工具有自己的界面，彼此之间的数据流动需要人工中转。

CLI 的基本单位是文本流，任何工具都可以通过 pipe 连接：

1

用户反馈 → 解析脚本 → issue 创建 → agent 分配 → worktree 修复 → PR 提交

这条流水线里，每个环节独立替换、独立测试、独立优化。某个环节出了问题，你可以单独调试那一段，而不需要重走整个流程。这是 GUI 工具根本无法复制的架构灵活性。

结语

GUI 有它适合的场景——可视化需求、初次上手、非技术用户。这些场景 GUI 是正确的选择。

但对于开发者，对于需要处理规模化工程任务的技术用户，CLI 不只是"够用"，它在结构上就是更优的工作方式。批量处理、并行执行、可组合、可脚本化——这些不是 CLI 的附加特性，而是它的基本属性。

认知负担更低，处理规模更大，工作流可以版本化。这三点加在一起，足以说明问题。