AI“洗稿”正在污染开源社区：当Bug报告被大模型“美化”之后

起因：当“AI助手”变成“问题制造者”

你可能已经习惯了用ChatGPT或Copilot来帮你写代码、解释错误。但有没有想过，当你用同样的方式来“美化”一个开源项目的Bug报告时，会发生什么？知名开源项目（如Flask、Jinja2）的维护者Armin Ronacher最近道出了一个令人头疼的新现象：越来越多的人提交问题报告时，不是用自己的话描述问题，而是先让AI“润色”一遍。结果呢？这些报告看起来格式工整、术语专业，但内核却是一团糟——错误的根因分析、伪造的最小复现步骤、不相关的代码类比，以及一长串可能根本不相关的错误类型。Ronacher将这种由AI生成、缺乏人类原始观察的“垃圾内容”称为“slop”（泔水/废料）。

拆解：“洗稿”式报告的三大危害

这不仅仅是“报告写得不好”那么简单。它揭示了AI工具在开源协作中可能引发的深层问题。

首先，它严重浪费了维护者的核心资源：注意力和时间。维护者需要像侦探一样，从一堆看似合理实则误导的信息中，剥离出用户到底遇到了什么问题。这比处理一个描述粗糙但真实的报告要费力得多。其次，它破坏了开源协作的信任基础。开源社区建立在清晰、诚实的沟通之上。当一份报告充满了AI生成的、自信满满的错误结论时，维护者无法判断这是用户的真实困惑，还是AI的胡乱猜测。最后，它掩盖了最有价值的调试信息——用户的原始体验。用户说“我运行了X命令，期望Y，但得到了Z错误”，这个简单的链条包含了最直接的因果线索。而AI的“美化”常常会插入自己的（通常是错误的）推断，切断了这条宝贵的线索。

趋势洞察：从“AI辅助编码”到“AI辅助沟通”的异化

这件事揭示了一个更广泛的趋势：我们正在从“AI辅助生成内容”快速进入“AI辅助生成沟通”的时代。但沟通与写代码不同，它高度依赖上下文、真实意图和细微差别。当人们把需要精确描述个人观察的场景（如提交Bug报告、撰写技术文档、甚至写邮件）也交给AI“代笔”时，就很容易产生这种“沟通的异化”——形式完美，但内容失真。这不仅仅是开源社区的问题，未来在企业内部的Issue跟踪、客户服务、技术论坛等所有需要精准问题描述的场景，都可能面临“slop”的泛滥。

实用价值：如何与“AI润色”共存？

对于开发者和开源贡献者而言，Ronacher的呼吁是一个重要的提醒：AI是优秀的“语法检查员”和“格式整理器”，但不应成为“问题描述者”。在提交问题前，你可以用AI帮你检查命令格式、纠正拼写，但问题的核心——你做了什么、你看到了什么——必须来自你自己的观察和记录。一个黄金法则是：在让AI润色之前，先用最朴素的语言写下“我运行了...我期望...但实际发生了...，错误日志是...”。

对于项目维护者，或许可以考虑在贡献指南中明确提倡这种“原始观察优先”的报告文化，甚至提供模板，引导用户回归最本质的问题描述。

反常识/意外

一个可能被忽视的角度是：这些“slop”报告的提交者，其本意往往是好的。他们可能认为用AI把报告写得“更专业”是在帮助维护者，是一种尊重的表现。这恰恰说明，AI工具的使用规范和社区文化的引导是多么重要。我们正处在一个需要重新定义“什么是好的AI辅助协作”的十字路口，而开源社区，作为全球开发协作的先锋，正在率先体验这场阵痛。

---

原文地址: Quoting Armin Ronacher