Normal view

There are new articles available, click to refresh the page.
Before yesterdayCode & Tech

白嫖Gemini_API搭建个人AI助理

By: wayen
8 March 2024 at 20:19

白嫖Gemini_API搭建个人AI助理

发表于|更新于|实用教程
|字数总计:443|阅读时长:1分钟|阅读量:

说明

本次搭建过程分为两步,第一步获取Gemini_API_Key,第二步搭建适用Key的程序,不考虑Key泄露第二步完全可以省略。
示例: https://chat.xml.wiki 访问码: xml.wiki(输入访问码即可直接试用)

Gemini_API_Key

ChatGPT-Next-Web

有许多程序可以使用Gemini_API_Key,在此只介绍ChatGPT-Next-Web的搭建。事实上你也可以直接使用别人搭建好的,在不输入访问码时将自己的Key填入设置即可。ChatGPT-Next-Web可以使用Vercel、Docker和CloudflarePages三种不同的方式搭建,见官方教程,本节复述CloudflarePages搭建教程。ChatGPT-Next-Web也提供了桌面版本,下载点击安装即可使用。

  • 打开https://dash.cloudflare.com,点击左侧Workers和Pages下的概述
  • 点击创建应用程序后点击Pages连接到Git
  • 链接你的Github账号,选择你Fork的项目后开始设置
  • 项目名称和分支一般默认即可,其他未提及项默认即可
  • 框架预设选择Next.js,构建命令填写npx @cloudflare/next-on-pages@1.5.0
  • 点开环境变量(高级),挨个复制以下内容
    1
    2
    3
    4
    5
    6
    7
    CODE = xml.wiki    #访问码,即登录使用的密码
    CUSTOM_MODELS = -all,+gemini-pro #选择使用的模型
    GOOGLE_API_KEY = ****************** #Gemini_API_Key
    NEXT_TELEMETRY_DISABLE = 1
    NODE_VERSION = 20.1
    PHP_VERSION = 7.4
    YARN_VERSION = 1.22.19
  • 点击保存并部署后立即取消部署
  • 来到你部署的这个项目的设置->函数->兼容性标志
  • 分别在配置生产兼容性标志配置预览兼容性标志两项中填写nodejs_compat
  • 点击部署选择重新部署即可,等待部署完成即可访问
文章作者: wayen
版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 Wayen

评论
数据库加载中

记录一次 AIGC Hackathon 参赛经历和收获

AIGC Hackathon 主题海报,由公司品牌设计师陶老师和 Stable Diffusion 的共同创作

公司在 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 实时对话。

所以很快,在第一天的时候我们就有了一个大概的原型,中途通过每日下班前的简短碰面来一起决定增加/减少哪些内容。

最开始的原型。在 Figma 中进行的,由方框和简单文案组成的原型图。分为消息模块和配置模块,每个模块的原型图下方列举了一些必做的功能清单。

然后也确定了我们三人小组的分工:

  • 我:前期负责设计界面、实现静态界面。后期参与 Prompt 调试。
  • 另一个设计师:负责界面设计、图标设计、PPT 制作/包装。
  • 研发大佬:负责功能实现,比如表单提交,发送和接收消息,接口调试等。

然后我们就各司其职,我这边按照大佬给的流程,每天把自己做好的部分提交 Pull requests,并标记清楚完成了哪部分,哪部分的功能需要研发大佬来实现等等。

Github 仓库的 Pull requests 截图。展示了 SQL-Helper 仓库中部分 Pull requests 记录,并且用带有圆角的绿色方框高亮由我提交的部分 Pull requests。

整体的时间表如下图(只有五个工作日,时间紧迫。):

时间表截图。记录了三个成员在周一至周五各自的工作,完成的工作会用绿色打勾图标来标记。

一些细节

初试 Ant Design 的感受

平常在设计稿中使用基于 Ant Design 组件的经验有很多,但是自己亲自在代码里使用该组件还是第一次。

