AI 编程时代，人与人的交流减少了是好事吗？

随着 AI 编程在团队越来越普及，猛然发现一个正在变得「习以为常」的变化：以前遇到问题，第一反应是问同事或 Google；现在第一反应是问 AI。

Anthropic 在 2025 年 8 月对内部 132 名工程师和研究员做了调研（53 次深度访谈 + Claude Code 使用数据分析），把这个变化讲得很具体：Claude 成了“第一站”。有人说自己现在提问更多了，但 80%–90% 的问题都丢给 Claude，只有剩下 Claude 解决不了的才去找同事。

交流减少，到底是不是好事？

答案很难用一句话盖棺定论，但可以把它拆开：减少的是什么交流、增加的是什么交流、谁受益、谁受损、组织会丢掉什么能力。拆开之后，我们聊聊。

1. 交流为什么会减少？

「问同事」换成「问 AI」，最核心的原因不是大家突然不爱社交，而是成本变了：

  • 问 AI 不需要等对方空闲
  • 不担心打断别人
  • 不欠人情
  • 不需要把上下文组织成「适合对人讲」的样子（很多时候我们只要把报错、代码片段、目标贴过去）
  • AI 还能陪你迭代：你改一句，它再改一句，来回几十轮也不尴尬

Anthropic 的访谈里，很多人把 Claude 描述成「常驻协作者」。但与此同时，他们也强调：多数工作仍要监督和验证——频繁使用，不等于完全放手。在问卷里，超过一半的人认为自己能「完全委派」的比例只有 0–20%。

交流减少，不代表工作变简单；很多交流只是从「人际通道」搬到了「人机通道」。

2. 交流减少可以带来好处

如果只说交流减少带来「效率提升」，太粗了。

更准确的说法是：很多原本不值得打扰人的问题，现在可以被即时解决，这会直接改变团队的节奏。

Anthropic 的数据里有几个信号很典型：

  • 受访者自报：现在 Claude 参与了他们 约 59%–60% 的工作，平均带来 约 +50% 的生产力提升（相较 12 个月前是 2–3 倍增长）。
  • 他们把生产力的来源描述为：每类任务耗时略降，但产出量显著上升。
  • 还有一个容易被忽略的点：受访者估计 27% 的 Claude 辅助工作“本来不会做”，包括一些“nice-to-have”、探索性工作、文档测试、以及小修小补。

交流减少在这里的正面作用是：
很多「本来要去问人」的碎问题，被 AI 吃掉以后，人的协作可以更集中在真正需要对齐的地方。

在 Anthropic 的访谈里，有人说 Claude 形成了一个过滤器：例行问题交给 Claude，同事只处理更复杂、更需要组织上下文或判断力的部分。

这对很多团队来说，会带来几类直接收益：

  1. 减少同步阻塞：你不用等某个专家上线回复，很多事可以自己推进。
  2. 减少社交摩擦：不必反复确认「我现在打扰你是否合适」。
  3. 让“冷启动”更容易：对新人或跨领域的人，AI 能补齐工具链、代码风格、惯例解释。
  4. 让协作更聚焦：把人从「答疑机器人」解放出来，去做判断、方案权衡、目标对齐。

从组织角度讲，这确实是好事：同事的时间更像「稀缺资源」，而 AI 的时间不是。

3. 交流减少是有代价的

交流减少的问题在于：人与人的交流减少，减少的往往不是闲聊，而是一些「看起来低效、但在组织里非常有价值」的过程。

3.1 指导与传承会变弱（尤其对新人）

Anthropic 有个很直接的反馈：一位资深工程师说，难过的是初级员工不像以前那样常来问问题了——虽然他们确实更快得到答案、学得也更快，但连接少了。

这类“连接”不是情绪价值这么简单，它对应的是：

  • 代码审美与工程判断的口口相传
  • 对系统边界、坑位、历史遗留的理解
  • 「为什么我们不这么做」的经验
  • 出问题时应该找谁、怎么升级、什么时候停手

AI 能解释代码、给建议，但它替代不了一个组织里那些隐性的「运行规则」和「风险嗅觉」。或者我们可以称它为「潜规则」

3.2 越依赖 AI，越需要高手，但高手可能变少

