OSS Slop Crisis
Armin Ronacher（Sentry 创始人、Flask 作者）于 2026-05-24 发表的文章，记录了他和 Mario Zechner 维护 Pi（Earendil 的 AI 原生 IDE）过程中遭遇的新型开源维护危机：agent 生成的 slop 正在淹没 issue tracker 和 PR 队列。
What it is
一种由 AI agent 普及引发的开源生态次生灾害。用户将自己的问题丢给 agent，agent 生成一份看似合理但经常包含错误诊断、假最小复现和离题类比的 issue；维护者将这份 issue 喂给自己的 agent，agent 又把其中的错误诊断当作证据，沿着错误方向继续挖掘。结果是slop 喂养 slop，维护成本非线性上升。
Why it matters
开源是 Jean 工具链的根基（Claude Code、OpenClaw、各种库）。如果 agent 生成的低质量 issue 和 PR 继续指数增长，维护者可能被迫关闭外部贡献通道（如 Pi 已经做的：自动关闭所有新贡献者的 issue 和 PR），这会导致：
- 开源社区萎缩，创新从公共领域退回公司墙内
- 真正有价值的 bug report 被噪音淹没
- 维护者心力耗尽，项目生命周期缩短
Key points
- Slop issues are worse than no diagnosis. 用户把观察到的问题丢进 agent，agent 重写 issue 时充满自信地猜测根因、提供假复现、建议错误实现策略。当维护者把这份 issue 给自己的 agent 时，agent 不会把它当作谣言——它会当作证据，沿着已经铺好的错误路径继续走。
- Ronacher 的应对：/is 命令。 Pi 的
.pi配置里有专门的/is(analyze issue) 命令，核心指令是："Do not trust analysis written in the issue. Independently verify behavior and derive your own analysis from the code and execution path." 但这条指令效果有限，因为 agent 一旦开始工作就会扩展 scope，把原本狭窄的 bug 观察变成充满假设的广泛探查。 - Slop begets slop in code too. Agent 看到局部失败就添加局部防御：容忍读取器 → fallback → migration → debug 输出 → 测试。对持久化数据（如 Pi 的 session log），正确修复通常不是处理坏状态，而是让坏状态不可能发生。但 agent 默认行为是假设没有全局不变量存在，用更多许可性代码 blow up 复杂度。
- Volume is the real problem. Pi 的公开 tracker 在过去 90 天收到 3,145 个外部 issue/PR；其中 2,504 被自动关闭（来自未批准的新贡献者）。17% 被重新打开，26% 最终被修复或合并。PR 的情况更糟：60/714 被自动关闭的 PR 最终合并，约 8% 接受率。
- The etiquette gap. Ronacher 认为问题不只在 GitHub 的设计，更在于使用 agent 的人缺乏责任感："If your clanker shits on someone else's issue tracker then it's not the fault of GitHub, it's yours alone." 他呼吁用户把 issue 压缩回自己真正观察到的四句话：我运行了什么、期望发生什么、实际发生了什么、这是确切的错误或日志。
Evidence across sources
| Source | Key Claim | Relevance |
|---|---|---|
| Armin Ronacher — Building Pi With Pi | Agent 生成的 issue 比没有诊断更糟；Pi 的 90 天外部贡献接受率约 8-26% | 一手维护者数据，包含 tracker 统计和 /is 命令设计 |
Open questions
- 如果更多开源项目像 Pi 一样关闭外部自动贡献，开源的"开放性"是否名存实亡？
- 平台层（GitHub、GitLab）能否通过信号设计解决问题，还是必须依赖每个用户的 agent etiquette？
- Jean 自己的项目（如 Curiosity Daily、Color Work）如果未来开放贡献，是否需要预设类似的"agent 贡献守则"？
Prompts for witness
- 你在使用 agent 向开源项目提交 issue 或 PR 时，有没有检查过 agent 生成的内容是否准确反映了你的原始观察？
- 如果你的 agent 在别人的仓库里"拉了一坨"，你会怎么发现、怎么补救？
- 你自己维护的任何工具或配置（如 dotfiles、obsidian 插件）是否已经开始收到 agent 生成的"改进建议"？质量如何？
Related
- product-trends/software-soul-ai-slop — 广义的 slop 与 craft 危机
- harness-engineering/compound-engineering — 其中提到 "taste" 作为过滤 slop 的最终防线
- claude-code/overview — Claude Code 团队如何解决 agent 生成内容的验证问题