AI 编码工具让 PR 规模增 12 倍，但测试覆盖率从 5% 升至 88%

两年一个仓库，2210 个合并的 PR，全部从 git 重新统计。AI 编程 Agent 到底改变了什么——以及为什么 MindFlock 要跑在我自己的笔记本上而不是厂商的虚拟机。

代码：https://github.com/MindFlock/MindFlock

在我使用 AI 编程 Agent 之前，我一个典型的 pull request 是 68 行、4 个文件。现在是 873 行、13 个文件。

你应该觉得这很惊人。我当时也是。一个让 diff 变大约一个数量级的工作流，表面上来看，就是一个生产没人看的代码的机器——而大多数"AI 让我快了 10 倍"的文章之所以经不起恶意读者的审视，就是因为它们在体积数字这里就停下来了。

所以这是我一直不敢算的那一行。在同样的 2210 个合并 PR 中：涉及测试的比例从 5% 上升到了 88%。二十分之一，变成了十分之九。

这个数字才让更大的 diff 变成了一个发现，而不是一个自证其罪。如果额外的体积是 Agent 在凑字数，测试覆盖率应该持平或下降。结果上升了 17 倍。

还有另一个数字，这才是真正重点：

我的工单吞吐量几乎没动。Agent 之前每月关闭 43 个，现在 55 个。

我没有开始交付更多的工单。我开始交付完成度更高的工单——包括测试——数量几乎相同。所有变化都在工单内部，而这恰恰是单工单速度仪表盘看不到的东西。

这篇文章讲的是怎么做到的、怎么衡量的，以及我最愿意捍卫的一个设计决策：所有东西都跑在我自己的笔记本上。

完整数字和方法

一个开发者的仓库，两年，从 git 和跟踪器的 API 重新计算，而不是估算或回忆。

最后一行如果只要一个头条数字的话就是：在键盘前每半小时，审查的源代码增加了 6.3 倍，工单速率基本持平。

每个数字怎么来的，因为一个你无法验证的数字就是一个你不应该相信的数字：

仅源代码。lockfile、生成文件和压缩文件、图片、CSV、notebook、dist/、vendor/、node_modules/ 和数据库 dump 都被排除了。它们在近期代码行数中占比不到 1%，所以不是驱动变化的原因。

用中位数，从不用均值。有一个月包含了一个 160 万行的大规模导入，会搞砸数据集中所有的平均值。

每个 PR 的 diff = 在合并提交时，从本地 clone，对该作者全部 2210 个合并 PR 做 git diff <base> <branch-tip>。

有效半小时 = 包含这些分支上至少一次提交的不同 30 分钟窗口。

最后这个定义值得细想，因为它对我不利。在近期，有些提交是 Agent 在我喝咖啡时产生的，这会膨胀分母。6.3× 是一个下限。在对时代边界做任何合理选择时，它也保持在 5.5× 到 7.2× 之间。

两件变糟的事

墙上时钟周期时间变长了。跟踪器的开始→完成时钟衡量的是审查、QA 和部署队列，没有任何编程工具能影响这些。如果你被推销"更快的工单"，先问清楚他们说的是哪个时钟。

不是免费的。46 个有日志的天里，这台机器上跑了 135 亿个 token。

为什么是一群 Agent，而不是一个

再看中间那一列。采用一个 Agent 大致让典型变更的体积变成了三倍——68 → 210 行。从一个 Agent 到多个，又在这个基础上乘以四。后面这一步才是更大的。

原因不是吞吐量，这让我很意外：平均每天在飞的分支在两个时代都是 5–8 个，一直如此。变化的是上限——16 → 31。

并行不是整天都在用的东西。它是你在同一天六件事同时做到一半时需要的东西，而那些天恰恰是以前最容易触顶的天。抬高这个上限意味着一个地方看到所有 session、每个 session 一个 worktree 这样它们不会互相踩踏、可靠的每 Agent 状态（工作中 / 空闲 / 需要输入），以及下一步 git 操作始终一键可达。

