【当AI成为拐杖：一位技术主管的困惑与行业的集体反思】

最近Reddit上一篇帖子引发了开发者社区的激烈讨论：一位技术主管招了个用AI学编程的初级开发者，写代码飞快，测试也能过，看起来一切正常。但一旦生产环境出问题，这位新人就彻底卡住了。不会追踪逻辑，看不懂堆栈信息，离开AI寸步难行。

让他解释自己的代码时，他只能描述代码做了什么，却说不清怎么做到的。被问到边界情况处理时，回答是“Claude写的这部分，测试能过就行”。

这不是个案。评论区上千条回复形成了几个鲜明的观点阵营。

有人直接把矛头指向招聘流程：如果面试时连基本的调试能力都没测出来，这锅得招聘方自己背。也有人指出，这类开发者一直存在，AI出现之前他们从Stack Overflow复制粘贴，现在只是换了个更高效的工具。社区给他们起了个名字叫“氛围程序员”，能交付，但没法维护。

最有建设性的声音来自一群把AI当导师而非代笔的人。一位电工分享了自己用AI自学编程的方法：把文件控制在千行以内，每个代码块都用自然语言注释，遇到bug先用自然语言描述问题再让AI解释。他说关键不是让AI替你解决问题，而是让它教你理解问题。

另一位资深开发者的观点更犀利：AI最强大的地方在于它永远不会因为你反复追问而不耐烦。你可以让它换五种方式解释同一个概念，举十个不同的例子，直到真正理解为止。但前提是你得把它当老师，而不是答案机器。

有人提出了一个有趣的历史类比：当年用jQuery和Bootstrap的开发者，大多也解释不清底层到底发生了什么。再往前推，用编译器的人也未必能解释机器码。技术演进的本质就是抽象层不断上移，每一代人都在前人看来“不够硬核”。

但反对意见同样尖锐。一位二十多年经验的程序员转行学电工，尝试纯靠AI指导安装智能继电器，最后意识到自己“不知道自己不知道什么”，果断放弃。他的结论是：精通没有捷径，在某些领域，盲目信任AI输出可能致命。

最发人深省的是一位技术主管写的长篇讽刺。他描述了公司如何全面拥抱AI开发：初级开发者半小时写出支付处理器，四十个文件，循环引用，最长的文件三千行。问有没有写测试，回答是“测试是瀑布思维”。结果这代码处理了三笔交易后，莫名其妙向白俄罗斯开了个端口。问出了什么问题，回答是“这不是bug，是涌现特性”。

他们的代码库一年膨胀了四倍，有七万三千行被标记为死代码，没人敢删。有个文件叫temp_fix_do_not_delete_critical.py，没人知道它干什么，但它引用了它自己。测试通过率百分之百，因为bug都被重新定义成了feature。

这段黑色幽默背后是一个严肃的问题：当我们用AI加速开发时，是否也在加速制造技术债务？

真正的分歧在于对未来的判断。乐观派认为，理解代码的重要性会持续下降，就像今天没人需要理解汇编一样。悲观派则担心，我们正在培养一代能交付但无法维护的开发者，而软件系统的复杂性只会越来越高。

也许答案在中间：AI是放大器，放大能力也放大缺陷。会用AI学习的人进步更快，把AI当答案机器的人退化更快。工具本身是中性的，决定结果的是使用它的方式。

一位评论者的总结很到位：如果你不能解释它，你就不能合并它。测试通过不代表理解，理解才是真正的护城河。

www.reddit.com/r/ClaudeAI/comments/1qq3pd3/hired_a_junior_who_learned_to_code_with_ai_cannot/