基于HuggingFace Chat-UI快速构建大语言模型对话应用

feizai yun

343人浏览 · 2026-05-07 10:10:20

feizai yun · 2026-05-07 10:10:20 发布

1. 项目概述：一个开箱即用的对话界面构建器

如果你正在寻找一个能快速将大语言模型（LLM）能力转化为直观、美观、可部署的聊天应用的工具，那么 huggingface/chat-ui 绝对值得你花时间深入研究。这个项目，简单来说，就是由 Hugging Face 官方维护的一个现代化、功能齐全的聊天界面前端。它不是一个独立的服务，而是一个强大的“壳”，专门用来连接和展示后端的大语言模型。

在过去一年里，我亲眼见证了无数团队和个人在尝试构建自己的 AI 对话应用时，花费了大量精力在前端界面的开发上——从消息气泡的样式、对话历史的管理，到复杂的流式输出渲染、文件上传预览，每一个细节都耗时耗力。而 chat-ui 的出现，几乎完美地解决了这个痛点。它提供了一个生产就绪级的 React 前端，你只需要关心如何将你的模型 API 对接到它的标准接口上，一个功能堪比 ChatGPT 的 Web 应用就诞生了。无论是用于内部工具演示、产品原型开发，还是作为开源模型的服务门户，它都能极大地缩短开发周期，让你专注于模型本身的能力优化和业务逻辑。

这个项目适合所有需要与 LLM 进行交互式前端开发的开发者、研究者以及产品经理。对于前端经验不那么丰富的 AI 工程师，它让你免于陷入 CSS 和状态管理的泥潭；对于追求效率的全栈开发者，它提供了一个高度可定制且代码质量优秀的基础模板。接下来，我将带你深入拆解这个项目的设计思路、核心功能，并分享如何从零开始将其部署并与你自己的模型进行集成。

2. 核心架构与设计哲学解析

2.1 为什么是“聊天界面即项目”？

在深入代码之前，理解 chat-ui 的设计哲学至关重要。它不是一个全栈应用，而是一个纯粹的前端客户端。这种定位非常巧妙，它遵循了前后端分离的现代 Web 开发最佳实践。后端（你的模型服务）负责处理复杂的 AI 推理、上下文管理、知识库检索等重型任务，并通过标准的 API（通常是 OpenAI 兼容格式）提供能力。前端（ chat-ui ）则专注于提供最佳的用户交互体验。

这种分离带来了巨大的灵活性。你的后端可以用任何语言编写（Python、Go、Rust），部署在任何地方（本地服务器、云服务、边缘设备），只要它能够响应 chat-ui 所期望的 API 请求格式。同时， chat-ui 本身也可以独立升级，享受社区在 UI/UX 上的持续改进，而无需改动你的模型服务代码。这种设计使得技术栈的选择和迭代变得非常清晰和低耦合。

2.2 技术栈选型：现代前端框架的集大成者

chat-ui 选择了 React + TypeScript + Vite 作为其技术基底，这是一个经过市场充分验证、兼具开发效率与性能的黄金组合。

React 18+ : 提供了强大的组件化能力和声明式 UI 编程模型。 chat-ui 充分利用了 React 最新的特性，如并发特性（Concurrent Features）来优化大量消息渲染时的用户体验，确保界面在流式输出大量文本时依然保持流畅。
TypeScript : 对于这样一个涉及复杂状态（对话、模型列表、配置项）的项目，TypeScript 提供的静态类型检查是保障代码质量和开发体验的基石。它明确定义了与后端 API 交互的数据结构（请求体、响应体），极大地减少了因数据类型错误导致的运行时问题。
Vite : 作为新一代的前端构建工具，Vite 的快速冷启动和高效的热更新（HMR）为开发体验带来了质的飞跃。在开发 chat-ui 并频繁修改样式、逻辑时，你能感受到几乎实时的反馈，这大大提升了开发效率。

此外，项目还集成了诸如 Tailwind CSS 进行原子化样式设计，使得 UI 定制变得异常简单；使用 zustand 进行轻量级的状态管理，避免了 Redux 的繁琐，又能清晰管理全局的对话状态、设置状态等。

注意：虽然 chat-ui 的技术栈很现代，但并不意味着你必须精通所有这些技术才能使用它。对于只想部署使用的用户，你完全可以直接构建和运行。只有当你需要深度定制界面或功能时，才需要深入了解这些框架。

2.3 核心数据流与组件结构