这个工具以前不存在于我想要的样子，所以我自己做了。它叫 MindFlock，Apache-2.0 许可，已经当了我的日常驾驶舱三个月。

当 GitHub Issues、Jira、Linear、Shortcut 或 Asana 中有一个工单分配给我时，大约 20 秒后，什么都不用打：

它在自己的 git worktree 中，基于自己的 feature/<ticket>/<slug> 分支，从一个缓存的 clone 切出来，这样第二个工单不需要重新 clone 仓库。

依赖在 Agent 启动前安装——Python/uv 仓库自动检测，其他任何东西声明一行 setup_commands。

一个 Agent CLI 启动时已经载入了工单信息：标题、描述、从 markdown 中挖出的验收标准，以及评论线程。

它出现在一个网格中，作为一个带有阶段徽章的实时终端，旁边是所有其他 session。

然后我做需要人来做的那部分——读 diff——然后一键搞定：commit（在那个 session 自己的终端中运行，所以我能看到 hooks 触发）、push、打开 PR、合并。

带着评审评论回来的 PR 以同样的方式变成 session，基于 PR 自己的分支，未解决的行内评审评论作为 prompt。过时的 thread 和 PR 顶层对话被跳过，一个 PR 至少 15 分钟大之前不会被处理，所以你刚 push 的分支不会被扑上去。

38 天里：38 个工单被 provision 成 session，什么都没打，provision 到 PR 合并的中位时间是 22 小时，我自己的 42 个 PR 被分类处理评审评论。

设计决策：跑在你自己的机器上

分配工单、拿回 PR 不再是稀罕事了——GitHub、Google 和 Atlassian 都有第一方支持，还有 Devin 和 Cursor。它们能用。但它们也有一个共同属性：

每一行都以一台我不拥有的机器结束，持有我仓库的一个 checkout。对于副项目，可以。对于 NDA 约束的客户代码，或者任何需要书面回答"哪些第三方在处理这个源代码"的地方，这一列就是那个对话。

MindFlock 中间没有云：没有服务、没有账户、没有拿着你仓库副本的沙箱。引擎是你笔记本上一个绑定到 127.0.0.1 的进程；Agent 就是你已经在终端里运行的那些 CLI，launch 到你自己磁盘上的 worktree，用你自己的订阅。

我不会告诉你你的代码永远不会离开你的机器。对于任何包装了托管 Agent CLI 的东西这个说法都是假的，包括这个。claude 把代码发给 Anthropic，codex 把代码发给 OpenAI，和你自己在这个仓库里跑它们时一模一样。

真实的是 MindFlock 没有增加任何跳板和任何第三方。你本来就在打那个厂商电话；没有新的东西拿到副本。MindFlock 自己在网络上接触的所有内容，全部如下：

没有分析、没有遥测、没有崩溃报告、没有许可检查、没有任何形式的 phone-home。代码树是公开的——grep 它，而不是相信我。

如果那最后一个电话是你不能打的，关掉它。把 session 指向你自己服务的模型（Ollama、LM Studio、任何 OpenAI 兼容服务器），就完全没有代码出口：没有 API key、没有订阅、没有任何东西穿过网络。这也适用于 ingest 的 session，所以一个工单可以从分配到提交全程不离开机器。支持 codex、aider 和 goose，它们有原生本地模型支持。claude 只说 Anthropic API，所以没有本地路由——mindflock doctor 会直接说出来，而不是让一个 session 悄悄继续用它。

它自己永远不会做的事

一个你不能信任的 pipeline 比没有更糟：

每个 git 操作都是你点的。commit、push、打开 PR、合并。你写 commit message；PR 正文从你的提交填充。

你的跟踪器是只读的。不评论、不改状态。一个编辑共享工单的 bot 会把自己的错误变成别人的困惑。

只有你自己的 pull request 会被挑出来做评审工作。

