抽查 F-Droid 一天内更新的 102 个应用：72% 基本由 AI 写成

原文来源：tintotint — 一个 FOSS 应用维护者用肉眼加提交记录，给 F-Droid 一天内更新的 102 个应用做了 AI 含量分档。

起因是一个丑图标

作者是个业余写代码的学生，也是 F-Droid 的应用维护者。他说自己对 F-Droid 只有好话——"甚至可能对人太客气了，我自己好几次忘了 commit 就构建，导致可复现构建校验（repro）失败"。

然后有一天他逛 F-Droid，看到一个图标明显是 AI 生成的 App。他没有点名，但那件事让他开始想一个具体问题：F-Droid 里到底有多少是 AI 写的？

先说清楚：这件事没法准确判断

他很干脆地承认了方法上的先天缺陷："文本本身不携带足够的元信息，任何评估都不可能接近准确。"

但痕迹是存在的。他的推理是：大模型的核心吸引力就是让开发者变懒——这本来就是它的卖点。你只管提需求，然后坐下来等着。这种态度会反映在 vibe-coder 碰过的每一样东西上：README 何必手写，让模型写；代码评审何必自己做，让模型审自己的改动，再把仓库权限给它，连 commit 按钮都不用按。如果一个项目还在乎自己看起来靠谱，这些事手工做一遍是很容易的；但一路下来全是低投入。

评分标尺：三档

他设计了一个粗糙但可操作的分档：

• 基本是 AI：有明显的 LLM 痕迹，他估计超过 50% 的代码由模型生成。只要仓库里存在 agentic 基础设施，一律落进这一档——他的理由是，他不相信在一个 编程代理框架（coding harness）里能"负责任地"使用 AI。
• 不好判断 / 基本是人写的：偶尔有 LLM 提交（维护者或贡献者），但整体看起来是人写的，预计 LLM 占比低于 50%。
• 看不出 AI 痕迹：找不到可疑之处，或者项目有严格的 LLM 政策。

判断依据是最近的提交内容和项目品牌形象，没有写什么"slop 检测器"。他还特别声明：不看历史——一个 2014 年就存在的项目，只要最近的提交是模型写的，照样归进"基本是 AI"。

样本是 F-Droid 在 2026 年 9 月 12 日那一批更新，共 102 个应用。

几个让人印象深刻的例子

• Amber（Nostr 事件签名器）：最近的提交全部由 LLM 完成，接受 agent 提的 PR，仓库里能看到 Claude Code 和 Codex 的基础设施。
• BayesianBahn（德铁到达时间的贝叶斯分布）：所有提交都是 Claude 共同署名。作者的吐槽很有意思——"德铁烂到能让人去 vibe-code 一份非官方时刻表"。
• Feeder：这是名单里第一个他本人真在用的应用。结论是基本由 AI 写——最近的代码提交像是模型生成，还接受过 agent 的 PR。他写了一句"挺遗憾的，但它能用"。
• DuressKeyboard：他见过最让人困惑的仓库。2025 年 11 月就在开发了，但作者好像不会用 git——所有改动都是手工复制粘贴、通过 GitHub 网页编辑器提交的。
• Chompass：托管在 Codeberg 平台上，最近提交像是 AI 写的，很可能违反 Codeberg 的使用条款。

另外两个现象值得单拎出来。一个是某个用户名下同时维护着这批更新里好几个 vibe-coded 应用，而且分散在毫不相关的命名空间里（有些是应用名，有些是 com.presley.*、com.codesail.* 这种）——"要么他是个极度活跃的 vibe-coder，要么就是某个拿到了 GitHub 账号的 agent"。另一个是托管在 Codeberg 的 5 个应用里有 4 个基本由 AI 生成，可能违反平台自己的 AI 政策。

数字

102 个应用：

• 74 个基本由 AI 写成，占 72.5%
• 10 个不好判断，占 9.8%
• 18 个看不出 AI 参与，占 17.6%

他自己的矛盾

真正让这篇文章值得一读的不是那 72.5%，而是作者没有把结论包装成一句爽话。

他明确说了自己没做代码质量分析——那要花的时间多得多，而且大概率超出他的能力范围。但他很好奇那 72% 在健壮性和可维护性上到底怎么样。他还随手查了几个自己在用的 FOSS 应用，"不少都有很重的 LLM 使用痕迹"。

他的结论是分裂的：一方面，有些应用确实有不少用户，如果这些人因此生活变好了一点，他凭什么说不？另一方面，他担心这个数字对整个 FOSS 社区意味着什么。他说自己会继续用那些应用，因为它们有用，但整件事让他觉得相当纠结。

换个角度看这件事

这篇文章的方法论当然可以挑：靠肉眼和提交记录分档，样本只有一天，作者本人也承认可能有错，而且他坦言自己讨厌 LLM——尽管他花了一整节先承认模型确实有用、确实能发现真实的代码缺陷。

但正因为作者先把偏见摊开写了，那份 72.5% 反而更值得当真。它至少说明了一件事：在"没有商业压力、没有 KPI、为兴趣而写"的 FOSS 领域，vibe coding 的渗透率也已经过半了。 如果连这里都是这个比例，用它来推断闭源商业软件的情况，只会更极端。

真正的问题被作者留在了最后，也是他没能回答的那个：那 72% 的代码，三年后还有人能改得动吗？他没法回答，因为他连代码质量都没看。而这恰恰是所有人都还没答案的部分——我们今天能测量的只是"谁写的"，还测不出"写得撑不撑得住"。