项目地址
- 在线预览：frontend-ai-assistant-two.vercel.app/
- GitHub 源码：github.com/hewq/dify-c…
说明：当前在线版本部署在 Vercel，国内网络访问可能不稳定。如果打不开，可以直接查看 GitHub 源码并在本地启动。
前言
我是一名前端开发工程师，已经工作了 10 年。
工作久了以后，会遇到一个很现实的问题：很多日常需求已经不再有太强的新鲜感。页面、表单、列表、权限、组件、状态管理、接口联调、性能优化，这些东西都做过很多遍。
如果公司最近事情不多，这其实是一个很好的窗口期：可以系统性地学一点东西，把自己从“资深前端开发”往更高阶的方向推一推。
一开始我也想过很多方向：
- 再深入学 React / Vue 源码
- 补 Webpack / Vite 原理
- 学微前端
- 学 Node.js 全栈
- 学性能优化
- 学低代码
- 学 AI
最后我决定从一个项目开始：
做一个 AI 知识库问答系统。
它不是一个单纯的 Demo，而是一个可以持续扩展的项目。这个项目可以串起 AI 应用开发、前端工程化、Node BFF、流式输出、RAG、会话管理、部署、数据库等一整套能力。
这篇文章是这个系列的第一篇，主要聊聊：为什么我选择这个方向，以及整个项目准备怎么做。
为什么不是再学一个前端框架？
前端技术一直在变化，但对一个有多年经验的前端来说，继续追逐“又一个框架”带来的边际收益其实没有以前那么高。
比如：
- 会 React，再学 Vue，不难
- 会 Vue，再学 Svelte，也不难
- 会 Webpack，再学 Vite，也不难
- 会 antd，再学 shadcn/ui，也不难
这些当然都有价值，但它们更多是在已有前端能力上的局部扩展。
工作 10 年后，更重要的问题变成了：
我能不能独立设计并交付一个完整产品？
这背后需要的不只是写组件能力，还包括：
- 技术选型
- 产品理解
- 前后端协作
- API 设计
- 数据流设计
- 工程化
- 性能体验
- 可维护性
- 部署上线
- 成本意识
所以我不想再单独学一个技术点，而是想通过一个完整项目，把这些能力串起来。
为什么选择 AI 知识库问答？
AI 应用现在非常适合前端工程师切入。
原因很简单：
大模型本身很强，但真正落地到产品里，仍然需要大量前端和工程能力。
一个 AI 知识库问答系统，看起来只是“用户提问，AI 回答”，但真正做起来会涉及很多细节：
- 文档上传
- 文本切片
- 向量检索
- Prompt 组装
- 流式输出
- 多轮对话
- 会话历史
- 错误处理
- 停止生成
- Markdown 渲染
- 代码高亮
- 引用来源
- API Key 安全
- 权限控制
- 数据持久化
- 部署上线
这些能力都和前端开发高度相关。
更重要的是，这个项目不是纯玩具，它有真实业务价值。企业内部知识库、客服助手、文档问答、研发助手、学习助手，本质上都可以基于这个思路扩展。
这个项目最终要做成什么样？
第一阶段目标不是做一个复杂平台，而是先做一个能跑通的 AI 知识库助手。
核心链路是：
用户输入问题
↓
前端发送请求
↓
服务端代理调用 Dify
↓
Dify 做知识库检索
↓
LLM 基于检索结果回答
↓
前端流式展示答案
↓
展示引用来源
最终希望具备这些能力：
- Dify 知识库问答
- DeepSeek 模型接入
- Vite + React 前端
- Express BFF 代理
- API Key 服务端保护
- SSE 流式输出
- Markdown 渲染
- 代码高亮
- 引用来源展示
- 多会话管理
- 会话本地持久化
- 停止生成
- 错误处理
- 组件拆分
- 自定义 Hook 状态管理
- ESLint / Prettier / TypeScript 工程化
- 后续接入 SQLite / Prisma
这个项目会从最小可用版本开始，一步一步加功能。
技术栈选择
前端
React
TypeScript
Vite
React Markdown
Highlight.js
选择 Vite 是因为它轻量、启动快，适合快速做项目原型。
后端
Node.js
Express
后端主要做 BFF 层，负责：
- 隐藏 Dify API Key
- 转发 Dify 请求
- 处理流式响应
- 统一错误处理
- 后续接入数据库
AI 应用层
Dify
DeepSeek
Dify 负责知识库、RAG、Chatflow 编排。DeepSeek 作为模型供应商，成本相对适合学习项目。
为什么要加 Express 代理？
一开始最简单的方式是：前端直接调用 Dify API。
但这个方式有一个严重问题：
Dify API Key 会暴露在浏览器里。
只要打开浏览器 DevTools，任何人都可能看到这个 Key。
所以更合理的结构是：
浏览器前端
↓
自己的 Express 接口
↓
Dify API
这样 Dify API Key 只存在服务端 .env 中，不会暴露给用户。
这也是一个很典型的 BFF 设计。
为什么要做流式输出？
AI 产品和普通接口最大的体验差异之一，就是流式输出。
如果用户提问后等 10 秒，最后一次性返回一大段文字，体验会很差。
更好的方式是：
用户发送问题
AI 立即开始逐字输出
用户持续看到反馈
这背后涉及：
- Dify streaming 模式
- SSE 数据格式
- ReadableStream
- TextDecoder
- 前端增量更新最后一条消息
- 停止生成
这部分会单独写一篇文章展开。
为什么要展示引用来源？
如果只是让 AI 回答，用户很难判断它到底是基于知识库，还是自己“编”的。
RAG 产品里非常重要的一点是：答案要可追溯。
也就是回答下面能看到：
引用来源：
- frontend-notes.md
这能提升可信度，也方便用户回到原文确认。
所以项目里会解析 Dify 返回的 retriever_resources，把引用来源展示出来。
为什么要做多会话？
单轮问答只是 Demo。
真正的 AI 助手一般都需要：
- 新建会话
- 切换会话
- 删除会话
- 重命名会话
- 搜索会话
- 保存历史记录
一开始我们会先用 localStorage 做本地持久化。
后面再迁移到服务端数据库，比如 SQLite + Prisma。
这样项目可以自然演进：
localStorage
↓
SQLite
↓
PostgreSQL
↓
用户系统
这个系列适合谁？
我觉得适合这几类人：
- 有一定前端经验，想切入 AI 应用开发
- 做了几年业务前端，想提升工程化和架构能力
- 想做一个能写进简历的 AI 项目
- 想理解 Dify / RAG / SSE / BFF 的实际用法
- 想从 Demo 逐步升级到产品雏形
如果你是完全零基础前端，这个系列可能会有一点快。
但如果你已经熟悉 React、TypeScript、接口调用、基础 Node，那会比较合适。
系列计划
这个系列会按真实开发顺序来写：
- 为什么选择 AI 知识库项目
- 用 Dify 搭建第一个 RAG 应用
- 解决 Dify Chatflow 上下文传递问题
- 用 Vite + React 调用 Dify API
- 用 Express 做 Dify 代理层
- 实现 SSE 流式输出
- Markdown 渲染与代码高亮
- 展示知识库引用来源
- UI 优化与组件拆分
- localStorage 会话持久化
- 多会话管理
- 停止生成与错误处理
- 自定义 Hook 重构状态管理
- Express 服务端分层
- ESLint / Prettier / TypeScript 质量门禁
- 部署方案选择
- SQLite + Prisma 数据库存储
后续如果继续扩展，还可以做：
- 用户登录
- 云端会话同步
- 文件上传
- 知识库管理
- 权限系统
- Docker 部署
- CI/CD
- 前端监控
- 成本统计
总结
对一个有多年经验的前端来说，AI 知识库项目是一个很好的升级入口。
它不是单点技术学习，而是一个完整项目：
AI 应用能力
+ 前端工程能力
+ Node BFF 能力
+ 产品体验能力
+ 工程化能力
这个系列会从最小 Demo 开始，一步一步把它做成一个可维护、可展示、可继续扩展的 AI 产品雏形。
下一篇开始，我们先用 Dify 搭建第一个 RAG 知识库应用。
