我见过一个年轻人，面试的时候聊框架聊得头头是道，什么分布式、微服务、设计模式，张口就来。面试官让他手写一个简单的二分查找，他愣了半天，最后说“我平时都用AI生成”。这不是段子，是这两年越来越常见的事。
AI工具已经把编程这件事的门槛削掉了一大截。你想写个排序，Copilot补全得比你打字还快。你想搭个后台，跟ChatGPT描述一下需求，它能把路由、数据库连接、甚至Dockerfile都给你吐出来。新一代程序员从学第一行代码开始，旁边就坐着一个全知全能的助手。他们习惯了一种新的工作流：遇到问题，描述问题，复制答案，粘贴，跑通，下一个。
这种工作流在大多数日常开发里确实够用。CRUD接口、数据清洗脚本、简单的爬虫、前端页面，AI都能搞定。一个刚入行的人，靠着AI的加持，产出效率可能比五年前一个工作三年的人还高。但这恰恰是问题所在。效率高不等于能力强，就像计算器算得快不等于你懂数学。
脱离AI之后，第一道坎是调试。AI生成的代码跑不通，你得自己看报错。报错信息指向一个你没见过的库，文档全是英文，Stack Overflow上的答案跟你用的版本对不上。这时候你需要的不是“再问一次AI”，而是读懂堆栈、定位变量、在关键位置打日志、逐步缩小范围。这套能力是靠大量亲手写代码、亲手踩坑、亲手修bug长出来的。AI可以帮你写代码，但它没法替你建立这种直觉。
第二道坎是架构。AI能给你一个能跑的方案，但它给不了你一个适合当前业务的方案。你的系统要扛多少并发，数据一致性要求到什么程度，团队里几个人维护，未来半年会不会换技术栈。这些判断需要你对系统有整体的理解，知道每个技术选型的代价是什么。AI给的答案往往是“最常见”的答案，不是“最适合”的答案。而“最常见”和“最适合”之间的差距，就是独立开发能力的体现。
第三道坎是阅读。AI时代成长起来的程序员，很多人已经不太习惯读长文档了。他们习惯的是“我问你答”。但真实的开发场景里，你要读的是官方文档、RFC、源码、别人的代码。这些东西没有AI帮你总结，你得自己啃。啃文档的能力，决定了你能不能在一个陌生的技术领域里独立站稳。
还有一个更隐蔽的问题。AI让“从零到一”的过程变得太容易了，容易到很多人跳过了“理解”这一步。他们拿到一段能跑的代码，就默认自己懂了。但代码能跑和你知道它为什么能跑，是两回事。哪天业务变了，需求改了，AI给的新代码跟旧代码打架，你就得自己判断该保留什么、改什么、删什么。这个判断力，AI给不了你。
当然，也不是所有新一代程序员都这样。我认识几个刚毕业一两年的，他们用AI，但用得很有分寸。AI帮他们省掉的是查语法、写样板代码的时间，省不掉的是理解业务、设计方案、排查问题的过程。他们脱离AI也能做，只是慢一些。慢不是问题，慢说明你知道每一步在干什么。
真正危险的是另一类人。他们离开AI就完全动不了。不是不会写代码，是不知道从哪里开始。需求摆在面前，第一反应是打开聊天窗口，而不是打开编辑器。这种状态，本质上不是“用AI提高效率”，是“把思考外包给了机器”。机器能帮你写，但机器不知道你要什么。你要什么，只有你自己知道。
所以回到那个问题：脱离AI，新一代程序员还能不能独立完成开发？答案取决于你怎么定义“独立完成”。如果只是写一个能跑的东西，很多人可以，因为AI已经帮他们把路铺好了。但如果是从需求到上线、从设计到维护的全流程，能独立扛下来的人，比表面上看起来的要少。
这不是AI的错。AI只是把一个问题暴露得更明显了：编程这件事，到底是在学工具，还是在学怎么解决问题。工具会变，今天用AI，明天可能用别的。但解决问题的能力，是长在人身上的，AI拿不走。