Anthropic 提到一个很关键的矛盾：监督 Claude 需要技能，而过度使用 AI 又可能让技能变少。有人担心的不是自己会不会写代码，而是「监督与安全使用」的能力会不会退化。

访谈里还有个安全相关的例子很典型：Claude 提出一种「很聪明但很危险」的方案，像「非常有才但缺经验的初级工程师」会提的那种。能识别这种危险，需要经验和判断力。

当团队把大量交流（包括讨论、复盘、推演）替换为「我和 AI 私下迭代」，长期会出现一种风险：
团队表面产出更快，但「集体判断力」的增长变慢。

3.3 协作方式会变

Anthropic 的访谈呈现出分化：

  • 约一部分人认为协作没变：会照开、方向照讨论，只是执行方式变成「你对着很多个 Claude 工作」。
  • 也有人明显感到：自己和 Claude 的协作远多于和同事的协作。
  • 有人喜欢这种变化，因为“不用麻烦别人”；也有人抵触，因为“更喜欢和人一起工作”。

这说明：交流减少不是单向度的，它改变的是交流的结构——从“随手问”转向“更重的对齐”。
而一旦对齐变重，团队如果没有刻意经营，很容易出现：

  • 每个人都在本地把东西做很快，但最终合并、上线、验收时冲突变多
  • 设计决策被“私下定稿”，缺少充分挑战
  • 标准不一致：测试、可维护性、可观测性被忽略（尤其在产出量暴涨时）

当「实现」和「规划」都更多交给 AI，人类之间如果还沿用旧的协作节奏，很容易失配。

3.4 意义感

写代码的「手感」和「心流」正在消失，甚至影响职业满足感。
从个人体感上来说也是，已经没有心流和手感的状态了，只不停的输入提示词和等待。 当然，你的脑海里还是会有一个架构图，一个方向。 如果这个都没有了，那你存在和不存在已经没有意义了。

也有人发现自己真正喜欢的是「写完之后带来的结果」，而不是「写的过程」。

这会影响一个很现实的问题：当我们减少了与同事的交流，同时也减少了自己动手的比例，我们每天工作的乐趣来源会改变。如果团队不谈这个问题，人的流失会以更隐蔽的方式发生。

4. 所以，交流减少是不是好事？

看你减少的是哪一种

把「交流」粗暴地当成一个东西，会得出很混乱的结论。更可操作的拆分方式是：你减少的是下面哪一种？

4.1 如果减少的是“低价值同步”，通常是好事

比如：

  • 解释某个报错怎么修
  • 查一个命令怎么用
  • 复制粘贴式的示例代码
  • “我现在卡住了，给我一个思路”这种轻量提示

这些问题交给 AI，整体是正收益：快、便宜、不打扰人。

4.2 如果减少的是「决策对齐」和「经验传承」，长期不是好事

比如：

  • 为什么我们要这么设计？约束是什么？边界是什么？
  • 这个改动会不会引入安全/合规风险？
  • 出现事故时如何复盘、如何改流程？
  • 新人如何在真实项目里形成判断力？
  • 谁对什么负责？升级路径是什么？

这些不是「知识问答」，而是组织的运行方式。AI 可以参与，但不能替代团队成员之间的共识建立。

4.3 如果减少的是「互相看见」

我们会失去韧性

很多团队扛过线上事故、跨部门冲突、方向摇摆，靠的不是某个代码技巧，而是：

  • 彼此信任
  • 知道对方擅长什么、在意什么、底线是什么
  • 关键时刻愿意帮、愿意兜

当日常交流下降到只剩「正式会议」，这类韧性会下降。平时看不出来，出事时就会很明显。

5. 把「人际交流」从随缘变成机制

如果我们是负责人，最重要的不是号召大家「多交流」，而是把交流做成机制，让它在 AI 加速的节奏下仍然成立。

5.1 明确：哪些事必须找人，哪些事默认找 AI

给团队一个简单的「分流规则」，避免两种极端：

  • 极端 A：什么都问人，人被打爆
  • 极端 B：什么都不问人，最后在合并时爆炸

可以直接定几条硬规则（按团队情况调整）：

  • 涉及架构边界、接口契约、数据一致性、安全权限：必须找人评审/同步
  • 影响线上、影响成本、影响合规：必须找人
  • 只是工具用法、报错排查、脚手架生成：默认问 AI
  • 不确定是否该找人：先写清楚问题和已尝试的路径，再找人（减少沟通成本）

