注：本篇纯手打，不涉及脑替(GPT)自动生成，为保证安全性，在与GPT交互过程中不涉及业务代码与实际业务需求描述
背景：
目前Open AI新推出了CHAT-GPT，许多人分享了它是如何替代部分工作场景，如何解决日常甚至是相对专业的问题的，如根据需求写出对应代码，在普通业务开发场景下他的语言识别能力的极限是什么？除了作为查找问题的工具提效，还有没有更加深入的业务场景。
业务需求迭代链路
需求终审->需求系分涉及基于业务背景的整合，不同角色会从不同视角进行理解，这个环节暂时搁置
我们围绕技术方案->代码开发展开探索
未经训练的GPT
如果我们让他写一个简单表单，可能是没有问题的，以下是一个基础问题
暂时无法在文档外展示此内容
在这个代码中，确实是基本写出我们要的需求，但有几个问题
- 没有使用pro-from，原因在于gpt的数据收集截止至2021年9月 ，它不理解pro-form是什么，因此对于最新的提效组件是没办法使用的，即没法获取最新数据
- 没有使用团队内部自带的地址组件，即无法结合团队场景进行开发
- 语言组织复杂，对于一个语言模型来说，提问者描述的越详细，它回答的准确就越高。如果每一个需求的开发都需要准确描述就会带来较高的沟通成本
下面我们问一个更加细化的问题，基于 schema form 写代码
问题：请基于Antd Pro-components的BetaSchemaForm实现一个表单，字段名包含姓名（name，文本）、民族（nation，选择项）、是否在职（isWork，单选）
这段代码基本无法运行 ，原因是他对SchemaForm 知之甚少，或者说并不知道SchemaForm是什么，这也是GPT令人诟病的地方。
css
const schema = {
type: 'object',
properties: {
name: {
title: '姓名',
type: 'string',
},
nation: {
title: '民族',
type: 'string',
enum: nationOptions.map((option) => option.value),
enumNames: nationOptions.map((option) => option.label),
},
isWork: {
title: '是否在职',
type: 'string',
enum: ['是', '否'],
},
},
};让我们试想一下，对于一个团队内部的前端开发者来说，初期或者基础的，需要具备编程与技术栈开发使用能力，这决定他是否能够根据需求开发页面。这点很像GPT，他了解很多编程知识，他知道如何实现我们的'简单需求'，但它缺少一个比较关键的能力，持续更新学习 。而这对于持续学习与拥抱变化的互联网行业来说是不可或缺的，我们是否能让他学习呢？
把React新文档投喂给 GPT-4 后... - 掘金 似乎印证了GPT具备这样的能力？
让我们来问一问GPT模板预训练是否能够让他写出符合我们要求的代码？
GPT给出了肯定的回答，并预想出了这种策略可能带来的影响。同时也给出实现落地预训练开发这一方案需要的两个重要的条件，模板的质量 和模板的多样性， 这直接影响代码生成的准确性 与可靠性
我们可以简要拟一下它的训练输出过程
- 学习新的组件库与场景模板代码，这些训练代码要足够多，足够高质量
- 合理的自然语言模型，需求的讲解如何让GPT更好理解，同样符合上面说的特点，足够高，足够好
- 分模块输出，因为GPT有token限制，我们需要训练他分模块回答。
下面我们以上面SchemaForm为例对他进行预训练，看看效果如何
模板预训练
后台中大量使用了表单的场景， 我们加入[Pro-Form SchemaForm学习模板] ，模板内容主要包括SchemaForm的基础使用，联动等各类场景的使用，目的是让它学会如何使用SchemaForm，下面我们将模板内容输入到GPT中
然后重复上面的问题，看他如何作答
从输出内容来看，他掌握了SchemaForm不同valueType对应了哪些表单控件，表单的基础属性用什么标识，同时知道控件的属性应该写在什么位置，BetaSchmaForm如何引用，这段代码属实挑不出什么毛病。这证明了GPT确实是可学习的。
在学习模板中，我尽量详尽的描述了SchemaForm的基础使用，前面提到模板的多样性和质量直接决定了输出代码的准确度。也就是说，关键点在于你给到模板需要尽量涵盖所有的使用方式，并最好列出常用场景（如联动，动态请求）的使用方式。模板代码量质量越高，量越多，输出的内容就更加贴近你的预期
增量学习
如果模板不够丰富，我们可以继续提供其他场景的代码，并且尝试给出更复杂的组件写法，比如我在学习模板中加入了联动的场景，并给出联动代码模板对应的联动含义
然后重复之前的问题，并加上了联动的场景，下面来看他的回答
他准确地写出了联动的场景，我们也能看到他一步一步在学习成长，同时多会话学习的方式也避免了单次学习模板过长截断的问题
我们将上面的过程叫代码学习，旨在输出正确的代码
自然语言模板
虽然GPT在大多数场景下能够满足普通人的问答需求（如苹果公司市场分析，某某城市的发展潜力，如何评价XXX对XXX的影响），但是在特定领域的特定分支上，可能需要更准确与详尽的问题描述能让GPT输出更准确的代码
举个例子，如果我们使用大白话去描述一个需求，请帮我实现一个创建页面，其中包含姓名，性别，学校，其中学校是可选的
他的回答仍然是泛化的，且部分代码是不准确的（如我说学校是可选的，但是输出的代码仍然是输入框）。
因此这里我们需要对基础的自然语言，转换为更适合程序开发的自然语言。
请帮我实现一个创建页面，其中包含姓名，性别，学校，其中学校是可选的。
可以被我们转换为，请基于BetaSchemaForm实现一个表单，其中包含姓名（name，输入框），性别（sex，单选），学校（school,单选）。
代码是符合预期的，综合来看，未来前端开发人员可能需要做三件事，首先是训练质量高的，大量的，符合团队部门要求的代码模板，然后是基于产品给出的需求做程序自然语言的转换，代码输出的微调与审查
结合前端业务
整洁架构
目前团队内全量落地了整洁架构，将数据处理逻辑层与UI层做解耦，提升了系统稳定性，并为全量单测打下了基础，我将这一整洁架构进行了脱敏整洁架构学习模板-脱敏 ，并喂给了GPT。
然后基于此给出需求：请基于整洁架构与antd pro-table实现一个列表页,包含订单编号，订单类型，是否生效
可以看到，除了它对于部分处理环节的引入位置不太规范外，但整体代码设计上已经符合整洁结构设计，同时如果需要持续约束代码生成的准确度，可以持续向GPT输入整洁架构相关内容，增量学习后面会介绍到。
在进行模板预训练下我们就可以针对后台几类场景生成快速生成符合团队要求代码风格的模板。
脱敏方案探索
B端业务体系下，前端与用户的交互大部分是表单与列表，我们可以尝试在需求沟通时对指定业务词汇进行脱敏。在指定关键词进行序列与反序列化
这样将业务与前端逻辑解耦的方式解决脱敏的问题，这是一个方案探索，相信未来AI私有化成熟后能解决这个问题。
总结
基于对GPT进行模板预训练，增量学习，我们可以在日常开发中快速生成指定业务场景的代码，可以通过业务关键词脱敏的方式降低低复杂度的需求代码编写成本。
未来展望
输入与输出的约束
我们能从GPT中看到自然指令到产出的可能，但它在人机交互上还有很长的路要走。也就是为什么目前它仅用于常用问题回答，客服，搜索引擎等日常对话场景，真正影响到生产力 还是需要很多人不断努力与探索。原因在于目前的模型是相对发散的，在代码开发，数据分析这样的对准确度要求很高或者是需要程式化输出的领域还是要通过预训练，持续学习的方式来尝试满足我们的需求。这个过程很容易让我们想到熵减。
工业革命的蒸汽机提供了热能到动能的转化能力，但一开始它的转化效率并不高，随着人类不断探索发展，在转换效率 与做工约束上做了很多探索，最终到现在的汽车、电脑，这其中包含了几十上百年不同时代的人的努力才达到了汽油/电输入入直接能让机器有效做工的能力。
同样的，在当前的AI时代互联网行业也在探索如何对GPT这个模型雏形人类语言到代码生成（做工）做提效与约束，提升输入输出效率，以最小成本满足我们的需求，让语言模型真正带来生产力的提升