一个强烈的感受是,Ant Design 组件库确实很丰富,很多常用的组件都有封装好,主题色更改的功能也很强大。但是想要基于 Ant Design 组件库来做一些客制化的改动,实在是太费劲了(也可能是因为我太菜...)。

比如当时我想实现一个 TextArea 根据容器高度来自动填满高度的话,我的样式代码是如此之多:

在深色主题下 Visual Code 中的代码截图。展示了我使用大量重复的样式来让一个 TextArea 组件自适应高度。

另一个坑是我们的聊天窗口是嵌入到网站当中的,而且原本我们公司的产品也是基于 Ant Design 组件库搭建的,所以会出现很多样式的冲突。

比如我在自己的界面中使用了 Button 组件,而被嵌入的网站中如果也用了 Button 组件,那么样式将会被原本网页覆盖掉。

如果在这种情况下想要自定义样式,需要在 CSS 中通过多种手段来提升样式的优先级。这里是我比较频繁用到的两个提高优先级的方法:

  • 使用选择器提高 Class 的优先级
  • 使用 !important
在深色主题下 Visual Code 中的代码截图。展示了我使用选择器和 !important 的方法来提升所编写的 Class 层级。
CSS 选择器的优先级相关内容可以参考张鑫旭大神的名著《CSS选择器世界》,写得特别详细。

所以后面回想起来,我在改造 Ant Design 组件库花的时间还是太多了。这个组件库可能在做复杂后台的时候好用,但在做这种小应用,发挥创意的地方,我觉得还限制还是太多了。我觉得我们最开始应该选择使用有更高扩展性的组件库,比如前段时间看到的 Radix UI

从文档来看,Radix UI 会组件里面每个 DOM 都提前命名好相关的 ClassName,那么用户在想自定义样式的时候,就方便很多了。

Radix UI 组件库的截图。展示了 Alert Dialog 组件的代码,并且用带有圆角的绿色方框高亮了代码中的四处 className。

对比起 Ant Design,引用一个组件进来后,会生成巨多个没有打标记的 DOM。每个 DOM 的样式巨难选择,想要改组件内某个元素的样式,没有熟练的 CSS 选择器功夫还真搞不定。

但还是得具体试一试才知道 Radix UI 是不是真的好用,或许也会暗藏某些坑。或许我应该拿自己的个人网站来试一试 🤔。

改造弹窗:拖拽和操作

由于这是一个嵌入在网页当中的对话窗口,本着提高一个易用性的初心,我觉得需要对弹窗组件进行魔改,支持以下两种特点:

  • 支持拖拽:允许用户拖拽弹窗标题区域,改变弹窗的位置,以免挡住原本页面中的元素。
  • 移除遮罩:不展示弹窗背后的黑色遮罩,并且弹窗出现的时候,不影响用户操作原本的网页。

仅仅是改造弹窗这块,足足花了我一天。严重影响了我调试 Prompt 的时间,所以感觉很有必要把它记录下来,即便我的做法绝非最佳实践。

拖拽

拖拽这块我是用了一个名为 DragM 的开源库来实现了,因为看到示例里面效果很不错,所以直接用上了。效果确实也很不错,强烈推荐。

过程有点丢人,就不详细描述了。大概是我参照示例代码做到了弹窗能够实现拖拽,但弹窗的关闭按钮却失效了,后面还是得靠研发大佬来修复。

允许操作背景

这个特点的实现简直是噩梦。Ant Design 文档是提供了一个 API 是能够允许我们隐藏掉黑色的遮罩。

Ant Design Modal 组件的 API 截图。用带有圆角的绿色边框高亮 Ant Design Modal的 API。该 API 控制是否展示 Mask,默认是展示的。

但是这只是让我们看不见遮罩,打开弹窗时,原本页面的元素仍然是无法点击的。所以我试了一些方法,比如说将每一个疑似是遮罩的 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 商品详情页 AI 功能截图。画面是一个卡片叠加在商家管理后台的商品详情页的富文本输入框上,该卡片左侧是一个纵向排列控件的配置面板,第一个是输入框,输入一些关于商品的关键字;第二个是调整文本风格的下拉菜单,第三个是额外的备注。然后右侧是由 AI 生成的文本,用淡紫色背景的文字来区分,并且提供赞和踩的反馈。卡片右下角是一个 Pointer 样式的鼠标指针,选停在保存按钮上方。

