昨天在 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 自动回复了。不是那种"感谢反馈，已转发产品团队"的模板废话。它直接告诉我：

1. 这个功能大部分已经存在了——hideThinkingBlock 设置、Ctrl+T 快捷键、渲染路径
2. 缺的只是 CLI 启动参数
3. 有一个设计决策需要 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。只删了三行：

1. sdk.ts:1860 — agent 初始化时不再把 hideThinkingBlock 赋给 hideThinkingSummary
2. input-controller.ts:758 — Ctrl+T handler 里不再联动
3. 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 都能写代码。但这次不一样的地方在于：

完整的闭环

整个流程是零人工的：

1. 我开 issue → bot 读代码库，给出现有实现状态
2. 我提出设计疑虑 → bot 理解了我的观点
3. 它自己定位到耦合引入的 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 大概率是他把代码理解能力做得特别深的产物。

这个项目没有开源。

有类似的开源项目吗

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

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

意味着什么

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

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

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

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