普通视图

发现新文章,点击刷新页面。
昨天以前首页

第 9 篇:让 AI 助手记住会话:示例问题点击发送与 localStorage 持久化

2026年4月28日 19:38

项目地址

说明:当前在线版本部署在 Vercel,国内网络访问可能不稳定。如果打不开,可以直接查看 GitHub 源码并在本地启动。


前言

上一篇我们做了一次 UI 和组件结构升级。

项目现在已经有了更像 AI 产品的界面:

顶部 Header
中间消息区
底部输入框
用户 / AI 消息气泡
空状态示例问题
Markdown 渲染
引用来源展示

但当前项目还有一个很明显的问题:

刷新页面后,所有聊天记录都会丢失。

因为现在消息保存在 React state 中:

const [messages, setMessages] = useState<Message[]>([])
const [conversationId, setConversationId] = useState<string>()

React state 只存在于当前页面生命周期里。只要刷新页面,状态就会重新初始化。

这篇文章我们先不引入数据库,而是用最简单的方式解决这个问题:

使用 localStorage 保存会话历史和 conversationId。

同时,我们也把空状态里的示例问题改成可点击发送。


本篇目标

完成后项目会支持:

1. 空状态示例问题可以点击发送
2. 消息列表保存到 localStorage
3. Dify conversationId 保存到 localStorage
4. 刷新页面后自动恢复历史会话
5. 清空会话时同步清除本地缓存

这一篇仍然只做单会话持久化。

多会话列表会在下一篇实现。


为什么先用 localStorage?

真正的产品里,会话历史应该保存在服务端数据库里。

比如:

SQLite
PostgreSQL
MySQL
MongoDB

但这个阶段我们还没有用户系统,也没有数据库。

如果一上来就引入数据库,会多出很多额外复杂度:

表结构设计
接口设计
数据同步
用户身份
服务端存储
迁移脚本

而我们当前最想解决的问题很简单:

刷新页面后不要丢失聊天记录

所以 localStorage 是一个很合适的过渡方案。

它的优点是:

1. 使用简单
2. 不需要后端接口
3. 适合本地 Demo 和个人项目
4. 可以快速验证会话持久化体验

缺点也很明显:

1. 只保存在当前浏览器
2. 清缓存会丢失
3. 不能多设备同步
4. 不适合多用户系统
5. 存储容量有限

但作为项目演进的中间阶段,足够用了。


第一步:让示例问题可以点击发送

上一篇的 EmptyState 只是展示示例问题:

<div className="example-card" key={example}>
  {example}
</div>

现在我们希望点击示例问题后,直接发送这个问题。

修改:

src/components/EmptyState.tsx

改成:

type EmptyStateProps = {
  onExampleClick: (question: string) => void
}

export function EmptyState({ onExampleClick }: EmptyStateProps) {
  const examples = [
    '前端架构主要包括哪些内容?',
    '什么是 RAG?',
    '大型前端项目可以怎么分层?',
  ]

  return (
    <div className="empty-state">
      <h2>Frontend AI Assistant</h2>
      <p>基于你的知识库回答前端学习和架构问题。</p>

      <div className="example-list">
        {examples.map(example => (
          <button
            type="button"
            className="example-card"
            key={example}
            onClick={() => onExampleClick(example)}
          >
            {example}
          </button>
        ))}
      </div>
    </div>
  )
}

注意这里把 div 改成了 button

因为它现在是可交互元素,用 button 更符合语义,也更利于可访问性。


第二步:把 onExampleClick 传给 ChatWindow

修改:

src/components/ChatWindow.tsx

给 props 增加 onExampleClick

import { useEffect, useRef } from 'react'
import type { Message } from '../types/chat'
import { ChatMessage } from './ChatMessage'
import { EmptyState } from './EmptyState'

type ChatWindowProps = {
  messages: Message[]
  loading: boolean
  onExampleClick: (question: string) => void
}

