第一周我们把 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 助手将不再只是一个能聊天的对话框，而是具备基于公司资料回答问题、展示依据并支持调试优化的知识问答基础能力。