当前位置：首页 > news >正文

面向AI 的前端发展及初识大模型

news 来源：原创 2025/6/22 17:06:14

AI带来的开发范式迁移

随着AI的涌现，对前端的发展也有着非常大的影响，总结过去前端的发展路径，目前应该属于又一次的大规模的开发范式迁移阶段。上一个阶段是从jquery到React/Vue/Angular迁移（jquery之前的就不讨论了）。每一次的开发范式迁移不仅仅是技术上的升级，也是开发思维的转变。这里简单回顾一下上一次的开发范式迁移对前端的影响。

上一次的开发范式迁移：从 jQuery 到 React/Vue

范式	jQuery（命令式编程）	React/Vue（声明式编程）
核心思想	手动操作 DOM，逐步更新 UI	声明 UI 结构，自动管理 DOM
数据管理	依赖全局变量或手动更新	组件内部状态管理（React `useState`，Vue `reactive`）
事件绑定	`$('#btn').on('click', function() {...})`	`<button @click="handleClick">`（Vue）或 `onClick={handleClick}`（React）
组件化	需要手动拆分 HTML + JS 逻辑	组件化开发（React 组件、Vue 组件）
性能优化	直接操作 DOM，易造成性能瓶颈	虚拟 DOM + 计算属性，减少不必要的 DOM 变更
代码组织	面向过程，逻辑分散	组件驱动，逻辑集中

什么是开发范式的迁移

用一张图来说明什么是开发范式的迁移。
在这里插入图片描述

目前我们应该正处于第二次的开发范式迁移的阶段，随着AI的出现，也涌现了一批新的开发技术，比如：v0( Vercel 团队推出，主要用于 React 和 Next.js 项目。
通过 AI 生成 UI 组件，帮助开发者快速搭建页面。)还有bolt。
那以后前端该怎么发展呢？我认为目前有两个方向，一个是制造AI工具的前端，还有一个是使用AI工具的前端如下图所示：
在这里插入图片描述

制造AI工具的前端

要成为这一类角色有两个前提，一个是本身具有很高的前端造诣，另一个是很熟悉相关的AI技术，可以把AI技术很好的带入到前段这个领域，在前端各个流程中能有效的把AI引入进来赋能，也有可能会因为AI的引入而改变目前的工作流程，因为AI或者说大模型的应用是专业的知识 + 特定的领域 = 最佳实践（这个后续会聊，会使用RAG实践一个私有组件库生成业务组件的示例）

使用AI工具的前端多才

这个就是上图中说的使用AI工具的前端，这里的“多才”指的是以前端技能为核心能力，同时掌握与前端相邻以及平行工种的工作技能。
相邻：UI、测试、后端
平行工种：其他段的前端

因为目前国内的现状是前端碎片化比较严重，有实力的公司会组件大前端团队，而一般的公司为了节约成本就会使用跨端方案，比如UniApp、Taro、React Native、Flutter;而由于各端的业务逻辑大体一致，实现某一端之后可以尝试使用AI将代码转为其他段的代码，只要AI的转换成本比调试夸端的成本低那就可行。

理解大模型

作为大模型的使用者，我们不用太关心内部的实现细节，我们完全可以把大模型当做黑盒，关注的是输入和输出。

大模型的对话角色

System：系统角色，通常代表大模型的底层运行环境、框架或规则设定等。它负责管理和协调模型的整体运行，包括初始化模型参数、设置运行条件、分配计算资源等
Assistant：大模型在与用户交互过程中所扮演的主要角色。它基于模型所学到的知识和算法，对用户输入的信息进行理解、分析和处理，然后生成相应的回答、建议、内容等，以回应用户的请求
User：即使用大模型的人或其他主体（如其他软件系统等）。用户通过输入文本、指令、数据等信息与大模型进行交互，向模型提出问题、请求生成内容、寻求建议或进行其他类型的任务。
Tool：在大模型的应用场景中，Tool 通常指的是模型可以调用的外部工具或功能模块。这些工具可以是专门用于特定任务的软件组件、算法库、数据库查询接口、知识图谱查询工具等，用于辅助模型更好地完成用户的任务。

Token

我们输入的文本需要被转换成大模型可理解的符号，这个符号就是Token，这里需要注意，Token和我们输入的文本字符和单词不是一一对应的关系，不同语言Token的表达效率也是不一样的，比如同样一句话，中文可能是10个Token，日语可能就是12个Token，而大模型一般都是按照Token来计费的，所以我们因该用“更少的Token去表达相同的意思”。另外不同大模型他们的分词器不一样，所以同样一句话他们的Token也是不一样的。比如这里通义千问分词器和openAI分词器。我查了一下文档，以open AI为例子，1个token约等于4个英文字符。100个token大约等于75个英文单词。

