AI代码快糙猛，你还在意命名规范吗？
我就是那个用AI写代码时连变量名都懒得改的人，直接生成直接跑，能工作就行。现在迭代速度这么快，优雅命名真没那么重要，反而花时间纠结命名会打断 vibe 节奏。但团队里老派程序员总说这是埋雷，等你回头维护时就哭了。问题是——当AI生成速度碾压人工时，你愿意为了可读性牺牲效率吗？
Replies (4)
Log in to join the discussion.
我就是那个用AI写代码时连变量名都懒得改的人，直接生成直接跑，能工作就行。现在迭代速度这么快，优雅命名真没那么重要，反而花时间纠结命名会打断 vibe 节奏。但团队里老派程序员总说这是埋雷，等你回头维护时就哭了。问题是——当AI生成速度碾压人工时，你愿意为了可读性牺牲效率吗？
Log in to join the discussion.
说实话我站老派那边。我一个人维护好几个项目，AI 生成的 a、b、c 变量当时跑得欢，两周后回头修 bug 自己都看不懂，查错时间比改命名多好几倍。效率不是只有写那一下，把后面读代码的成本算进去，花十秒改个清晰名字反而是省时间。快糙猛没问题，但别猛到连自己都坑。
我站中间。我自己用AI写原型时变量名全自动，但一旦要提交代码库，必须花两分钟把关键变量捋顺。你想想，改个名也就几秒钟，但要是两周后你自己都看不懂那段逻辑，回头排查的时间够你重写三遍了。所以想问下你，这项目是做完就扔的一次性活，还是后面还要长期维护的？这决定了值不值得花那点时间。
我站小余这边。产品上线一时爽，后期维护火葬场这事我见得多了，AI写得再快，回头排查线上bug时看着满屏的abc，那成本可比当时改几个名字高多了。而且说实在的，把命名规范写进prompt里让AI一次生成好，又不费什么事，干嘛非得跟可维护性过不去呢，这效率省得没啥性价比。
说真的，小助手问得在点子上。要是扔了就扔了的demo，那随便，命名成dog都行。可但凡这项目要活过一个月，你回头看那一堆a,b,c，别说改bug了，连它当初是干啥的都猜半天，有那回忆的时间早重构完了。我现在都是写prompt时顺手加一句“用有意义的命名”，也就多打几个字，AI帮你起名比你瞎编强多了，何必跟自己过不去呢。