Shopify 将同样也是利用 LLM 来实现的生成文本能力,这被官方称为「Shopify Magic」。除了在商品详情页生成商品描述,也能在邮件当中根据活动类型或产品关键字生成邮件标题,或者在主题编辑器中根据要求来生成标题等等。

微软就不必多说了,也已经在 Microsoft 的办公软件上集成了很多 AI 功能。

代码仓库

这里放上我们产品的代码仓库吧,记录这段热血时光:

SQL-Helper · Github

最后,通过这次 AIGC Hackathon 活动,我真正参与到了产品的代码贡献,同时也看到了许多 AI 能力的应用场景。听说公司有产品在研究 AI 能力在业务中的应用,希望之后自己也有机会在商业项目上进行更多相关的实践吧!

近况

太久没发博客了,记录下我最近的状态吧。应该没有人想知道,但若干年后的我可能会想知道。

  1. 近沉迷于学习英文,所以会导致网站、博客的更新会比之前慢一些。
  2. 发现英文还挺有意思的,但在学生时代是看见英文就想睡觉。以前的我应该是比较喜欢数学和历史。
  3. 小目标是今年内能出一篇全英文的博客。全程用英文书写,然后在发布之前先给 ChatGPT 帮忙检查和润色一下。
  4. 个人网站 LRD.IM 正在开发支持切换语言至「英语」的功能。
  5. 有一个前端相关的分享会正在准备进行,是面向部门内产品、本地化运营和设计同事的。
  6. 在手机上开通了 ChatGPT Plus。直观感受是 GPT-4 的回答比 GPT-3.5 靠谱很多很多,应该会持续订阅。
  7. 正在尝试一种新的作息,再多体会一段时间后,可能也会在博客上记录。

用 Next.js 重构个人网站 (一):概述

By: 李瑞东
14 March 2023 at 22:03
封面图:Maxime Bourgeois

我的个人网站从 2017 年底(大四上学期的期末)进行 “研发”,2018 年初部署运行,现在已经过去了 5 年。中途经过大大小小近 300 次迭代和内容更新。

从原本只是用来放置我做 Side Project 成果的内容,到后来变成我对外展示的窗口,用来展示我在实际工作中的项目,以及设计博客和翻译的文章等。LRD.IM 的页面布局、风格样式、内容、功能等等随着我的设计生涯发展有着很大变化。

个人网站的发展过程图

互联网档案馆 Internet Archive 保留了 2019 年之后的存档。之后每一次改版我也会在该网站留下存档。不知 5 年后又会是啥样呢。🤔

唯一不变的是,它仍然是用纯粹的 HTML + CSS + JavaScript 来实现的。访问我的网站就像是打开一个文件夹,浏览器只是将我的 html 打开而已。

网站内部没有组件,没有数据源。改动一个公用的地方,如页面顶部导航栏或博客的文章添加一个模块时,我需要在编辑器里打开数十个 html 文件逐个修改。

自己一直有想着改造一波,但自己当前的水平,想做出一个现代化的个人网站还差很多。所以这个计划也就一直搁置,自己日常中最多是观察下其他优秀的个人网站及其实现方式,储备点灵感。

直到两个动机和一个条件的出现,我觉得是时候了。

动机和条件

动机:迭代频率

最开始我的博客页面只是一个列表,点击里面的文章都会跳转到 Medium 平台里面。后面我觉得这样做体验巨差,原因:

  • 自己创作的内容全部都放在别的平台上面去了。这是一个令我太不舒服的感受。我的想法是可以放到其他平台内,获取一点点流量和 SEO 的优势,但自己的站点是最优先的;
  • Medium 需要科学上网才能较好访问。读者的体验未必会好,从稳定性上考虑也不利于长期发展;
  • Medium 一直没有进步。感觉这几年这个平台在原地踏步,或者甚至是下坡路。这是我作为长期用户的主观感受。

