一张 AI 生成的 PPT，把技术讨论变成了表演（转）

引子

有一种人，不懂技术，但懂开会。
有一种会，解决不了问题，但能解决提问题的人。
有一种 PPT，10 页，AI 生成，字字皆是废话，却能决定线上方案的走向。

这不是段子，这是我亲历的事。

---

背景

作为国内对外的开发窗口，早已摸透了对面那帮人的行事风格。

国外那边搞了个活动，由于历史数据积累，数据量相当可观。活动期间接口响应极慢，核心 API 需要将近 10 秒才有反应。初步判断是慢 SQL 引发了数据库内存飙升，触发了自动扩容机制，数据库实例最多时扩到了 16 台。

数据库本身配置不低——专用计算型实例，读写分离架构。正因为一直在动态伸缩，日志定位极其困难，对方也懒得深究。

---

发现问题

活动就持续那几天，直到第三天才有人来通知我们。而实际上，活动刚开始，我这边盯着监控就已经察觉到了异常。

第二天早上，我发现内存指标开始异常攀升，随即锁定了一条慢 SQL。结合整体监控时间线一对比，基本吻合。追问了一句搞的什么活动，对方说是配合电视新闻做的，时间点也完全匹配——慢 SQL，基本坐实。

---

分析过程

拿到 SQL 开始 EXPLAIN，最多也就是两张十万级数据量的表做关联，按道理不至于慢成这样。

于是把 SQL 拆开来逐段分析，大致分为两块：

• 第一块：活动基础信息查询
• 第二块：活动当前答对人数的百分比统计
  

两段单独跑，各自都在 0.089 秒以内，飞快。但拼在一起，直接飙到 10 秒。

这已经超出了我的常规认知范围——单独查都快，合在一起就崩，说明大概率是执行计划出了问题，或者合并后的资源分配逻辑触发了某种低效路径。

与其深挖根因（对方也不配合），不如直接给方案：拆成两步查询，结果在应用层拼接，结构和原来保持一致，代码稍微复杂一点，但效率有保障。

---

PPT 登场

本以为可以趁活动还在线验证修复效果，结果对方搞了个会议，用 AI 生成了整整 10 页 PPT，洋洋洒洒分析了一番，最终结论是：加索引。

我当时的心理活动分三秒：

• 第一秒：这人还知道加索引，不错。
• 第二秒：等等，这表走的全是主键关联，加索引有什么用？
• 第三秒：他根本没看过 SQL。
  

这张表数据量不大，第二块查询全程走主键关联，加索引几乎没有收益。况且最终的关联条件压根没有用到索引字段，加了也是白加。

但话不能直说，毕竟人家也是在认真解决问题。

但 PPT 做得好看，会开得很认真，结论说得很自信。于是这个方案，就这么定了。

---

AI 给了什么？

AI 给了他开口的底气。

以前不懂技术的人，在技术讨论里多少还会收敛一下，毕竟说外行话会被看穿。但现在不一样了——把问题扔给 AI，得到一堆术语和结论，往 PPT 里一贴，就成了"有备而来"。

至于这些术语对不对、结论成不成立，没人追问，也没人敢追问。因为追问就是挑衅，挑衅就是不合作，不合作就是你的问题。

技术讨论，就这样变成了表演。

---

内部斗争才是真正的慢 SQL

活动第一天我就发现了问题，第三天才有人通知我们。

为什么？因为通知就意味着承认，承认就意味着责任，责任就意味着麻烦。所以先拖着，拖到瞒不住了，再开会，开会就要出方案，方案要像回事，于是 AI 来了，PPT 来了，索引来了。

加索引这件事，从提出到部署，花了整整 7 天。黄花菜早凉了。跑了一下，还是那么慢。让他们自己去发现吧。

再之后，我们的拆分方案也跟着上线，接口确实快了。只是活动已经结束，没有实际流量验证，效果存疑。

---

尾声

以为这事就翻篇了。

一个半月后的今天，对方又来消息，说"能解决一部分，但整体还有问题"。

我心里只有四个字：PPT 做得好。

---

结语

以前我以为技术问题最难的部分是定位根因。

后来我发现，根因找到了也没用。

真正难的，是在一个用 PPT 说话、用 AI 撑场面、用流程消耗问题的环境里，让一个正确的方案活过开会这一关。

AI 让不懂的人有了话语权。
内部斗争让正确的方案没有生存空间。
最后慢的不是 SQL，是整个协作链路。

而我，把面子丢大了。