理解数据流是定制和调试的基础。 chat-ui 的核心数据流可以概括为“用户输入 -> 前端状态更新 -> API 请求 -> 流式响应解析 -> 前端状态更新 -> UI 渲染”。

用户交互触发 ：用户在输入框发送消息或上传文件。
状态管理 ： zustand 的 store 会创建一个新的消息对象，包含内容、角色（user）、时间戳等，并将其添加到当前对话的消息列表中，同时界面立即显示这条用户消息。
API 调用 ：前端根据配置（模型端点、API Key 等）构造一个符合 OpenAI 格式的 POST 请求，发送到指定的后端 /api/chat/completions 端点。关键点在于，它设置了 stream: true ，要求服务器返回流式响应。
流式处理 ：前端通过 EventSource 或 fetch 的流式 API 读取服务器返回的 SSE（Server-Sent Events）数据流。它会实时解析每个 chunk（数据块），提取出模型生成的文本片段。
实时渲染 ：每解析出一个文本片段，就立即更新到对应助手（assistant）消息的内容中。这就是我们看到打字机效果（逐字输出）的实现原理。
状态持久化 ：对话结束后，完整的对话历史会被保存到前端的持久化存储（如浏览器的 IndexedDB 或配置的数据库）中，以便下次访问时恢复。

在组件层面，项目结构清晰：

components/ : 存放所有可复用的 UI 组件，如 Message （消息气泡）、 ModelSelector （模型选择下拉框）、 FileUploader （文件上传组件）。
stores/ : 包含 zustand 的状态定义，如 useChatStore （管理所有对话和消息）、 useSettingStore （管理模型配置、参数设置）。
pages/ : 主要的页面组件，如聊天主界面。
types/ : 集中定义所有 TypeScript 接口，尤其是与后端 API 交互的请求/响应类型。

3. 核心功能深度拆解与实操要点

3.1 多模型支持与动态端点配置

这是 chat-ui 最实用的功能之一。它允许你在一个界面中无缝切换不同的后端模型。

实现机制 ：在设置中，你可以配置一个“模型列表”。这个列表本质上是一个 JSON 数组，每个模型对象定义了其显示名称、唯一的 ID、以及对应的 API 端点 URL。当用户切换模型时， chat-ui 只是将后续的所有 API 请求发送到新模型对应的端点。

实操配置示例 ：你可以在环境变量或设置文件中这样配置：

{
  "models": [
    {
      "id": "local-llama3",
      "name": "本地 Llama 3 8B",
      "endpoint": "http://localhost:8080/v1",
      "apiKey": "sk-no-key-required"
    },
    {
      "id": "openai-gpt4",
      "name": "OpenAI GPT-4",
      "endpoint": "https://api.openai.com/v1",
      "apiKey": "sk-your-openai-key-here"
    },
    {
      "id": "claude-3-haiku",
      "name": "Anthropic Claude 3",
      "endpoint": "https://api.anthropic.com/v1",
      "apiKey": "sk-your-anthropic-key-here"
    }
  ]
}

注意事项 ：

API 兼容性 ： chat-ui 默认期望后端完全兼容 OpenAI Chat Completions API 格式。这意味着你的后端 /v1/chat/completions 接口需要接受相同结构的 JSON 请求体，并返回相同结构的响应（尤其是流式响应格式）。许多开源模型服务框架，如 vLLM , TGI , Ollama , LocalAI 等都提供了这种兼容模式。
API Key 处理 ：前端会将配置的 apiKey 通过请求头（ Authorization: Bearer <apiKey> ）发送。对于本地无需鉴权的模型，可以像示例一样设置一个虚拟值，并在后端忽略它。 切勿在前端代码中硬编码真实的云服务 API Key ，而应通过环境变量或安全的配置服务注入。
模型能力差异 ：不同模型支持的参数（如 max_tokens , temperature ）范围可能不同。 chat-ui 提供了通用的参数滑块，但最佳值需要根据具体模型调整。

3.2 对话历史管理与持久化

一个优秀的聊天应用必须能妥善管理对话历史。 chat-ui 在这方面做得相当完善。

核心特性 ：

对话列表 ：左侧边栏展示所有历史对话，可以按时间排序，支持重命名、删除、置顶。
自动保存 ：每当对话有更新（新消息、标题生成），变化都会自动保存。
多存储后端 ：这是其强大之处。它支持多种持久化方式：
- 浏览器存储 ：默认使用 IndexedDB，适合个人临时使用。
- 数据库存储 ：可以配置连接到 PostgreSQL、MySQL 等数据库，实现跨设备、跨会话的历史同步，适合团队协作或生产环境。
- 文件系统 ：在特定部署环境下（如 Docker 卷），也可以保存到文件。