所以后面我将 Medium 的文章导出成 HTML 文件(平台的功能),作出相应的调整后贴回自己的网站上面,这样文章就能又回到自己那儿了。

但这个转换的过程并不简单,Medium 导出的 HTML 是带有他们的一些标签和样式的,当时我是将每一篇文章的 HTML 都筛掉没用的内容,然后 CSS 里编写了一套自己的格式文本的样式,使其适应网站的设计风格。由于步骤太多我甚至还将做法记录了下来,发布文章之前任何一步有纰漏都会出问题。

Github 中我对 Medium 导出文章的处理方法

这套混乱的秩序维持了至少一年半,这期间我的每一篇文章都经过这样的处理。包括后面添加的「目录功能」、「博客功能区」等有新增或调整代码的时候,我都要在每一篇文章(40+ 篇)的对应位置里增删改。

这种手动、机械式、重复的工作不仅导致迭代网站的时间成本极高,也很容易出错

比如某篇博客的功能区,本身应该所有页面的这块内容都应该长得一样,只是日期不同,但就是因为我将数十个 html 文件逐个修改的时候出现了纰漏,导致某些页面的样式异常。

博客功能区异常和正常的对比
我将某段代码复制到该页面时可能某个地方出现了疏漏,就出现了样式异常。
这次重构我抛弃了 HTML,改成了用 MDX 来支持我的博客内容。之后的文章会介绍到我是如何用 mdx-bundler 来重构整个博客功能模块。以及我为了提升阅读体验所做的工作。

动机:体验问题

我对网站里面有一个非常刺眼的体验问题一直耿耿于怀。

暗色主题下刷新页面会出现闪烁
原本的做法下,亮/暗主题色的切换功能是写在 JS 文件里面。而用户在跳转页面时会重新加载一次文件,偶尔会出现令人难以接受的闪烁。

留意页面切换时的背景色闪烁问题。

我也带着这个问题咨询了前端工程师朋友,他认为如果将网站做成 SPA,应该就能解决这个问题。

单页应用(英语:single-page application,缩写SPA)是一种网络应用程序或网站的模型,它通过动态重写当前页面来与用户交互,而非传统的从服务器重新加载整个新页面。 — — 维基百科

而且对于主题色,其实最好是能给用户手动来切换,并且记录上次更改后的结果。但这个功能要做在静态网站上,而且想到有代码更改的话又得将数十个 html 文件逐个修改,实在是没有研究的动力了。

条件:离职之后

2022 年 11 月我从欢聚离职,回到老家,暂时离开城市和朋友圈。有充足的时间给我去学习这方面的知识,以及去做相关的实践。

技术栈

这次的重构我的个人网站并不是一时兴起,平常自己也会了解相关的资讯。既然选择了行动,就已经做好跳出舒适圈的准备,接触一些以往从没有实践过的内容。

Next.js

整个 2022 年,通过 Next.js 构建的网站挤满了我的推特信息流。时不时都会看到有些设计师/开发者在推特上发布自己的个人网站。也发现许多充满设计感的网站都是通过 Next.js 来做的,比如 LinearPipeFeyFrame.io 等。

设计的较好的网站截图示意

在一众先驱者的引导之下,我也去了解了下相关介绍,甚至还看了点 Next.js 初学者教程,里面大部分内容我大部分都能够 Get 到。感觉上手难度不大,又有这么多大佬级的网站做背书,于是乎,就是你了 — — Next.js!

Tailwind CSS

我选择使用 Tailwind CSS 的原因主要有两个:

第一个是这个网站做得很好看,包括它给出来的 Template,这让我有了进一步了解的兴趣;

第二个原因是这确实有效解决了在迭代原网站时让我烦恼的地方:

  1. 我基本上再也不用绞尽脑汁去想某一个元素的类名(还得是英文的,时间久了想不起来哪个样式用在哪);
  2. 在实际写代码的过程中也不用经常在页面和 CSS 文件中来回切换了。现在写反馈效果、媒体查询、深色样式时很方便;
  3. 最关键:我再也不用维护一个 2,000+ 行的层叠样式表了!重构后的 CSS 文件轻量了很多,因为都写进网页和组件中了。
