AI编程也会犯低级错误

前段时间提到过，我为自家小餐馆开发了一套网页版点餐系统，打算让AI将其重写为安卓版本。起初我对AI做项目抱有过高期望，没给它设置好限制条件，结果给自己埋了个大隐患。

今天记录一下踩坑过程。先介绍背景：我之前的开发全是本地环境，本地数据库、本地服务器……最近想加快进度，希望在公司也能抽空做点东西，于是搭建了一个云端数据库环境，没想到今天一启动程序，进入菜品管理界面后，应用就直接闪退了。

查看日志发现，服务端返回菜品列表超时，而App没有处理接口超时的异常，导致崩溃；再排查服务端，发现获取菜品列表时，还要分别获取每个菜品的多SKU信息。

AI的处理方式是这样的：先取出菜品列表，再逐个循环查询每道菜的SKU……这完全是新手程序员才会写的低效代码……这样一来，数据库查询次数直接变成N+1次，即N个菜品各查一次SKU再加一次列表查询。

之前用本地环境，数据库响应很快，这个毛病没显现出来；换成云端环境后，数据库响应变慢，又被N+1倍放大，直接引发了上述故障。

理清问题后，下一步就是着手解决，目前有两件事需要处理：

第一个问题相对简单，跟AI说明情况后，等它自动完成就行。

第二个问题，我没有直接让AI改，而是先让AI给出几种解决方案并推荐最佳方案。

简要列出AI给出的方案：

AI推荐第一种方案，因为菜品总数通常不超过200条，可以一次性查出所有SKU，再在内存里关联匹配，负载可控。而第二种方案会产生笛卡尔积，还需给菜品实体增加List skus属性，改变了实体结构。

理论上第三种方案性能最优，但考虑到菜品列表从服务端查询的频次不高（客户端一般查询后会缓存），而且引入缓存会提高服务端复杂度，最终我也采纳了AI推荐的方案。

之后的工作就完全可以交给AI处理了。

简单总结一下从这次小问题中得到的启示。

我们在使用AI进行氛围编程时，不能真的只是随心所欲地编程，该认真思考的环节绝不能省。

就拿这个小问题来说，如果我在最初让AI实现功能时，多叮嘱一句：要兼顾菜品列表和SKU的查询效率，可能就不会出现这个问题了。

当然，项目开发中考虑不周在所难免，遇到问题时，我们不该只是把错误信息原样丢给AI，那样我们反而成了被AI驱使的工具人。

我们更应该停下来，静下心分析错误的根源，然后让AI提供几种备选方案，凭借自己的判断来引导AI执行，这样做反而比盲目地向AI发出指令效率更高。

而且，借助这种方法解决问题，本身也是一种更有效的学习和经验积累方式。