AI 编程会重演前端的“失落十年”吗？问题在去技能化

Mauro Bieg 5 月 23 日发文，提出一个对前端开发者不陌生的判断：AI 代理式编程可能正在让编程职业经历一轮“去技能化”。类似的变化，前端在过去十年已经尝过一次。

这件事有意思的地方，不在于 AI 是否马上消灭程序员岗位。原文也没有给出就业数据。它更像是在问另一个问题：当工具把复杂细节包进更高抽象层，行业拿到更快交付时，失去的是什么？

我的判断是，风险不在“工具变强”本身。风险在于，团队把“能跑”误认成“可维护”，把“会用工具”误认成“懂系统”。

前端的教训：不是 React 有罪，是能力结构被改写了

“去技能化”这个词，在劳动史里有很具体的含义：技术让半熟练劳动者接手原本需要专业技能的工作。企业因此降低成本，也会压低劳动者的议价能力。

Bieg 把这个概念放到前端史里，重点不是批判某一个框架。前端过去十年的变化，是整套框架、构建系统、组件库、包管理生态一起改变了工作方式。

早期前端并不只是“把页面写出来”。它包含语义 HTML、CSS 布局、浏览器差异、可访问性、性能、渐进增强，也包括对界面和用户测试的理解。

后来，现代前端越来越像在“面向框架编程”。浏览器变成编译目标，组件库给出默认解，脚手架处理构建细节。产出速度上去了，协作也更顺。但很多底层判断被藏了起来。

这不是说 React 单独造成了“失落十年”。React、Next.js、npm 生态、设计系统和组件库都提高了团队产能。问题是，它们也让一些人可以拼出看似可用的界面，却不理解屏幕阅读器、低端手机、慢网络和浏览器边界。

这张表里的连续性很重要。搜索和问答社区早就让懂的人更快，也让不懂的人复制出“差不多能跑”的东西。LLM 只是把这件事做得更顺滑，也更容易让人放松警惕。

主线仍是那一句：抽象层越高，越要有人懂它盖住了什么。

AI 编程更难管：它不只是抽象，还带着非确定性

AI 编程和现代前端框架有相似处。它们都降低门槛，都能加速交付，也都可能让使用者远离底层细节。

差异也很关键。框架通常是确定性的。同样的输入，大体得到同样的输出。LLM 不是编译器，提示词、上下文窗口、模型版本一变，结果就可能变。

所以，AI 更像一个会漏水的抽象层。它能省力，但不能让团队少负责。

把 AI 当“初级工程师”有一定解释力，但不能完全照搬。初级工程师会在代码评审、事故复盘和团队规范里学习。模型不会真正理解组织历史，也不会因为一次线上事故形成长期经验。

这对开发流程的影响很直接。以前复制 Stack Overflow 的答案，至少能看到来源、评论和上下文。现在代理式工具可能直接改一串文件、补测试、写提交说明。包装更完整，审查反而更容易被跳过。

这也是我不太买账“AI 写完人看一眼就行”的原因。很多问题不是肉眼一眼能看出来的。权限边界、数据处理、缓存失效、可访问性退化、性能回退，都需要明确的检查点。

原文没有证明 AI 已经大规模消灭程序员岗位。现在能判断的，是劳动定价逻辑正在变：会用 AI 的人更快，不懂系统的人也更容易交出“像样”的半成品。管理层若只看短期速度，很容易把质量成本推到维护阶段。

对开发者和技术管理者：别只问能不能用，要问哪些地方不能省

对前端和全栈开发者来说，最实际的应对不是拒绝 AI。更现实的做法，是把 AI 当加速器，而不是当资质证明。

能让 AI 写样板代码、补重复测试、整理迁移脚本、生成初版文档。但涉及核心业务逻辑、权限、支付、数据删除、依赖升级、性能预算和可访问性，不能只靠“模型说可以”。这些地方要自己读代码、跑测试、看指标。

对技术管理者来说，也不要只统计“AI 提效了多少”。更该盯三件事：谁负责审查，哪些路径必须测试，哪些质量指标不能退。

这里有一个现实约束：软件质量和商业成功并不总是强相关。很多体验糟糕、代码混乱的网站照样能赚钱。也正因为这样，质量债常常不会马上暴露。

问题会在维护时出现。新人接不住代码，性能问题没人能定位，辅助技术用户被挡在门外，依赖升级牵一发动全身。到了那一步，早期省下的时间会以更贵的方式回来。

Bieg 用包豪斯作结，这个类比是准的。包豪斯不是拒绝工业化，而是要求设计者理解材料、理解工艺，再面向量产和用户重新设计。

软件行业面对 AI，也不该退回手写一切。更好的态度是：接受工业化工具，但不放弃材料感。代码、浏览器、用户限制、运行环境，都是软件的材料。

下一步最该看清的，不是 AI 写了多少行代码，而是团队有没有把 AI 输出纳入质量流程：代码评审是否更严，关键路径是否有测试，前端是否仍有人对性能和可访问性负责。

如果这些护栏没有建立，所谓提效很可能只是把成本从开发阶段挪到维护阶段。前端的“失落十年”给过一次提醒：工具可利其事，但不能替人判断。