AI 向左，前端向右？

AI 降低的是写代码的成本，不是交付结果的成本。真正开始贬值的，不是前端这个岗位，而是“只把自己定义成代码实现者”的那种工作方式。

618 那天，我们团队有位同学离职了。

他是我花了不少力气从上一家公司争取来的优秀工程师，也是几个 Apache 顶级开源项目的 Committer，在社区里有一定影响力。聊到离职原因时，除了个人原因，他提到一句话，让我印象很深：

“AI 时代，做前端还有前途吗？”

这句话让我很受触动。

过去三年，AI 替代人类工作的论断时常成为热门话题，大厂工程师因 AI 被优化的报道也常见诸报端。但在我身边，真正因为 AI 带来的焦虑而主动提出离职的，这还是第一个。

回想起来，变化确实来得太快。刚做工程师那几年，我的经理经常给我讲乔布斯深夜打电话讨论产品字体细节的故事；我们也时常为 iOS 上一两个像素的对齐问题反复打磨、加班修正。可现在，那些我们曾经愿意为之倾注心力的细节、效果和呈现，似乎正在被 AI 迅速抹平。

所以，我知道这不是一个人的顾虑，它代表了一部分前端工程师这两年的共同焦虑。

我想分享一下自己粗浅的思考：

为什么这种焦虑可以理解，为什么不必过度焦虑，以及工程团队接下来真正该往哪里迁移。

焦虑，因为前端离变化最近

这种焦虑完全可以理解。

每一次技术范式切换，前端和客户端往往都是工程团队里更早感受到震荡的一群人。因为它离用户最近，也最容易被新的交互方式重新定义。

互联网时代如此。
移动互联网时代如此。
今天的 Vibe Coding 和 AGI 时代也是如此。

所以，前端的焦虑再正常不过。它说明你离变化足够近。而且很多时候，前端本来就是变革风暴的中心：想想移动互联网最激烈的那几年，各家厂商按季度产出 App，按周、甚至按天更新版本，有多少人还记得凌晨往app store提交审核时的紧张与压力?

所以我觉得，“前端没有前途”的结论，还太早了。

真正变化的，不是前端有没有价值，而是价值在迁移

过去，前端的核心价值很大一部分来自“把东西做出来”。

页面能不能还原，交互能不能落地，体验顺不顺，这些事情决定了前端岗位的重要性。

但今天，AI 正在快速压低“写代码”这件事本身的成本。

很多原来需要工程师一点点敲出来的东西，现在几轮对话就能生成一个像样的雏形。

这时候，如果前端工程师还只是把自己理解成一个功能实现者，焦虑就会越来越强。

因为 AI 最先压缩的，恰恰就是纯实现层的价值。

但我在组织内部也看到另一面。

有一些原本做前端的同学，反而在这轮转型里跑得很快。原因不是他们比别人更会写代码，也不只是更会用 AI，而是他们开始把自己的位置，从“功能实现者”转成了“业务问题解决者”。

以我们构建的 codemarrs 内部协作平台为例，主要贡献者就是两位前端团队的工程师。技术上，他们完成了前后端、测试、部署上线的整套工作，两个多月写下 50 余万行代码，边拿反馈边迭代；业务上，他们把客户、销售、CSM、产品和研发串成了一整套工作流，让这个平台逐步成为公司的核心协作平台。

他们关心的，不再只是页面做完没有，而是：

问题有没有定义清楚；
方案有没有把数据、流程、交互和交付串起来；
最后做出来的东西，能不能真的在客户环境里解决问题。

这也是我越来越明确的一个判断：

AI 时代，前端的价值会从“写代码”，迁移到“定义问题和交付结果”。

代码会越来越便宜，但判断和结果会越来越贵

写代码不会消失。

但它正在从核心能力，慢慢退回基础能力。

以后真正拉开差距的，不再是谁写得更快，而是谁更知道该写什么、为什么写，以及写完之后如何真的跑起来。

这背后，其实也是工程角色的一次迁移。

工程师的工作，正在从“亲手完成每一步执行”，转向另一种角色：设计环境、管理约束、构建反馈回路，让 Agent 可以稳定地长程工作。

如果借用最近更流行的一些说法，这背后其实就是 Harness Engineering 和 Loop Engineering。

以后能持续、稳定地用好 AI，靠的不是灵感，靠的是工程化。

