我對由LLM編寫的事故報告的未來感到擔憂
摘要
一篇博客文章警告不要使用LLM編寫事故報告,認為這繞過了寫作過程中固有的批判性思維,導致報告看似合理但可能錯誤,且難以驗證。
<p><a href="https://lobste.rs/s/ysxvko/i_am_dreading_our_llm_written_incident">評論</a></p>
查看缓存全文
缓存时间: 2026/06/20 14:32
# 我对未来由 LLM 撰写事故报告感到恐惧
来源:https://surfingcomplexity.blog/2026/06/19/i-am-dreading-our-llm-written-incident-report-future/
前几天,Reginald Braithwaite(https://raganwald.com/)发布了以下帖文(https://social.bau-ha.us/@raganwald/116766319180124300)。为了记录,我也附上了我自己的回复:
[](https://surfingcomplexity.blog/wp-content/uploads/2026/06/image-2.png)
Braithwaite 的帖子充满了讽刺,但毋庸置疑,完全由 LLM 撰写的事故报告即将来临。而我对这个未来并不期待。
在深入讨论之前,我想指出,要收集撰写一份良好事故报告所需的数据,确实需要做大量繁琐的工作,而 LLM 可以显著减少这种负担。这一点我毫无异议。但使用 LLM 来帮助你准备事故报告的素材,与直接让 LLM 撰写报告本身,两者之间有着天壤之别。
Braithwaite 的帖子让我感到恐惧,正是因为它展现了 LLM 作为一种事故报告生成工具的诱惑力。毕竟,你只需让它写报告,它就会照做。而这正是我担心的。
漫画家 Dick Guindon 有一句名言:“*写作是自然用来揭示你思维有多混乱的方式*”。你可能以为自己理解了一个概念,但只有当你在纸上(比喻意义上)动笔,真正尝试用文字向潜在读者解释这个概念时,你才会意识到自己的理解其实有多模糊。用自己的话写作迫使你直面自己对所写内容的理解程度。或者,正如 Leslie Lamport 所说:“*如果你只在脑中思考而不动笔,你只是以为自己思考了*。”
让 LLM 生成事故报告的文字绕过了这个思考步骤。现在,写作过程中没有人类需要在循环中直面解释是否与他们收集的证据一致。相反,你得到的只是一个看似合理的解释,对不熟悉细节的人来说,可能读起来点头称是,心想“嗯,说得通”。但 LLM 可能编造了系统中并不存在的耦合关系,也可能遗漏了事故中实际存在的关键交互,而因为没有人真正费力合成数据来撰写报告,也就没有人会发现这些问题。因为如果你试图减少写作工作量,你又会花多少精力去核查 LLM 的工作呢?
在我看来,LLM 生成的事故报告比用 LLM 写代码或执行 AI SRE 风格的任务更危险。对于编码任务,即使没人细看代码中的有意义的细节,也总有一个测试步骤来检查代码是否表现出预期的行为。对于 AI SRE 任务,LLM 的输出要么帮助你解决事故,要么不能。在这两种情况下,大自然是对 LLM 输出的最终仲裁者。
但事故报告并非如此。一份拙劣报告的后果并不会像错误代码或错误运行诊断那样立竿见影。相反,我们得到的事故报告形式正确,但内容却是错误的,同时没有明显的测试来验证其正确性。
而且,由于撰写事故报告很耗时,使用 AI 工具生成的诱惑将不可抗拒。但这些 LLM 不会去和事故的参与者交谈。这些报告将是拟像——它们拥有正确的形式,但不会为读者带来关于系统本质的真正洞见。从中汲取的教训将大打折扣。
而且,是的,人们可能也会用 AI 来总结它们。
这不是一个我期待的未来。
## 文章导航
相似文章
LLM批评者是对的,但我仍然使用LLM
作者同意LLM批评者关于内容泛滥和伦理等问题的观点,但仍然使用LLM,描述了在科技会议上观察到的认知失调。
LLMs 不擅长编写“氛围式”规范
Hillel Wayne 基于对社区项目的分析,讨论了尽管 LLM 在编写 TLA+ 和 Alloy 等形式化规范方面很受欢迎,但它们经常生成浅显、同义反复的属性,无法捕捉微妙的缺陷。
"This is written by an LLM" 这类评论应标记为离题
文章建议,在 Lobsters 上仅仅指责帖子由 LLM 生成的评论应标记为离题,以维护讨论质量。
@madiator: 帮自己一个忙,留出15分钟阅读本文,再花数小时去执行。我们现在对LLM的依赖太过头了……
一条推文,呼吁人们减少对LLM的依赖,回归到纸上的长文写作和思考,以便更清晰地思考,避免自欺欺人。
使用LLM助手写博客
关于使用LLM作为博客写作助手的讨论,发布于Lobste.rs。