5.2 给资深工程师留出“可见的指导时间”

Anthropic 的访谈里已经出现了「新人不来问了」的信号。很多团队会误判：新人不问 = 新人更强。短期可能是，长期不一定。

更稳的做法是：

  • 每周固定一个短时段做 office hours（公开问答，不私聊）
  • 重要模块设定 design review/ADR（哪怕轻量）
  • 对“AI 生成的关键代码”设立更严格的 review 标准（不是反 AI，而是防止组织能力流失）

核心目标是：让“提问—讨论—形成共识”这条链继续存在，只是把低价值部分交给 AI。

5.3 把「AI 使用痕迹」纳入协作，而不是藏起来

现在很多人会私下反复与 AI 迭代，最后只给团队一个结果。协作成本反而上升，因为别人看不见过程，也不知道你为什么这么做。

我们可以要求（或鼓励）大家在 PR/设计文档里补两类信息：

  • 关键决策的备选方案与取舍（哪怕两三条）
  • 风险点和验证方式（你如何确认它是对的）

这会让交流更少但更高质量。

5.4 允许「必要的慢」

关键能力要刻意练

团队层面可以做这些：

  • 对核心链路、核心组件：要求成员能解释清楚，而不是「AI 说的」
  • 对新人：阶段性要求手写/手推一些关键部分，确保他们能监督 AI，而不是被 AI 带着跑
  • 对事故复盘：强调人对系统的理解沉淀，而不是贴一段 AI 总结

目标不是回到过去，而是让团队保持「监督能力」。

6. 我们能做点什么

如果我是工程师，交流减少对我最直接的影响通常是两点：我变快了，但我更孤立了。要避免后者，方法也不复杂。

6.1 让 AI 解决「问题」，让人参与「判断」

我们可以默认把下面这些交给 AI：

  • 解释陌生代码
  • 查资料、列步骤
  • 生成脚手架
  • 写测试样例的初稿
  • 重复性重构

但遇到这些场景，建议尽量把人拉进来：

  • 需要在多个方案之间做取舍
  • 觉得“有点不对劲但说不上来”
  • 要改动一个并不拥有的模块
  • 担心引入隐性风险（安全、性能、成本、可维护性）

AI 很会「给你一个能跑的答案」，但很多线上事故的起点就是“能跑”。

6.2 主动经营「被看见的贡献」

当大家都在本地和 AI 加速时，团队很容易只看到结果，看不到难度。我们需要更明确地让别人理解我们的贡献是什么，尤其在：

  • 做的是“减少未来成本”的事（可观测性、稳定性、性能、可维护性）
  • 修的是“papercuts”（Anthropic 也提到 Claude Code 里 8.6% 的任务属于这类小修小补）

这些工作如果不被看见，组织很容易把它们当作「AI 随手做的」，从而压缩这类投入，最后反噬效率。

6.3 保留与同事的「低成本连接」

不需要刻意社交，也不用强迫自己多聊。最实用的是维持低成本连接，比如：

  • 每周一次简短同步：在做什么、接下来风险是什么、需要谁拍板
  • 关键节点提前说：我准备这么改，谁最该看一眼
  • 把求助写成可复用的文本：背景、现象、试过什么、倾向的方案

这样不会回到「到处问人」，但也不会变成“「独自和 AI 闭门造车」。

7. 小结

交流减少本身不是问题，但当交流减少以失去组织能力时这会是一个问题，而且还是一个大的问题。

「人与人的交流减少」这件事，短期几乎一定会发生，因为它符合成本与效率逻辑。Anthropic 的内部研究把这种变化讲得很直白：AI 正在成为第一入口，很多例行沟通会被替代，协作结构会重排。

真正需要在意的是：

  • 我们减少的是不是那些本来就该被自动化吞掉的交流
  • 我们有没有保留决策对齐、经验传承、风险评审这些「组织能力」的通道
  • 当每个人都能更快产出时，我们的团队是否还能形成一致的标准与判断

如果这些做到了，交流少一点通常是好事：更少打扰、更少等待、更高产出。
如果这些没做到，交流少一点会变成隐性负债：新人长得快但根不稳，系统跑得快但风险更高，团队看起来忙但共识更薄。

参考资料

以上。