以前，软件工程最佳实践是为了约束人。
今天，它也开始用来约束 Agent。

规范要不要进仓库，测试能不能自动验证，错误能不能快速诊断，流程有没有反馈闭环，这些事情以前重要，今天只会更重要。

因为 AI 可以帮你生成代码，但不能替你对结果负责。

工程团队真正需要迁移的，是自己的定位

当然，这也不意味着所有领域都适合用 AI 来重构。

至少到今天，一些对稳定性、复杂协作和工程可靠性要求极高的工作，依然依赖人。不管是亲自下场，还是站在回路之上设计约束与反馈，人都还在关键位置上。

产品的品味、体验的判断、复杂取舍下的决策，也依然掌握在工程师、设计师、产品经理这些真正对结果负责的人手里。

所以，真正需要迁移的，不是某个前端框架，而是工程团队看待自己的方式。

过去我们常说，懂技术不等于懂业务。

到了 AI 时代，这句话不但没过时，反而变得更尖锐了。

以后真正稀缺的，不只是把需求翻译成代码的人，而是能把现场问题翻译成产品约束、工程任务，甚至 Agent 可执行流程的人。

谁离业务更近，谁更理解真实上下文，谁就更有机会成为新的价值节点。

接下来，工程团队大概要往三个方向走

第一，提高自己对产品的把控能力。
不只是关注实现，还要理解体验、结构和品味。

第二，把工作做得更深入、更完整。
不是把代码写完就结束，而是对交付结果负责。

第三，往前线迈进。
离真实业务和客户现场更近，理解问题是怎么发生的，也理解结果到底有没有解决问题。

真正有前途的，未必是某个具体端的工程师。

真正有前途的，是那些离业务更近、能驾驭 AI、也能对结果负责的工程师。

为什么我们会去做 DecideX

这也是为什么，我们会开始认真去做 DecideX，观远新一代的“AI 决策智能平台”。

在我们看来，DecideX 不是一个单纯提升编码效率的工具，而是一个面向企业经营决策场景的 AI 决策智能平台。

它的意义，不只是把 AI 接进企业，而是把企业已经沉淀的数据、知识、规则和流程真正调动起来，让 AI 从“会说”走向“会分析、会判断、会推动行动”，帮助组织形成从洞察到决策、再到执行的闭环。

关于 DecideX 的完整介绍，也可以参考我同事的一篇公众号文章：《DecideX：一个企业决策智能体的诞生故事》。

结尾

所以，如果今天还有前端同学在问，AI 时代自己该往哪里走，我的答案不是“别焦虑”，也不是“赶紧转行”。

而是三句话：

先把自己从功能实现者，变成价值创造者。
再把自己从代码产出者，变成结果交付者。
最后，尽可能往真实业务和客户现场再走近一步。

AI 向左，前端未必要向右。

更准确地说，前端和工程团队需要往更深处走，往结果走，往业务走。

---

文末推荐

最后，想推荐一本最近很适合工程师读的小书：《写给大家的设计书》。

推荐它，不只是因为在 AI 时代，工程师如果想提升自己对产品的品位，设计一定是一个绕不过去的落脚点。也因为这本书足够浅显、足够直接，能用很短的篇幅把设计里最基础、也最常被忽略的几个原则讲清楚。

而且，书里有一句话，我印象很深：

“对比一定要强烈。如果两个元素虽然不同，但是区别不大，这时候就不是对比了，而是冲突。干脆让它们截然不同。”

表面上，这是在讲设计。讲标题、字体、版式、颜色，不要停留在“有点不一样”却又不够明确的状态里。因为那不是对比，而是冲突。

但往深处看，它其实也像一句很朴素的人生道理。

很多糟糕的设计，不是因为没有选择，而是卡在“差一点”和“又没差开”的中间地带。很多产品和组织的问题，其实也一样。方向不够清晰，边界不够清晰，优先级不够清晰，看起来像折中，最后往往变成内耗和冲突。

所以对工程师来说，这本书最珍贵的地方，不只是教你把东西做得更好看，而是提醒你两件事：品位不是天赋，判断也可以训练；如果真的想做出影响力，就不要停留在小修小补里，而要主动跳出“只是前端”或“只是工程师”的思维，在更大的问题上拉开差距。到了 AI 时代，这种能力反而会变得更重要。

Let’s make a BIG difference.