大家好，我卡颂。
最近两年，整个前端圈都比较焦虑，主要有两个原因：
- 经济下行造成工作不好找
AIGC对行业未来的冲击
其中第一条大环境如此，没什么可抱怨的。第二条的焦虑则更多是对未知的恐惧造成的。
换言之，大家都知道AIGC（Artificial Intelligence Generated Content，生成式人工智能）会改变行业现状，但不知道改变的方式是取代工程师还是帮助工程师？
最近，TypeChat的发布让前端未来的发展方向变得更清晰 —— 在不远的未来，AIGC将会是工程师得力的助手，而不是取代工程师。
为什么这么说呢？本文会从以下角度阐述：
- 当前
LLM（large language model，大语言模型）的问题 TypeChat是什么，他是如何解决上述问题的TypeChat的实现原理TypeChat对前端行业的影响
欢迎围观朋友圈、加入人类高质量前端交流群，带飞
LLM的问题
LLM应用最广、普及度最高的应用场景是聊天助手（比如chatGPT）。
聊天助手场景的特点是：用户输入自然语言，模型输出自然语言。
如果模型仅能输出自然语言，那他的应用场景只能局限在聊天助手。毕竟，自然语言只能作为LLM的输入，没法作为其他应用的输入。
比如，我希望做一个舆情监控应用，周期性爬取全网关于某明星的言论，再分析言论的情绪是否正向，最终统计全网对该明星的整体评价。应用实现思路是：
- 全网爬取言论数据
- 分析每一条言论数据，输出情绪是否正向的判断
- 统计所有言论对应的情绪
- 分析结果
其中第二步，我们可以让LLM判断输入的言论情绪是否正向。
当输入鸡哥辛苦训练了两年半，LLM判断这段话的情绪是正向后，可能回复我：
- 这段话的情绪是正向的
- 结果是积极的
- 这是一段积极的对话
- ...或者其他啰嗦的回答
虽然上述结果都表达了情绪是正向的，但输出结果也是自然语言描述的，且结果句式并不稳定，没法输出给第三步的程序做统计。
好在，LLM也可以输出结构化数据（比如JSON）或者代码，其中：
- 如果能输出符合其他应用规范的
JSON，其他应用可以直接读取使用 - 如果能输出符合其他应用的代码调用，可以直接调用其他程序（通过
RPC通信）
比如，我们让LLM对上述问题输出JSON格式的结果，可能的输出如下：
// 可能的结果
{"result": "positive"}
// 可能的结果
{"emotion": "positive"}
// 可能的结果
{"sentiment": "good"}虽然程序可以读取JSON，但输出的字段可能是不稳定的。假设第三步的统计程序统计的是result字段，但我们第二步输出的结果是sentiment（情绪的意思）字段，这就没法使用了。
为了解决用户输入自然语言，LLM输出稳定的结构化数据或函数调用的问题，openAI推出了一个新功能 —— function-calling（即函数调用）。
当我们调用openAI API时，参数依次传入：
- 用自然语言描述的需求
- 对输出结果函数的类型定义
LLM会输出符合类型定义的函数调用。
比如，我们依次输入：
- 需求：判断鸡哥辛苦训练了两年半情绪是否正向
- 函数定义：
{
"name": "mark_sentiment",
"description": "标记输入语句的情绪是否正向",
"parameters": {
"type": "object",
"properties": {
"prompt": {
"type": "string"
},
"sentiment": {
"type": "string",
"enum": ["negative", "neutral", "positive"]
}
}
}LLM的输出结果为：
mark_sentiment({
prompt: "鸡哥辛苦训练了两年半",
sentiment: "positive"
})只需要定义mark_sentiment方法，用于存储言论对应的情绪即可。
function-calling功能极大扩展了LLM的应用场景（chatGPT的插件功能就是通过function-calling实现的）：
但是，function-calling同样存在缺点，比如：
- 只受限于
openAI的模型，其他模型（比如Llama 2）没有该功能 LLM的响应只有一个函数调用，无法在一次响应中调用多个函数- 函数的类型声明对开发者不够友好，内部实现比较黑盒，当返回的函数调用不符合预期时，不好纠错
TypeChat的出现解决了上述问题。
TypeChat是什么，有什么用
在聊function-calling缺点时，我们提到函数的类型声明对开发者不够友好，那么什么类型系统对前端开发来说是最熟悉、友好的呢？
答案不言而喻 —— TypeScript。
TypeChat是TypeScript之父Anders Hejlsberg（同时也是C#之父）发布的新项目，他可以根据：
- 自然语言描述的提示词
- 对输出产物类别的定义（是表示数据的JSON，还是表示函数执行的JSON）
- 对输出产物的
TS类型声明
让LLM输出符合类型声明的JSON数据。
比如，对于上述判断言论情绪的例子，可以向TypeChat输入：
- 需求：判断鸡哥辛苦训练了两年半情绪是否正向
- 输出产物是表示数据的JSON
- 输出产物的
TS类型文件如下：
// 下面是对用户输入情绪的类型定义
export interface SentimentResponse {
// 情绪的可选项
sentiment: "negative" | "neutral" | "positive";
}LLM输出的结果会被严格限制在上述TS类型。
如果要简单的类比，可以认为TypeChat是使用TS定义类型的function-calling。但实际上，TypeChat的能力不止如此。
首先，TypeChat不和任何LLM绑定，只要能同时理解自然语言与编程语言的LLM都可以使用TypeChat。
其次，输出产物是JSON，JSON除了可以表示数据，还能表示多个函数的执行过程，这样LLM的一次输出可以是多个函数的连续执行。
举个例子，下面是我们的输入：
- 需求：计算如下算式：1 + 2的结果乘以3，再除以2
- 输出产物是表示函数执行的JSON
- 输出产物的
TS类型文件如下：
// 下面是对四则运算的类型定义
export type API = {
// 两个数字相加
add(x: number, y: number): number;
// 两个数字相减
sub(x: number, y: number): number;
// 两个数字相乘
mul(x: number, y: number): number;
// 两个数字相除
div(x: number, y: number): number;
// 对一个数字求负数
neg(x: number): number;
// id
id(x: number): number;
// 未知情况
unknown(text: string): number;
}LLM输出结果为由JSON表示的函数执行过程：
{
"@steps": [
{
"@func": "mul",
"@args": [
{
"@func": "add",
"@args": [1, 2]
},
3
]
},
{
"@func": "div",
"@args": [
{
"@ref": 0
},
2
]
}
]
}其中@XXX是TypeChat中的关键词，比如：
@step代表执行步骤，每个index对应一个步骤@func代表这是个函数执行@args代表函数的传参@ref代表引用某个步骤的执行结果
经由TypeChat内部转换后，得到如下代码：
import { API } from "./schema";
function program(api: API) {
const step1 = api.mul(api.add(1, 2), 3);
return api.div(step1, 2);
}也就是说，我们告诉TypeChat下述信息后：
- 我们希望计算：1 + 2的结果乘以3，再除以2
- 输出结果要表示为函数执行
- 每个执行的函数要符合我们定义的
TS类型
TypeChat输出的结果为：
import { API } from "./schema";
function program(api: API) {
const step1 = api.mul(api.add(1, 2), 3);
return api.div(step1, 2);
}并且，这个结果是稳定的（即使多次执行，输出结果的函数名、类型定义都不会变）。
除了上述功能外，TypeChat最大的亮点在于 —— 他能够对输出结果自动纠错。
因为我们有输出结果的TS类型声明，所以可以用TS编译器检查输出结果是否符合类型声明，如果不符合，TypeChat可以将TS报错信息连同输出结果再次输入给LLM，让他纠错后重新输出。
比如，对于上述检查言论情绪的例子，如果输出结果为：
{sentiment: "good"}经由TS编译器检查后会报错：
Type '"good"' is not assignable to type '"negative" | "neutral" | "positive"'.TypeChat会将上述报错信息连同输出结果再输入给LLM让他纠错。
TypeChat实现原理
TypeChat的实现原理可以用一张图概括：
其中：
- 红色路径输出结果为表示数据的JSON
- 蓝色路径输出结果为可执行的代码
对于红色路径，以上述检查言论情绪为例，TypeChat输入给LLM的提示词类似这样：
你是个将用户输入转换为JSON的系统，转换需要遵循下面的TS类型声明：
${输出产物TS类型声明}
下面是用户的输入：
${"鸡哥辛苦训练了两年半"}
下面是用户输入转换为JSON后的结果：LLM接收以上提示词后输出JSON。
对于蓝色路径，以上述四则运算为例，TypeChat输入给LLM的提示词类似这样：
你是个转换系统，将用户输入转换为由JSON表示的程序，转换需要遵循下面的TS类型声明：
${对@step、@ref、@func等如何使用的类型声明}
程序可以执行由下面的TS类型定义的函数：
${输出产物TS类型声明}
下面是用户输入转换为JSON后的结果：LLM接收以上提示词后输出代表程序执行的JSON，该JSON再经由TypeChat转换后变为可执行的代码。
对输出产物的纠错
如果LLM返回的JSON有TS类型错误，那么TypeChat会拼接出下面的提示词，并输入给LLM：
${报错的JSON数据}
上述JSON对象由于下述原因导致他是非法的：
${TS报错信息}
下面是修正后的JSON：TypeChat对前端行业的影响
不止是前端工程师，当前程序员使用LLM的主要方式还是：
- 用自然语言描述一段代码需求
LLM输出代码- 程序员修改输出的代码，为项目所用
而业界预期的LLM终极形态是：产品经理用自然语言描述产品需求，LLM直接写代码。
如果达到这种程度，程序员就完全没有存在价值了，这也是大部分程序员焦虑的原因。
那么，制约达到终极形态的因素有哪些呢？有三点：
LLM对自然语言描述的需求的理解能力LLM一次处理的提示词长度（token数量限制）LLM生成代码的稳定性
对于第一点，当GPT-3.5出现后，好像LLM的理解能力突然上了好几个台阶。所以，大家会焦虑是不是再过几年，LLM的理解能力突然又爆发性提高，能够完全理解自然语言描述的需求。
对于第二点，GPT-3.5有最多4096token的限制，但这一限制正在逐步放宽。这意味着在不远的将来，LLM能够输出的代码量会越来越多。
正是预见到以上两个因素的变化趋势，导致程序员产生假以时日，会被AIGC取代的焦虑。
但我们发现，要达到终极形态，还要考虑第三个因素 —— LLM生成代码的稳定性。
也就是说，LLM虽然可以帮我们编写函数代码、模块代码，但如果这些函数、模块的代码是不稳定的，他们就没法配合使用，需要工程师手动修改。
如果LLM生成的代码经常需要工程师手动修改，那就限制了它能够自动生成代码的规模，那么他只能沦为工程师的编程助手，而不是取代工程师。
而要解决生成代码的稳定性问题，不管是通过openAI的function calling，还是TypeChat，都需要工程师能够对产物做出精准的类型定义。
这就形成了一个悖论 —— AIGC要想取代工程师独立完成项目，需要能生成稳定的代码。而为了生成稳定的代码，需要工程师理解业务逻辑后，编写详尽的类型声明。
为了取代工程师，还需要工程师积极参与？那取代个der。
这顶多算是一种编程范式的迁移，类似之前前端用jQuery开发页面，后来迁移到用前端框架开发页面。
未来，前端工程师编写详尽的类型声明，LLM再根据声明生成框架代码。就像现在前端通过框架编写状态变化逻辑，框架再去执行具体的DOM操作一样。
总结
有些同学会焦虑 —— 未来是AIGC的天下，我要不要转行搞人工智能？
实际上，通过本文，我们能感受到一种趋势，未来将会分化出三种工程师：
- 搞
AIGC算法研究的工程师
这类工程师人数很少，都在头部互联网企业或人工智能企业的实验室中。
- 负责公司
AIGC基建的工程师
这类工程师负责将上一类工程师的产出与公司业务结合，他们的工作职责包括：
- 评估、部署各种开源模型
- 会使用各种工具，比如
langChain、Pincecone，当然也包括本文介绍的TypeChat - 根据公司业务场景，落地
AI基建
- 业务工程师
比如前端工程师、后端工程师、全栈工程师。他们会在AIGC基建工程师开发的基建上，进行业务开发。
前端这个岗位会持续存在，只是要求会更高（对业务的抽象能力）、从业者会更少。
可以简单的做个比喻，如果你当前小组的构成是：
- 一个对业务更理解的前端组长
- 几个负责业务开发的中级前端
那么未来的构成会是：
- 一个理解业务的高级前端（可能是之前的前端组长），负责对业务进行抽象
- 编写具体业务逻辑的
AIGC基建
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。