export function ChatWindow({
  messages,
  loading,
  onExampleClick,
}: ChatWindowProps) {
  const bottomRef = useRef<HTMLDivElement | null>(null)

  useEffect(() => {
    bottomRef.current?.scrollIntoView({ behavior: 'smooth' })
  }, [messages, loading])

  if (messages.length === 0) {
    return <EmptyState onExampleClick={onExampleClick} />
  }

  return (
    <div className="chat-window">
      {messages.map((message, index) => (
        <ChatMessage
          key={index}
          role={message.role}
          content={message.content}
          sources={message.sources}
        />
      ))}

      {loading && <div className="typing">AI 正在思考...</div>}

      <div ref={bottomRef} />
    </div>
  )
}

这样空状态的点击事件就能传回 App。


第三步:把发送函数改成支持传入指定问题

原来的发送函数大概是:

async function handleSend() {
  const text = input.trim()
  if (!text || loading) return

  // 发送逻辑
}

现在我们希望两种方式都能发送:

1. 用户在输入框输入后点击发送
2. 用户点击空状态示例问题

所以把 handleSend 改成:

async function handleSend(question?: string) {
  const text = (question ?? input).trim()

  if (!text || loading) return

  setInput('')
  setLoading(true)

  // 后续发送逻辑保持不变
}

然后在 ChatWindow 中传入:

<ChatWindow
  messages={messages}
  loading={loading}
  onExampleClick={question => handleSend(question)}
/>

ChatInput 中仍然这样调用:

<ChatInput
  value={input}
  loading={loading}
  onChange={setInput}
  onSend={() => handleSend()}
  onClear={handleClear}
/>

这样示例问题和输入框共用同一套发送逻辑。


第四步:设计本地存储结构

我们要保存两类信息:

messages:聊天记录
conversationId:Dify 多轮对话 ID

所以本地存储结构可以设计成:

type StoredState = {
  messages: Message[]
  conversationId?: string
}

为什么要保存 conversationId?

因为 Dify 的多轮对话依赖它。

如果只保存 messages,不保存 conversationId,刷新后页面虽然能看到历史消息,但下一次追问时,Dify 会认为这是一个新会话。

保存 conversationId 后,刷新页面继续追问,仍然可以延续同一个 Dify 会话。


第五步:创建 storage 工具函数

新建:

src/utils/storage.ts

写入:

import type { Message } from '../types/chat'

const STORAGE_KEY = 'frontend-ai-assistant-state'

type StoredState = {
  messages: Message[]
  conversationId?: string
}

export function loadChatState(): StoredState {
  try {
    const raw = localStorage.getItem(STORAGE_KEY)

    if (!raw) {
      return {
        messages: [],
        conversationId: undefined,
      }
    }

    const parsed = JSON.parse(raw) as StoredState

    return {
      messages: Array.isArray(parsed.messages) ? parsed.messages : [],
      conversationId: parsed.conversationId,
    }
  } catch {
    return {
      messages: [],
      conversationId: undefined,
    }
  }
}

export function saveChatState(state: StoredState) {
  localStorage.setItem(STORAGE_KEY, JSON.stringify(state))
}

export function clearChatState() {
  localStorage.removeItem(STORAGE_KEY)
}

这里做了几个保护:

1. localStorage 没有数据时返回默认值
2. JSON.parse 失败时返回默认值
3. messages 不是数组时返回空数组

不要假设 localStorage 里的内容永远是可靠的。

用户可能手动改,旧版本数据结构也可能和新版本不一致。


第六步:初始化状态时读取 localStorage

打开:

src/App.tsx

先引入:

import { useEffect, useState } from 'react'
import {
  clearChatState,
  loadChatState,
  saveChatState,
} from './utils/storage'

然后把原来的状态初始化:

const [messages, setMessages] = useState<Message[]>([])
const [conversationId, setConversationId] = useState<string>()

改成:

const initialState = loadChatState()

const [messages, setMessages] = useState<Message[]>(initialState.messages)
const [conversationId, setConversationId] = useState<string | undefined>(
  initialState.conversationId
)

这样页面第一次加载时,会优先从 localStorage 恢复历史会话。


第七步:状态变化时自动保存

App 组件中增加:

useEffect(() => {
  saveChatState({
    messages,
    conversationId,
  })
}, [messages, conversationId])

这段逻辑表示:

只要 messages 或 conversationId 变化,就保存到 localStorage

所以:

用户发送消息 → 保存
AI 流式输出 → 保存
conversationId 返回 → 保存
引用来源更新 → 保存

