企业官网建设流程全解析

Cursor 刚发布了一份报告，基于两年、数万名用户的真实行为数据。Gergely Orosz 在 Pragmatic Engineer 上做了解读。看完之后，我久久不能平静。不是因为模型又强了，不是因为哪家公司又融资了，而是因为数据里藏着一个我完全没预料到的转变：程序员们正在集体放弃阅读自己代码的权利。说"危言耸听"？我查了三遍。不是危言耸听。

数据：AI 补全率两年翻了四倍

Cursor 的用户数据背后，是一条清晰的行为曲线。下图来自报告中的关键指标，描绘了 AI 代码补全率在两年时间里的演进轨迹：

这意味着什么？意味着你在编辑器里看到的代码，越来越大面积不是你逐行写出来的，而是模型吐给你的。你按下 Tab 的那一刻，你信任它。问题是：信任不等于理解。过去我们写代码，是从需求到逻辑到语法，一层一层自己搭建的。即使有 IDE 补全，补全的是函数名和参数，不是整段逻辑。你的大脑始终握着方向盘。现在，AI 直接给你一段能跑的实现。你扫一眼，觉得没问题，accept。下一行，再扫一眼，再 accept。一小时后回看自己的 diff，你自己都说不清这段代码里哪几行是你"想"的，哪几行是模型"给"的。这不是效率的问题，是认知主权的问题。

数据：程序员的日常正从"创作"滑向"审核"

Cursor 报告里最触目惊心的一个数字：大量开发者表示，他们花在"阅读和审查 AI 生成代码"上的时间，已经超过了"从零写代码"的时间。我们用一组对比来看这件事意味着什么：

这意味着程序员的日常正在从"创作"滑向"审核"。这听起来像程序员版的内容农场——AI 生产，人做校对。但这里有个致命区别。内容做校对，你至少能看懂文字。代码做校对，你连自己在审什么都不知道。我见过这样的场景：一个资深工程师跑了一段 AI 生成的代码，发现 bug，debug 半小时没找到原因，最后发现是 AI 引入了一段他根本不认识的模式。不是因为代码难，是因为他从未真正理解过这段代码——因为它压根不是他"写"的。Gergely 的解读里，最让我后怕的不是数据本身，而是一个隐含的推论：当 AI 补全率达到某个阈值，人类会从"写代码的人"变成"看代码的人"。但如果你连自己生成的代码都不读了，你还算"会写代码"吗？

两种用法：辅助 vs 放弃

这里要区分两件事。"让 AI 辅助写代码"和"放弃阅读代码"是两回事。

Cursor 的数据揭示的，正是后一种用法在大规模蔓延。为什么会这样？因为太诱人了。写业务代码本身就是累的。需求永远在变，框架永远在更新，技术债永远在积累。当 AI 说"我可以替你写"，对任何一个被 deadline 追着跑的人，都是无法抗拒的诱惑。但代价是隐性的。它不会立刻让你出 bug，也不会立刻让你被裁。它只会一点一点侵蚀你"理解系统"的能力，直到有一天你发现，自己维护的项目里，90% 的代码不是自己写的——甚至连自己能不能维护，你自己都没底气。

隐形危机：初级工程师的学习通道正在消失

这带来的第二个问题是：初级工程师的危机。过去，初级工程师靠"读别人的代码"来学习。现在，当整个团队的代码风格、命名习惯、架构选择都越来越像 AI 统一风格，一个新人从代码里"读"到的经验会越来越少。他会失去最重要的学习通道——通过阅读真实代码来建立工程直觉。

这不是 AI 的错。AI 是中性的工具。错的是我们把工具当成了替代。

怎么办：三条底线

那该怎么办？我想了三个方向。

第一，刻意保留"手写代码"的比例。不是不用 AI，而是告诉自己：核心逻辑必须自己先写出来，AI 只能优化，不能替代。给自己设一条线，跨不过去。

第二，把"读懂 AI 代码"当成正式工作。不是扫一眼就 accept，而是逐行审查，问自己：这行为什么这样写？有没有更好的方式？如果我自己写，我会怎么写？审得够痛，才真正拥有这段代码。

第三，定期回顾。每周抽 30 分钟，打开自己这一周合并的代码，从头到尾读一遍。如果你读着读着发现自己有看不懂的地方，停下来，查清楚，再合上编辑器。这一步的价值，远超你想象。

Cursor 的报告不是终点，是信号。它在告诉我们：一个行为正在发生，大规模、不可逆。问题是——你要做那个被信号推着走的人，还是做那个停下来说"等一下，我还没完全同意"的人？代码最终是你的。你愿意放弃读懂它的权利吗？