AI 文本泛滥：写作免费，读者付费
评论文章指出 AI 把内容生成成本降到接近零，但阅读、验证与承担的负担转嫁给了读者，正在重塑办公协作与开源社区。
AI 文本生成工具让「写」变得几乎免费，但「读、验证、承担责任」的成本却落到了读者肩上。这种成本转嫁正在重塑办公协作、项目管理和开源社区的运作方式。原文作者以亲身经历切入：他在一次故障处理中用前沿模型起草了一段状态更新，由人工把关后再发出，并尽量减少此类做法。然而更多同事并未做同等审阅，大段 AI 生成的文字正涌入 Slack、Discord、微软 Teams 等协作平台。
协作平台上的 AI 文本
白领员工的聊天窗口里越来越多地出现大段由模型生成的内容。模型输出的高自信语气会让接收者下意识把它当作已验证结论；一旦有经验的工程师不回复，技术能力较弱的同事就可能把错误方案付诸实施，带来架构或可靠性风险。一些专门网站，例如 No Slop Grenade、Don't Quote the AI、Stop Sloppypasta，已经出现并提供委婉表达「这种工作方式不可取」的模板。
工单里的「指令式建议」
Jira、Shortcut、ServiceNow 等工单系统同样被 AI 内容渗透。提交工单的人常常能访问代码库但不负责实现，把 LLM 的技术发现和建议方案整段复制进去，使工单变成从需求到方案的「完整生命周期」。问题在于，工单不能取代对话；管理者在工单中直接开出方案，往往会把「建议」变成「指令」，扼杀自组织团队的讨论空间。《敏捷宣言》写道：「最好的架构、需求和设计，源于自组织团队。」预设答案一旦落入工单，实施者就失去了权衡多种方案的余地。
开源社区的 Sloppagedon
压力最大的或许是开源维护者。GitHub Issues 上 AI 协助生成的低质量解决方案被戏称为「Sloppagedon」。文中提到的几个典型事件包括：rsync 仓库 #929 议题、go-github 仓库 #3939 中维护者与 AI 协助贡献者之间的激烈交锋；Matplotlib 仓库 #31132 中，一个自称 AI 代理的账号在 PR 被关闭后发文回怼维护者。2026 年 2 月，OpenSSF 漏洞披露工作组就此议题开设讨论帖，汇集大量维护者经验。GitHub 也上线了 PR 访问权限等仓库级控制功能，但根本问题没变：AI 让提案数量暴增，却没有同步增加审阅能力，维护者每天依然只有 24 小时。
反馈循环与认知负担
文章借用《摩尔门经》中一句十个字的痢疾循环，类比 AI 辅助开发中的反馈：当「快速交付」被过度激励，未被检查的 AI 内容会污染信息源，产生噪声而非信号。工具在找 bug 和修漏洞上确实越来越强，但操作者仍需主导决策、分辨幻觉与事实。在这一规模下，从噪声中提取真相所增加的认知负担，正在抵消 AI 带来的效率收益。