AI 改写的 GitHub issue，正在把开源维护者拖进雾里

一个很反常的变化正在 GitHub issue 里出现：用户确实遇到了 bug，却不再直接写自己看到了什么，而是先把问题交给 AI 润色。

最后提交出来的东西，常常更完整、更礼貌、更像技术分析报告。问题也在这里。它像报告，不像证据。

Armin Ronacher 最近批评的就是这种开源项目里的“AI 改写 issue”。他的核心不复杂：真实观察被模型包进了一堆自信但错误的推断里，维护者反而更难定位问题。

这不是反 AI，也不是反 coding agent。Ronacher 反的是 AI 把低质量反馈包装成高密度噪音。

维护者要四件事，不要半篇推理报告

Ronacher 给出的要求很朴素，几乎就是 bug report 的基本功：

这四条没有技术炫技，也没有 AI 魔法。正因为没有魔法，才可靠。

开源维护者处理 issue，最怕的不是用户写得粗。粗糙事实还能追。真正麻烦的是材料不可验证。

AI 改写后的 issue 常见问题，是把“我看到的现象”和“模型猜的原因”混在一起。Ronacher 提到的几类污染很典型：伪根因、伪最小复现、错误类比、无关错误类型列表、看似专业的实现建议。

这些东西读起来像帮忙。查起来像绕路。

最坏的是“自信但错误”。一个错误根因可能让维护者沿着不存在的路径排查；一个伪最小复现可能让人以为问题已经被缩小，其实只是模型根据上下文编了一个合理剧本。

这对三类人影响最直接。

开源维护者要先拆包装，再找事实。项目贡献者要在噪音里判断哪些 issue 值得跟。使用 AI 辅助提交反馈的开发者，也可能误以为自己写得更专业了。

其实只是把不确定性包装得更像确定性。

AI 省下的是提交者时间，花掉的是维护者耐心

我更在意的是成本转移。

开发者用 AI 写 issue，省下的是自己的表达成本。维护者付出的，是验证、拆解、反向还原的成本。

原本一句话就够：“我运行这个命令，崩了，日志如下。”现在变成一段带推断、带类比、带修复建议的半自动报告。维护者要先判断：哪些是人真的跑过的，哪些是模型顺手补的。

这不是协作更聪明。是噪音更贵。

这里有一个很现实的对比：

所以问题不在“能不能用 AI”。问题在用 AI 做什么。

让 AI 帮你整理日志、翻译描述、检查有没有漏掉环境信息，可以。让 AI 替你猜根因、编最小复现、建议实现方案，就危险了。

这条边界很清楚：AI 可以清理表达，不能污染现场。

孔子说“辞达而已矣”。放在 bug report 上尤其准。报告首先要达意，不是润色；是递线索，不是写论文。

这和早年的开源协作习惯也能对上。邮件列表、补丁、issue 模板，本质上都在压低沟通成本。格式不是为了好看，是为了让陌生人快速确认：你做了什么，机器返回了什么。

AI 现在把这个顺序倒过来了。先生成一个像样的解释，再让维护者从解释里挖事实。

接下来该看什么：模板会不会反向收紧

这件事目前还不能夸大成“开源生态崩坏”。证据支撑不到那一步。

但它至少说明一种协作噪音正在变坏：低质量输入不再长得像低质量输入。它变得流畅、完整、有条理，也更难一眼识别。

接下来最该观察两个变量。

一个是开源项目会不会收紧 issue 模板。比如强制填写命令、预期结果、实际结果、完整日志，并要求标明哪些内容由 AI 生成或整理。

另一个是维护者会不会更快关闭“推理过多、证据不足”的 issue。不是因为维护者脾气差，而是他们没有义务替模型做事实清洗。

对开发者来说，动作也很简单：用 AI 前，先把原始事实留住。提交 issue 时，把“我实际运行过的内容”放在最前面。模型给出的根因和建议，如果没验证，就不要写成结论。

更好的写法是分层：

• 事实.命令、环境、预期、实际结果、日志。
• 猜测.如果一定要写，明确标注“未验证”。
• AI 辅助.如果用了 AI 整理，别让它改掉事实顺序。

开源协作靠的是低成本信任：我相信你描述的是你看到的东西。现在中间夹了一层模型，维护者不得不多问一句：这句话是观察，还是生成？

一旦 bug report 失去“事实底稿”的身份，它就不再是协作入口，而变成新的排障对象。

Ronacher 这段话刺痛人的地方就在这里。AI 没有制造 bug，却制造了围绕 bug 的雾。

所以，给开源项目提 issue，用 AI 不是禁忌。底线只有一条：让 AI 修句子可以，让 AI 猜案情不行。

回到那四句笨话：我运行了什么，我以为会怎样，实际怎样，日志是什么。

笨一点，干净一点。