实操心得：选择正确的存储后端

个人开发/测试 ：直接用默认的浏览器存储，最简单。
团队内部工具 ：强烈建议配置 PostgreSQL。你需要运行一个数据库，并在 chat-ui 的环境变量中设置 DATABASE_URL 。这样，任何团队成员登录后都能看到完整的对话历史，便于知识共享和问题追溯。
数据安全 ：对话历史可能包含敏感信息。如果使用数据库，务必确保数据库连接本身是安全的（使用 SSL），并考虑对存储的消息内容进行加密。 chat-ui 本身不提供加密功能，这需要你在后端或数据库层面实现。

配置数据库连接的 .env 文件示例 ：

DATABASE_URL=postgresql://username:password@localhost:5432/chatui_db
NEXTAUTH_SECRET=your-strong-secret-key-here
NEXTAUTH_URL=http://localhost:3000

配置好后，项目在启动时会自动运行数据库迁移脚本，创建所需的表结构。

3.3 文件上传与多模态交互

现代 LLM 正朝着多模态方向发展。 chat-ui 内置了文件上传功能，允许用户将图像、PDF、文本文件等上传并作为上下文的一部分发送给模型。

工作原理 ：

前端处理 ：用户选择文件后，前端会读取文件，并将其转换为 base64 编码的字符串，或者直接作为 FormData 的一部分。
API 请求 ：文件内容被嵌入到消息体中。对于兼容 OpenAI 格式的多模态模型（如 GPT-4V），文件信息会按照特定的格式（如 image_url ）放入 messages 数组的 content 字段中。
后端处理 ：后端需要有能力解析这种包含多部分内容的请求。对于图像，可能需要先调用视觉编码器；对于 PDF/文本，可能需要先进行文本提取。处理后的结果再送入 LLM。

实操要点与限制 ：

后端支持是关键 ： chat-ui 只负责“发送”文件数据。你的后端模型服务必须能够接收并处理这些数据。例如，如果你部署的是纯文本模型，上传图片将毫无意义，甚至会导致 API 错误。
文件大小限制 ：为了避免请求过大和超时，前端和后端都应该设置文件大小限制。这通常需要在后端的反向代理（如 Nginx）和模型服务本身进行配置。
预览功能 ： chat-ui 会对上传的图片进行缩略图预览，对于 PDF 和文本文件则会显示文件名和图标。这是一个很好的用户体验细节。
安全考虑 ：允许文件上传存在安全风险（恶意文件、存储空间耗尽）。在生产环境中，务必在后端对文件类型、大小、内容进行严格校验和扫描。

3.4 参数化配置与系统提示词

为了让用户能精细控制模型行为， chat-ui 暴露了所有关键的生成参数。

可调参数包括 ：

Temperature（温度） ：控制输出的随机性。越低（接近0）输出越确定、保守；越高（接近1或2）输出越随机、有创意。
Max Tokens（最大生成长度） ：限制模型单次回复的最大长度。需要根据模型上下文窗口和你的需求合理设置，设置过小可能导致回答被截断。
Top P（核采样） ：另一种控制随机性的方法，与 Temperature 通常只需调整一个。
系统提示词 ：这是一个极其强大的功能。你可以为每个对话或每个模型预设一段“系统提示词”，它会在后台被插入到每次请求消息列表的最前面，用于设定模型的角色、行为准则和回答风格。例如，你可以设置：“你是一个专业的代码助手，只回答与技术相关的问题，用中文回复。”

实操技巧：系统提示词的妙用 系统提示词是引导模型行为的隐形指挥棒。通过精心设计提示词，你可以让同一个模型服务于不同场景：

客服机器人 ：“你是一个友好、专业的客服代表。请先问候用户，然后简洁准确地回答关于产品功能、价格和售后政策的问题。如果不知道答案，请引导用户联系人工客服。”
代码审查助手 ：“你是一个经验丰富的软件工程师。请仔细分析用户提供的代码，指出潜在的错误、性能问题、不符合编码规范的地方，并给出修改建议。优先关注安全漏洞和逻辑错误。”
创意写作伙伴 ：“你是一个充满想象力的作家。请用生动、优美的语言进行创作。鼓励用户，提供多个角度的灵感，但不要直接完成整个故事，而是通过提问引导用户思考。”

