AI 编程的认知成本：生产力提升 vs. 精神萎缩

来自大型科技公司高管的叙述是胜利的。在 Google、Microsoft 和 Meta 等公司，领导层经常引用 AI 生成代码的惊人比例——在某些部门甚至高达 30% 到 75%——作为进入高效新时代的证明。对于 C-suite 而言，这是 "tokenmaxxing" 的胜利，即 AI agent 减少了人员编制并加速了交付周期。

然而，在企业新闻稿的背后，在那些实际编写和审查代码的工程师中，一个不同的故事正在浮现。对于许多人来说，向 AI 辅助开发的转型并非自愿的生产力飞跃，而是一种强制性的转变，正在侵蚀他们的技术技能和心理健康。

强制指令：绩效评估与 "Vibe Coding"

来自 FAANG 和其他大型科技公司的开发者最令人震惊的发现之一是，AI 的采用往往不是自发的。在几个案例中，使用 AI 工具已被明确地与绩效评估挂钩。当使用率成为衡量成功的指标时，结果往往是 "performative adoption"（表演式采用）。

正如一位 UX designer 所指出的，输出的实际质量变得次于参与 AI 生态系统的意愿。这创造了一种危险的激励结构：开发者被迫交付大量的 AI 生成代码以展示 "velocity"（速度），即使他们知道输出是有缺陷或不安全的。

"认知债务"现象

在企业压力之外，还存在着更深层、更个人的担忧："rotting brains"（大脑腐烂）的感觉。这不仅仅是对新工具缺乏热情，而是一种有据可查的认知萎缩现象。当编程的 "mechanical act"（机械行为）被外包给模型时，解决问题和进行架构推理所需的心理肌肉开始萎缩。

开发者报告了几个关键的失效点：

• 丢失心理模型： 当代码是以大块形式生成，而不是通过逐行推理得出时，维护代码库复杂心理地图的能力就会减弱。
• 技能退化： 资深工程师报告称，在依赖 LLMs 数月后，他们忘记了基础的实现细节——例如如何构建一个简单的 API。
• 审查负担： AI 可以在几秒钟内生成数千行代码，但人类审查这些代码的能力是恒定的。这导致了 "burnout by review"（因审查而精疲力竭），工程师们被海量的 pull requests 淹没，他们觉得由于能力不足或过于疲惫而无法进行适当的审计。

"我感觉我的批判性思维和坐下来对问题或设计进行推理的能力已经退化了，因为 all-knowing-dalai-llama 只需要一个问题就能给我他的看法。"

反方观点：向 "Editor" 的转变

并非所有开发者都认为这种转变是负面的。一些人认为，软件工程角色的性质正在发生演变。在这种观点看来，开发者正从 "writer"（编写者）转变为 "editor"（编辑）或 "agent manager"（agent 管理员）。

这种转变的支持者认为，AI 处理了 "boring stuff"（无聊的事）——JIRA 清理、文档检索和 boilerplate（样板代码）——从而让渡出人类来专注于更高层级的设计。对于这些开发者来说，增加的 velocity 是一个切实的利益，其价值超过了肌肉记忆萎缩的风险。一位前 CTO 指出，虽然他们在面试中因为几个月的 AI 依赖而难以应对一个基础语法问题，但他们在构建阶段的整体生产力显著提高。

即将到来的清算

人们越来越达成共识，当前的轨迹是不可持续的。行业正看到 "vibe coding" 的激增，即软件是基于 AI 输出的整体感觉而非严谨的验证。这导致了停机事故的常态化感知以及技术债务的大剧增。

正如一位开发者所说，目前的系统就像是 "使用筷子来控制火箭飞船的转向轮"。速度极快，但控制却极其不稳定。

结论：理解 vs. 外包

行业内的紧张关系目前集中在一个根本性的区别上：外包 thinking（思考）与外包 understanding（理解）之间的区别。虽然 AI 可以生成一个解决方案，但它无法灌输对 why（为什么）该解决方案有效的深层理解。

对于初级开发者，风险尤为严重。如果没有手动实现的过程中的挣扎，他们可能永远无法培养出发现 AI 经常引入的细微且灾难性的错误的直觉。行业可能很快就会面临一场 "reckoning"（清算），即 AI 生成代码的感知速度与生产系统实际稳定性之间的差距将变得无法忽视。