IndexedDB存储结构设计：AI规划本地数据库表关系-育师

IndexedDB存储结构设计：AI规划本地数据库表关系

在现代前端工程中，一个日益突出的需求正在浮现：如何让轻量级 AI 模型在浏览器端“记住”用户的历史行为？尤其是在数学推理、编程解题这类需要反复迭代和上下文复用的场景下，页面刷新即丢失所有记录的体验显然无法接受。VibeThinker-1.5B-APP 这类专为高强度逻辑任务优化的小参数模型（15亿参数），虽然能在本地高效运行，但若缺乏持久化机制，其智能价值将大打折扣。

而解决这一问题的关键，并非依赖云端同步或复杂后端服务，而是充分利用浏览器原生能力——IndexedDB。它不仅是当前唯一支持大规模结构化数据存储的客户端方案，更具备事务性、索引查询与版本迁移等特性，恰好满足 AI 工具对“记忆”功能的核心诉求。

为什么是 IndexedDB？

localStorage 简单易用，但仅限字符串存储且容量极小；Web Storage 同样受限于同步阻塞与低扩展性。相比之下，IndexedDB 的优势几乎是降维打击：

容量可达数百MB甚至数GB（依浏览器策略）
支持 JavaScript 对象、Blob、ArrayBuffer 等复杂类型
提供异步非阻塞操作，不冻结 UI
具备索引、游标、范围查询等高级检索能力
通过事务保障数据一致性

更重要的是，它的键值对+对象仓库模型天然适合存储“一次推理全过程”这样的复合结构。比如一条完整的交互记录可能包含问题描述、系统提示词、模型输出、时间戳、任务分类等多个字段，这正是传统 Web Storage 难以承载的。

