大厂之间的竞争越激烈，对开发者越有利——模型价格会更低、API 会更稳定、功能会更丰富。现在通义千问的 API 价格已经降到和 DeepSeek 差不多的水平，竞争只会让价格继续下探。过去两年，大厂做 AI 的思路是"先做出一个能打的模型"。字节的豆包团队可能会独立，腾讯的混元团队也可能升级。——那些大厂不会做的、不够标准化、但真实存在的需求，就是你该去的地方。层面，大厂的标准化产品往往不能满足具

大厂之间的竞争越激烈，对开发者越有利——模型价格会更低、API 会更稳定、功能会更丰富。现在通义千问的 API 价格已经降到和 DeepSeek 差不多的水平，竞争只会让价格继续下探。过去两年，大厂做 AI 的思路是"先做出一个能打的模型"。字节的豆包团队可能会独立，腾讯的混元团队也可能升级。——那些大厂不会做的、不够标准化、但真实存在的需求，就是你该去的地方。层面，大厂的标准化产品往往不能满足具

前一篇实现了文档处理 Pipeline，上传的文档已经变成向量存入了 Qdrant。今天实现面向用户的问答接口——用户提问，从知识库检索相关内容，交给 LLM 生成流式回答。这是整个产品面向用户的最终功能。组件说明检索服务Qdrant 向量检索 + Re-rank 重排序问答 API流式 SSE 输出，支持引用来源对话管理创建/列表/历史/删除前端 Hook流式消息解析 + 加载状态 + 中止对话

MiniMax M3 正式发布，采用全新稀疏注意力架构 MSA，编程能力在 LiveCodeBench/SWE-bench 上超越 GPT-5.5 和 Gemini 3.1 Pro，支持 100 万 token 上下文和原生多模态。本文包含 benchmark 数据、实际体验和价格对比。

MiniMax M3 正式发布，采用全新稀疏注意力架构 MSA，编程能力在 LiveCodeBench/SWE-bench 上超越 GPT-5.5 和 Gemini 3.1 Pro，支持 100 万 token 上下文和原生多模态。本文包含 benchmark 数据、实际体验和价格对比。

前一篇我们实现了文档上传管理，但上传后的文档还是"死"的——只是存了个文件。今天我们要让文档活起来：解析内容、切分成片段、向量化、存入向量数据库。这是整个产品的核心引擎——文档处理 Pipeline。组件说明文档解析PDF/TXT/MD/DOCX → 纯文本文本切分递归字符切分（chunk_size=512, overlap=128）EmbeddingBGE 模型向量化Qdrant 存储Colle

用户系统完成后，今天实现核心业务模块——知识库与文档管理。用户登录后可以创建知识库、上传文档、管理文件。这是整个产品的数据入口，后面所有的 RAG 问答都基于这里的数据。用户操作 API 后端服务 存储创建知识库 → POST /api/knowledge-bases → PostgreSQL → users + knowledge_bases上传文档 → POST /kb/:id/documen

前两篇我们搭建了项目骨架，所有服务都能跑起来了。今天实现第一个完整的功能模块——用户系统。用户系统是几乎所有 Web 应用的基础。用户注册（邮箱 + 密码）用户登录（JWT Token）密码加密与验证登录状态检查与 Token 刷新完整的 API + 前端页面组件说明密码加密bcrypt 哈希存储JWT Token签发/验证/过期注册接口邮箱唯一性检查 + 密码规范登录接口密码验证 + Token

上一篇完成了产品定义和架构设计。今天开始真正动手搭项目——从零初始化整个项目骨架，确保所有服务能一键运行。我们会创建完整的项目目录、配置 docker-compose 编排所有依赖服务、搭建 FastAPI 后端骨架和 React 前端项目。组件状态docker-compose 编排（6 个服务）✅FastAPI 后端骨架（配置、数据库、模型）✅React 前端骨架（Vite + Tailwind

前面五篇我们学了 AI 应用开发的各项技术。从今天开始，我们要做一个真正的产品——一个可上线、可运营的 AI 知识库助手。这个系列的目标不是"写 Demo"，而是从产品定义到部署上线的完整流程。每篇都有可运行的代码，最终交付一个可以给真实用户使用的产品。users（用户表）knowledge_bases（知识库表）documents（文档表）conversations（对话表）title VARC