纠结"AI 行不行"的时间，结果可能都出来了。

随手记，欢迎拍砖。

最近一直在折腾 AI，中间也跟很多同学交流。

发现做多的一个问题是：“AI 能不能做这个？AI 能不能做那个？”

比如有同学说：“AI 可以通过自然语言写 SQL 吧？”

我当时随口回了一句：“AI 都能写 Java 了，SQL 结构上更简单，肯定没问题啊。”

说完感觉自己好像很懂一样，但其实我也是边做边摸索，真正去做了之后才发现，中间有很多细节是你事先根本想不到的。

---

AI 是个智商很高但对你的业务一无所知的合作者

打个比方，你去把 SQL 语言的创始人请过来，跟他说：“帮我查一下今天湖北省未完结的单子。”

他肯定一脸懵——查哪个库？库里有哪些表？"未完结"在你们系统里是哪个字段、存的什么值？时间字段是时间戳还是字符串？

所以你得把数据库相关的信息都给他讲清楚。这不是 AI 的问题，换任何人来都一样。

---

然后你以为讲清楚了……

表结构说明白了，继续问：“我只要维修的单子。”

他可能还是懵——维修在哪个表，怎么存的，是中文"维修"还是某个 ID？除了维修，还有安装、换货，是同一个字段不同的值，还是不同的表？

（当然，如果 AI 足够"聪明"，也许会先取一部分数据自己推断，这点倒是挺有意思的——有时候它真的能自己摸出一些规律来。）

再往下，“我只要空调维修的单子”——空调好理解，但存在哪、以什么形式存，还是得说清楚。

慢慢说，一层一层其实都能搞定，没什么难的。

---

直到踩到这种坑

“我只要空调清洗的单子。”

清洗……这不就是一种服务类型吗？洗空调嘛，跟维修、安装并列，很正常。

但实际上——空调清洗是一个商品。

它不在服务类型字段里，它在商品表里，以一个具体的 SKU 形式存在。

这种东西，你在脑子里推演一百遍也推演不出来。你把 Schema 背得再熟，也想不到一个看起来完全合理的词，在具体的业务系统里存法会这么反直觉。

这不是 AI 的锅，换人来也一样懵，就是业务本身的复杂性。

---

说了这么多，其实想表达很简单的一件事

不用纠结 AI 能不能做某件事，先去试一遍。

真正有价值的，不是"AI 能做"这个结论，而是你亲自走一遍之后碰到的那些预料不到的细节。

那些细节读别人的总结替代不了，就是得自己踩一遍才知道。

而且说实话，AI 时代试错的成本真的不高。 以前想验证一个想法，可能要查资料、写代码、找人讨论，折腾半天。现在很多东西直接跟 AI 说一声，几分钟就能跑出一个粗糙的结果来，够不够用先看看再说。

与其在那里想"这个 AI 行不行"，可能你想的这段时间，结果都出来了。

我也还在摸索，远没到能总结方法论的程度，就是觉得——在 AI 这件事上，动手比想破头管用。