都会自动持久化。


第八步:清空会话时同步清除本地缓存

原来的清空函数可能是:

function handleClear() {
  setMessages([])
  setConversationId(undefined)
}

现在要加上:

clearChatState()

完整如下:

function handleClear() {
  setMessages([])
  setConversationId(undefined)
  clearChatState()
}

这样点击清空后,刷新页面也不会恢复旧记录。


第九步:补充示例卡片样式

上一篇的 .example-card 是普通展示卡片。

现在它变成了按钮,可以补充 hover 效果:

.example-card {
  width: 100%;
  background: #ffffff;
  border: 1px solid #e5e7eb;
  border-radius: 12px;
  padding: 14px 16px;
  text-align: left;
  color: #374151;
  transition:
    border-color 0.15s ease,
    box-shadow 0.15s ease,
    transform 0.15s ease;
}

.example-card:hover {
  border-color: #2563eb;
  box-shadow: 0 4px 12px rgba(37, 99, 235, 0.12);
  transform: translateY(-1px);
}

这样用户能明显感知它是可点击的。


第十步:测试功能

启动项目:

npm run dev:all

依次测试:

1. 点击示例问题

初始页面点击:

前端架构主要包括哪些内容?

应该能直接发送,并开始流式回答。

2. 刷新页面

等待回答完成后刷新页面。

历史消息应该仍然存在。

3. 刷新后继续追问

刷新后继续问:

那大型项目怎么分层?

因为 conversationId 被保存了,所以 Dify 仍然可以延续同一个会话。

4. 清空会话

点击清空会话后,再刷新页面。

旧消息不应该再恢复。


localStorage 持久化有什么坑?

1. 服务端渲染环境不能直接访问 localStorage

当前项目是 Vite SPA,所以没问题。

但如果以后迁移到 Next.js,要注意:

localStorage 只存在浏览器环境
服务端渲染时不能直接访问

需要放到 useEffect 或判断 typeof window !== 'undefined'

2. 数据结构升级要兼容旧数据

比如现在存的是:

{
  messages: [],
  conversationId: 'xxx'
}

下一篇做多会话后,结构会变成:

{
  activeSessionId: 'xxx',
  sessions: []
}

所以读取 localStorage 时要做好兜底,不能盲目信任旧数据。

3. 不要存敏感信息

localStorage 不是安全存储。

不要把这些内容放进去:

Dify API Key
DeepSeek API Key
用户密码
敏感 Token

我们这里只存聊天内容和 conversationId。

4. 流式输出会频繁写入

因为 AI 每输出一段,messages 都会更新一次,所以 useEffect 也会频繁写 localStorage。

当前项目规模小,问题不大。

如果后面内容变多,可以考虑:

防抖保存
只在 message_end 后保存
迁移到数据库

当前版本的局限

现在已经解决了单会话刷新丢失问题,但还有一个不足:

只有一个会话。

真实 AI 产品一般都有左侧会话列表,比如:

新建会话
历史会话
切换会话
删除会话
重命名会话
搜索会话

目前我们的 localStorage 结构只支持一个会话。

下一篇会把它升级成多会话结构:

type ChatSession = {
  id: string
  title: string
  messages: Message[]
  conversationId?: string
  createdAt: number
  updatedAt: number
}

然后实现类似 ChatGPT 的左侧会话列表。


本篇总结

这一篇我们完成了两个可用性增强:

1. 示例问题点击发送
2. localStorage 单会话持久化

具体做了:

1. EmptyState 支持 onExampleClick
2. ChatWindow 透传示例点击事件
3. handleSend 支持传入指定问题
4. 创建 storage 工具函数
5. 保存 messages 和 conversationId
6. 页面刷新后恢复会话
7. 清空会话时同步清除缓存

现在项目已经可以持续使用,不会一刷新就丢失记录。

下一篇我们继续升级:

实现多会话管理:新建、切换、删除、重命名和搜索。

第 7 篇:让 RAG 答案可追溯:展示知识库引用来源

2026年4月28日 19:32

项目地址

说明:当前在线版本部署在 Vercel,国内网络访问可能不稳定。如果打不开,可以直接查看 GitHub 源码并在本地启动。


前言