在 chat-ui 的设置中，你可以为不同的模型配置不同的默认系统提示词，实现开箱即用的场景化体验。

4. 从零到一的完整部署与集成指南

4.1 环境准备与项目获取

首先，确保你的开发环境已就绪：

Node.js : 版本 18 或更高。推荐使用 nvm 管理 Node 版本。
包管理器 : npm , yarn 或 pnpm 均可。本文以 pnpm 为例，因其速度更快。
Git : 用于克隆代码。

步骤 1：克隆项目

git clone https://huggingface.co/spaces/huggingface/chat-ui
cd chat-ui

注意：官方仓库位于 Hugging Face Spaces，这确保了代码的官方性和稳定性。你也可以 fork 一份到自己的 GitHub 进行定制开发。

步骤 2：安装依赖

pnpm install

这个过程会下载所有必要的 JavaScript 包。如果遇到网络问题，可以尝试配置国内镜像源。

步骤 3：配置环境变量 项目根目录下有一个 .env.local.example 文件，复制它并重命名为 .env.local ：

cp .env.local.example .env.local

然后编辑 .env.local 文件，这是配置应用行为的关键。以下是一些核心配置项：

# 应用运行的主机名和端口
HOST=localhost
PORT=3000

# 数据库连接（如果使用数据库持久化）
# DATABASE_URL=postgresql://user:pass@localhost:5432/dbname

# 认证相关（可选，用于多用户管理）
# NEXTAUTH_SECRET=your-secret-key
# NEXTAUTH_URL=http://localhost:3000

# 模型配置：可以通过环境变量预置模型，也可以在运行时通过UI添加
# NEXT_PUBLIC_DEFAULT_MODELS=[{"id":"local-model","name":"My Local Model","endpoint":"http://localhost:8080/v1","apiKey":"sk-no-key"}]

对于初次尝试，你可以先保持 .env.local 相对简单，主要关注模型配置。

4.2 连接后端模型服务

这是最关键的一步。 chat-ui 需要一个兼容 OpenAI API 的后端。这里以两个最流行的开源方案为例。

方案 A：连接 Ollama（本地运行模型的最简单方式）

Ollama 是一个强大的本地大模型运行框架，它自带了一个兼容 OpenAI 的 API 服务器。

安装并运行 Ollama ：访问 Ollama 官网下载安装，然后拉取一个模型并运行服务。

# 拉取模型（例如 Llama 3 8B）
ollama pull llama3:8b
# 启动 Ollama，默认 API 在 http://localhost:11434
ollama serve

配置 chat-ui ：在 chat-ui 的 .env.local 文件中添加模型配置：
```
NEXT_PUBLIC_DEFAULT_MODELS=[{"id":"ollama-llama3","name":"Ollama Llama3","endpoint":"http://localhost:11434/api","apiKey":"ollama"}]
```
Ollama 的 API 路径通常是 /api ，且默认不需要有效的 API Key，这里填 ollama 作为占位符即可。
启动 chat-ui ：
```
pnpm dev
```
访问 http://localhost:3000 ，在模型选择下拉框中就应该能看到 “Ollama Llama3” 这个选项了。

方案 B：连接 vLLM 或 Text Generation Inference（高性能生产级部署）

对于需要更高吞吐量和并发能力的生产环境， vLLM 或 Hugging Face 的 TGI 是更好的选择。

启动 vLLM 服务器 （以 Llama 3 为例）：

# 使用 vLLM
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Meta-Llama-3-8B-Instruct \
    --served-model-name llama-3-8b \
    --api-key token-abc123 \
    --port 8080

这个命令会启动一个服务在 http://localhost:8080/v1 ，并提供了一个 API Key。

配置 chat-ui ：

NEXT_PUBLIC_DEFAULT_MODELS=[{"id":"vllm-llama3","name":"vLLM Llama3 8B","endpoint":"http://localhost:8080/v1","apiKey":"token-abc123"}]

启动并测试 ：启动 chat-ui 后，选择对应模型即可开始对话。

4.3 构建与生产环境部署

开发环境使用 pnpm dev 很方便，但生产环境需要构建优化后的版本。

步骤 1：构建静态文件

pnpm build

这个命令会执行 TypeScript 编译、代码优化、打包等操作，生成一个 .next 目录，里面包含了优化后的应用。

步骤 2：运行生产服务器

pnpm start

现在应用运行在生产模式下，性能更好，但错误信息不会像开发模式那样详细。

生产部署选项 ：

