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

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分
一个好的提示词的目的是为了对抗Token生成的随机性，让大模型更好的按照自己的意愿来完成任务。

提示词载体

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

提示词结构-CO-STAR结构

一个好的提示词应该符合CO-STAR结构，新加坡政府组织的首届 GPT-4 提示工程大赛的获奖提示词框架。一条提示词要包含如下模块：

C：context 上下文要做事的背景信息
O：Objective 目标明确要实现什么目标
S：Style 风格写作风格
T：Tone 语气输出的语气
A：Audience 受众输出的受众，会根据受众理解能力调整输出
R：Response 响应规定输出的格式，JSON、专业报告等

现在也有很多提示词框架来帮助我们输出更好的提示词，比如LangGPT，全称是Language For GPT like llm，创作者是中国的提示词布道师李继刚；他的核心理念就是将复杂任务分解成结构化的指令，举一个例子。

<role>你是一位专业的中英双语翻译专家
</role><task>将用户输入的文本在中英文之间互译
</task><rules>- 保持原文的意思和语气- 翻译要自然流畅- 专业术语需准确翻译- 如遇到歧义词，提供多种可能的翻译
</rules><workflow>1. 分析源文本的上下文和语境2. 进行翻译3. 校对和优化译文4. 对专业术语或歧义处提供解释说明
</workflow>

提示词模块

以LangGPT为例子，模块按需组装，常见模块：

role：设定AI助手的专业背景和行为模式，明确特定场景
task：具体执行的任务，原始需求
constraints：对内容输出的限定条件
global：定义贯穿整个会话的全局变量

举一个例子

<global>$style = "有美感"$language = "中文"$topic = "爱情"
</global><role>你是一位经验丰富的浪漫主义诗人
</role><task>撰写一首关于{$topic}的诗歌
</task><constraints>- 字数限制: 200词- 风格要求: {$style}  - 语言: {$language}
</constraints>

提示词内容

模块内容本身也可以是多种载体，以技术写作为例：

<global>
$style = "专业简洁"
$length = "中等"
$format = "markdown"
</global><role>
你是一位经验丰富的技术写作专家，擅长{$style}风格写作
</role><task>
创建技术文档和教程
</task><constraints>
- 文章长度: {$length}
- 输出格式: {$format}
- 语言: 中文
</constraints><workflow>
1. 分析需求阶段:IF 用户提供主题:分析主题关键点ELSE:请求用户明确主题END IF2. 内容规划阶段:- 创建大纲- 确定重点内容- 设计示例代码3. 写作阶段:FOREACH 章节 IN 大纲:- 撰写内容- 添加示例- 进行解释END FOREACH4. 审查阶段:- 检查专业术语使用- 确保格式统一- 优化表达方式
</workflow><output_format>
# {标题}
## 概述
{概述内容}## 主要内容
{详细内容}## 示例
{示例代码和说明}## 总结
{关键点总结}
</output_format>