Armin Ronacher 吐槽 AI 生成的 GitHub Issue：全是自信满满的胡扯
Flask 作者 Armin Ronacher 发文批评用户用 AI 重写 issue 导致信息失真、结论错误。他呼吁开发者回归原始观察，按四步模板提交。对中文开源社区同样适用，提醒我们 AI 辅助沟通的陷阱。
一句话看懂
Flask 作者 Armin Ronacher 公开批评用户用 AI 重写 issue，导致报告充满自信却错误的猜测，呼吁回归人类原始观察。
详细发生了什么
Armin Ronacher（Flask、Jinja2、Click 等知名 Python 库的作者）在博客中吐槽了一个让他越来越头疼的现象：用户提交的 GitHub Issue 不再是自己说的话，而是把观察到的问题扔给 AI（他称之为 “clanker”）重写，结果被搞得一团糟。
他指出，这些 AI 重写后的 issue 通常 prompt 写得很差，导致结论虽然充满自信，但往往不准确。具体表现为：对根因的完全猜测、虚假的最小复现步骤、建议的实现策略、类比到邻近但错误的代码，以及列出大量可能无关的错误类。
Ronacher 呼吁，至少对他个人而言，他希望 issue 报告能精简为人类实际观察到的内容，并给出了一个四步模板：
- 我运行了这个命令。
- 我期望发生什么。
- 实际发生了什么。
- 这是确切的错误或日志。
这篇博客是针对他参与的开源项目 Pi（一个开发者平台）而发，但问题显然具有普遍性。
中文圈视角
这个问题对中文开源社区同样尖锐。随着 ChatGPT、DeepSeek 等工具普及，不少开发者习惯把报错信息丢给 AI 生成 issue，结果往往出现“幻觉”复现步骤或错误归因。
国内现状：在 Gitee 或 GitHub 中文项目里，类似“AI 味” issue 已不少见。比如把“运行报错”描述成“模型推理失败”，实际只是路径写错。维护者需要花大量时间澄清，反而降低了沟通效率。
对比反思：Ronacher 的模板其实和国内一些开源项目（如 Vue、Element Plus）的 issue 模板异曲同工，但后者往往被用户忽略。AI 的介入让问题更糟——它让用户误以为“写得更专业”，实则丢失了关键细节。
对中文用户的建议：如果你用 AI 辅助写 issue，务必保留原始报错和操作步骤，不要让 AI 替你“总结”或“推理”。直接贴日志比任何 AI 润色都更有用。
几条值得记住的细节
- Ronacher 明确表示，AI 重写后的 issue 结论“more often than not inaccurate but always full of confidence”。
- 他建议的 issue 模板只有 4 步：命令、期望、实际、错误/日志。
- 该吐槽源于他参与的 Pi 项目（pi.dev），但适用于所有开源项目。
- 问题根源在于用户用糟糕的 prompt 让 AI 重写，导致信息失真。
- Ronacher 强调“human actually observed”是核心，不要添加 AI 的猜测。
一句话总结
写 issue 时，直接贴原始报错和操作步骤，比任何 AI 润色都更有助于维护者解决问题。