Josh Moody 6 月 23 日在个人博客写了一篇很尖的文章，题目也带着玩笑味：如何用被动攻击的方式羞辱那些自私使用 LLM 的人。

他给“自私式 LLM 使用”下的定义很直接：一个人用 LLM 节省自己的时间，却消耗其他人的时间，最后让整体生产率下降。

这不是反 AI。

真正的问题是协作账本变了。发送者少花了五分钟整理，读者可能多花十分钟过滤废话。Slack、PR、代码评论、文档里，只要这种文本越来越多，团队就会觉得忙，但不一定更清楚。

问题不在 AI 味，在成本被转嫁

Moody 点到的几个场景，很多知识工作者都不陌生。

Slack 里，一条原本能两句话说清的问题，被扩成带标题、粗体和项目符号的长列表。博客里，出现大量熟悉的“不是 X，而是 Y”式句法。Pull Request 描述和代码评论里，也开始堆出成片的 AI 文本。

这些内容看起来更完整，未必更有用。

在软件团队里，Reviewer 打开 PR，最想知道的是三件事：改了什么、风险在哪里、哪里最该看。如果描述被模型扩成一面文字墙，Reviewer 的第一项工作就变成删噪音。

Slack 也是一样。问题本来是“这个接口现在返回空数组，谁知道最近改动吗？”如果被写成一套背景、目标、观察、可能原因和下一步建议，读者反而要先猜：你到底要我做什么？

场景看似省下的时间被转嫁的成本更好的做法
Slack 长列表发送者不用组织短问题读者要提炼真正请求一两句话说明背景、问题、希望谁回应
PR 描述作者快速生成说明Reviewer 要过滤套话写清范围、风险、测试方式
代码评论LLM 补满解释维护者读不出重点只解释复杂逻辑、取舍和边界
技术博客快速铺满结构读者读到熟悉句式保留真实判断、具体细节和限制

我更在意的是，Moody 把“AI 写得像不像人”这个争论，拉回了协作成本。

文本是不是模型生成，不是最关键的。关键是它有没有让接收者更快理解。如果没有，它就是把整理成本甩给别人。

表情符号是讽刺，不是管理制度

Moody 提的第一套办法很故意：用表情符号给 AI 垃圾内容贴标签。

比如 🏺 暗指人类手工艺术，📎 让人想起微软 Office 时代的 Clippy，🧨 对应 slop grenade，🧱 指文字墙，🐋 和 ✨ 则用来嘲讽那种一眼熟悉的 AI 味。

这部分不能读成企业管理制度。

作者自己也带着自嘲。他不是认真建议公司把这些 emoji 写进规范，而是在点出一个尴尬现实：很多人不愿当面说“你这段像 AI 灌水”。于是低密度内容会在礼貌里越堆越多。

这个讽刺成立，是因为它抓住了一个老问题。

过去，邮件模板、PPT 模板、Clippy 式建议，也常常让人误以为“格式完整”就是“表达清楚”。LLM 的变化在于，它能把这种低密度文本批量放大，而且语气更顺，识别起来更费劲。

但限制也要说清。

团队不能靠“闻 AI 味”执法。不同人的语言能力、岗位压力、写作习惯都不一样。把风格当证据，很容易误伤真正表达困难的人。

所以更稳的标准不是“你是不是用了 LLM”，而是“这段话有没有帮别人更快行动”。

真正该做的是缩短沟通路径

Moody 最后给出的办法，反而很低冲突。

他建议团队多奖励清楚但不完美的真人表达。看到一个粗糙但有真实想法的句子，可以追问：“你是怎么想到这个点的？”或者请对方展开某个细节。

这比贴标签有效。

因为它把对话拉回人脑，而不是继续奖励模型腔的完整包装。

他也提到一些更工程化的做法：PR checklist、评论长度限制、要求描述简洁有用。比如 PR 说明要写清范围、风险和测试方式；前端变化附截图或视频；复杂代码评论保持简明；重要假设、弱点和开放问题要标出来。

他还写过一个 Claude Code 的 comment guard script，用来阻止超过两行的代码评论。

这些做法的重点不是禁用 AI，而是限制 AI 把沟通变胖。

对软件工程团队和技术管理者来说，动作可以很具体：

  • 收紧 PR 模板，只保留 Reviewer 真需要的信息。
  • 给代码评论设长度上限，复杂处再例外说明。
  • 在 Slack 里鼓励短问题，少发自动生成的长清单。
  • 文档评审看信息密度，不看篇幅和格式完整度。

对频繁使用 LLM 的知识工作者来说，也有一条简单判断：如果你让 AI 写完之后，自己都没有读一遍、删一遍、压缩一遍，那它大概率不是帮团队省时间，而是把你的整理工作外包给同事。

接下来最该观察的不是团队有没有更多 AI 工具，而是这些工具有没有让沟通更短。

PR 是否更容易 review？Slack 问题是否更快被回答？文档是否更少需要二次解释？如果答案是否定的，那再漂亮的生成文本，也只是把成本换了个地方藏起来。

AI 可以继续用。真正该被管住的，是把“我懒得整理”包装成“我已经充分说明”。