【在公司前端项目中落地 ChatGPT】是 「一系列」 的篇章，总结笔者目前在公司做的事情，将会持续更新。
分享出来是希望和优秀的社区一起 「探讨ChatGPT在前端更多的可能性」 ，相互学习、交流、一起成长。
初探成果描述了笔者如何使用ChatGPT基于公司的UI组件库、按照公司规范的组件文件结构，写出来一个 「完整、可运行、可测试的业务组件」。
开篇介绍
大家好，我是lv，本人已经完全拥抱了ChatGPT（现在没了ChatGPT都不会敲代码了？）
最近我在公司搭建了一个新的 React 项目架构，同时基于新架构制定了新的开发的工作流。目前已经在实际的项目中落地，同事反馈也挺好的。
因此，公司领导也跟我讨论如何可以把 ChatGPT 融入到新架构工作流中，用来进一步 「提高前端开发的效能」。
于是lv近期主要负责研究ChatGPT如何在前端中落地，在这里分享出来一些想法和实践，希望和大家一起探讨，一起学习，（一起被ChatGPT淘汰）。
接入 ChatGPT 的一些想法
在日常的工作中，ChatGPT 在以下场景的表现是绰绰有余：
「技术调研」：ChatGPT 可以帮助我们快速了解某项技术，提供一些技术方案的参考。
「写工具函数」：ChatGPT 可以帮助我们自动生成一些常用的工具函数，减少手动编写的时间。
「代码 Review」：ChatGPT 可以在代码 Review 过程中，自动生成一些代码改进的建议。
「写单元测试」：ChatGPT 可以帮助我们自动生成一些单元测试代码，提高测试覆盖率和代码质量。
笔者之前也尝试过用ChatGPT来写公司的业务代码，但是由于祖传代码的原因，各种业务逻辑揉杂在一起，各种变量引用，ChatGPT理解起来有点吃力，但是如果可以把所有的上下文都喂给ChatGPT，它的表现应该是可观的。
但是从长远来看，解决祖传代码问题的根源是优化架构，规范工作流，这样才能让后续的代码往可维护性发展，不至于是错上加错
趁着最近落地了新的架构工作流，于是研究了一波如何在其中接入ChatGPT，笔者取得了一些突破，下面先介绍一下新的开发工作流。
工作流介绍
主工作流分为两步，「开发Storybook组件、页面集成联调，」分成这两步的原因是为了规范组件的类别，不同的组件类别负责不同的职责，保证独立的可维护性。
根据工作流整体分为两大类别组件：
「开发Storybook组件：业务组件，由公司的基础UI组件+交互逻辑而成」 ，只包含纯前端交互的组件，不与后端产生任何数据交互，在storybook中可以独立运行、独立维护、独立测试，也可以理解为它是一份由前端提供给前端的Swagger文档。
「页面集成联调：对接层组件，由storybook中的业务组件拼装而成」 ，负责请求后端数据，分发数据到不同的storybook业务组件中，这里的数据就包括服务端状态数据、前端状态数据，如此一来，整个前后端的业务逻辑的交互只存在于 「对接层组件」，任何人只要看对接层组件就能明白整体的业务逻辑，不至于无头苍蝇到处乱找。
「1、开发Storybook组件」
❝Storybook是一个开源工具，用于构建UI组件库并展示每个组件的不同状态。它可以帮助开发人员将组件开发与应用程序开发并行进行，从而加快开发速度。
❞
拆分UI设计：
根据UI提供的设计，将大块的页面按照独立性、可复用性拆分为为一个个的业务组件，定好组件的名称和开发者。
按照组件规范分工开发：
StorybookExample // 业务组件名称
├─ index.ts // 仅仅将组件内容暴露给外部
├─ interface.ts // 定义组件内部用到的所有类型，包括 interface、type、enum等
├─ StorybookExample.stories.tsx // 组件的storybook文档，包含组件的使用示例
├─ StorybookExample.tsx // 组件的主体逻辑，如果组件太大可以拆分为其它的文件
├─ styles.ts // 组件所有的样式资源存放在此，使用styled-components来编写
├─ helpers.ts // 如果存在一些工具函数，那放在此处
「2、页面集成联调」
将编写好的storybook组件拼装成真正的页面，给组件提供后端数据交互、前端组件间的通讯数据交互。
❝具体的目录结构本篇章先不展示，因为本篇章主要介绍如何 「使用ChatGPT开发Storybook组件」
❞
使用ChatGPT开发Storybook组件
下面开始尝试将工作流的第一步 「开发Storybook组件」 交给ChatGPT来做。
「使用ChatGPT官网还是API」
我自己基于API搭建了一个国内可访问的ChatGPT网站 (https://chat.xmn-lv.cn/)，首先想到的肯定是通过API去调用，第一个原因是无需魔法上网，第二个原因是后续可以使用APi进行一些二次定制，但是经过尝试发现了一些限制：
「RPM：」针对gpt-3.5-turbo-0301模型，每分钟的请求限制为3次。
「TPM: 针对」gpt-3.5-turbo-0301模型，每分钟的token限制为 「4097tokens」。
官网速率限制的介绍
于是先在官网上进行试验，后续需要用API进行工具化的定制再来处理请求次数和token限制的问题。
「开发流程」
1、给ChatGPT定义一个角色，资深的前端开发“大佬”从此诞生。
2、将公司的组件库给到ChatGPT学习
整理公司的组件使用文档，可以考虑使用ts声明文件，或者使用组件的md使用文档，最后考虑组件源代码，下面我用组件的声明文件试一下。
3、描述组件的基本信息，开始生成组件
4、提供给ChatGPT一个规范组件的模板，按照模板优化一下
5、运行和调试组件
将大佬生成的代码直接拷贝到我的工程中，运行一下，发现一处错误，是从antd中导入的Table组件，不怪大佬，因为我没有告诉它公司的组件库名称。
将antd改成公司的组件库，效果如下…
虽然是个简单的业务组件，但是如果是我自己来敲这个，需要多久呢？
后续规划
「1、生成组合多个基础UI组件的业务组件」
上述演示的 Attachment 组件仅仅是单个 Table UI组件封装的业务组件，如果存在多个基础的 UI 组件组合，你觉得ChatGPT的表现会怎样？
「2、生成页面集成联调的对接层组件」
当页面上所有业务组件已经封装好了，这个时候需要将页面上所有的业务组件拼装起来，请求后端的数据，将数据分发给不同的业务组件，并且提供不同业务组件间的数据交互，这就涉及到服务端状态数据和前端状态数据的处理，跟业务强相关的代码，你觉得ChatGPT能处理吗？
「3、基于API开发公司的ChatGPT生产工具」
支持所有人共享一份内置的UI组件库文档上下文，统一维护，无需每个用户自己来喂基础UI组件数据。
集成Vscode插件，在编辑器中直接生成代码。
基于ChatGPT开发可视化的代码生成系统，技术小白（产品、UI）也能写出符合公司规范的前端代码。
粉丝福利
「国内免魔法免费使用ChatGPT」：https://chat.xmn-lv.cn/，目前使用量还挺大的
「抽奖送ChatGPT账号」：上一轮抽奖送出3个ChatGP独立账号，5个独立open ai key
