在开源项目 Pi 的开发中引入 AI 辅助后，出现了一系列新问题。由大型语言模型（LLM）“润色”过的 issue 和 PR 报告，不仅内容失真、冗长，还常常提供错误的诊断，误导了人类维护者和自动化工具。同时，AI 生成的代码倾向于为局部问题增加复杂的兼容和容错逻辑，破坏了系统本应遵循的全局规则，增加了整体的复杂性。最终，AI 只是增加了问题的数量和噪音，却没有相应地提升维护能力，这反而凸显了开源社区更需要清晰的人类反馈、协作精神和对问题根源的坚持，而非依赖机器进行孤立的局部修复。
虚假繁荣：被 AI “污染”的议题
在 Pi 项目中，issue 描述不仅仅是用户与维护者之间的沟通，它们还被用作 AI 代理的输入指令。这带来了一个新问题：许多 issue 报告经过了 AI 的“加工”，变得极其糟糕。
一个糟糕的 issue 过去只是令人烦恼，但现在我们面对的是一种全新的、包含 5% 人类反馈和 95% AI 生成的、基本不准确的垃圾信息。一个包含看似合理但实际错误的诊断的 issue，会制造额外的工作。
这些被 AI 重写后的 issue，充满了自信但错误的结论、虚假的复现步骤和对代码的错误类比。这比没有任何诊断还要糟糕，因为它会误导维护者和后续介入的 AI 工具，使其沿着错误的路径进行修复。AI 工具通常不会质疑 issue 中的分析，而是将其视为 可靠的证据。
一个理想的、由人主导的 issue 报告应该简洁明了，只包含核心事实：
- 我运行了什么命令。
- 我期望发生什么。
- 实际发生了什么。
- 这是确切的错误或日志。
如果你不知道根本原因，就直接说不知道。 提交者应该对自己提交的内容负责，而不是甩出一个由 AI 编造的、自己都无法确认的“烂摊子”。
治标不治本：AI 倾向于增加系统复杂度
AI 生成的代码也存在类似的问题。它们在解决问题时，倾向于过度设计，从而破坏系统的核心原则。例如，当面对一个因日志格式错误而导致读取器崩溃的问题时，AI 的第一反应通常是构建一个能兼容错误格式的“宽容”读取器，并为其添加回退机制、迁移路径和更多的调试输出。
这种做法在局部看似乎没问题，但从整个系统来看却是错误的。Pi 项目的核心是一个设计精良的会话日志，它有必须遵守的 全局约束。AI 的行为模式是假设这些约束不存在，试图让系统兼容所有可能的错误情况，结果是系统的复杂度急剧膨胀。
几乎在所有情况下，正确的修复方法都不是去处理错误状态，而是 让错误状态不可能发生。
维护者的工作变成了不断地将 AI 的注意力从 局部防御 拉回到 全局约束 上，这是一个既困难又费力的过程。这种模式导致 LLM 编写的代码增加了大量不必要的复杂性。
数量的诅咒：贡献的激增与质量的下滑
AI 带来了大量的 issue 和 PR，但其中大部分质量低下。这本身就是一个巨大的 维护问题。
过去 90 天的数据显示：
- Pi 项目收到了 3,145 个外部 issue 和 PR。
- 其中 2,504 个因来自未经批准的贡献者而被自动关闭。
- 只有 17% 的 issue 被重新打开，而最终被合并的 PR 比例不足 10%。
许多贡献是完全的垃圾信息，有些提交者甚至不知道自己创建了它们。GitHub 显然没有为这种新型的开源协作模式做好准备，但责任更多在于那些滥用 AI 工具，向他人的项目倾倒垃圾信息的人。
开源的本质：协作，而非孤立
AI 时代下的开源项目正承受着一种新的压力。我们看到了更多的代码、更多的项目和更多的问题，但很多项目缺乏真正的用户，生命周期也极短。
AI 并没有增加真正需要软件的人，也没有增加能够审查代码的维护者。它主要增加的是代码的数量和争夺注意力的项目数量，这在很大程度上 分散了本应共享的努力。
我们需要更坚实的基础，而不是更脆弱的。开源需要更多的协作，而不是更多与机器的孤立工作。
机器让局部的变通方案变得廉价，导致代码中堆积了大量针对个别行为的防御措施。人们不再与其他人沟通、讨论修复方案的最佳位置，而是一个人与一台机器在孤立的环境中绕过问题。人类沟通虽然困难，但开源的价值恰恰来源于社区和协作，这种结构能让项目超越其最初的创建者而长存。