上一篇我们解决了 AI 回答的展示体验问题:

Markdown 渲染
代码高亮
表格展示
列表展示

现在 AI 的回答已经更像一个正式产品,而不是普通纯文本输出。

但对于一个 RAG 知识库问答系统来说,还有一个非常关键的问题:

AI 的答案到底来自哪里?

如果用户只能看到 AI 回答,却看不到引用来源,那他很难判断:

这段内容是知识库里的?
还是模型自己补充的?
有没有可能编造?
我能不能回到原文确认?

所以这一篇我们要做一个非常重要的能力:

展示知识库引用来源。

最终效果类似:

前端架构主要包括项目分层、组件设计、状态管理、权限控制、性能优化、工程化和可观测性。

引用来源:
- frontend-notes.md

这一步做完后,我们的 AI 知识库应用会更像真正的 RAG 产品。


为什么引用来源很重要?

RAG 的核心不是“让 AI 回答”,而是“让 AI 基于可检索的知识回答”。

普通聊天机器人可以随便回答,但知识库问答系统更强调:

可追溯
可验证
可解释
减少幻觉

引用来源的价值在于:

1. 告诉用户答案来自哪份文档
2. 增强回答可信度
3. 方便用户回到原文确认
4. 帮助开发者调试知识库召回效果
5. 判断模型有没有脱离上下文发挥

尤其是企业知识库场景,如果 AI 回答后能显示:

引用自:员工手册.pdf
引用自:研发规范.md
引用自:项目介绍.docx

用户会更容易信任这个系统。


Dify 的引用来源在哪里?

在 Dify 的流式响应中,答案片段通常通过 message 事件返回。

类似:

{
  "event": "message",
  "answer": "前端架构"
}

而引用来源通常会在回答结束时的 message_end 事件中返回。

结构大概是:

{
  "event": "message_end",
  "conversation_id": "xxx",
  "metadata": {
    "retriever_resources": [
      {
        "dataset_name": "frontend-learning-kb",
        "document_name": "frontend-notes.md",
        "content": "前端架构主要包括项目分层、组件设计、状态管理、权限控制、性能优化、工程化和可观测性。"
      }
    ]
  }
}

我们要做的就是解析:

metadata.retriever_resources

然后把它展示到 AI 回答下面。


本篇目标

这一篇完成后,项目会支持:

1. 从 Dify streaming 的 message_end 事件中解析 retriever_resources
2. 保存每条 AI 消息对应的引用来源
3. 在 AI 消息下方展示引用文档名称
4. 为后续展示引用片段、跳转原文打基础

第一步:扩展消息类型

之前我们的消息类型可能是:

export type Role = 'user' | 'assistant'

export type Message = {
  role: Role
  content: string
}

现在要给 AI 消息增加引用来源。

打开:

src/types/chat.ts

改成:

export type Role = 'user' | 'assistant'

export type Source = {
  datasetName?: string
  documentName?: string
  content?: string
}

export type Message = {
  role: Role
  content: string
  sources?: Source[]
}

这里的 sources 是可选的。

原因是:

用户消息没有引用来源
AI 消息也不一定每次都有引用来源

比如用户问了一个知识库没有命中的问题,或者 Dify 没有返回 retriever_resources,那 sources 就可以为空。


第二步:扩展流式 API 类型

打开:

src/api/difyStream.ts

定义 Dify 返回的引用来源类型:

export type RetrieverResource = {
  dataset_name?: string
  document_name?: string
  content?: string
}

然后在回调类型里增加 onSources

export type StreamCallbacks = {
  onMessage: (text: string) => void
  onConversationId?: (conversationId: string) => void
  onSources?: (sources: RetrieverResource[]) => void
  onError?: (error: Error) => void
  onDone?: () => void
}

onSources 的作用是:

当流式回答结束,并且 Dify 返回引用来源时,把 sources 通知给外层组件。

第三步:解析 message_end 事件

sendMessageToDifyStream 的 SSE 解析逻辑中,之前我们已经处理了:

if (data.event === 'message' && data.answer) {
  callbacks.onMessage(data.answer)
}

现在加上 message_end

if (data.event === 'message_end') {
  const sources = data.metadata?.retriever_resources || []

  if (sources.length > 0) {
    callbacks.onSources?.(sources)
  }
}

