第一周我们把 AI 助手的前后端骨架跑通了AI 已经能聊天、能结构化回答、还能调用工具查订单但它回答问题时依赖的始终是模型自身的通用知识一旦涉及公司内部的售后政策、产品说明这类专属资料就无能为力。第二周的目标就是补上这个短板花五天时间完成知识库管理页面和文档问答能力的搭建让 AI 从什么都能聊几句变成真正懂公司业务。五天的节奏依然是层层递进先解决文档怎么管的问题再解决文档怎么处理的问题然后让 AI 真正基于资料回答接着补上引用溯源最后再做一个调试页面来检验检索效果是否可靠。Day 6让知识库文档可管理这一天的目标是解决管理员上传公司资料后系统接得住的问题。真实场景里资料的格式五花八门可能是售后政策的 PDF、产品说明的 Markdown、接口文档的 Word也可能是常见问题的表格或历史工单的 CSV系统需要有一套统一的方式来接收和管理这些异构文档。技术上后端搭建文档上传接口配合文档解析逻辑把不同格式统一转换成可处理的文本再落库并维护每份文档的状态前端则实现一个知识库文档列表页面支持点击上传和拖拽上传两种方式同时展示上传进度和文档状态标签让管理员对整个知识库的资料情况一目了然。这一天结束时公司资料终于有了一个集中管理的入口而不是散落在各个员工的电脑里。Day 7让文档处理过程可见文档传上去只是第一步真正能被 AI 利用还需要经过切片和向量化而这个过程往往需要一些时间管理员必须清楚地知道每份文档到底进行到哪一步了。这一天的目标就是把这个原本黑盒的处理流程变得透明。技术上后端实现文档切片和索引逻辑并且用异步任务的方式记录处理状态和日志避免长耗时操作阻塞请求前端则在文档列表基础上新增状态展示用解析中、索引中、完成、失败这几种状态标签清晰呈现进度配合片段数量和错误信息的展示让管理员在文档卡住或者解析失败时能第一时间发现问题。这一天做完知识库的处理链路就从上传了但不知道有没有用变成了全程可追踪。Day 8让 AI 从公司资料里找答案前两天把资料管理和处理流程打通之后这一天终于要让这些资料真正派上用场。当用户问出类似7 天无理由退款政策是什么这样的问题时AI 不该继续凭空回答而要先去知识库里检索相关资料再基于检索到的内容组织答案。技术上后端实现向量检索能力并搭建一个知识库问答接口把检索到的结果连同用户问题一起交给模型生成回复前端则在聊天页面里展示正在检索知识库的过程反馈并把命中的文档片段和相似度分数直接呈现出来用户点击还能查看对应的原文片段。到这一天AI 的回答第一次真正建立在公司自己的资料之上而不再是通用知识的泛泛而谈。Day 9让回答带上引用来源即便 AI 已经能基于资料回答业务方依然不会轻易相信一段没有依据的文字尤其在售后政策这类需要严谨性的场景里回答必须能说清楚这句话是从哪份文档来的。这一天的目标就是补上引用溯源的能力。技术上后端在返回答案的同时附带来源信息包括文档标题、页码、chunk 编号以及对应的原文片段前端则在回答下方展示引用来源列表支持点击展开查看原文、跳转到文档详情页甚至直接复制引用内容方便业务方核实。这一天做完AI 的每一个回答都变得有据可查业务方也终于敢把这套系统用在真实的客服场景里。Day 10搭建检索调试页面知识库跑起来之后开发和运营很快会遇到一个新问题有些问题检索出来的结果并不理想但光看最终答案根本无法判断到底是检索环节出了问题还是生成环节出了问题。这一天的目标是为团队自己准备一个调试工具把检索过程的每一个细节都摊开来看。技术上后端提供一个检索调试接口支持设置 top_k 等参数并同时支持向量检索、关键词检索和混合检索几种策略还能对结果做 rerank前端则新增一个独立的调试页面包含查询输入框、检索参数设置面板、召回结果列表、分数展示以及最终进入模型的上下文预览方便直接对比不同检索策略的效果差异。这一天结束时团队手里多了一件排查知识库问题的利器而不再只能靠猜测去优化检索效果。这一周我们会围绕“公司资料如何进入 AI 回答链路”展开从文档上传、解析、切片、索引开始一步步把知识库管理、检索问答、引用来源和检索调试串起来。文章不会把重点放在 RAG 概念堆砌上而是继续按照每天交付一个可见功能的节奏推进让你清楚知道每一步要解决什么问题、会用到哪些技术、最终会形成怎样的页面和接口。等第二周完成后这个 AI 助手将不再只是一个能聊天的对话框而是具备基于公司资料回答问题、展示依据并支持调试优化的知识问答基础能力。