最近我做了一个小项目：一个基于 RAG 的企业报销知识问答系统。
本来只是想练手，结果越做越上头，最后把它一步步打磨成了一个更接近“产品原型”的 Demo。
今天就简单分享一下我从想法、技术方案，到界面优化和最终效果的完整过程。
一、为什么会做这个项目
现实里，很多企业都有一个共同问题：
- 报销制度很复杂，差旅、发票、补贴、审批规则一大堆。
- 文档很多，但员工根本不想翻。
- 问 HR 或财务，沟通成本又高。
所以我一直在想：能不能做一个东西，让员工直接问一句：
发票丢了还能报销吗？
然后系统直接给出一个结构化、可执行、带来源依据的答案。
这就是这个项目的出发点。
二、核心技术方案
整个系统本质上就是一个标准的 RAG 架构：
用户问题 → 向量检索 → Top-K 相关片段 → 大模型生成答案
我现在用的技术栈是：
- LLM：智谱 GLM
- 向量库：ChromaDB
- 检索方式：Embedding + Top-K
- 前端：Streamlit
- 文档来源：Markdown 格式的报销制度文件
这个方案的好处是比较轻量，适合快速做出一个能演示、能迭代、能继续扩展的版本。
三、我做了哪些产品化优化
一开始这个项目只是一个能跑的 Demo，但后来我发现：
Demo 和产品的差距，往往不在模型，而在体验。
所以我重点做了几处优化。
1. 把输入框前置
最开始的交互逻辑是“用户先找地方，再提问”。
后来我直接改成：
用户一进页面，就能马上输入问题。
这个改动看起来很小，但实际体验提升很大。
因为用户的第一目标不是“研究界面”，而是“尽快得到答案”。
2. 把 AI 回答结构化
我没有让模型只输出一大段文字，而是强制它按结构返回：
- 结论
- 报销条件
- 所需材料
- 注意事项
这样做的好处是，回答不再像“聊天”，而更像“能直接拿来用的制度说明”。
这一步是我觉得最关键的改动之一。
3. 重做了 UI 风格
原来的界面偏工具感，更像一个后台。
后来我把它调整成更接近 SaaS 产品的感觉：
- 有一个更像产品首页的 Hero 区
- 问题入口做成卡片式
- 聊天区域更简洁
- 数据展示部分弱化，不抢主流程
这样改完之后，整个 Demo 的观感提升非常明显。
4. 让知识来源可追溯
每个回答都能查看：
- 来源文档
- 匹配片段
- 相似度
这个设计很重要，因为它解决了一个 RAG 产品里最核心的问题：
AI 不能只会答，还得让人知道它为什么这么答。
四、最终效果怎么样
现在这个系统的体验大概是这样：
- 打开页面。
- 直接输入报销相关问题。
- 系统返回结构化答案。
- 可以展开查看制度来源。
- 支持上传制度文档并重建索引。
做到这里以后，它已经不只是一个“能跑的玩具项目”，而更像是一个内部工具原型了。
五、这个项目最大的收获
这次做下来，我最大的感受不是“学会了多少技术”，而是下面这三点：
1. RAG 不难，难的是让人愿意用
很多人一开始会把重点放在模型、向量库、检索参数上。
但真正决定体验的，往往是交互、结果组织方式和页面结构。
2. UI 真的决定项目上限
同样一个功能，工具感强的界面会显得“像实验室 Demo”。
但如果 UI、文案和交互做好了，它就会更像一个真实可用的产品。
3. Demo 和产品差的不只是功能，而是体验设计
一个能用的 Demo，和一个让人愿意继续用的产品，中间隔着很多细节。
比如入口是否清晰、回答是否结构化、信息是否可信、流程是否顺滑。
六、如果继续优化，我会做什么
如果后面继续迭代，我准备往这几个方向走：
- 多轮对话上下文优化。
- 增加权限系统，不同角色看到不同制度。
- 做审批流程联动，不只停留在问答。
- 把前端重构成更完整的 Web 应用，比如 Vue 或 React。
目前这个版本更偏原型验证，但路线已经比较清晰了。
七、适合谁参考
如果你也在做类似项目，这篇文章可能对你有帮助，尤其适合：
- 想做 AI 项目的同学。
- 准备面试、校招的同学。
- 想把 RAG 项目写进简历的人。
- 想把 Demo 做得更像产品的人。
因为这个项目比“单纯调用 API”更完整，也更容易讲清楚自己的能力。
最后
如果你也在做类似的项目，或者也想把一个 Demo 做得更像产品，欢迎交流。
项目地址：github.com/kayon09/expense-rag-qa