没有入站端点。它是轮询的，所以没有 webhook 要配置，也没有 secret 要轮换。

ingestion 是一个开关，关闭直到你打开它，而且它保持在你上次的位置。

每个 Agent CLI 就是一个 TOML 文件——二进制、启动参数、prompt 种子、活动检测钩子、定价——所以 Claude Code、Codex、Antigravity、aider、OpenCode、Cline、Goose 或某个没人听过的其他东西都获得同样的状态检测和成本跟踪。添加一个只需要改配置，不需要打补丁。

这给谁用，谁不适合用

如果厂商-VM 那一列对你来说是 blocker——合同工作有 NDA、受监管的代码、要求说明谁能看到源代码的安全审查——你可以在你已经拥有的硬件上获得这个循环，用本地模型的话还可以零出口。

如果你在 GitHub Issues 上维护东西，这是最便宜的入门：gh 已经认证，origin 已经正确，所以 ingestion 就是一个开关加零配置。

如果你已经手动跑好几个 Agent，这是一个不错的并行 Agent 工作空间，而且我很多天根本不碰工单——+ New，选一个 repo 和一个 Agent，打一个 prompt，在旁边的另一个隔离 worktree 得到结果。同一网格、同一 diff 视图、同一个引导式 git bar、同一个手机 UI。跟踪器是 session 的来源，不是必要条件。

我指向别处的地方。如果你想要云，你是对的——笔记本关机时工作继续、别人的算力付 token、一个舰队研磨一个待办列表。这些都是真实的，MindFlock 一样都没有。如果你 Mac 且想要原生，Conductor 是 SwiftUI 的，做得很扎实。如果你生活在终端里，Claude Squad 是一个成熟的多 Agent TUI，Claude Code 自己的 Agent Teams 加 worktrees 是免费的而且已经装好了。

还有那个明显的反对意见：是的，你可以自己构建 intake 那一半。一个 issues.assigned 上的 workflow，在自托管 runner 上跑一个 Agent CLI，就能拿到 issue → PR，在你自己的硬件上。OpenHands 的 resolver 今天就能基于 fix-me 标签做到，自托管且 MIT。现在也有一些本地 orchestrator 轮询跟踪器。如果标签触发的 CI job 覆盖了你的场景，用它——要信任的软件更少。我想要但没找到的是个人版本：分配给我、跨五个跟踪器而不是一个 repo 的 Actions 配置、在一个监督网格中落地，diff 和整个 git 循环都在我眼前而不是在 run log 里。那部分是我构建的，这是形状上的不同，不是能力上的不同。

网站：https://mindflock.ai

代码：https://github.com/MindFlock/MindFlock

都有下载链接。如果你喜欢这个项目，给个 GitHub star 我也很感激。它让我知道有兴趣，我会继续开发。

macOS、Windows（引擎跑在 WSL2）和 Linux 的桌面应用在 releases 页面。需要 git、tmux 和一个 Agent CLI；gh 是可选项，只会让 PR 按钮少点一下。mindflock serve tailscale 打印二维码——手机 UI 带着同样的 diff 视图和引导式 git bar，所以你可以从手机上阅读和批准工作。

一个人，业余时间，Apache-2.0 原样提供，没有支持 SLA，业余项目响应时间。早点知道这些比接了板子之后才知道好。

Shortcut 连接器是测试最充分的，因为它是我每天用的——所以如果你在真实 board 上跑 Jira 或 Linear，你的一个 bug 报告比我能收到的任何其他东西都更有价值。同样的，上面那张表是 2026 年 7 月的快照，这个领域每周都在动。如果有格子是错的，开个 issue 我来修。

非常感谢你对 MindFlock 的任何反馈或评论。我每天工作中都在用，收获了很多价值。我把它开源分享给大家，这样你们也能受益，也能帮我继续改进一个对我们都有用的工具。谢谢大家 :)

网站：https://mindflock.ai

代码：https://github.com/MindFlock/MindFlock