记录一次 AIGC Hackathon 参赛经历和收获
公司在 5 月上旬的时候举办了一场 AIGC Hackathon 比赛,鼓励内部员工基于公司相关业务,利用 AI 技术进行创作,重塑生产力。
这么有意思的活动我当然也要掺一脚,在同事的怂恿和牵线之下,召集到了另一位设计师,以及一位研发大佬。所以加上我总共是 3 个人,2 个设计,1 个研发。但是严格来说应该是 1.5 个设计,1.5 个研发。因为我会参与到前端界面的实现,这也是我想参与这次活动的其中一个主要原因。
先放上我们开发的小工具的最终效果,其实是通过提前录入 SQL 语句规则,然后用自然语言询问 AI,让 AI 帮忙生成一个可用的 SQL 语句:
过程
想法
因为当前我们公司的业务是研发管理平台,所以我想到能通过 AI 帮助我们的主要是提高效率,减少出错,诸如此类的方向。
尤其是我在刚来到公司的时候有一段时间给我学习体验公司产品。中途就看到有个地方生成图表的话,可以选择各种筛选条件,也能用 SQL 来快速筛选,当时我就觉得如果用 SQL 来筛选会比手动一个个条件添加来的快,但我又不会写 SQL 语句,所以就想到一个主题:「输入自然语言,通过 AI 生成一段 SQL 语句」,产品名称就被定为「SQL-Helper」。
最开始我们讨论到有几种实现方式:
- 产品原生:在公司的产品中搭建一个开发环境,在里面进行对话交互功能的设计和开发。
- 外部网页:搭建一个网页,在网页里实现对话。
- 谷歌插件(Popup):在浏览器右上角上添加一个 Popup 入口,点击后打开一个浏览器提供的容器,在上面进行对话交互。
- 谷歌插件(嵌入网页):在公司的产品当中嵌入一个小卡片,在上面实现对话和配置等,会遮盖部分网页内容。
最终选择了谷歌插件(嵌入网页)的方式,因为这样算是能比较融入到产品当中去,不需要来回切换网页这么麻烦,毕竟是一个对话的产品。而且 Popup 有一个致命问题是,如果鼠标点击到了网页的任何地方,Popup 就会收起,这种体验不适合用在聊天式的产品当中。而直接基于公司产品的开发环境中进行开发,这种做法成本比较大而且难以协作,毕竟团队中只有一个正经的研发。
团队合作
得益于大佬的用爱发电,他花了一个休息日的时间把架子搭起来了,技术栈是:
- React
- Ant Design Manifest V3(支持 Chrome 96)
- Stylus 样式结构支持
最初搭建好的框架。是能够在网页中嵌入一个按钮,点击后打开一个弹窗:
这两个地方就是我们作品的主要载体。我们希望点击悬浮窗之后能打开一个聊天小窗口,能在里面填入 SQL 语句相关的 Key 和 Value,然后填入用户的 API Key,并实现与 AI 实时对话。
所以很快,在第一天的时候我们就有了一个大概的原型,中途通过每日下班前的简短碰面来一起决定增加/减少哪些内容。
然后也确定了我们三人小组的分工:
- 我:前期负责设计界面、实现静态界面。后期参与 Prompt 调试。
- 另一个设计师:负责界面设计、图标设计、PPT 制作/包装。
- 研发大佬:负责功能实现,比如表单提交,发送和接收消息,接口调试等。
然后我们就各司其职,我这边按照大佬给的流程,每天把自己做好的部分提交 Pull requests,并标记清楚完成了哪部分,哪部分的功能需要研发大佬来实现等等。
整体的时间表如下图(只有五个工作日,时间紧迫。):
一些细节
初试 Ant Design 的感受
平常在设计稿中使用基于 Ant Design 组件的经验有很多,但是自己亲自在代码里使用该组件还是第一次。
一个强烈的感受是,Ant Design 组件库确实很丰富,很多常用的组件都有封装好,主题色更改的功能也很强大。但是想要基于 Ant Design 组件库来做一些客制化的改动,实在是太费劲了(也可能是因为我太菜...)。
比如当时我想实现一个 TextArea 根据容器高度来自动填满高度的话,我的样式代码是如此之多:
另一个坑是我们的聊天窗口是嵌入到网站当中的,而且原本我们公司的产品也是基于 Ant Design 组件库搭建的,所以会出现很多样式的冲突。
比如我在自己的界面中使用了 Button 组件,而被嵌入的网站中如果也用了 Button 组件,那么样式将会被原本网页覆盖掉。
如果在这种情况下想要自定义样式,需要在 CSS 中通过多种手段来提升样式的优先级。这里是我比较频繁用到的两个提高优先级的方法:
- 使用选择器提高 Class 的优先级
- 使用 !important
CSS 选择器的优先级相关内容可以参考张鑫旭大神的名著《CSS选择器世界》,写得特别详细。
所以后面回想起来,我在改造 Ant Design 组件库花的时间还是太多了。这个组件库可能在做复杂后台的时候好用,但在做这种小应用,发挥创意的地方,我觉得还限制还是太多了。我觉得我们最开始应该选择使用有更高扩展性的组件库,比如前段时间看到的 Radix UI。
从文档来看,Radix UI 会组件里面每个 DOM 都提前命名好相关的 ClassName,那么用户在想自定义样式的时候,就方便很多了。
对比起 Ant Design,引用一个组件进来后,会生成巨多个没有打标记的 DOM。每个 DOM 的样式巨难选择,想要改组件内某个元素的样式,没有熟练的 CSS 选择器功夫还真搞不定。
但还是得具体试一试才知道 Radix UI 是不是真的好用,或许也会暗藏某些坑。或许我应该拿自己的个人网站来试一试 🤔。
改造弹窗:拖拽和操作
由于这是一个嵌入在网页当中的对话窗口,本着提高一个易用性的初心,我觉得需要对弹窗组件进行魔改,支持以下两种特点:
- 支持拖拽:允许用户拖拽弹窗标题区域,改变弹窗的位置,以免挡住原本页面中的元素。
- 移除遮罩:不展示弹窗背后的黑色遮罩,并且弹窗出现的时候,不影响用户操作原本的网页。
仅仅是改造弹窗这块,足足花了我一天。严重影响了我调试 Prompt 的时间,所以感觉很有必要把它记录下来,即便我的做法绝非最佳实践。
拖拽
拖拽这块我是用了一个名为 DragM 的开源库来实现了,因为看到示例里面效果很不错,所以直接用上了。效果确实也很不错,强烈推荐。
过程有点丢人,就不详细描述了。大概是我参照示例代码做到了弹窗能够实现拖拽,但弹窗的关闭按钮却失效了,后面还是得靠研发大佬来修复。
允许操作背景
这个特点的实现简直是噩梦。Ant Design 文档是提供了一个 API 是能够允许我们隐藏掉黑色的遮罩。
但是这只是让我们看不见遮罩,打开弹窗时,原本页面的元素仍然是无法点击的。所以我试了一些方法,比如说将每一个疑似是遮罩的 DOM 设置为 display: none;,然而并不奏效。
最后生效的方法是用 CSS 选择器选中遮罩层,并将其调整为跟弹窗一样大。那么实际上遮罩还是存在的,但已经被修改为和弹窗一样大,并且叠在弹窗的后面,其实谁都感知不到这个透明遮罩的存在。
所以对于弹窗尺寸以外的部分,是没有被遮罩所覆盖的,自然能够正常响应鼠标操作。
这种做法无法适应弹窗高度会动态变化的情况,但我们这次设计的产品中,弹窗的宽高是固定的,所以即便做法比较不成熟,但确实是达到效果了。
结果
比赛最终有点遗憾,距离拿奖仅一步之遥。获得我们组目标奖项的是一个单人成组的高手。 很可惜的是我们就差一点点,因为最后颁奖的时候大佬也提到了我们的作品,说是如果能更好用一些,比如将生成的 SQL 语句自动填进输入框,或者自动应用然后直接生成图表,就有更大的机会获奖了🤦。
确实我们在演示的时候没有将这个这个产品最强大的功能发挥出来。因为本身产品也有些缺陷,限制了我们的演示范围。
最开始我们设想是演示的时候用自然语言多问几个问题,然后 AI 每次回复都很准确,凸显了自然语言生成 SQL 语句的便利性,而且还想演示输入了几个错别字,AI 仍然能够正确地识别我们的意图,回复正确的 SQL 语句。
但实际上我们最终的产品还是有一个明显的 BUG,在连续聊天时,消息队列不正常,AI有时候会回复我问的上上一个问题,而不是紧接着我的提问来进行回答。
这使得我们演示的时候只能问一个问题,简单带过,没有办法将自然语言带来的便捷性完全地展现出来,实属遗憾。
收获
虽然没能获奖,但参与这次公司内部的 AIGC Hackathon 比赛对我来说有三个特别重要的收获。
参赛经验
简单来说就是产品设计和功能开发的边界,需要根据演示需要来进行规划。
之前我在样式实现中花了太多时间(职业病🤦),比如输入框的聚焦效果,聊天气泡出现的动画,发送消息加载中的动画等等,而实际上在演示的时候,这些可能只展示了 1~2 秒,甚至更少。
因为这些内容大概率不会是评委所在意的东西,反而在过程中怎么调试 Prompt,调试过程中遇到什么挑战,怎么解决,怎么选择模型等等,显得团队很沉浸于与 AI 接口进行交互,通过这个项目积累了挺多经验,可能这些才是大佬们有兴趣了解的地方。
我应该早点完成产品界面还原,然后尽快投入到调试 Prompt 当中的。 如果之后再次参与类似的活动,我觉得我的所有工作都会围绕最后一天的演示来进行,其他东西能减就减。
首次参与代码 PR,并且与真正的研发同事合作
这次是我第一次将代码 PR 到其他成员的仓库当中,并且解决代码冲突,编写改动点,同步最新代码等等。这种团队协作的感觉,让作为设计师的我感觉很新鲜和奇妙。
而且各司其职,每个人都做出了超出自己以往经历的内容,然后每天短会同步下今天的进度、明天的工作内容。尤其是路演前一天晚上一起调试 Prompt,然后把最佳表现录屏,录屏中还出现了几次滑稽的意外...这种协作的经历让我感觉很充实,富有激情。
而且我每天都会遗留一两个事项给峰哥来解决,比如:
- 我做完了一个表单填写框和提交按钮,我就告诉峰哥让他来做表单提交的功能;
- 我做完了聊天气泡(由AI、用户、系统发出的消息)的三种样式,也是一样让峰哥来做相关的展示逻辑...
真正参与产品代码贡献对我来说是一直想去做的事情,因为我一直觉得如果能由做界面/交互设计的人,来亲手将其创作内容实现出来,是一件很酷的事情,也能够减少很多沟通成本。
参与到 AI 的浪潮之中
我最开始是在去年年底的时候,用 ChatGPT 来帮我解决我重构个人网站时的一些实现问题,中途因为好奇心驱使,也问了很多奇奇怪怪的问题。然后最近也在高频使用 ChatGPT,来作为我学习英语的助手。
而这次比赛不仅给了我一个机会去参与创造一个跟 AI 相关的产品(包括代码也有不少是 ChatGPT 参与的),还给了我推强大的动力去了解 AI 在商业中的场应用景。除了在比赛中看到其他参赛者的创意之外,现在还了解到比如 Atlassian 已经有相关的功能前瞻了。
从 Atlassian 在 5 月 4 日发布的股东信当中,也透露到该公司已经在用 AI 来来为客户提供服务了。
"Now that generative AI has reached consumer-grade maturity with LLMs, we can create magical new experiences for our customers."现在,随着大型语言模型(LLMs)带领生成型人工智能达到了消费级的成熟,我们可以为我们的客户创造魔术般的新体验。
除了 Atlassian,另一个互联网巨头:Shopify 也将 AI 能力应用到其产品当中。比如在商品详情页的编辑界面当中,我们可以输入几个关键字,让 AI 帮忙生成一段商品介绍的文本,还能够调整文本的风格。
Shopify 将同样也是利用 LLM 来实现的生成文本能力,这被官方称为「Shopify Magic」。除了在商品详情页生成商品描述,也能在邮件当中根据活动类型或产品关键字生成邮件标题,或者在主题编辑器中根据要求来生成标题等等。
微软就不必多说了,也已经在 Microsoft 的办公软件上集成了很多 AI 功能。
代码仓库
这里放上我们产品的代码仓库吧,记录这段热血时光:
最后,通过这次 AIGC Hackathon 活动,我真正参与到了产品的代码贡献,同时也看到了许多 AI 能力的应用场景。听说公司有产品在研究 AI 能力在业务中的应用,希望之后自己也有机会在商业项目上进行更多相关的实践吧!
近况
太久没发博客了,记录下我最近的状态吧。应该没有人想知道,但若干年后的我可能会想知道。
- 近沉迷于学习英文,所以会导致网站、博客的更新会比之前慢一些。
- 发现英文还挺有意思的,但在学生时代是看见英文就想睡觉。以前的我应该是比较喜欢数学和历史。
- 小目标是今年内能出一篇全英文的博客。全程用英文书写,然后在发布之前先给 ChatGPT 帮忙检查和润色一下。
- 个人网站 LRD.IM 正在开发支持切换语言至「英语」的功能。
- 有一个前端相关的分享会正在准备进行,是面向部门内产品、本地化运营和设计同事的。
- 在手机上开通了 ChatGPT Plus。直观感受是 GPT-4 的回答比 GPT-3.5 靠谱很多很多,应该会持续订阅。
- 正在尝试一种新的作息,再多体会一段时间后,可能也会在博客上记录。