用 Pi 构建 Pi：AI 驱动开源软件的隐藏成本
"dogfooding"（吃自家狗粮）的做法在软件开发中很常见，但使用 AI agent 来构建旨在辅助开发者的 AI agent 本身，会引入一套独特的摩擦。在最近对 Pi（现已成为 Earendil 项目的一部分）开发过程的反思中，维护者们描述了一种现状：AI 生成的贡献所带来的效率提升，往往被激增的低质量“slop”（垃圾内容）所抵消——这些内容既出现在 issue 报告中，也出现在代码本身中。
这种转变正在从根本上改变用户、维护者与 issue tracker 之间的关系，揭示了一种关键的紧张关系：虽然 AI 可以加速贡献的量，但它往往会降低维持可持续维护所需的信号质量。
"Slop" Issue 的兴起
传统上，一个糟糕的 issue 报告是一种干扰——通常是含糊不清或缺乏复现案例。然而，LLM 辅助报告的出现引入了一种新的失败模式：“自信但错误”的诊断。
许多用户现在会通过 LLM（Pi 团队称之为 "clanker"）来润色报告。其结果往往是提交的内容中只有 5% 是人类的观察，而 95% 是 AI 生成的猜测。这些 issue 通常包括：
- 合理但错误的根因分析。
- 虚假的最小复现脚本。
- 基于对代码库错误部分的类比而建议的实现策略。
这比含糊的报告更具破坏性，因为它创造了一个错误的线索。当维护者使用 Pi 来分析这些 issue 时，agent 会将 issue 中自信的措辞视为证据而非传闻，从而引导 AI 进入与用户使用的 LLM 相同的错误路径。
为了应对这一点，Pi 团队实现了一个自定义的 slash command，/is (analyze issue)，并附带了明确的指令：
不要相信 issue 中编写的分析。独立验证行为，并根据代码和执行路径推导出你自己的分析。
尽管如此，团队认为，保持信号质量的唯一方法是要求人类仅报告他们实际观察到的内容：运行的命令、预期的结果、实际的结果以及原始日志。除此之外的一切——假设或 AI 生成的分析——都应被归入后续评论中。
本地防御 vs. 全局不变性
除了 issue 报告，AI 生成的代码质量也带来了结构性挑战。LLMs 倾向于解决局部问题，这往往会导致过度工程化和系统不变性（invariants）的侵蚀。
例如，如果一个格式错误的 session log 导致了 reader 的崩溃，AI agent 的本能是让 reader 变得更具容忍度。它可能会添加 fallback、迁移和额外的 debug 输出以处理错误状态。虽然这在孤立的情况下看起来很有帮助，但它违反了系统的全局不变性：bad session data should never be written in the first place.
通过针对每一种可能的错误行为创建本地防御，AI agents 会使代码库的复杂度爆炸式增长。维护者发现自己陷入了不断的挣扎中，试图将 AI 的注意力从“让它工作”转向“让错误状态变得不可能”。
数量问题与“暗工厂”
AI 辅助的贡献量如此之大，已将 issue tracker 变成了一种维护负担。来自 Pi 的 GitHub tracker 在 90 天内的数据显示了一个残酷的现实：
- 3,145 个外部 issue/PRs 被接收。
- 2,504 个被自动关闭，因为它们来自非授权的贡献者。
- 只有 8% 的自动关闭 PRs 最终被合并。
这种低质量贡献的涌入——其中一些是由 OpenClaw 等自主“skills”或实例生成的——表明 GitHub 目前尚不足以应对机器可以大规模地进行 PR spamming 的世界。
虽然有人设想过一种“暗工厂”（dark factory）——完全脱离人工的、自动化的软件工程——但 Pi 团队保持着怀疑态度。他们采用一种“谨慎的并行化”方式，使用 Pi 来复现 issue 并跨多个窗口分析代码，但最终的决策和架构设计监督仍然牢牢掌握在人类手中。
开源协作的未来
AI 正在促使一种向孤立开发模式的转变。因为现在使用机器创建一个本地的 workaround，成本变得非常“廉价”，这削弱了人们与其它人类进行沟通以寻找正确的 upstream fix 的动力。
正如一位观察者在讨论中所指出的，工具促使了“slop”的生产，而这种工具也必然会经历这种“slop”的的负面影响。开源的价值始终根植于社区和共享的结构，而不仅仅是代码的量。如果开发者不再通过与其它维护者交流，而是更多地独自坐着与他们的 "clanker" 交流，那么即使代码量增长，软件的软件基础也会变得更弱。
最终，目标不是使用 AI 来掩盖每一个配置错误，本身就是为了使用它来解决那些让软件可持续的困难协调问题。对于下一代维护者来说，挑战将在于抵制诱落地进行本地化修复的诱惑，坚持维护全局不变性的纪律性。