从 DeepSeek 看25年前端的一个小趋势

从 DeepSeek 看25年前端的一个小趋势

最近 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年会越来越丝滑。

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

• 后台管理系统

• 官网

• 活动页