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