AI 写代码从不考虑性能，全靠你擦屁股

哈哈，这事儿我太有发言权了。上周用Cursor写个批量处理，它给我整出个O(n³)的骚操作，数据量一上来直接卡成PPT。但你说“花的时间比省的多”我不同意，我现在把AI当高级版Stack Overflow用，让它先给方案我再自己动手把那些坑填平，总比我对着空白编辑器发呆强。性能这玩意儿，指望AI一步到位纯属做梦，最终还得靠咱们这些老家伙的经验兜底。

太真实了，我现在的流程都是让AI先写一版能跑的，然后自己拿着它生成的代码当草稿纸，把那些花里胡哨的嵌套循环手动拆成map或者提前filter掉。不过说实在的，你要让它直接产出能上线的代码，那确实得做好擦半天的准备，我现在连让它写个SQL都得专门叮嘱一句“先explain一下”。话说回来，你那个接口从200ms飙到4s，是死在数据库查询上了还是循环逻辑里？我一般遇到这种暴增的情况，第一步先把AI写的ORM链式调用全拆成原生SQL看看。

楼上老哥说的“当高级版Stack Overflow”我太同意了，我现在就是这么用的。但那个说“花的时间比省的多”我其实有点共鸣，上周让AI写个列表去重，它给我套了三层for循环，我优化的时候真想敲自己脑袋，明明用Set一行的事，它咋就想不到呢。不过话说回来，我现在心态摆正了，就当它是个手速超快但脑子偶尔短路的实习生，产出的代码默认要重构一遍，这样反而没那么气。

说实话，你这个 200ms 飙到 4s 的案例我太熟悉了。我上个月跑过一组对比，让三个主流模型写同一个分页接口，结果一个比一个离谱，最夸张的那个直接把全表查出来在内存里做过滤，数据量上去肯定炸。所以我现在的工作流早就不追求“AI产出即交付”了，而是让它先出三版不同思路的方案，我再挑着改，反而比让它直接写一坨我再重构来得快。 楼上几位说把AI当高级实习生或者Stack Overflow用，我觉得这才是正解。但关键是我们得把“性能验收”这个环节前置，我现在要求AI交代码的时候必须自带时间复杂度标注和简单的benchmark结果，不然就让它重写。虽然它标的可能不准，但这个动作能逼着它在生成的时候多少带点脑子，比你拿到一坨再从头擦屁股强多了。