先讲一个真实的故事。
我认识的一个大三学生，计算机专业，上学期刚修完数据结构。这学期他用Cursor写课程作业。一个图书管理系统的后端，以前至少要写两三周，他两天就交上去了。老师给了高分。
然后老师做了一个附加测试：把Cursor关掉，让他用记事本当场写一个二分查找。他卡了十分钟，最后还是写错了。
这不是个例。我最近跟几个在一线互联网公司带新人的朋友聊，他们说了一个共同的感受：这两年的实习生，代码产出量比以前大得多，但是对代码的理解深度普遍变浅了。你问他为什么这里用线程池而不是协程，他答不上来。你让他排查一个并发bug，他第一反应是把bug日志贴给AI。
AI编程工具正在悄悄改变程序员的成长路径。这件事的好处很明显——效率提升了，重复劳动减少了。但坏处正在暗中累积：新手程序员正在经历一场“能力断崖”。
一、从“写代码”到“改代码”的位移
在AI编程工具出现之前，一个新手学编程的路径是固定的：看书、看文档、自己敲。从第一行“Hello World”到能独立写一个完整的模块，中间要经历成百上千次报错、调试、查资料、再调试。这个过程很痛苦，但正是这些痛苦，让人真正理解了指针、内存、并发、边界条件。
现在不一样了。一个新手打开Cursor，输入“用Python写一个爬虫，抓取某个网站的文章标题和发布时间”，十几秒后，几十行代码就出来了。他复制粘贴，运行，发现报错。他把报错信息贴回Cursor，AI告诉他“缺少requests库，请先安装”。他装上，再跑，通了。
整个过程，他可能都没有认真读过那几十行代码。他不知道requests.get()的超时参数默认是多少，不知道BeautifulSoup的find_all返回的是什么类型，不知道异常处理被AI默认省略了。他只是完成了一个任务，却没有习得任何可以迁移的能力。
这不是学习，这是代劳。
更隐蔽的问题是：当你用AI写代码的时候，你实际上从“生产者”变成了“审阅者”。审阅一个已经能跑的代码，比从零开始写要容易得多。你看一眼，觉得逻辑差不多，就过了。但你不知道AI有没有在某些边界条件下偷偷埋下bug，你不知道它的算法选择是不是最优的，你不知道它有没有引入不必要的依赖。
你失去了对代码的掌控感。而掌控感，恰恰是工程师最核心的能力。
二、bug来临时，谁去调试？
写代码只是编程的一半。真正的功力体现在调试和排错上。
我见过一个案例：一个团队用AI生成了一个数据处理模块，上线后跑了三天，突然在某一个特定数据上崩溃了。团队里的两个 junior 开发查了一整天，每查一步就把日志贴给AI，AI给出一个猜测，他们照着改，再跑，还是崩。最后是一个 senior 花了一个小时，从堆栈跟踪一步步倒推，发现是AI生成的一段并发代码里，一个共享变量没有被正确地加锁。
这个bug，AI自己查不出来。因为AI没有在你那个具体环境里跑过代码，不知道你的数据特征，不知道你的部署配置。它能做的只是根据通用的错误日志给出“可能性最高的几个原因”。真正的调试，需要对系统有全局理解，需要知道哪块代码是谁写的、为什么这么写、改这里会不会影响那里。这些上下文，AI没有。
新手如果用AI写代码，但从来没有亲手调试过一个棘手的bug，他的调试能力就会停留在“把错误贴给AI”这个层面。等到有一天，AI也解决不了那个bug的时候，他就彻底卡住了。
三、代码可以生成，但技术债务不会消失
AI生成代码的速度很快。快，有时候是最大的风险。
以前一个功能要写一周，程序员会认真设计数据结构、考虑扩展性、写注释。现在用AI半小时就出来了，谁还愿意花时间设计？结果是：代码堆得飞快，但架构一塌糊涂。重复逻辑到处都是，命名规则混乱，错误处理要么缺失要么不一致，性能问题被埋在各个角落里。
这些技术债务，当时看不出来。但六个月后，当需求变更、需要修改那段代码的时候，噩梦就开始了。读不懂、不敢改、一改就崩。重构的成本远比当初用AI写的成本高得多。
更讽刺的是，AI对技术债务的修复能力也很有限。你可以让AI“重构这个模块”，它可能会做一次不错的局部优化。但它不知道整个项目的业务边界在哪里，不知道哪段“看起来很蠢”的代码其实是专门为了兼容某个老客户的数据格式。全局性的架构决策，现在还是只能靠人。
四、这不是AI的错，是我们的使用方式出了问题
我不想把锅全甩给AI。工具本身是中性的。锤子可以盖房子，也可以砸人。AI编程工具也是一样。
问题出在两类人身上。
第一类是初学者。他们本来就不具备判断代码质量的能力。AI给他们代码，他们以为那就是正确答案。但实际上，AI生成的代码经常是“能跑但不够好”——性能不是最优，可读性一般，边界情况覆盖不全。初学者照单全收，等于在学一套有瑕疵的范例。
第二类是企业和学校。很多公司把“用了AI编程工具”当成提效的手段，但没有配套的能力培养机制。新人不写代码，只改代码，三年后他到底是三年经验，还是三个月的经验重复了十二次？学校也在迷茫，有的课程已经开始允许学生用AI写作业，但还没有想清楚怎么考核学生的底层能力。
我见过一些比较好的实践。有的团队要求：AI生成的代码，提交前必须人工逐行解释。解释不清楚的，不能合入。有的学校在考试时切换到没有AI的环境，专门考察基础算法和代码阅读能力。这些都是把AI当成工具、而不是拐杖的做法。
五、程序员真正的护城河，正在被我们主动丢弃
有人说，AI迟早会取代程序员。我不同意。但我同意一个判断：只会用AI写简单代码的程序员，会被取代。
程序员的护城河从来不是“敲键盘的速度”。是理解复杂系统的能力，是抽象建模的能力，是在混乱中做出正确权衡的能力，是在压力下调试一个诡异bug的心理素质。这些能力，没有一个是在复制粘贴AI代码的过程中获得的。
它们来自亲手写过的每一行烂代码，来自熬过的每一个通宵排查的线上事故，来自那些“为什么要这样设计而不是那样”的反复追问。这些东西，AI给不了你。
我没有任何反对使用AI编程工具的意思。我自己每天都用Cursor。但我知道我在做什么——我用它来生成那些我已经写过一百遍的样板代码，用它来帮我回忆某个冷门函数的参数顺序，用它来快速搭一个原型。我不会让它替我做架构决策，不会不经审查就合入它的代码，不会因为它能写就不再去读文档。
AI编程工具是一个放大器。它让好的程序员变得更好，但它也让懒的程序员变得更懒。
如果你是一个正在学编程的新手，我的建议很简单：关掉AI，先亲手写一千行代码。报错、调试、崩溃、重来。等你真的体会过“从零到一”的完整痛苦和快乐，再打开Cursor。那时候，你知道怎么用它，而不会被它用。