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

Software Factory：把 PR Review 修复做成一个闭环

Mon, 23 Mar 2026 00:00:00 +0800

如果你已经在用 Claude Code、OpenCode、Codex（不提 Aider 了）这类工具写代码，真正耗时间的往往不是“第一次生成”，而是 review 之后那几轮重复劳动：看评论、整理问题、切回分支、修代码、跑测试、再回写 PR。

software-factory 就是我为这段流程写的一个轻量系统。它不想变成另一个 GitLab，也不准备一上来就做成重型多租户平台；它只专注一件事：把 GitHub PR review 反馈变成一个可追踪、可自动执行、可本地运行的修复闭环。

为什么要做这个项目

现在很多 AI 编码工具已经能把“写代码”这一步提速很多，但团队协作里的瓶颈并没有消失。

一个典型场景是这样的：

开发者提交 PR
reviewer 留下 review comment 或 issue comment
开发者或 AI 再去手动整理这些意见
回到本地修复，再跑测试，再 push
如果修得不完整，再重复一轮

问题不在于这条链路复杂到无法理解，而在于它太重复了。只要你已经接受“让 AI 参与改代码”，那下一步自然就是把 review 之后的修复过程也纳入自动化。

software-factory 的目标，就是把这段重复劳动抽出来，做成一个边界清晰的小系统。

它到底在做什么

一句话概括：software-factory 是一个围绕 GitHub PR 审查反馈闭环构建的轻量编排器。

它的核心链路大致是这样：

1
2
3
4
5
6
7


Hook (Claude Code lifecycle)
 -> Local Orchestrator API
 -> State Store / Queue
 -> GitHub Webhook Adapter
 -> Review Normalizer
 -> Agent Worker
 -> Thin Web

这条链路里，每一层都只做一件事：

Hook 负责记录受管开发会话，确定触发点
GitHub Webhook 负责感知 PR review、inline comment、issue comment 的变化
Review Normalizer 负责把零散反馈整理成结构化修复输入
Agent Worker 负责 checkout、修复、验证、提交、回写
Thin Web 负责展示最近任务、状态和错误摘要

我觉得这样实际上实现起来比较敏捷：它不是把所有逻辑塞进一个“大模型万能入口”，而是尽量把触发、归一化、执行、可视化拆开。这样以后你要替换 agent、增加策略或者接入别的触发源，成本会低很多。

它到底有多轻

我用最轻量的方式实现了 software-factory：

后端就是一个 FastAPI 服务
状态存储先用 SQLite
页面就是服务端渲染的 HTML template
主链路就围绕 GitHub PR review feedback 展开
本地就能把 service、worker 和数据库一起跑起来

换句话说，它更像一个能逐步扩展的 AI-native PR Autofix Orchestrator，而不是一个覆盖整个研发流程的大平台。

如果你看过我之前写的使用 OpenCode + GLM-4.7 实现 GitHub PR 自动代码审查，应该能感觉到这条思路是一脉相承的：先把 runner 和模型跑起来，再把 review 之后的动作继续往前推。software-factory 只是把这条链路从“自动 review”再往前做了一步，开始处理 review 之后的修复闭环。

现在已经做到什么程度

从当前代码和文档来看，software-factory 已经不是一个只有想法的草稿，而是有比较完整主干能力的 MVP，也已经发了 v0.1.0 release。

目前已经完成的部分包括：

最小可跑骨架：FastAPI 服务、健康检查、基础 SSR 页面
Hook 和 GitHub Webhook 入库：包括结构化解析、幂等去重、会话与 PR 关联
Review Normalizer：把 review/comment 归一化成 must_fix、should_fix、ignore
Agent Worker 执行链路：checkout、跑检查命令、commit、push、回写 PR
稳定性模块：PR 锁、重试、最大自动修复次数限制、噪声评论过滤、日志归档

这意味着它已经覆盖了从“收到反馈”到“尝试修复并回写结果”的主路径。