完整片段类似:

try {
  const data = JSON.parse(jsonStr)

  if (data.event === 'message' && data.answer) {
    callbacks.onMessage(data.answer)
  }

  if (data.conversation_id) {
    callbacks.onConversationId?.(data.conversation_id)
  }

  if (data.event === 'message_end') {
    const sources = data.metadata?.retriever_resources || []

    if (sources.length > 0) {
      callbacks.onSources?.(sources)
    }
  }

  if (data.event === 'error') {
    callbacks.onError?.(new Error(data.message || 'Dify stream error'))
  }
} catch {
  // 忽略无法解析的 SSE 行
}

这样,前端就能拿到 Dify 返回的引用来源了。


第四步:把引用来源保存到 AI 消息上

我们之前处理流式回答时,是先插入一条空 AI 消息:

setMessages(prev => [
  ...prev,
  { role: 'user', content: text },
  { role: 'assistant', content: '' },
])

然后每收到一段 answer,就更新这条 AI 消息的 content

现在拿到 sources 后,也要更新同一条 AI 消息。

在调用 sendMessageToDifyStream 时增加:

onSources: sources => {
  setMessages(prev => {
    const next = [...prev]
    const current = next[assistantMessageIndex]

    if (current) {
      next[assistantMessageIndex] = {
        ...current,
        sources: sources.map(source => ({
          datasetName: source.dataset_name,
          documentName: source.document_name,
          content: source.content,
        })),
      }
    }

    return next
  })
}

这里把 Dify 的字段名转换成了前端更习惯的驼峰命名:

dataset_name   → datasetName
document_name  → documentName
contentcontent

这样组件里使用会更自然。


第五步:创建 SourceList 组件

接下来写一个组件专门展示引用来源。

新建:

src/components/SourceList.tsx

写入:

import type { Source } from '../types/chat'

type SourceListProps = {
  sources: Source[]
}

export function SourceList({ sources }: SourceListProps) {
  if (sources.length === 0) return null

  return (
    <div className="source-list">
      <div className="source-title">引用来源</div>
      <ul>
        {sources.map((source, index) => (
          <li key={index}>
            <span>{source.documentName || '未知文档'}</span>
          </li>
        ))}
      </ul>
    </div>
  )
}

第一版我们只展示文档名。

后续可以扩展成:

展示知识库名称
展示引用片段
点击展开原文
显示相似度分数
跳转到原文位置

但第一版先简单一点。


第六步:在 ChatMessage 中展示来源

打开:

src/components/ChatMessage.tsx

引入类型和组件:

import type { Source } from '../types/chat'
import { SourceList } from './SourceList'

把 props 改成:

type ChatMessageProps = {
  role: 'user' | 'assistant'
  content: string
  sources?: Source[]
}

然后在 AI 消息下面加:

{!isUser && sources && sources.length > 0 && (
  <SourceList sources={sources} />
)}

完整组件类似:

import ReactMarkdown from 'react-markdown'
import remarkGfm from 'remark-gfm'
import rehypeHighlight from 'rehype-highlight'
import type { Source } from '../types/chat'
import { SourceList } from './SourceList'

type ChatMessageProps = {
  role: 'user' | 'assistant'
  content: string
  sources?: Source[]
}

export function ChatMessage({ role, content, sources }: ChatMessageProps) {
  const isUser = role === 'user'

  return (
    <div className={`message ${isUser ? 'user' : 'ai'}`}>
      <strong>{isUser ? '你' : 'AI'}:</strong>

      {isUser ? (
        <div className="message-text">{content}</div>
      ) : (
        <div className="markdown-body">
          <ReactMarkdown
            remarkPlugins={[remarkGfm]}
            rehypePlugins={[rehypeHighlight]}
          >
            {content}
          </ReactMarkdown>
        </div>
      )}

      {!isUser && sources && sources.length > 0 && (
        <SourceList sources={sources} />
      )}
    </div>
  )
}

第七步:App 渲染时传入 sources

原来渲染消息时可能是:

<ChatMessage
  key={index}
  role={message.role}
  content={message.content}
/>

现在改成:

