程序员正在放弃阅读自己代码的权利

Cursor 刚发布了一份报告基于两年、数万名用户的真实行为数据。Gergely Orosz 在 Pragmatic Engineer 上做了解读。看完之后我久久不能平静。不是因为模型又强了不是因为哪家公司又融资了而是因为数据里藏着一个我完全没预料到的转变程序员们正在集体放弃阅读自己代码的权利。说危言耸听我查了三遍。不是危言耸听。数据AI 补全率两年翻了四倍Cursor 的用户数据背后是一条清晰的行为曲线。下图来自报告中的关键指标描绘了 AI 代码补全率在两年时间里的演进轨迹这意味着什么意味着你在编辑器里看到的代码越来越大面积不是你逐行写出来的而是模型吐给你的。你按下 Tab 的那一刻你信任它。问题是信任不等于理解。过去我们写代码是从需求到逻辑到语法一层一层自己搭建的。即使有 IDE 补全补全的是函数名和参数不是整段逻辑。你的大脑始终握着方向盘。现在AI 直接给你一段能跑的实现。你扫一眼觉得没问题accept。下一行再扫一眼再 accept。一小时后回看自己的 diff你自己都说不清这段代码里哪几行是你想的哪几行是模型给的。这不是效率的问题是认知主权的问题。数据程序员的日常正从创作滑向审核Cursor 报告里最触目惊心的一个数字大量开发者表示他们花在阅读和审查 AI 生成代码上的时间已经超过了从零写代码的时间。我们用一组对比来看这件事意味着什么这意味着程序员的日常正在从创作滑向审核。这听起来像程序员版的内容农场——AI 生产人做校对。但这里有个致命区别。内容做校对你至少能看懂文字。代码做校对你连自己在审什么都不知道。我见过这样的场景一个资深工程师跑了一段 AI 生成的代码发现 bugdebug 半小时没找到原因最后发现是 AI 引入了一段他根本不认识的模式。不是因为代码难是因为他从未真正理解过这段代码——因为它压根不是他写的。Gergely 的解读里最让我后怕的不是数据本身而是一个隐含的推论当 AI 补全率达到某个阈值人类会从写代码的人变成看代码的人。但如果你连自己生成的代码都不读了你还算会写代码吗两种用法辅助 vs 放弃这里要区分两件事。让 AI 辅助写代码和放弃阅读代码是两回事。Cursor 的数据揭示的正是后一种用法在大规模蔓延。为什么会这样因为太诱人了。写业务代码本身就是累的。需求永远在变框架永远在更新技术债永远在积累。当 AI 说我可以替你写对任何一个被 deadline 追着跑的人都是无法抗拒的诱惑。但代价是隐性的。它不会立刻让你出 bug也不会立刻让你被裁。它只会一点一点侵蚀你理解系统的能力直到有一天你发现自己维护的项目里90% 的代码不是自己写的——甚至连自己能不能维护你自己都没底气。隐形危机初级工程师的学习通道正在消失这带来的第二个问题是初级工程师的危机。过去初级工程师靠读别人的代码来学习。现在当整个团队的代码风格、命名习惯、架构选择都越来越像 AI 统一风格一个新人从代码里读到的经验会越来越少。他会失去最重要的学习通道——通过阅读真实代码来建立工程直觉。这不是 AI 的错。AI 是中性的工具。错的是我们把工具当成了替代。怎么办三条底线那该怎么办我想了三个方向。第一刻意保留手写代码的比例。不是不用 AI而是告诉自己核心逻辑必须自己先写出来AI 只能优化不能替代。给自己设一条线跨不过去。第二把读懂 AI 代码当成正式工作。不是扫一眼就 accept而是逐行审查问自己这行为什么这样写有没有更好的方式如果我自己写我会怎么写审得够痛才真正拥有这段代码。第三定期回顾。每周抽 30 分钟打开自己这一周合并的代码从头到尾读一遍。如果你读着读着发现自己有看不懂的地方停下来查清楚再合上编辑器。这一步的价值远超你想象。Cursor 的报告不是终点是信号。它在告诉我们一个行为正在发生大规模、不可逆。问题是——你要做那个被信号推着走的人还是做那个停下来说等一下我还没完全同意的人代码最终是你的。你愿意放弃读懂它的权利吗