使用 TailwindCSS 前后的代码量对比

Mdx-bundler

之前将 Medium 文章迁移过来的时候,就发现了 HTML 的做法只适合有富文本编辑器的平台。而像我这样式的多数在代码编辑器里面书写的话,可能 Markdown 更合适。

然后我是在 Tailwind CSS 的 Protocol 模版介绍当中了解到原来 MDX 是可以让 Markdown 和 Next.js 联动起来,然后也在 Josh 介绍自己的博客时。也有介绍到相关内容,于是就选择了 mdx-bundler 来实现我的博客模块。

Protocol 和 Josh 博客的截图

MDX 允许我们安装各种插件来增强博客的能力。比如支持到 Github Markdown 语法的插件 remark-gfm 和代码高亮插件 Rehype Pretty Code 等。

remark-gfm 和 Rehype Pretty Code 的截图

而且还能嵌入自己编写的 React 组件,这是让人感到惊奇的能力。这意味着我的博客文章可以不仅是图文、视频和 iframe 了,还能有一些互动元素,有很大的想象空间。

过程概述

由于我属于边做边学,所以整个重构的过程并非从头到尾一次性完成的。而是一个螺旋式上升的过程。

路线图:核心功能(设定通用布局和主要的样式、数据源和遍历、mdx-bundler 渲染博客文章) -> 填充内容(填充列表所需的文本、配图、URL等数据、用 Markdown 重写博客文章,并填入元数据、填充作品详情的内容) -> 带着过程中遇到的卡点和问题,在课程或其他开发者博客中学习理论知识 -> 将理论知识运运动到实际网站开发当中,解决问题和优化代码。
插图素材来自 egghead.io

第一步:核心功能

当时先完成核心或通用的功能部分(遇到难搞的功能先记录并跳过),然后将原站点的所有内容填充进去。
这时确保网站在本地环境中基本能正常跳转和响应点击,深色模式和响应式等适配工作需要完整做好,因为这方面是相对简单的工作。具体来说:

  1. 先学会 Tailwind CSS 和 Next.js 的配合使用,设定好通用的布局和主要样式。以及调试主要页面之间的路由跳转;
  2. 开始构建主要页面,学会运用数据源和循环遍历来呈现页面内容(完整的内容先不填充,确保循环能跑通,数据能正常获取);
  3. 尝试使用 mdx-bundler 来读取博客列表和渲染 Markdown 文章。这个模块特别重要,当时花了不少时间。

第二步:内容填充

这时会带着早些时候记录下来的问题和卡点,去耐心查阅并参考尝试其他开发者博客里面他们的实现方案,同时也进入 The Joy of React 课程当中系统地学习一遍 React 的基础内容。具体来说:

  1. 填充所有数据源和遍历中用到的内容,如某个字段的文本、配图的 URL 等;
  2. mdx-bundler 跑通之后,我用 Markdown 重写了所有的博客文章,并且每篇文章都填入相应的元数据;
  3. 填充所有作品详情页里的内容。

第三步:填坑优化

有了知识储备之后,最后再回头把原有的一些卡点和问题填补上,或者优化下原本的代码。甚至会改良下组件的命名、文件夹结构等等,这些会参考到其他开发者他们所总结出来的的最佳实践。

  1. 带着过程中遇到的卡点和问题,在其他开发者博客或课程中学习理论知识;
  2. 解决之前的卡点和问题,完成所有功能,以及边缘场景的处理;
  3. 看看原有代码有没有哪些地方可以改良;
  4. 重复「学习→解决→改良」步骤,直到网站达到了我认为能够部署的标准。

解决问题的方法

做一个网站实属不容易。尤其像我一样在自己的能力之外,选择用框架来实现,过程更加是绝非一帆风顺。不止跳出了舒适圈,甚至还跳进了「痛苦圈」。