Docker（推荐） ：项目提供了 Dockerfile 。你可以构建镜像并运行容器，这能确保环境一致性。
```
docker build -t chat-ui .
docker run -p 3000:3000 --env-file .env.production chat-ui
```
你需要创建一个 .env.production 文件，包含所有生产环境所需的变量（如数据库连接、密钥）。
云平台 ：你可以将构建好的应用部署到 Vercel、Netlify（需要适配为 SSR）、或任何能运行 Node.js 的云服务器（如 AWS EC2、Google Cloud Run）。部署时，务必设置好环境变量。

4.4 界面定制与主题修改

chat-ui 的界面采用 Tailwind CSS，定制起来非常灵活。

修改主题颜色 ：主要的样式定义在 tailwind.config.js 文件中。你可以修改 theme.extend.colors 部分来定义自己的主色调。

// tailwind.config.js
module.exports = {
  theme: {
    extend: {
      colors: {
        primary: {
          50: '#eff6ff',
          100: '#dbeafe',
          // ... 定义你的颜色梯度
          900: '#1e3a8a',
        },
      },
    },
  },
}

然后，在项目中搜索原有的颜色类（如 bg-blue-500 ），将其替换为你自定义的 bg-primary-500 。

修改布局或组件 ：直接编辑 components/ 目录下的 React 组件即可。例如，想修改消息气泡的样式，可以编辑 components/Messages/Message.tsx 文件。想调整布局结构，可以修改 pages/index.tsx 。

隐藏或禁用功能 ：如果你不需要某些功能（比如文件上传、模型切换），可以在代码中找到对应的 UI 组件并将其注释掉或通过条件渲染隐藏。更优雅的方式是通过环境变量来控制功能的显隐，但这需要你修改代码逻辑。

实操心得 ：在定制前，建议先 fork 官方仓库，在自己的分支上进行修改。这样你可以随时同步官方的更新，并通过 git 合并来处理冲突。对于小的样式调整，直接覆盖 CSS 类可能比修改配置文件更快捷。

5. 常见问题排查与性能优化实录

在实际部署和使用 chat-ui 的过程中，你肯定会遇到各种各样的问题。下面是我总结的一些典型问题及其解决方案。

5.1 连接后端失败的排查步骤

问题现象 ：在 chat-ui 中选择模型后发送消息，界面长时间显示“正在思考”，然后报错“Network Error”或“Failed to fetch”。

排查流程 ：

检查后端服务状态 ：首先确认你的模型服务（Ollama, vLLM等）是否正在运行。使用 curl 或浏览器访问其健康检查端点（如 http://localhost:11434/api/tags 对于 Ollama）。
检查网络连通性 ：确保 chat-ui 前端（通常在浏览器中）能够访问后端服务的地址和端口。如果前后端部署在不同机器或 Docker 容器中，检查防火墙、安全组规则和 Docker 网络配置。
- Docker 容器间通信 ：如果 chat-ui 和模型服务都在 Docker 中，使用 Docker 网络或通过宿主机的 host.docker.internal （Mac/Windows）或 172.17.0.1 （Linux）进行通信。
检查 CORS（跨域资源共享） ：如果前端和后端域名/端口不同，浏览器会因同源策略阻止请求。你需要在后端服务的响应头中添加 CORS 允许头。
- 对于 vLLM ：启动命令中添加 --cors-origins "*" （生产环境应替换为具体前端域名）。
- 对于自定义后端 ：确保你的后端服务器在响应 OPTIONS 预检请求和 POST 请求时，包含正确的 Access-Control-Allow-Origin 、 Access-Control-Allow-Methods 、 Access-Control-Allow-Headers 头。

检查 API 路径和格式 ：确认


   chat-ui

中配置的


   endpoint

是否正确。完整的聊天请求路径是


   {endpoint}/chat/completions

。用


   curl

模拟请求测试：

curl -X POST http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer your-api-key" \
  -d '{
    "model": "llama-3-8b",
    "messages": [{"role": "user", "content": "Hello"}],
    "stream": true
  }'

观察后端是否返回流式数据。

查看浏览器开发者工具 ：打开浏览器的 Network 面板，查看失败的请求详情。检查请求 URL、Headers、Payload 是否正确，以及响应的状态码和错误信息。

5.2 流式输出中断或显示异常

问题现象 ：回复生成到一半突然停止，或者出现乱码、重复的 token。

可能原因与解决 ：