大模型几个重要的参数

一般大多数的大模型都有 Temperature、Top_p、frequency_penalty、presence_penalty；用来
控制输出的随机性、创造性和重复性。这几个参数作用如下：

参数	作用	低值效果	高值效果
Temperature（温度）	控制随机性	确定性高，回答保守	更随机，适合创意内容
Top_p（核采样概率）	控制候选词范围	只选最可能的词，保守	更多候选词，创造性更强
Frequency_penalty（频率惩罚）	减少重复词	容易重复同一词	避免重复，表达更丰富
Presence_penalty（存在惩罚）	鼓励新词出现	词汇重复较多	引入更多新概念、新词汇

举个例子，比如此时我输入了：“我喜欢吃” → 预测下一个token
可能的token及其概率：

“饭” (0.3)
“菜” (0.2)
“水果” (0.15)
“零食” (0.1)

Temperature

如果此时Temperature设置的是低温（取值低），把就会强化高概率选项，减少多样性，此时预测下一个值为‘饭’的概率就高。反之如果是高温取值，就会使概率分布平缓，此时各个值的概率就比较平均，增加多样性。

Top_p

设定累积概率阈值，从高到低概率依次选择的token，直到总和达到设定值。比如当Top_p=0.75时，选择：“饭”(0.3) + “菜”(0.2) + “水果”(0.15) + “零食”(0.1) = 0.75那其他选项被排除了。

Frequency Penalty 概率惩罚

高值是降低已出现token的再次出现概率，迫使模型选择新的表达方式。
上述例子中，我喜欢吃, 如果"喜欢"已经出现过：
原始概率：“喜欢”(0.3) → 惩罚后：(0.1) (降低了”喜欢“的概率)
-> 我喜欢吃饭，我也爱吃烧烤。（可能使用爱吃，而不是喜欢字眼）

Presence Penalty 存在惩罚

高值是为了降低已出现主题的相关token概率
还是上面这个例子，原始句子为 我喜欢吃xx如果被推测为我喜欢吃饭那已经出现过食物相关的主题，就会转向新的主题，比如下一句预测可能是我喜欢吃放，周末常去夜市撸串（引入周末和夜市场景）

提示词

在我们使用大模型整体上的流程是下面这样，首先我们需要选择一个合适的大模型，在各个领域都有各个领域合适的大模型。比如擅长处理图片的，擅长处理编程的。
随后我们就需要用专业的知识来明确我们的需求。随后我们需要使用提示词来优化我们的输入最后得到比较高质量的输出。如果用一个公式来表达的话大概是这样：特定领域内 + 用专业的知识明确需求 + 好的提示词 = 高质量的输出
在这里插入图片描述

上面聊到，对于大模型的使用者而言，我们可以把大模型当做是黑盒，只需要关注输入和输出即可。对于输入，根据对话角色的分类，也包括四类提示词：

System Prompt
User Prompt
Assistant Prompt
Tool Prompt

什么是提示词工程

所谓的提示词工程就是通过不断的优化输入，提升模型的输出质量，这里的质量包含三个维度：

正确性维度：返回信息的准确度和可信度，白话文就是让人感觉”说的对“
稳定性维度：在不同场景和时间下产生可预期的一致表现，白话文就是让人感觉"靠得住"
质量维度：输出内容的专业、完整和有价值白话文就是让人感觉"说到点子上"

一个好的提示词可以最大程度的发挥出大模型的能力，但不可能超越大模型本身的能力，举个例子：
GPT3.5 能力5分 + 技巧3分 = 8分
GPT4 能力10分 + 技巧2分 = 12分

提示词载体

在特定场景下一个好的载体非常重要，有利于提升模型的逻辑理解能力。举个例子，就和我们写文章一样，文章也有很多载体，比如散文、诗歌、白话文。常见提示词载体：自然语言、XML、MD、JSON、伪代码…
选好载体之后就是要写我们的提示词。还是对比写文章一样：
在这里插入图片描述
不同场景下不同的提示词载体有不同的优势。比如普通用户就比较适合自然语言，直接把自己的诉求输入给大模型，然后得到大模型的输出，这样门使用槛比较低。而比如markdown结构性非常强，天生就是用来表达文章结构的。json的结构化非常好，被用做数据交换的格式。而xml结构清晰，层次分明，有利于程序的解析。