首先是模型调用相关的llms.py，这个文件是整个项目的发动机，负责两件事：提供大语言模型和提供文本嵌入模型，简单说就是，谁想要跟AI对话，谁想要把文本转成向量，都来找这个文件要。在线模型进行数据向量化，测试时发现它响应不快还可能因为网络问题报错，换成本地模型之后又显示模型不存在，改了半天路径结果是模型里有同名文件被我用进去了，所以大家在写的时候要注意确认文件夹里的内容是不是真正的模型文件。这样先

从原始文件到干净文本的全流程，包括多格式文件读取、文本提取、表格识别、长文本切分、数据清洗与数值提取，最终输出结构化的JSON数据，为后续向量化建库做准备。

qa_chain.py是整个RAG系统的大脑，它负责把用户输入的问题，经过清洗和格式化后，从向量库里检索出相关的文档，再交给大模型生成答案，最后把结果返回给用户，总的来说它的核心职责就是让模型更好的理解用户的每一个问题，增强模型的理解力和检索能力。

折腾了小半月，终于搞出来一套比较完整的方案，想着既然踩了这么多坑，不如整理出来分享给大家。这个项目就是一个端到端的RAG（检索增强生成）系统，可以帮助大模型依据知识库更好的回答用户问题，从原始文档到智能问答，把整个流程都串起来了。这个流程看着简单，真的做起来也有不少坑要踩，这一章先交代项目的总体结构，接下来的章节，我会深入到每个代码文件，展开讲讲具体实现。：应用集成，把前面四个模块串起来，加个命令

vector_store.py实现了从文本到向量的转换、存储和检索，是连接数据处理和智能问答的桥梁，它使用BGE模型将文档转为向量，存入 Chroma 数据库，并提供灵活的检索接口

随着人工智能技术的快速发展，智能化客户服务与业务辅助工具已成为企业数字化转型的核心组件。传统的CRM系统主要依赖人工操作和数据录入，效率低下且难以满足日益增长的个性化服务需求，本项目——AI-CRM智能助手，是一款基于大语言模型（LLM）和检索增强生成（RAG）技术构建的智能化辅助系统，旨在通过自然语言交互的方式，为用户提供天气查询、法律条文检索、数据库业务数据管理等一站式服务。

到这里，这套FastAPI路线已经形成完整闭环：1. 单体CRUD、分层架构与统一异常工程底盘2. SQLite -> MySQL/PostgreSQL持久化与迁移能力3. JWT/OAuth2身份与权限治理4. pytest与TestClient可回归质量护栏5. Uvicorn/Gunicorn +配置 +监控日志上线稳定性按这五步执行，你得到的不只是能跑的FastAPI项目，而是一个可以持续

到第三篇为止，我们已经有了：分层架构数据库接入JWT/OAuth2鉴权现在项目最容易出现的风险是：你每次改一处功能，都不确定会不会把别的接口弄坏这就是为什么第四步必须是测试体系建设本文目标：1. 用pytest与TestClient建立FastAPI的主流程测试2. 让CRUD、鉴权、异常语义都可回归3. 把测试接入CI，做到提交即验证。

先做schemas/common.py：code: strdef success_response(data: Any = None, message: str = "成功") -> dict:为什么这一步要最先做：- 前端只要认一个结构：success/message/data/error- 测试断言成本更低- 后续你换业务实体，也不需要改交互协议`python这层的价值：- 把脏数据拦在入口-

第一篇我们把FastAPI的工程底盘搭稳了：- 单体CRUD跑通- 分层职责清晰- 统一异常和响应结构固定第二篇我们进入真正会影响项目寿命的一步：数据库接入与迁移策略这一步如果做得随意，后期会出现本地能跑，线上全是坑的典型问题本文目标：1. 用SQLAlchemy2+Alembic完成FastAPI的数据库接入2. 先用SQLite快速起步，再迁移到MySQL/PostgreSQL3. 给出一套可