【在公司前端项目中落地 ChatGPT】是 「一系列」 的篇章，总结笔者目前在公司做的事情，将会持续更新。
分享出来是希望和优秀的社区一起 「探讨ChatGPT在前端更多的可能性」 ，相互学习、交流、一起成长。
上篇【在公司前端项目中落地 ChatGPT】初探成果 描述了笔者使用ChatGPT基于公司的单个UI组件，编写出符合规范的、完整的、可运行的组件。
其中最重要的是 「符合规范」，因为这和组件的后期可维护性强相关。如果写出来的组件不符合规范，就算能跑，一旦业务形态发生变化，需要程序员介入修改代码，所需要的维护成本就会急剧上升，最终的结果很可能就是重构。
当然，对于那种「一次性」的活动界面，用完即丢，这种界面不存在后期的业务拓展，也就不存在代码的可维护性之说。这种场景使用常规的低代码平台来实现可能更加合适，毕竟可视化托拉拽能搞定的事情，不需要来调教ChatGPT。
既然说到低代码，仔细想想，在这个ChatGPT等AI产品大爆发的时代，后续低代码项目的发展方向将是什么？
给低代码平台一份需求文档，直接生成符合规范的、可维护的、拓展性强的系统代码？
开篇介绍
大家好，我是LV。
回归正题，本篇 「聊天式编程」 是基于上篇进行的一些拓展，因此还未看过上篇的同学需要先去熟悉一下，因为其中用到了一些概念，如新项目架构的工作流、storybook业务组件等。
本篇通过与ChatGPT的几轮较量，来调整ChatGPT在前端项目中的落地方案。笔者将会基于实际业务场景，组合多个UI组件，使用ChatGPT封装业务组件。
下面先介绍一下对于开发一个业务组件来说，传统的编码思维和使用ChatGPT进行开发的编码思维。
编码思维的碰撞
如上图，对于开发一个规范的业务组件来说，从工作流上拆分为了3步，下面针对 「程序员」 和 「ChatGPT」 工作流分别描述：
程序员
「Step1」：拆分业务需求
在动手写代码之前，先仔细拆解业务需求，并定义清晰的接口。同时按照规范搭建组件的目录结构，形成统一的规范，这样便于团队成员更容易理解代码的布局和结构，增加可维护性。
「Step2」：手撸代码
根据设计稿和接口的指引，开始正式编码，按照业务需求，逐步实现组件的各个功能模块。同时在写代码的时候，保证代码的 「可读性、可维护性和可扩展性」。
「Step3」：storybook文档和测试
当代码写完之后，编写组件的 Storybook 文档。可以理解为Storybook就是一份组件文档。建议根据不同props的组合，编写清晰、详细的 Storybook 用例，在方便同事使用的同时，也方便后期自己快速回顾组件，不至于再去看代码逻辑，耗费时间。
最后需要编写组件的单元测试，保证后续的每次迭代不会对之前的组件功能产生影响。
一步步手撸业务组件，程序员表示很nice，毕竟是自己亲手一行行创造出来的，就像是自己下的崽一样，反正我的崽最好，什么ChatGPT怎么牛逼，都跟我没关系。
ChatGPT
「Step1」：定义ChatGPT角色
为了高效开发业务组件，首先要为ChatGPT定义一个具体的角色，并提供其开发业务组件所需要的资源，这些资源可以包括组件声明文件文档，组件使用示例等。
「Step2」：描述业务组件生成代码
这一步是整个ChatGPT开发流程中最重要的一步，如何描述你需要生成的组件至关重要，描述地越详细，生成的组件越符合你的预期。
但是描述的越详细，也会带来一定的问题，因为编写描述信息本身就是一项繁碎的工作了，甚至还不如直接手撸代码，我们使用ChatGPT的目的是为了提高编码效率，不是为了使用ChatGPT而使用。
如下是笔者一开始在描述组件信息这块犯的错误，越写越不对劲，越写越怀疑人生…
因此如何描述组件信息，需要用户不断探索实践，并且在不同业务场景下均衡来使用。比如说简单的组件可以描述的详细一点，生成出来的代码可能直接就能运行。但是比较复杂的组件就得打住了，别想着ChatGPT能一把给你搞出来，心急吃不了热豆腐，要懂得聊天、循序渐进…
「Step3」：提供规范，优化代码
经过Step2，ChatGPT已经写出来了一个它理解的业务组件，此时组件还不符合我们的组件结构规范，因此需要提供给它一个规范的模板，让它按照这个模板来进行优化，这个模板就包括了规范的组件文件结构、storybook文档自动生成、组件的单元测试等。
有人肯定有疑惑为什么一开始不让ChatGPT按照模板来生成呢？笔者尝试过，但是效果不太好，甚至出来的代码没有按照描述信息生成。在使用现阶段大模型的时候，不要想着把所有的东西一把都喂给它（如果后续ChatGPT4.5、ChatGPT5.0出来了，那可能无所谓了），要循序渐进，先让它理解你描述的内容，当它符合预期生成了描述的代码，然后再提供模板将上面符合预期的代码优化成规范的代码。这就相当于将一个复杂的任务拆分为了很多个较简单的小任务，人类处理复杂任务都是这样的步骤，更何况是AI大模型呢？
与ChatGPT的几番较量
当你尝试用ChatGPT写业务组件，你会发现一些问题，不要想着ChatGPT可以把代码100%地写出来。如果能100%写出来，那还需要你干啥…
关键是如何才能最好地让ChatGPT给编写业务组件提效，最大程度减少人为编码的工作量。
下面笔者跟GPT展开了几轮较量，主要是针对如何更好地提供组件的描述信息。
下面是一个实际的业务场景：
1、点击 + 「按钮」，弹出「模态框。」
2、模态框中包含「两个选项」，点击不同的选项，将展示不同的「表单项」，表单项中包含 「下拉选项」、「输入框」等，用来输入项目信息。
3、填写完表单项，点击提交将表单数据传输到后端创建项目。
第一回合
「注意」：定义角色、投喂基础UI组件与【在公司前端项目中落地 ChatGPT】初探成果 保持一致，不熟悉的可以先看上篇，下面的回合仅展示如何描述组件。
如下为第一回合输入的组件描述：
输入描述信息之后省略了一些额外的小步骤，比如按照公司规范模板进行代码优化等，详情请看上篇。
ChatGPT的表现如何呢？
点击 + 「按钮」，弹出「模态框。」
模态框中包含「两个选项」，点击不同的选项，将展示不同的「表单项」，表单项中包含 「下拉选项」 、 「输入框」等，用来输入项目信息。
填写完表单项，点击提交将表单数据传输到后端创建项目。
下面看一看自动生成的styled-components样式、storybook文档和单元测试。
如上生成代码的满意度 80%， 整体符合预期，用户的整体交互逻辑都实现了，包括点击按钮弹出模态框、根据不同的选项展示不同的表单、样式抽离到styles中、storybook文档、单元测试等。
但是有一些缺点，我们说过使用ChatGPT来进行编码是为了提升我们的工作效能。
「缺点一」：第一回合的组件描述信息太多了，而且看起来也很繁琐，各种序号融合在一起，写着写着自己都不知道到哪了。
「缺点二：」 上面大量描述了组件props的定义，从体验上来说，这不就是用大白话在写代码吗，和普通的写代码没太大区别，我需要更加智能地体验，让不怎么懂技术的小白也能过GPT写出符合规范的业务组件代码。
第二回合
基于上述两个缺点，我们尝试优化一下。
如上是第二回合的描述信息，生成的组件最终效果与第一回合相差不大，但是描述信息相对来说比第一个回合更加口语化、没有描述技术层面的组件props，但是整体内容还是有点偏多，看起来有点乱。
思考一下，为什么没有告诉 “大佬” 基础组件的Props如何传递，但是它能够通过大白话推测出来呢？比如说 「弹出的 DiaLog 描述：标题是 Create Project、点击弹出层可以关闭、宽度为 720、DiaLog 中包含两行。」，他知道设置title、width这些props。
原因是组件的声明文件中对于每一个Props写了备注，通过大白话和声明文件的备注就能够匹配到对应的Props。
最终回合
既然ChatGPT有很强的上下文理解能力，那我门直接基于第二回合的描述信息分段来给，先让“大佬”搭建架子，然后再优化细节的内容。
先聊整个大架子：
再聊细节：
跟大佬聊完天，代码也写的差不多百分之八九十了，这可能就是聊天工程师吧！
后续规划
「收集反馈」：目前 「聊天式编程」 的工作流笔者正在公司内进行实践，同时也希望接收到来自社区的各种反馈，一起进步，一起高效办公。
「页面集成联调」：目前仅仅是开发了业务组件，还没有进行后台数据的对接。数据对接就涉及到更多的业务场景交互，还包括组件间的通讯，还能和 “大佬” 愉快地聊天吗？
「工具开发」：这一步上篇简单介绍了一下，简单来说就是类似集成Vscode插件，开发可视化的代码生成系统，但是具体的实施还需要看上两步的成效，有兴趣的朋友可以提前与我交流。
粉丝福利
「自建免费国内ChatGPT网站」：https://chat.xmn-lv.cn/
「互动探讨学习」：加入「社群」，跟LV还有一群优秀的小伙伴一起探讨ChatGPT、AI更多的可能性。「进群方式」：公众号后台回复 ”进群”。
