大家好，我是双越老师～
背景
最近这 2 个月我一直致力于【划水AI】项目的研发，最近终于有了阶段性的进展：即将开启第一期的内部测试。
本文分享这段时间的开发过程和一些思考，包括：技术选型，项目搭建，富文本编辑器，AI 写作，AI 处理文本，CI/CD 等。
当前开发的仅仅是一期的功能，待一期测试、上线稳定以后，我会再逐步迭代二期、三期。2024年专心搞好这个项目。
为何要做这件事
早在今年 3 月我就发表过一篇文章 前端转全栈: Next.js + ChatGPT 开发 AIGC 知识库(AI 写作) 欢迎围观~ 得到很多同学的关注和点赞，这也鼓励我从 4 月开始就投入该项目的设计和开发。
我觉得，作为一个自由开发者，必须要有自己的技术产品，自己的代表作。当年我在百度、滴滴工作时，公司项目是我的技术产品，后来离职了 wangEditor 就是我的代表作。再后来我宣布不再维护 wangEditor ，就需要新的个人代表作，我选择了去开发这个项目：AIGC 知识库平台。
不过，开发这样一个产品是非常具有挑战性的，它比制作一门 ke程 可麻烦多了，比开发 wangEditor 也要麻烦。
- ke程 中的项目一般都是本地开发、演示，然后讲解清楚就好了。而 划水AI 是要真实上线的，一上线就有带来各种问题和挑战。如，各种线上服务（域名、证书、服务器、Serverless、数据库、存储、统计等）需要购买和管理，线上用户多了会遇到各种 bug 和优化，需要持续迭代升级。
- wangEditor 只是前端的一个工具，而 划水AI 是一个全栈项目，就像前者是发动机，后者是整车，它俩不是一个级别的东西。
- 有时候会费力不讨好。大家更喜欢看各种标题党文章、视频，很少会有人能踏实的关注一个复杂的项目，这是难免的。PS：所以目前收获这么多支持，我觉得非常难得，感谢所有支持者。
但挑战，也就代表着能力。做有挑战性的事情，并且能做出来，能做好，这就代表着个人综合技术能力和经验。
这和你们写简历是一样的，通过写上各种 nb 的项目、亮点，来证明自己的技术能力和工作能力。
我也需要不断的提升自己、证明自己，用真实的项目去证明，而不是光做个ke程、写个文章、录个视频 ------ 那都是次要的。
技术选型
这次我毫不犹豫的选择了 node 全栈，且倾向于 React 选择了 Next.js 。前端技术栈已经稳定了，未来前端破局的方式就是全栈，这个在国外已经实践了两三年了。
有些同学评论说：后段不应该用 node 应该用 java python 或者 go ，这话是没毛病的。但是呢，我不会 java python 和 go ，如果现学现卖的话，技术栈转行可是不容易。而且，我们开发的就是一个 web 应用，没有太多过于复杂的功能，node 是完全可以应对的。至于说 node 性能不好，我可以在硬件配置方面弥补，成本不大。
倾向于 React ，第一是我个人更喜欢 React 一些，第二是我评审过很多前端简历，看到好多人只会 Vue 不会 React ，我就更想通过一个 React 项目来帮助大家。其实我还写过一篇文章 React 和 Vue 对比 22 个方面，React 更简单
Next.js 是最流行的 node SSR 框架，母公司 vercel 的商业化也做的非常成功。近期 React19 即将发布，一些更新也能说明 React 自己也是往 Server component 方面发力。
所以，选择 node 全栈没问题，选择 React 更没问题。
架构设计
整体架构设计如下图。
开发过程
当前开发的是一期功能。待一期测试、上线稳定以后，会再继续迭代升级二期、三期，到时再分享。
分 4 个阶段
第一阶段主要是搭建项目环境，开发基础的 UI 结构，开发基础的功能，如数据库操作、用户登录等。最后能跑通基础的增删改查流程即可，比较简单，好入门。
第二阶段主要开发富文本编辑器的功能，使用 tiptap ，引入基础功能，开发自定义扩展功能，开发各种菜单。最后做出一个简洁易用的 block-editor ，下文有截图。
第三阶段主要对编辑器进行性能和体验的优化，开发图片上传功能，并开发左侧列表的层级结构（这部分也很麻烦），还有删除、收藏、搜索等，最后得到一个完善的知识库平台。
第四阶段主要集成 AI 接口，包括 AI 写作、AI 处理文本，还有 AI 接口报错的兼容、中止 AI 请求，还有限制 AI token 数量，定期领取，防止滥用。
每天我都会详细记录研发过程，包括设计、思考、调研、查询的过程，bug 的解决过程，还有详细的代码提交记录。跟着这份资料，你能体验真实项目的研发过程，积累真实项目经验，也能开发出同样的项目功能。
block-editor 块编辑器
基于 tiptap 开发 block editor ，支持各种常见的富文本格式。并且实现了 slash command ，即在编辑器中输入 / 即可唤起格式菜单，如下图。
PS：富文本编辑器这部分的开发是非常麻烦的，但我记录的很详细，很多同学都跟着做出来了。
阿里云 OSS + CDN 存储图片
开通阿里云 OSS 和 CDN 功能（这俩都可免费使用），开发图片上传服务，并集成到 tiptap 编辑器中。
功能开发以后，我又做了很多优化（为了性能、用户体验、存储带宽等费用），这部分很有意思。例如：
- 上传时压缩图片尺寸和体积，通过 Canvas 压缩
- 下载时，压缩图片尺寸，通过阿里云 OSS 提供的动态尺寸参数
- 上传过程中可预览图片，增强使用体验
- 图片加载过程中，提前占位，防止重绘重排时的抖动
- 上传图片时，动态设置宽度，防止"高瘦型"图片宽度 100% 而占用很大高度
- 图片懒加载
如下图，这个图片的原始文件有 2M ，经过上述一系列优化后，网页中显示只有 422kb ，优化掉 80%
调用 ChatGPT API 实现 AI 写作功能
在项目开始之前我就有调研，并记录文章 用 Node.js 调用 ChatGPT API 实现 Stream 流式聊天效果
基于这个能力，再结合富文本编辑器，实现了 AI 写作功能。包括：续写、头脑风暴、写大纲、写总结，或者自定义命令。如下图
还有 AI 处理文本，在编辑器中选中一段文本，可交给 AI 操作：扩展、精简、切换语气、翻译、解释、修复语法错误等。如下图
还有，每个人都限制了 AI token 的使用数量，如果不够用可以每周定期领取一部分。AI token 也是需要购买的，所以要防止滥用，而且要考虑未来商业化的可能。
设想一下，如果你是一名文字工作者，经常需要写一些内容或者创意，有了 AI 写作的加持，那工作效率就大大提高。
即便你是程序员，每周写写周报，写工作总结，使用 AI 辅助也比你自己写的要好很多。
Github Action + Docker 部署测试机
划水AI 项目分为多个环境：开发环境，测试环境，预览环境，线上环境。真实项目一般都这样分。
测试环境使用 Github Action 做 CI/CD ，使用 Docker 部署到一台 Linux 机器，是亚马逊 AWS 的云服务器。
在此前的部署过程中，经常遇到 255 报错，不是很稳定。后来经过综合分析，彻底解决了这个问题，原因和解决方案我都记录的很清楚。
阿里云 FC Serverless 部署预览环境
预览环境和线上环境，使用 Serverless 服务（不用考虑配置，按量付费），即阿里云函数计算 FC 。配置连接 github 代码库，提交代码会自动触发应用部署，CI/CD
如有报错，可以通过调用请求和函数日志，查看到报错信息
最近就遇到过几次 maxMemoryUsage 报错，经排查是在 Server Action 中使用 redirect 导致的问题。
这就是真实上线的项目，你会遇到很多问题（本地开发遇不到的），甚至很多怪异的、不常见的问题。你要努力排查、分析、解决这些问题 ------ 这就是你的真实项目经验。
内部测试
无论是内部测试，还是公开测试，除非正式上线，都需要限制用户自由注册。为此我开发了邀请码机制，测试用户需要验证邀请码，否则无法访问功能。
我还整理了详细的测试用例，测试人员要覆盖这些功能点，并给出测试反馈。测试也要体系化、规范化，不是瞎点一顿。
参与内部测试、公开测试，可以亲自体验一个真实项目的测试过程，这也是难得的项目经验积累。
我的开发感受
我的最大感受是：一个真实上线、业务复杂的项目，所带来的冲击。这是本地开发 demo 得不到的。
参与项目的很多同学在qun里讨论说：跟着 wiki 和代码做能做出来，但自己做不出来。有很多功能不知道如何从 0 开始设计，很多流程不知道如何搭建，甚至都不知道需要什么流程，什么方式是最佳的。
CI/CD 流程、测试机、预览环境的一些报错，分析解决这些问题的过程，都是这个项目独有的。
写简历或者面试，总是会谈到项目的亮点，其实能解决实际的问题就是亮点。公司招聘为何那么看重实际项目经验，尤其是大厂、复杂项目的实际经验？也是这个原因。一个线上、复杂的项目，能顶 100 个本地练手的 demo 项目。
未来计划
先完成当前功能的测试（内部测试、公开测试）和上线。测试期间还需要修改 bug ，增加统计、监控、报警等功能，做一些提高稳定性的建设。
上线后，再去迭代开发二期、三期，如协同编辑、VIP 、手机号登录等。关注我，到时再分享。