我在 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。代码改得对不对是一回事，改得该不该是另一回事。

Oh My Pi on Svtter's Blog