我们也通过让 software-factory 自己优化 PR #59，验证了这套流程确实能跑通。

这件事最有意思的地方在于，#59 不只是一个普通 PR，它意味着 software-factory 已经开始参与 software-factory 自己的开发了。

另外我觉得比较实用的一点，是这个项目并没有把 Web 界面做成纯展示页。除了任务列表和详情，它还在往更可操作的方向走，比如运行详情、operator hints、手动 issue 提交、agent 设置这些入口，说明它的目标不是只做一条后台脚本，而是做一个真正可运维的小系统。

这个项目最有意思的地方

如果只是做一个“收到评论后调用 AI 修代码”的 demo，其实并不难。software-factory 更有意思的地方，在于它开始认真处理真实系统才会遇到的问题。

1. 它把“触发”分成了内部和外部两类

内部触发来自 Claude Code Hook，用来确定性记录开发会话；外部触发来自 GitHub Webhook，用来感知 PR review 的变化。这种拆分让系统知道“什么时候发生了开发动作”，也知道“什么时候出现了新的修复需求”。

2. 它没有直接把 review 原文丢给 agent

Review Normalizer 的存在非常关键。真实 review 往往很零碎，来源也不统一，里面还混杂噪声、重复评论和优先级差异。先做归一化，再把结构化结果交给 worker，比直接让 agent 消化原始事件稳定得多。

3. 它开始考虑 agent 运行时的工程问题

从 agent_runner 这条链路里能看到很多现实约束：worktree、校验命令、预先存在的失败用例、重试、日志、取消、不同 agent mode 的切换。这些内容说明这个项目关心的不是“AI 能不能写一段代码”，而是“AI 能不能在工程系统里稳定地完成一次修复任务”。

4. 它是 local-first 的

这个项目默认就强调本地运行、共享 DB_PATH、轻量状态存储和可视化页面。这种 local-first 设计对个人开发者和小团队很友好：你可以先在自己的环境里把闭环跑通，再考虑是否要把它推向更大的部署形态。

它适合什么人

我觉得 software-factory 现在最适合下面几类场景：

已经在 GitHub 上做 code review，希望减少 review 后重复修复劳动的个人开发者
小团队或内部工具团队，想先把 PR 自动修复闭环跑起来，而不是先上完整平台
在尝试把 Claude Code、OpenCode、OpenHands 之类 agent 纳入研发流程的人

如果你的目标是做一个覆盖 CI/CD、权限、审批、租户隔离、复杂报表的企业平台，那它目前显然还不是那个方向。但如果你要解决的问题足够具体：把 review feedback 自动变成下一轮修复动作，那这个项目的切口其实很准。

接下来还可以往哪里走

从文档里的规划看，software-factory 下一步最值得期待的，不是继续堆页面，而是补齐几个真正影响可用性的能力：

更完整的 E2E 和压力测试
多仓库支持和更细的策略控制
融合 GitHub Actions 之类 CI 信号
为不同仓库生成可复用的 runtime image，减少每次 run 的环境准备成本

尤其是“按仓库构建可复用运行时镜像”这个方向，我觉得很有价值。很多 agent 系统失败并不是因为模型不会修，而是因为运行环境不稳定、依赖不完整、工作目录和真实项目不一致。要让自动修复从 demo 走向日常可用，这一步迟早得做。

写在最后

对我来说，software-factory 最重要的不是它用了 FastAPI、SQLite 还是某个具体 agent，而是它试图把一个很真实、很重复、也很容易被忽视的研发环节单独拿出来优化：PR review 之后的修复闭环。

如果说很多 AI 编码工具解决的是“怎么更快写出第一版代码”，那 software-factory 解决的问题更接近“怎么把代码真正推进到可以合并的状态”。而这一步，恰恰是团队协作里最容易反复消耗人的地方。

所以我会把它看成一个很典型的项目：它不是为了证明 AI 会不会写代码，而是想验证 AI 能不能在真实工程流程里，稳定地处理 review 反馈，并把后续修复一步步推进下去。