夜雨聆风
如果你这两天还在盯着“哪个 AI 编程工具更强”，可能已经错过了更有意思的一幕：开源世界的地板下面，AI 留下的脚印可能比我们以为的多得多。
不是发布会上那种漂亮脚印。
也不是某个账号大大方方写着“我是机器人”的提交。
真正麻烦的是另一类：它们混在普通开发者的提交里，提交信息像人写的，作者名像人，PR 流程也像人，只有在项目配置文件、提交习惯、工具签名、作者身份之间来回比对，才看得出一点轮廓。
6 月 23 日，一篇题为 Detecting AI Coding Agents in Open Source 的论文提交到 arXiv。两位作者把视角拉得很大：他们不是抽样看几十个热门项目，而是基于 World of Code 扫描了 1.8 亿多个 Git 仓库，试图回答一个看似简单的问题：现在到底有多少开源代码，是 AI 编码 Agent 参与写出来的？
答案很不舒服。
论文称，单靠“机器人账号”这类常见办法，会严重低估 AI 参与度。以 Claude Code 为例，研究者在一个快照里通过多种方法识别出 850157 个相关提交，但如果只看 bot 账号，只能捞到 28154 个，大约 3.3%。换句话说，那个最容易统计、最容易做成图表的数字，可能只看见了冰山一角。
这篇论文最值得写的，不是“Claude Code 很火”。这已经不是新闻。
真正的新鲜点是：AI 进入开源供应链以后，最先坏掉的可能不是代码质量，而是我们的观察方式。
以前看机器人，现在要看脚印
过去判断一个项目里有没有自动化，办法很朴素。
你看提交者名字，看头像，看 commit message，看 PR 描述。Dependabot、Renovate 这类工具很诚实，往往自带名牌，像一个穿反光背心的施工队。你知道它来了，也知道它干了什么。
AI 编码 Agent 不太一样。
它可以在开发者本地编辑器里写一段代码，由人提交；也可以在云端开分支、跑测试、发 PR；还可以只留下一个项目配置文件，告诉 Agent 以后进来该怎么干活。你看见的可能是同一个结果：一行提交。但它背后的劳动分工，已经完全不同。
这就是论文采用多方法识别的原因。它不是只盯着 bot 账号，而是把几类信号叠在一起看：配置文件扫描、提交信息分析、作者身份匹配、机器人签名查找。
听起来像刑侦。
但开源世界确实已经到了需要“看脚印”的阶段。
因为 AI 参与写代码这件事，正在从一个显性动作变成一种背景噪声。开发者不一定会在提交里写“本提交由某某模型生成”。他可能只是让 Agent 改了测试、补了文档、重构了一个边角函数，然后扫一眼 diff，觉得没问题，点了提交。
从项目结果看，这很合理。谁还会在每一封邮件底部标注“这句话由输入法联想帮助完成”？
但从供应链治理看，这就开始刺手了。
开源项目靠信任运转。我们相信维护者会审查代码，相信贡献记录能反映某种责任链，相信 PR 讨论能留下足够的上下文。AI 介入以后，这些信号没有消失，只是变得更滑。
一个提交仍然有作者。
但作者到底写了多少、审了多少、只是点了多少，就没那么好说了。
最反常识的地方：PR 统计也不够
很多人会说，别看提交，看 PR 呗。AI Agent 总得开 PR 吧？
论文偏偏指出，PR 视角也不完整。
它把自己的提交侧识别结果和另一个 AIDev 的 PR 普查对照，发现两边看到的 AI 人群几乎错开。论文摘要里有一句很关键：PR 普查漏掉了 79% 的提交侧 Claude Code 采用者，并且几乎漏掉全部 Codex 采用者。
这个结论容易被误读成“某个工具更隐身”。我倒觉得，重点不是工具，而是工作流。
有些 Agent 像外包同事：它开分支、发 PR、等你审。它的痕迹天然会出现在 PR 数据里。
有些 Agent 更像坐在你旁边的副驾驶：它在编辑器里帮你改，最后还是你自己提交。它的痕迹就会进入 commit，却不一定在 PR 层面露头。
再加上项目大小、团队习惯、是否强制走 PR、是否 squash merge，统计口径会越缠越乱。
所以这件事的新闻价值在于：我们正在进入一个“AI 写了多少代码”无法用单一指标回答的阶段。
只看 bot 账号，低估。
只看 PR，偏样本。
只看热门项目，漏掉长尾。
只看工具公司自己的用量数据，又像让餐厅自己统计大家吃得健不健康。
这不是学术洁癖。它会直接影响公司采购、开源安全、许可证争议和开发者绩效评估。
代码多了，维护者的工作没有少
AI 编码 Agent 的官方叙事，通常都很迷人。
OpenAI 介绍 Codex 时，把它描述成可以在云端并行处理多个软件工程任务的 Agent：写功能、回答代码库问题、修 bug、提出 PR，并把终端日志和测试结果交给用户检查。Anthropic 的 Claude Code 文档也明确写着，它可以读取代码库、编辑文件、运行命令，并和终端、IDE、网页、Slack 等开发工具集成。GitHub 的 Copilot cloud agent 文档则说，它能研究仓库、制定实现计划、在分支上改代码，开发者再审 diff、迭代、开 PR。
这些都不是科幻。它们已经是产品说明书里的日常句子。
问题在于，产品说明书讲的是“能做什么”，维护者要面对的是“谁来兜底”。
如果 AI 帮你补一段文档，风险不高。
如果 AI 改一个 CI 配置，风险开始上升。
如果 AI 顺手重构鉴权逻辑、依赖解析、加密参数、支付回调，那就不是“效率工具”四个字能盖过去的。
更麻烦的是，AI 很擅长把东西写得像那么回事。
过去一个新贡献者提交奇怪代码，维护者可能一眼就能闻出味道：变量名乱、测试缺、上下文没读懂、PR 描述前后矛盾。现在，Agent 会写整齐的描述，会补测试，会讲得头头是道。它可能把维护者的第一层直觉检查骗过去。
这不是说 AI 代码一定更危险。
恰恰相反，很多重复性工作交给 Agent，可能比人手抄更稳定。补测试、同步文档、批量改接口名、清理 lint，这些活原本就适合机器。
但当机器变得像人，治理就不能还停留在“看起来像不像人”。
维护者的工作从“亲手写每一行”，变成“判断哪些行可以信”。
这件事比写代码更累。因为写代码时你知道自己哪里偷懒，审 AI 代码时你得猜它哪里偷懒。
开源供应链多了一个隐形环节
过去几年，大家谈软件供应链安全，重点常常是依赖包投毒、维护者账号被盗、恶意提交、自动化发布被劫持。
AI Agent 让问题多了一层：代码不一定是恶意的，但来源变得不清楚。
一个小项目的维护者晚上十点让 Agent 修了三个 issue。Agent 查了上下文，改了代码，跑了测试。维护者困得不行，扫过 diff，合并。第二天，这个包被下游几十个项目自动更新。
这中间未必有坏人。
可是“没有坏人”和“没有风险”不是一回事。
AI 生成代码的风险不只在幻觉。还有几个更实际的坑。
它可能引入项目不想要的依赖。
它可能复制一种看似常见、实则不适合当前架构的写法。
它可能为了让测试过关，把测试改得更宽松。
它可能在异常处理、权限边界、资源释放这些无聊位置犯错。恰好这些位置平时也最没人愿意细看。
更现实的是，当 AI 参与比例上升，维护者会被更多“看起来已经完成”的工作淹没。PR 变多，描述更漂亮，测试更像样。真正稀缺的东西不是生成能力，而是高质量审查时间。
这也是我觉得中文科技圈容易看偏的地方。
大家热衷比较哪个 Agent 排名第一、哪个模型会写更长的项目、哪个 IDE 最顺手。但开源世界真正缺的不是又一个会写代码的角色，而是让代码来源、责任链和审查过程保持可见的规则。
受益者不是最会喊 AI 的团队
这波变化里，最先受益的不是“全员 vibe coding”的团队。
是那些本来工程纪律就好的团队。
它们有清楚的测试，有稳定的 CI，有代码所有权，有小步提交，有审查清单，有能被 Agent 读懂的项目说明。对这种团队来说，AI 像一台可以加速的车，路已经修好了，限速牌也在。
受冲击最大的，反而是那些长期靠英雄主义运转的项目。
文档没有，测试残缺，架构靠口口相传，核心维护者脑子里有一张没人看得见的地图。AI 进来以后，短期看起来会更快：终于有人肯补那些没人想碰的边角活了。长期却可能更乱，因为 Agent 会沿着项目已经混乱的纹理继续织下去。
它不会自动替你建立秩序。
它只会把现有秩序放大。
这对企业也一样。买 Agent 很容易，建立审查制度很烦；接入 GitHub、Slack、Jira 很容易，定义哪些任务必须人工批准很烦；让 AI 写 PR 很容易，追踪它到底参考了什么、改了什么、跑了什么测试很烦。
但真正拉开差距的，恰恰是这些烦事。
接下来该盯什么
我不认为开源社区应该要求所有 AI 参与的代码都贴一个巨大标签。
那会很快变成形式主义。就像“本邮件由手机发送”一样，时间久了没人看。
更有用的是几件具体的小事。
第一，项目要明确 AI 辅助贡献的披露方式。不是为了羞辱谁，而是让维护者知道应该用什么强度审查。
第二，工具应该把运行日志、测试结果、关键决策点留得更清楚。OpenAI 和 GitHub 这类工具都已经在强调可验证日志和人工审查，但开源世界需要的是更标准、更可迁移的证据，而不是每家工具各说各话。
第三，重要项目要把“AI 生成痕迹”纳入供应链审计。不是一刀切拒绝，而是识别哪些变更更需要人看：权限、网络、加密、解析器、构建脚本、发布流程。
第四，别再迷信单一统计。以后看到“某某 Agent 贡献了多少 PR”“某某项目 AI 代码占比多少”，先问一句：它看的是账号、PR、提交、配置文件，还是工具日志？口径不同，结论可能差到很离谱。
这就是那篇论文给我的最大提醒。
AI 编码 Agent 不是正在走进开源世界。
它已经进来了。
只是它没有每次都从正门进，有时从编辑器进，有时从云端分支进，有时从配置文件进，有时藏在一个看起来很普通的提交里。
接下来几年，优秀项目和普通项目的差距，未必体现在谁用了更强的模型。
更可能体现在谁能回答一个朴素问题：这段代码是谁写的，谁审过，谁批准，它为什么值得信任？
这问题听起来不性感。
但开源软件就是靠这种不性感的问题活下来的。
