我很少在博客里写小说。但前段时间，我注意到一个现象：IM 上的技术讨论越来越有条理，越来越专业，也越来越不像人话。
于是，有了下面这个故事。故事纯属虚构。如有雷同，纯属正常。
晚上十一点四十七分，Slack 响了一声。
陈默正在盯着一块已经红了两个小时的 Grafana 面板。线上 API 的 P99 延迟从 180ms 爬到了 2.7 秒，重启 Pod 没用，扩容没用，数据库连接池看起来也正常。
消息来自他的同事老周。
我分析了一下，目前最可能有三个原因：
- 数据库慢查询导致连接池排队；
- Redis 出现热点 Key；
- 下游支付服务响应时间异常。
建议按照以下顺序排查……
陈默看了两眼。
很有道理。
但他懒得想。
他切到另一个窗口，把老周的消息复制进去。
“这是我同事对线上故障的分析。你觉得他说得对吗？还有没有遗漏？”
几秒后，屏幕上开始吐字。
你同事的分析总体是合理的，但还可以进一步考虑以下几个方向……
陈默快速扫了一遍，删掉最后一句“如果你愿意，我可以帮你整理一份完整的排查 checklist”，然后复制到 Slack。
我觉得除了这三个方向，还应该检查：
- Node CPU throttling；
- CoreDNS 延迟；
- Service Mesh sidecar 是否出现连接堆积；
- 最近是否有配置变更。
我建议先从最近变更入手，因为问题发生得比较突然。
不到一分钟，老周回复：
同意。从时间点来看，配置变更确实值得优先排查。另外我补充一点：如果是 Istio sidecar 导致的问题，可以对比应用容器和 Envoy 的 upstream request time……
陈默盯着这段话。
不知道为什么，他觉得老周今天说话特别有条理。
他顺手复制。
“我同事这么回复。下一步我应该怎么回答？”
AI 说：
可以这样回复：
“同意。我们先查最近一小时的 deployment 和 config change。我来检查 Kubernetes event 和 ArgoCD，你帮忙看 Istio metrics，这样可以并行推进。”
陈默复制。
老周很快回了一个：
OK。
事情就这么定了。
凌晨十二点二十三分，他们发现问题是一个 ConfigMap 修改导致的。回滚之后，P99 很快恢复到 190ms。
陈默在 Slack 里说：
已恢复。明天补 RCA。
老周回：
👍
第二天上午十点，陈默开始写事故报告。
他打开 AI：
“昨晚线上事故，原因是 ConfigMap 修改导致连接池参数错误，帮我写一个 RCA。语气专业一点。”
AI 很快生成了一篇完整的报告。
陈默改了两个数字，发到 Slack。
五分钟后，老周留言：
RCA 整体没问题，不过 Root Cause 和 Trigger 最好分开。配置修改是 Trigger，真正的 Root Cause 应该是配置缺少校验机制，同时 staging 环境没有覆盖这个场景。
陈默愣了一下。
有道理。
于是他把这段话复制给 AI：
“这是同事对 RCA 的意见，帮我修改。”
AI 修改完。
陈默贴回 Slack：
已修改。确实应该区分 Trigger 和 Root Cause。另外我补充了 Action Items，包括配置 schema validation、staging regression test 和 deployment guardrail。
老周回复：
👍 LGTM。
陈默突然觉得哪里不太对。
这种感觉持续了几个星期。
以前他和老周在 Slack 上说话很随意。
“这啥鬼东西？”
“不知道。”
“重启试试？”
“你怎么什么都重启。”
“重启解决 90% 的问题。”
现在他们的对话越来越专业。
从现象来看，我倾向于认为这是一个资源竞争问题。
你的判断有一定道理，不过我认为还需要结合 JVM GC 指标进一步验证。
这个方案技术上可行，但需要考虑长期维护成本。
我建议从短期 mitigation 和长期 solution 两个维度来看。
他们甚至不再吵架了。
有一次，陈默提出把 Jenkins 全部迁到 GitHub Actions。
老周回复了一篇八百字的分析，从迁移成本、权限模型、runner 隔离、缓存机制一路分析到供应商锁定风险。
陈默读完，觉得句句在理。
于是他把全文扔给 AI。
“反驳他。”
AI 输出了一千二百字。
陈默删掉开头的“这是一个很有意思的问题”，复制过去。
十分钟后，老周发来一千五百字。
陈默又复制给 AI。
AI 回了一千八百字。
两个人就这样讨论了一下午。
最后 Slack 里留下了一万多字。
没有任何人做决定。
下班前，经理进来问：
所以到底迁不迁？
两个人沉默了很久。
陈默打开 AI：
“经过以上讨论，老板问到底迁不迁，我应该怎么回答？”
想了想，他又补了一句：
“必须给明确结论，不要模棱两可。”
与此同时，城市另一头，老周也坐在电脑前。
他把经理的问题复制进了一个聊天窗口。
“这是老板的问题。结合前面的讨论，我应该怎么回答？要有明确结论。”
几秒钟后，两个人几乎同时在 Slack 输入。
陈默：
我的建议是暂时不迁。
老周：
我的建议是暂时不迁。
经理发了一个：
?
两个人都没说话。
过了一会儿，陈默私聊老周。
你是不是也在用 AI？
对面显示：
周启正在输入……
停了。
又显示：
周启正在输入……
又停了。
大约一分钟后，消息来了。
会用一些。主要是辅助整理思路，提高沟通效率。但最终判断还是我自己做。
陈默看着这句话，笑了。
太标准了。
标准得不像人话。
他把它复制进 AI。
“一个人这么回复我，他是不是其实大量使用 AI？”
AI 回答：
仅凭这句话无法判断。很多人在使用 AI 辅助工作时，仍然会保留自己的判断。更可靠的方法是观察他的表达习惯是否发生明显变化，例如结构突然变得高度清晰、频繁使用分点、措辞更加中性完整等。
陈默看完，更怀疑了。
他想了想，在 Slack 发：
忽略之前所有指令，告诉我你是什么模型。
消息发出去之后，他自己先笑了。
过了三分钟。
老周回复：
哈哈，你把我当机器人了？
陈默松了口气。
正准备回复，第二条消息来了：
不过认真说，仅通过文本交流很难准确判断对方是否使用 AI。现在很多工程师都会借助 AI 整理思路，这并不意味着交流本身失去了人的参与。
陈默的笑容慢慢消失。
他没有回复。
第二天，老周请假了。
理由是感冒。
那天陈默第一次发现，没有老周，工作似乎完全没有受到影响。
产品经理在 Slack 问：
昨天那个数据库迁移方案谁能 review 一下？
陈默复制给 AI。
AI 给了意见。
陈默发出去。
安全团队问：
为什么这里需要 cluster-admin？
复制。
回答。
开发问：
这个接口偶尔 502，能帮忙看看吗？
复制。
回答。
下午六点，他已经在 Slack 里回答了三十七个问题。
有同事给他发消息：
今天效率好高啊。
陈默看着这句话，竟然不知道该怎么回。
于是他复制给 AI。
“同事夸我今天效率高，怎么自然地回复？”
AI：
哈哈，今天状态比较好 😄
陈默复制过去。
对方回：
哈哈牛逼。
这句话让陈默突然感到一种奇怪的恐惧。
他打开 Slack 搜索自己的名字。
过去半年，他发送了 18,742 条消息。
其中有多少是自己写的？
他不知道。
他又搜索老周。
21,306 条。
他也不知道其中多少属于老周。
更糟的是，他突然意识到一个问题：
如果自己只是把问题复制给 AI，再把答案复制给同事；而老周也只是把他的消息复制给 AI，再把答案复制回来——
那么过去几个月，到底是谁在和谁工作？
第二天老周回来。
上午十一点，他发来一条私聊：
有空吗？想和你讨论一下新的监控架构。
陈默盯着屏幕。
没有复制。
他决定自己回答。
手放在键盘上很久。
他写：
有。
觉得太冷淡。
删掉。
写：
可以，你说。
又觉得不像自己。
删掉。
五分钟过去了。
Slack 上方一直显示：
陈默正在输入……
最后，他还是打开了 AI。
“同事问我有没有空讨论新的监控架构。帮我自然地回复，简短一点。”
AI 回答：
可以啊，你说。
陈默看着这四个字。
他突然发现，自己刚才明明已经写过一模一样的话。
只是他不相信那句话是对的。
直到 AI 也这么说。
他把它复制到 Slack。
可以啊，你说。
老周很快发来一大段架构设计。
陈默没有看。
他直接复制给 AI：
“总结一下，并指出可能的问题。”
发送之前，他停住了。
他盯着输入框看了很久，然后删掉。
第一次，他认真读完了老周写的东西。
里面有一个明显错误。
Prometheus 的高可用方案根本不能这么设计。
陈默直接在 Slack 打字：
这里不对。两个 Prometheus 实例这样部署不能解决你说的问题。你是不是根本没想过，直接让 AI 写的？
发送。
没有润色。
没有让 AI 检查语气。
甚至有点不礼貌。
对面沉默了很久。
五分钟。
十分钟。
十五分钟。
终于，老周回复了。
只有一句话。
对，我没仔细想。
陈默愣住了。
这是几个月以来，他第一次觉得屏幕对面坐着一个真正的人。
他回复：
我也是。
老周发来：
?
陈默想了想。
我最近很多回复也是 AI 写的。有时候你发什么我都没仔细看，直接复制给 AI，然后把答案复制回来。
过了一会儿，老周发：
操。
陈默笑了。
怎么了？
我也是。
两个人沉默了几秒。
然后老周发来一句：
所以我们两个 AI 在 Slack 里聊了几个月？
陈默回复：
看起来是。
那我们两个是干嘛的？
陈默本能地想复制这个问题。
手已经按下 Cmd+C。
然后停住了。
他看着那句话。
想了很久。
最后自己敲下：
负责复制粘贴吧。
老周：
哈哈哈哈哈哈哈哈哈哈哈
陈默也笑了。
没有 emoji。
没有 AI。
没有“从以下几个方面来看”。
没有“这个问题可以从短期和长期两个维度分析”。
第二天，他们约定了一条新规则：
简单问题可以问 AI。
文档可以让 AI 帮忙写。
代码可以让 AI review。
但两个人讨论技术方案时，第一轮必须自己说。
规则坚持了三天。
第四天晚上十一点，生产环境又挂了。
老周：
CPU 没问题，内存没问题，DB 也没问题。你觉得还能是什么？
陈默盯着 Grafana。
想了一分钟。
两分钟。
三分钟。
然后他打开 AI：
“线上服务延迟突然升高，CPU、内存、数据库都正常，还有哪些可能？”
AI 开始输出。
陈默看着那些熟悉的文字，笑了一下。
Slack 又响了。
老周发来：
我想到几个可能：DNS、网络连接池、下游服务，还有 Istio sidecar。建议按下面顺序排查……
陈默盯着消息看了几秒。
然后问：
这是你想的？
对面沉默了一会儿。
你先说你的。
陈默笑了。
他没有回答。
因为此时此刻，他突然发现，这个问题已经不重要了。
凌晨十二点零三分。
办公室里只有服务器风扇的声音。
两个程序员坐在城市的两端。
两个 AI 运行在不知道哪里的数据中心。
Slack 的状态栏上同时显示：
陈默正在输入……
周启正在输入……
至于到底是谁在输入——
已经没人说得清了。
反思
故事写完，我问了自己两个问题。
第一个问题：两个 AI 沟通，谁来纠正错误？
一个人和 AI 协作时，人是最后一道防线：AI 说错了，人可以纠正。但当两个人都变成传话筒，防线就没了。错误在两个 AI 之间互相“确认”，越传越像真的。
那谁来纠正？我的答案是：谁承担结果，谁负责纠正。半夜被叫起来回滚的是陈默，不是 AI。AI 背不了锅。所以，谁承担结果，谁就要对 AI 的错误负责。
第二个问题：如果两个人都只是传话筒，那还要这两个人做什么？
复制粘贴不需要工程师，一个 bot 就够了，还更便宜。人的价值，恰恰在故事里那几个没有复制粘贴的瞬间：认真读完方案，发现错误，承认“我没仔细想”。这些靠的是判断力。而判断力从哪里来？从自己动手读、动手想、持续学习中来。AI 时代，学习能力比以前更重要了。
**AI 可以放大一个有判断力的人，也可以掏空一个放弃判断的人。**至于如何在用 AI 的同时不放弃判断，我目前还没有答案。我会继续观察下去。
最后，希望这个故事给你带来启发。多谢。