南京长江大桥让我又想了想:用 AI,最后还是要把问题解决

八一这天，我坐在长江游轮上，亲手拍下了这几张照片：蓝天下的红旗、横跨江面的南京长江大桥，还有从钢梁间驶过的列车。

南京长江大桥上层通汽车，下层跑火车。同一座桥，承载两种过江需求。

看着这座桥，我想起了自己这几个月使用 AI 的经历。

6 月 2 日，我做的 DeskCompanion 还没有真正打通核心连接。两天后的 6 月 4 日，我已经开始做支付。从 6 月 2 日到 7 月 21 日，这个项目留下了 1,394 个唯一 AI 会话。

AI 没有少干活，代码也没有少写。可最该先解决的连接问题，当时还在那里。

那次之后，我越来越清楚一件事：AI 不是目的，解决问题才是目的。

团队里的情况也很像。

正式推广三个月后，11 人团队里大部分人完成了每天的 AI 使用量目标，也逐渐习惯遇到问题先问 AI，再找同事。

但如果不看调用了多少次，而是看一个人能不能先弄清需求、想办法实现、检查结果，再一直跟到项目完成，目前真正改变工作方式的只有两个人。

Token 使用量可以证明大家开始用了 AI，却不能证明工作方式已经改变，更不能替项目结果作证。

这也是我现在理解 all in AI 和 AI in all 的区别。

如果每天关心的是模型、Token 和调用次数，最后把“用了多少 AI”当成进度，那更像 all in AI。

我更在意的是：连接有没有真正打通，需求为什么要做，系统最后能不能交到客户或业务手里。这些问题原来就存在，AI 只是进入其中，帮助我们分析、实现和检查。这更像 AI in all。

汽车还是汽车，火车还是火车。南京长江大桥没有改变它们要去哪里，只是让它们都能过江。

团队里的产品、开发、测试岗位也还在。变化不是所有人都变成 AI 工程师，而是不再只做完自己岗位里的那一小段，有人愿意把问题继续往下解决，直到事情真正做完。

在游轮上看着这座桥，我想到的其实很简单：南京长江大桥双层的设计把汽车和火车送过了江，这件事本身就是答案。

回到 AI，我愿意用同一个标准看它：不看留下多少会话、写了多少代码，只看最重要的问题，最后有没有解决。

说明：AI 参与资料梳理、文字润色与排版。