技术方面的指引我不敢乱写,倒是可以分享下在这次重构的过程中,我用到的几个解决问题的方法:

搜索引擎和编程社区

一些广泛的问题我会找 Google 来帮忙,比如我想看看别人是怎么做亮/暗模式切换的,我会搜索类似 “next.js darkmode switch”,搜索结果中可能会出现一些开发者的博客、Stack Overflow 或 Github Issue 中提出相似问题的人,这些内容是我可以拿来参考的。

搜索+实践的示意图

ChatGPT

在去年 12 月 ChatGPT 横空出世,当时有看到很多推文有展示它的神奇功力。我甚至觉得它很多的回答比人来回答还要好,很清晰和有条理,让人感到意外。

我也利用上这股强大的力量,用 ChatGPT 来解决一些具体的问题。比如现在博客文章里面的目录,会查找页面内所有的H2 H3标签并生成为一个列表,这就是我向 ChatGPT 提出我的需求之后,它来帮我写出来的。

ChatGPT 帮我实现博客文章目录功能的回答

另外我也会让 ChatGPT 帮忙解释某段代码的意思或作用。我从搜索引擎或编程社区里获得的一些解决方案,有时候某些语句自己没看懂的时候,会需要 ChatGPT 来帮忙解释一下,好让我针对自己网站的特点作出些许改造,或者了解报错原因和解决方法。

Joy of React

即便 ChatGPT 能解决部分具体的问题,但也不是万能的。实际开发中有些特别具体的问题,始终还是要靠自己。我对 JavaScript 掌握的程度是属于半滴水(半桶水都算不上),对 React 以及里面的 JSX 语法更是完全没了解过。

简单的内容靠查阅文档 + 观察规律可以学会,比如我通过看其他人的案例,我大概知道了每个组件里面都要有一个export、return()里面只能有一个子标签、JSX 里面有一个特殊的标签是<> ... </>等等...

但稍微再具体一点的问题,比如根据某个条件来更改样式,或者甚至想直接做一个需要传递参数来改变展示方式的组件,这些特别个性化的内容想要光靠搜索引擎和 ChatGPT,效率太低了。很可能搜半天还是一头雾水,浪费光阴。

刚好在今年 1 月 24 日,前端大佬 Josh W. Comeau 发布了 The Joy of React 的教程,这是一份面向初学者的 React 教程。在里面我能系统地学到一些 React 相关的知识,或者课程中会用到的 JavaScript 的基础等。

Joy of React 课程介绍页
The Joy of React 的课程封面

这门课程对我的网站重构项目起了很大的帮助,学习后我弄清楚了一些 React 的运行规则,也确实做出了一些实用的组件,改进了页面的代码质量。之前一直卡住的、很具体的问题也在学习之后得到了解决。

这份 $50 左右的课程干货满满,作者也很用心地安排了每个章节会有互动性的练习,也会附带一些视频解说(有 CC 字幕和视频摘要)。后续我可能会出一篇文章来回顾下我在这个课程内学到的内容,记录下这段激情澎湃的青葱岁月。

请教专业人士

好吧,如果有些问题确实难搞,自己用尽所有的方法都没法解决,同时也在这个问题上耗费了很长时间的时候,我会咨询一些前端工程师朋友。

工作几年我一直和前端工程师的关系都也还行,所以有时候问到些问题他们也乐意帮我解答(还因为我的问题在他们眼里其实非常基础…)。

除了现实中认识的朋友以外,其实也可以咨询网络上的一些开发者。如果一个开发者将他的经验分享出来后,其他人使用过程中遇到问题,大部分都乐意帮忙解决的。

联系两位站长后帮忙解决问题的邮件

未完待续…

这一篇文章记录了重构我的个人网站 LRD.IM 时的经历,计划后面会有多几篇文章来记录具体我做到某个模块时的一些过程,或者说重构之后一些我认为比较有意思的改良等等,算是给这次重构计划一个交代。

本文于 2023 年 02 月 21 日首发于 LRD.IM
❌
❌