Armin Ronacher 在 2026 年 5 月 24 日发表的一段评论中，指出了当下开源项目问题反馈中一个令他极为沮丧的失败模式：人们提交的 issue 已经不再使用自己的语言和声音。这些问题报告里确实包含某个被观察到的问题，但报告本身是被人丢给“clanker”（对 AI 大模型的戏称）之后由模型改写出来的，结果把整个问题搞得一团糟。
Ronacher 进一步解释了这种做法的具体后果。他指出，这类请求的提示词往往写得非常糟糕，因此模型得出的结论多数情况下并不准确，却总是充满自信。最终呈现出来的内容充满了对根本原因的纯猜测、伪造出来的最小化复现步骤、关于实现策略的建议、与相邻但常常是错误的代码进行的类比，以及一长串可能相关也可能无关的错误类别清单。换句话说，报告表面上信息量很大、条理清晰，但实际上把真正的观察掩盖在了模型的臆测之下。
正因如此，Ronacher 表示他个人越来越希望 issue 报告能够被精简到只保留人类真正观察到的内容。他给出了一个极简的模板，包含四步：第一，我运行了这条命令；第二，我预期会发生这件事；第三，实际发生的却是那件事；第四，这里是确切的错误信息或日志。这个结构的价值在于，它把事实和推测分开，让维护者能够直接从原始观察入手排查问题，而不用先费力剥去一层 AI 生成的、看似权威实则不可靠的包装。
这段评论是 Simon Willison 于 2026 年 5 月 24 日在其博客上收集引用并发布的，针对的是提交给 Pi 项目的“slop issues”（低质量、由 AI 批量生成的问题报告）。该引用被归入 ai、github-issues、llms、ai-ethics、open-source、coding-agents、generative-ai 等标签之下，反映出 AI 编程代理和生成式 AI 广泛进入开源协作流程后，社区正在面对的一个新的协作质量问题：当提交问题报告的成本被 AI 降到几乎为零时，维护者反而要为筛选和甄别付出更高的代价。