<ChatMessage
  key={index}
  role={message.role}
  content={message.content}
  sources={message.sources}
/>

这样每条 AI 消息就可以显示自己的引用来源。


第八步:补充样式

在 CSS 里加入:

.source-list {
  margin-top: 12px;
  padding-top: 10px;
  border-top: 1px solid #e5e7eb;
  font-size: 13px;
  color: #4b5563;
}

.source-title {
  font-weight: 600;
  margin-bottom: 4px;
}

.source-list ul {
  margin: 0;
  padding-left: 18px;
}

.source-list li {
  margin: 2px 0;
}

这样引用来源会作为 AI 消息的一部分显示在回答底部。


第九步:测试引用来源

启动项目:

npm run dev:all

提问:

前端架构主要包括哪些内容?

理想效果是:

前端架构主要包括项目分层、组件设计、状态管理、权限控制、性能优化、工程化和可观测性。

引用来源:
- frontend-notes.md

如果你能看到 frontend-notes.md,说明引用来源已经展示成功。


第十步:如何判断来源是否真的来自知识库?

可以打开浏览器 DevTools → Network。

找到:

/api/chat/stream

查看流式响应里是否有 message_end 事件。

你应该能看到类似:

{
  "event": "message_end",
  "metadata": {
    "retriever_resources": [
      {
        "dataset_name": "frontend-learning-kb",
        "document_name": "frontend-notes.md",
        "content": "前端架构主要包括项目分层、组件设计、状态管理、权限控制、性能优化、工程化和可观测性。"
      }
    ]
  }
}

如果这里有数据,但页面没展示,说明是前端状态或组件传参问题。

如果这里没有数据,说明 Dify 没有返回引用来源,可能是:

1. 知识检索没有命中
2. Dify 应用配置没有启用相关返回
3. 当前问题没有走知识库
4. Prompt 或流程配置有问题

一个细节:为什么 sources 要放在 Message 上?

因为每一条 AI 回答都应该有自己的引用来源。

如果把 sources 单独放成全局状态,比如:

const [sources, setSources] = useState([])

会有几个问题:

1. 多轮对话时,来源会被后一次回答覆盖
2. 历史消息无法保留各自来源
3. 多会话管理时更容易混乱
4. 后续持久化不好设计

所以更合理的结构是:

type Message = {
  role: 'user' | 'assistant'
  content: string
  sources?: Source[]
}

也就是:

回答内容和引用来源属于同一条 AI 消息

这对后续 localStorage 持久化、多会话管理、数据库存储都更友好。


现在引用来源只展示文档名够吗?

第一版够用。

但从产品体验上看,未来还可以继续优化。

比如可以展示:

1. 文档名称
2. 知识库名称
3. 引用片段
4. 相似度分数
5. 点击展开详情

比如 SourceList 可以扩展成卡片:

引用来源

frontend-notes.md
前端架构主要包括项目分层、组件设计、状态管理...

不过这会带来 UI 和交互复杂度。

当前阶段我们的目标是先把来源链路跑通。


当前版本还有哪些不足?

现在项目已经有:

Dify RAG
Express BFF
流式输出
Markdown 渲染
引用来源

但是 UI 仍然比较像 Demo。

比如:

页面布局不够正式
输入框没有固定底部
消息区不够像聊天产品
空状态比较简陋
组件拆分还不够完整

所以下一篇我们会开始做产品化 UI:

ChatLayout
ChatWindow
ChatInput
ChatMessage
SourceList
EmptyState

让项目从“功能 Demo”变成“像样的 AI 产品界面”。


本篇总结

这一篇我们完成了 RAG 产品很关键的一步:展示引用来源。

具体做了:

1. 扩展 Message 类型,增加 sources 字段
2. 扩展 difyStream 回调,增加 onSources
3. 解析 Dify message_end 事件中的 metadata.retriever_resources
4. 把引用来源保存到对应的 AI 消息上
5. 创建 SourceList 组件
6. 在 ChatMessage 下方展示文档来源

这一步让 AI 回答变得更加可信。

因为用户不再只能看到“AI 说了什么”,还能看到“AI 参考了哪里”。

下一篇我们继续做前端体验升级:

从 Demo 到产品:拆分组件,优化聊天 UI。

❌
❌