一篇题为《Don't just paste the AI at me》的短文，戳中了一个很新的协作毛病。

别人问你一个问题。你把问题丢给 ChatGPT、Claude 之类的大模型。几秒后，你把一整段未经处理的回复原样贴回 Slack、私信或代码评审里。

看起来你是在帮忙。

但对方真正收到的，往往不是回答，而是一份转交过来的 AI 初稿。它可能语气完整、结构漂亮、措辞安全，却没有你的判断，也没有你对当前语境的承担。

这件事有意思的地方在这里：AI 越好用，直接粘贴 AI 越不像能力，越像失礼。

问题不是用 AI，而是让 AI 代你回答

这篇短文批评的重点，不是“别用 AI”。

AI 可以用来起草邮件、整理思路、生成检查清单，也可以帮人在卡住时先迈出一步。对知识工作者来说，这已经是很常见的工作流。

边界在于：模型输出只能是草稿，不能冒充你的最终回答。

对方找你，不是因为他缺一个文本生成器。现在很多人都能自己打开模型，很多团队也已经接入 ChatGPT Enterprise、Microsoft 365 Copilot 或类似工具。通用答案的门槛很低。

对方真正需要的，是你知道的那部分东西：项目背景、团队旧账、代码风格、业务压力、沟通对象的偏好，以及这件事在当前环境里该怎么取舍。

未经编辑的 AI 长文，问题不只是“可能不准”。更要命的是，它把本该由你完成的阅读、筛选、判断和表达，转手丢给了别人。

这和早期互联网协作礼仪有点像。nohello.net 反对只发一句“在吗”，dontasktoask.com 反对先问“能不能问个问题”。它们反感的不是聊天，而是把沟通成本转嫁给对方。

直接粘贴 AI，也是同一类问题。

真正冒犯人的，是抹掉了人的判断

在 Slack 私信里，一段“Here’s what Claude said”可能比沉默更糟。

沉默至少说明你还没判断。原样粘贴 AI，则像是在说：我没有花时间理解你的问题，但我生成了一段看起来像回答的文字。

代码评审里，这种感受更明显。

如果一个工程师收到一段泛泛而谈的 AI 建议，比如“注意错误处理”“建议提升可读性”“考虑边界情况”，但没有指向具体文件、具体代码行、具体风险，那它不是评审。它是噪音。

内容协作也一样。ChatGPT 可以写背景介绍，但编辑不能只把长段背景转发给同事。真正有价值的是删掉空话，补上事实，指出哪一段能用，哪一段不可靠，哪一个角度更适合当前稿子。

不同场景里，失礼点并不完全一样：

场景低质量做法可接受做法真正差别
Slack / 私信原样贴一整段模型回复读完后压缩成自己的三句话你是否替对方省了时间
代码评审贴 AI 的泛泛建议核对代码后指出具体文件、风险和取舍你是否承担评审责任
内容协作转发 ChatGPT 的长段背景删改、补事实、加入编辑判断你是否做了筛选
必须引用模型不标来源直接发送标注模型来源，并说明为什么有用你是否诚实交代依据

我不太买账的是一种说法：既然 AI 答得不错，直接贴出来也没什么。

这句话只看到了“文本质量”，没看到“协作关系”。在团队里，一个回答的价值不只取决于写得顺不顺，还取决于它是不是来自一个愿意负责的人。

模型可以生成选项，但不能替你承担后果。

该改的不是工具，而是交付习惯

这件事对几类人影响最直接。

经常在 Slack、私信里用 AI 辅助回复的人，应该把“复制发送”改成“读完再说”。最简单的动作是：删掉模型客套话，只留下结论、理由和下一步。三句话够用，就不要发三段。

工程师在代码评审里用 AI，可以把它当检查清单，但不要把清单当评审意见。更好的做法是先让模型提醒风险，再回到代码里核对。最终评论要落到具体位置、具体影响和具体建议。

管理者要看的，也不是谁用了 AI。更该看的是，谁把 AI 初稿当成了交付物。方案讨论、客户回复、招聘反馈、代码评审，这些场景都需要人承担判断错误、语境误读和关系损耗。

可以给团队设几条很低成本的规范：

  • 模型输出先读完，再决定要不要发。
  • 关键事实要核对，不确定就标出来。
  • 删除空话、套话、重复话。
  • 加入自己的判断.赞成什么，反对什么，风险在哪。
  • 必须引用模型时，明确写出来源，并说明这段为什么可信或有用。

比如一句“我问了 Claude，下面这部分和官方文档一致，可以作为检查清单”，就比直接贴一整段更诚实。它保留了工具痕迹，也保留了人的责任。

还有一种情况更简单：如果你读完模型答案后发现自己没有补充，那就别发。

说“我现在没有更多判断”并不丢人。把一段未经阅读的 AI 长文推给别人，才是在透支信用。

这不是反 AI。

真正该反对的，是把 AI 初稿当成最终交付，把机器生成的完整句子包装成自己的判断。工具可借，责任不能转手。对方问的是你，不是你剪贴板里的模型输出。