网络不稳定 ：流式连接对网络稳定性要求较高。检查网络是否有波动。对于生产环境，确保服务器有稳定的网络连接，并考虑使用 WebSocket 作为更可靠的替代方案（但 chat-ui 默认使用 SSE）。
后端生成错误 ：模型在生成过程中可能遇到内部错误（如显存溢出、tokenizer 异常），导致流提前关闭。查看后端服务的日志，通常会有更详细的错误信息。
前端解析错误 ：SSE 流的数据格式必须是 data: {...}\n\n 。如果后端返回的格式不正确，前端解析就会失败。确保后端严格遵循 Server-Sent Events 规范。
上下文长度超限 ：如果对话历史很长，超过了模型的上下文窗口，后端可能会截断或报错。尝试在 chat-ui 中减少“上下文消息数”的设置，或者使用支持更长上下文的后端模型。

5.3 性能优化建议

随着对话历史增长或用户量增加，你可能会遇到性能瓶颈。

前端优化 ：

虚拟滚动 ：对于超长的对话历史，渲染所有消息气泡会非常消耗性能。可以考虑为消息列表实现虚拟滚动，只渲染可视区域内的消息。目前 chat-ui 可能未内置此功能，对于极长对话需要留意。
状态管理优化 ：确保 zustand 的 selector 被正确使用，避免不必要的组件重渲染。使用 React DevTools 的 Profiler 检查性能瓶颈。
构建优化 ：确保生产构建 ( pnpm build ) 被正确使用，代码分割、tree-shaking 等优化能有效减少初始加载体积。

后端与部署优化 ：

模型服务优化 ：使用像 vLLM 这样的高性能推理引擎，它通过 PagedAttention 等技术极大地优化了显存利用和吞吐量。
API 网关与缓存 ：在 chat-ui 和后端模型服务之间可以增加一个 API 网关（如 Nginx）。网关可以处理负载均衡、SSL 终止、请求限流，甚至可以对一些常见的、确定的提示词响应进行缓存，减少对模型服务的直接压力。
数据库优化 ：如果使用数据库存储历史，确保对经常查询的字段（如 conversation_id , user_id , created_at ）建立索引。定期归档或清理非常旧的对话记录。
资源监控 ：监控服务器 CPU、内存、GPU 显存使用情况，以及模型服务的请求延迟和错误率。设置告警，以便在资源耗尽或服务异常时及时处理。

5.4 安全加固 checklist

将 chat-ui 暴露在公网前，请务必检查以下安全项：

检查项	说明与操作
API Key 不暴露	确保前端构建时注入的 API Key 是用于代理或无需鉴权的本地模型。真正的云服务 API Key 应保存在后端，由 `chat-ui` 的后端代理转发请求时添加。
启用身份验证	如果服务涉及敏感信息，启用 `chat-ui` 的 NextAuth 集成，配置 GitHub、Google 或邮箱密码登录，避免服务被公开滥用。
数据库安全	使用强密码，启用 SSL 连接，将数据库服务置于内网，不直接暴露在公网。
CORS 限制	在生产环境，不要使用 `*` 通配符。将 `NEXT_PUBLIC_ALLOWED_ORIGINS` 环境变量设置为你的前端域名。
输入输出过滤	虽然主要靠后端模型，但前端也可对用户输入进行基本的长度限制和敏感词过滤，防止提示词注入攻击。
依赖包安全	定期运行 `pnpm audit` 或使用 `dependabot` 检查并更新有安全漏洞的依赖包。
HTTPS 强制	通过反向代理（如 Nginx）配置 SSL 证书，强制所有流量使用 HTTPS。

部署 chat-ui 的过程，就像搭积木，它提供了精美、功能完备的前端积木，你需要做的就是准备好后端模型服务这块核心积木，并将它们牢固地对接起来。整个过程中，最常遇到的坑基本都围绕“连接”和“配置”展开。耐心地按照上述步骤排查，利用好开发者工具和日志，大部分问题都能迎刃而解。这个项目最大的价值在于，它让你摆脱了前端开发的重复劳动，能更快速地将大模型的能力呈现给最终用户，无论是用于演示、测试还是构建真正的产品原型，都是一个效率利器。

乐奇 Rokid 开放社区

更多推荐

在 Rokid AI Glasses 上做背单词应用：AIUI拍照听写的实现

分享在 Rokid AI Glasses 上用 AIUI 开发背单词应用的实践：从镜腿单击拍照、图片编码和多模态识别，到切题时的异步任务处理、语音调度与学习进度保存，结合关键代码和界面动图说明实现过程。