1. 为什么做这个项目？
日常最痛的场景不是“没有文档”，而是：
- 文档很多，找不到
- 找到了，不确定是不是最新版
- 回答靠口口相传，缺少出处
所以我想做一个轻量工具：
上传本地文档 -> 提问题 -> AI 回答并给出引用来源，尽量在前端完成闭环，先跑通价值。
如果你想快速感受效果，可以直接访问：
www.ragclaw.help/
2. 项目定位：纯前端本地知识库（有边界，但启动快）
我这版的定位是：
- 前端主栈：Vue 3 + Vite + Pinia
- 文档处理：TXT / MD / PDF / DOCX
- 本地存储：IndexedDB（Dexie）
- RAG 能力：分块、向量检索、回答生成、引用来源展示
- 部署：Vercel
- 统计：
site_visit、chat_send事件统计（KV）
为什么先做纯前端？
- 开发快，迭代快，演示成本低
- 私有文档可先本地处理，便于验证场景
- 对“0 到 1”阶段非常友好
边界也很明确：
- 强鉴权、严格限流、防刷，最终还是要服务端兜底
- 大规模并发和复杂权限，不适合完全前端化
3. 功能做到了什么？
目前已经落地的核心能力：
- 多格式文档上传解析（PDF/Word/Markdown/TXT）
- 智能分块 + 向量化
- 对话问答（支持多轮上下文）
- 回答引用来源（可追溯）
- 知识库管理（文档分组、预览、删除）
- 本地持久化（刷新不丢）
- 访问/发送对话统计（便于观察使用情况）
4. 关键实现思路
4.1 文档不是“全文喂给模型”，而是先分块再检索
RAG 里最关键的是检索质量。
我这里先做文档解析，然后按内容结构分块（普通文本与代码文本策略不同），再向量化入库。
这样做的好处：
- 降低 token 压力
- 召回更精准
- 引用展示更容易定位到具体片段
4.2 问答链路：检索 -> 组装上下文 -> 生成答案 -> 输出引用
一次提问大致流程：
- 接收用户问题
- 向量检索相关片段（可叠加关键词策略）
- 拼接上下文给模型
- 输出回答 + 来源信息
- 在前端渲染“参考来源”
用户体验上最重要的不是“回答快”，而是：
回答是否可验证。所以引用来源是必须项，不是锦上添花。
4.3 统计怎么做（部署后可观察）
我加了两类核心事件：
site_visit：访问站点chat_send：发送问题
线上用 Vercel Serverless + KV 记录，提供 /api/stats 读取汇总。
这样就能快速回答两个问题：
- 有没有人访问？
- 有没有人在真实提问？
5. 上线后踩过的几个坑
- 只看前端埋点，不看服务端统计，容易误判
- 本地
npm run dev与线上 serverless 行为不完全一致 - 统计接口通了但数据不涨，通常是“事件没上报到服务端”
- 纯前端方案在“限次/风控”上天然薄弱，后续要补后端策略
6. 这个方案适合谁？
适合：
- 想快速做一个可演示的 AI 知识库原型
- 个人/小团队先验证文档问答价值
- 需要一个低成本 MVP 去争取资源
不适合：
- 对权限、审计、配额有严格要求的生产系统
- 高并发、复杂组织架构的企业级场景（需更完整后端）
7. 我的下一步计划
- 增加更细粒度统计看板（按来源、按路径、按问题长度）
- 增加每日使用配额（服务端计数）
- 补一个管理端页面（直接可视化
/api/stats） - 对检索效果做 A/B 对比（分块策略与召回策略）
8. 总结
这次实践最大的感受是：
RAG 项目早期最重要的是跑通“可用闭环”，不是一上来就追求重架构。
把“上传 -> 检索 -> 回答 -> 引用 -> 统计”先打通，你就已经有了一个能真实被使用、能持续迭代的起点。
