从 DeepSeek 看 25 年的前端趋势

jinchanchan

最近DeepSeek R1爆火。有多火呢？连我爷爷都用上了，还研究起提示词工程来了。

大模型不断发展对我们前端工程师有什么长远影响呢？本文聊聊25年前端会有的一个小趋势。

<顺便吆喝一句，技术大厂捞人，前后端测试都有，感兴趣试试~>

模型进步的影响

像DeepSeek R1这样的推理模型和一般语言模型（类似Claude Sonnet、GPT-4o、DeepSeek-V3）有什么区别呢？

简单来说，推理模型的特点是：「推理能力强，但速度慢、消耗高」。

他比较适合的场景比如：

Meta Prompting（让推理模型生成或修改给一般语言模型用的提示词）

路径规划

等等

这些应用场景主要利好AI Agent。

再加上一般语言模型在生成效果、token上下文长度上持续提升。可以预见，类似Cursor Composer Agent这样的AI Agent在25年能力会持续提升，直到成为开发标配。

这会给前端工程师带来什么进一步影响呢？

一种抽象的理解

我们可以将AI Agent抽象得理解为「应用压缩算法」，什么意思呢？

以Cursor Composer Agent举例：

我们传入：

描述应用状态的提示词

描述应用结构的应用截图

AI Agent帮我们生成应用代码。

同样，也能反过来，让AI Agent根据应用代码帮我们生成「描述应用的提示词」。

从左到右可以看作是「解压算法」，从右往左可以看作是「压缩算法」。

就像图片的压缩算法存在「失真」，基于AI Agent抽象的「应用压缩算法」也存在失真，也就是「生成的效果不理想」。

随着上文提到的「AI Agent」能力提高（背后是模型能力提高、工程化的完善），「应用压缩算法」的失真率会越来越低。

这会带来什么进一步的影响呢？

对开发的影响

如果提示词（经过AI Agent）就能准确表达想要的代码效果，那会有越来越多「原本需要用代码表达的东西」被用提示词表达。

比如，21st.dev[1]的组件不是通过npm，而是通过提示词引入。

相当于将「引入组件的流程」从：开发者 -> 代码

变成了：开发者 -> 提示词 -> AI Agent -> 代码

再比如，CopyCoder[2]是一款「上传应用截图，自动生成应用提示词」的应用。

当你上传应用截图后，他会为你生成多个提示词文件。

其中.setup描述AI Agent需要执行的步骤，其他文件是「描述应用实现细节的结构化提示词」

这个过程相当于「根据应用截图，将应用压缩为提示词」。

很自然的，反过来我们就能用AI Agent将这段提示词重新解压为应用代码。

这个过程在25年会越来越丝滑。

这会造成的进一步影响是：越来越多前端开发场景会被提炼为「标准化的提示词」，比如：

• 后台管理系统
• 官网
• 活动页
  

前端开发的日常编码工作会越来越多被上述流程取代。

你可能会说，当前AI生成的代码效果还不是很好。

但请注意，我们谈的是「趋势」。当你日复一日做着同样的业务时，你的硅基对手正在每年大跨步进步。

总结

随着基础模型能力提高，以及工程化完善，AI Agent在25年会逐渐成为开发标配。

作为应用开发者（而不是算法工程师），我们可以将AI Agent抽象得理解为「应用压缩算法」。

随着时间推移，这套压缩算法的失真率会越来越低。

届时，会有越来越多「原本需要用代码表达的东西」被用提示词表达。

这对前端工程师来说，既是机遇也是挑战。