const request = indexedDB.open('VibeThinkerDB', 1); request.onupgradeneeded = function(event) { const db = event.target.result; // 存储每次推理的完整记录 if (!db.objectStoreNames.contains('inference_records')) { const store = db.createObjectStore('inference_records', { keyPath: 'id', autoIncrement: true }); store.createIndex('taskType', 'taskType', { unique: false }); store.createIndex('timestamp', 'timestamp', { unique: false }); store.createIndex('language', 'language', { unique: false }); store.createIndex('source', 'source', { unique: false }); // 如 LeetCode #1234 } // 保存常用系统提示词模板 if (!db.objectStoreNames.contains('system_prompts')) { const promptStore = db.createObjectStore('system_prompts', { keyPath: 'name' }); promptStore.createIndex('lastUsed', 'lastUsed', { unique: false }); } }; request.onsuccess = function(event) { const db = event.target.result; console.log("✅ IndexedDB 数据库打开成功"); }; request.onerror = function(event) { console.error("❌ IndexedDB 打开失败:", event.target.error); };

这段代码看似简单，实则暗藏工程考量：
- 使用autoIncrement主键确保每条推理记录全局唯一；
- 将高频查询字段如taskType、timestamp建立索引，避免全表扫描；
- 分离静态配置（system_prompts）与动态日志（inference_records），提升维护清晰度；
- 利用onupgradeneeded实现未来 schema 扩展的基础——比如后续增加modelVersion字段时可安全迁移旧数据。

这种设计不是为了炫技，而是源于对实际使用场景的深刻理解。

VibeThinker-1.5B-APP 的特殊需求决定了数据结构

这款模型并非通用聊天机器人，它的目标非常明确：在资源受限环境下完成高难度数学推导与算法实现。这意味着几个关键特征直接影响数据库设计决策：

1. 推理质量高度依赖系统提示词

实验表明，当未正确设置初始指令（如“You are a programming assistant specialized in competitive coding.”）时，VibeThinker-1.5B-APP 的准确率会显著下降。因此，“提示词管理”必须成为核心功能之一。

我们不能让用户每次都要手动输入相同的长串英文提示。解决方案是预置一组高质量模板并持久化存储：

{ "name": "coding_assistant", "content": "You are a programming assistant specialized in competitive coding.", "lastUsed": "2025-04-05T10:00:00Z" }

前端提供一个“快速切换角色”下拉菜单，背后就是从system_prompts表读取这些配置。不仅提升了效率，也降低了因提示词错误导致推理失败的风险。

2. 用户常需回顾与对比历史推理过程

竞赛式编程学习者往往会在不同时间点尝试同一类题目（例如动态规划）。他们希望看到自己之前的思路是否被优化，或者某次成功的解法是如何构造的。

这就要求数据库不仅能存，还要能高效查。仅靠主键查找远远不够，我们需要多维度索引支持：

查询需求	对应索引
查看最近一周的算法题	`taskType + timestamp`组合筛选
检索所有涉及“图论”的记录	`taskType`索引
分析英文 vs 中文输入效果差异	`language`字段统计

有了这些索引，配合游标遍历或openCursor()查询，就能轻松构建“个人推理知识库”。

3. 输入输出可能存在长度风险

尽管 IndexedDB 支持大对象存储，但浏览器仍有单条记录大小限制（通常几百 MB）。对于生成超长证明链或大型代码文件的情况，直接写入可能触发异常。

应对策略有两种：
-分块存储：将长文本按固定长度切片，添加chunkIndex和totalChunks字段重组；
-客户端压缩：使用 pako 或 Compression API 在写入前压缩，读取时解压。

后者更适合本场景，因为推理内容多为重复模式明显的代码或自然语言，压缩率普遍较高。

完整的数据流转闭环

在一个典型的 VibeThinker-1.5B-APP Web 应用中，IndexedDB 实际上处于整个系统的中枢位置：

+------------------+ +---------------------+ | 用户界面(UI) | ↔→ | IndexedDB 存储层 | | (React/Vue 组件) | | (inference_records, | +------------------+ | system_prompts) | +----------↑-----------+ | +---------------v------------------+ | 模型推理服务 | | (本地 Flask API / ONNX Runtime) | +----------------------------------+

工作流程如下：

启动阶段
页面加载时自动连接数据库，并从system_prompts加载默认提示词填充输入框，实现“开箱即用”。
提问与响应
用户提交问题后，前端将完整上下文打包为结构化对象：

js const record = { taskType: 'algorithm', question: userQuestion, systemPrompt: currentPrompt, response: modelOutput, timestamp: new Date().toISOString(), language: detectLanguage(userQuestion), source: 'LeetCode #1234', modelVersion: '1.5b-app-v2' };

然后开启事务写入inference_records，确保原子性。

历史查阅与复用
用户可通过搜索框或筛选器查找过往记录。例如点击“查看所有组合数学相关解答”，系统利用taskType索引快速定位结果集，并按时间倒序展示。

更进一步，可以支持“回放模式”：点击某条历史记录，自动还原当时的输入与提示词，方便重新运行验证。

提示词管理界面
提供 CRUD 操作接口，允许用户新增、编辑、删除常用提示模板。每次使用都会更新lastUsed字段，便于排序推荐最常用的配置。

设计背后的权衡与最佳实践

一个好的本地数据库设计，不只是“能用”，更要考虑长期可维护性和用户体验细节。

对象仓库划分：动静分离原则

我们将数据分为两类：
-动态数据：inference_records，频繁增删改查，生命周期短；
-静态配置：system_prompts，较少变更，但对功能至关重要。

这种分离带来三大好处：
- 清晰职责边界，便于团队协作开发；
- 避免单一表过大影响性能；
- 可独立备份/导出配置项而不污染历史日志。

索引策略：精准而非泛滥

虽然 IndexedDB 允许创建多个索引，但每个索引都会增加写入开销。实践中我们只对真正高频查询的字段建立索引：

store.createIndex('taskType', 'taskType', { unique: false }); store.createIndex('timestamp', 'timestamp', { unique: false });

像question或response这种全文检索需求，不应建普通索引，而应引入客户端搜索引擎（如 FlexSearch 或 MiniSearch）做倒排索引处理，否则性能反而下降。

事务控制：粒度适中

单条记录插入使用短事务，尽快释放锁；
批量导入历史数据时使用长事务，减少开销；
跨表操作（如同时更新提示词+插入新记录）需显式声明事务范围，防止部分成功。

示例：

const transaction = db.transaction(['inference_records'], 'readwrite'); const store = transaction.objectStore('inference_records'); const request = store.add(record); request.onsuccess = () => console.log('✅ 记录已保存'); request.onerror = (e) => console.error('❌ 写入失败:', e.target.error);

错误处理与降级机制

并非所有环境都支持 IndexedDB。老旧浏览器、隐私模式或配额耗尽都可能导致初始化失败。因此必须做好防御：

request.onerror = () => { console.warn("⚠️ IndexedDB 不可用，启用内存缓存"); useInMemoryFallback(); };

内存缓存虽不具备持久性，但在临时会话中仍可提供基本历史浏览功能，不至于完全退化。

版本升级的安全演进

当需要新增字段（如加入tags数组用于标记知识点），必须在onupgradeneeded中处理兼容性：

if (event.oldVersion < 2) { const store = event.target.result.objectStore('inference_records'); if (!store.indexNames.contains('tags')) { store.createIndex('tags', 'tags', { multiEntry: true }); } }

同时考虑旧数据迁移：可通过一次性脚本为已有记录补全默认值，避免查询时报错。

更进一步：不只是存储，更是智能化辅助

一旦本地有了完整的推理历史，就可以在此基础上构建更高阶的功能：

自动草稿保存

用户在输入框中编辑超过30秒未提交？自动将其暂存为“草稿”记录，下次打开页面时提示：“您有未完成的问题，是否继续？”

智能搜索建议

基于历史记录中的taskType和关键词，实现输入联想。例如用户刚输入“dp”，就推荐“最长公共子序列”、“背包问题”等过往相关题目。

本地知识沉淀

定期生成“本月解题统计”报告：共解决多少道题、中英文使用比例、平均响应时间变化趋势等，帮助用户追踪成长轨迹。

结语

这套基于 IndexedDB 的本地存储架构，表面看只是解决了“别让我重输一遍”的痛点，实则为边缘 AI 应用打开了新的可能性：
它让一个原本无状态的小模型，拥有了持续积累的能力；
它使前端不再只是展示层，而成为具备“记忆”与“反思”功能的智能终端组件。

更重要的是，这种设计思路具有高度可复用性。无论是本地 CoPilot、离线数学辅导系统，还是科研级代码生成工具，只要涉及“人机协同推理+上下文复用”的场景，都可以借鉴这一范式。

未来的轻量 AI 工具，不应只是模型跑得快，更要懂得“记得住、找得到、用得久”。而这，正是现代浏览器存储能力赋予我们的新起点。

IndexedDB存储结构设计：AI规划本地数据库表关系