很多测试团队都会遇到一个很现实的问题：需求资料越来越多，但真正要用的时候，却越来越难找。 一个项目从立项到上线，可能会沉淀 PRD、接口说明、流程图、评审纪要、补充说明、变更文档、版本差异记录。资料本身都在，但测试人员真正提问时，经常会遇到几个典型场景： 所以，需求问答不是简单接一个大模型聊天框，而是要解决一个更关键的问题： > 如何让大模型在当前产品、当前项目、已解析资料范围内，先检索到可信内容，再基于证据回答？ 效能平台的“需求问答”功能，就是围绕这个目标设计的。 > 场景感受：用户不需要先判断答案在哪份文档里，只要在当前项目范围内提出问题，系统负责去知识库里找依据。
> 一句话看懂：先把资料变成知识分片，再用混合检索命中证据，最后让大模型基于证据回答。
一、需求问答解决的不是“聊天”，而是“项目知识可用性” 传统需求资料管理通常停留在“上传文件”和“人工查阅”阶段。 > 它是一个面向测试与产品协作场景的项目知识问答入口，让需求资料从“静态文件”变成“可检索、可追问、可引用、可结构化表达”的知识资产。 二、按产品和项目组织知识库，避免问答串库 选择项目后，平台会展示当前项目下的全部资料，并且在问答时严格限定检索范围： 当前 productId + 当前 projectId（展示产品名称和项目名称） 如果一个平台同时维护多个产品、多个项目，大模型问答最怕的不是“答不出来”，而是“拿错项目的资料来回答”。 所以当前实现不是全局混搜，而是明确按当前产品、当前项目过滤知识分片。这样可以保证： 后续测试用例生成、需求评审、风险分析都可以围绕同一套项目资料展开。 三、资料上传与解析：从文件到知识分片 > 提示：可以把这一步理解成：把“文档”拆成大模型能检索、能引用、能追溯的“知识卡片”。
在项目资料面板中，用户可以上传需求相关资料。目前页面支持的文件类型包括： 如果开启自动解析，文件上传后会直接进入当前项目知识库；如果没有自动解析，也可以在资料列表中手动点击“解析入库”。 解析入库后，系统会把文档拆分成多个知识分片。每个分片会保存： 这一步的意义是：大模型并不会直接读取整份文档，而是先通过检索找到最相关的分片，再把这些分片作为证据交给模型。 只有资料被解析成知识分片，后续的关键词检索、向量检索、证据引用、大模型回答才有可靠的数据来源。 四、为什么只做关键词检索不够？ 如果资料里刚好也出现“待办任务”，关键词检索可能命中。但真实场景里，问题和文档表达经常并不完全一致： 用户问“货件状态”，文档写“运输中、已取件、已到达”； 用户问“发布后会发生什么”，文档写“生成待办、发送通知、状态流转”； 用户问的是一句自然语言，而文档里是表格或流程描述。 五、混合检索：先命中资料，再让大模型回答 第一步：中文问题增强切词 除了常规按空格、标点拆分外，还会对中文连续文本做 2-4 字滑窗切分。 这样可以提高中文业务词的命中率，避免因为整句匹配失败导致漏检。 第二步：关键词召回 系统会在当前产品、当前项目范围内，对知识分片的标题和正文做模糊匹配。 如果文档里明确出现某个业务词，比如“待办任务”“发布”“货件计划”，关键词检索可以快速把相关片段拉出来。 第三步：向量召回 除了关键词，系统还会为问题生成查询向量，并与项目下已入库分片的向量做余弦相似度计算。 即使用户问题和文档原文不是完全同一套词，只要语义接近，也有机会被召回。 当前实现中，向量生成优先使用配置的 Embedding 模型。如果模型服务暂时不可用，或不支持 embedding 接口，系统会自动使用本地 hash embedding 兜底，保证检索链路不断。 需要说明的是：当前数据库环境未启用 pgvector 扩展，因此现阶段采用的是 JSONB 存储向量 + Python 内余弦相似度计算。后续如果部署环境支持 pgvector 或专用向量数据库，可以进一步升级检索性能和索引能力。 第四步：融合排序 系统会将关键词分和向量分归一化后进行融合排序，最终选出 TopK 条证据片段。 六、大模型问答：不是自由发挥，而是基于证据归纳 本地检索模式会直接返回命中的知识库依据，适合快速验证资料是否能搜到。 大模型问答模式则会把检索到的证据片段交给模型，由模型进行归纳、解释和结构化输出。 直接答案 依据引用 测试关注点/风险点 信息不足项 用户不用在一大段文字里找结论，开头就能看到业务定义、关键规则或流程说明。 回答会结合证据编号，团队可以展开“知识库依据”，查看具体来自哪份文档、哪个分片。 系统不只是回答“是什么”，还会尝试整理测试关注点和风险点，比如状态流转、通知触发、权限边界、异常路径、信息缺口等。 七、证据引用：让回答可复核 在对话区域，每次大模型回答都会保留 evidence 信息。 因为需求问答不是聊天娱乐，而是会影响测试分析、用例设计、需求澄清甚至上线判断。 如果回答没有依据，团队就很难判断它到底是来自文档，还是模型自己的推测。 八、回答脑图：把复杂答案变成结构化视图 这不是简单把整段回答塞进图里，而是只截取“直接答案”部分生成。 同时，中心节点不再固定为“直接答案”，而是使用大模型输出的： 比如回答的是“货件待签收”，脑图中心就应该是“货件待签收”；回答的是“黑名单管理”，中心就应该是“黑名单管理”。 对测试场景来说，脑图最大的价值是帮助团队快速形成共同理解。 复杂需求往往不是一句话能讲清楚的。通过脑图，可以把“业务名称 - 一级要点 - 二级规则”展示出来，便于评审、讨论和后续用例设计。 九、模型设置：问答模型和向量模型分开配置 问答模型 它会读取检索证据，生成直接答案、依据引用、测试关注点和信息不足项。 向量模型 向量模型负责把文档分片和用户问题转成向量，用于语义检索。 如果向量模型可用，系统会优先使用它；如果不可用，系统会自动回退到本地 hash embedding，保证资料仍然可以被检索。 另外，API Key 不在前端展示或保存，默认使用服务端环境变量。这种方式更安全，也更符合企业内部系统的管理方式。 十、历史会话：让需求分析可以持续追问 如果每次都从零开始，会很割裂。通过历史会话，项目内的需求分析过程可以沉淀下来。 十一、从使用流程看完整闭环 1. 选择产品和项目 进入需求问答页面后，先选择当前产品，再选择具体项目。 系统会把后续资料管理和问答检索都限定在这个项目范围内。 这里选择产品和项目后展示的文档与用例管理中AI生成用例的文档来源一致，两边都可以同时进行管理 2. 上传项目资料 3. 解析入库 系统会把文档解析成知识分片，并写入当前项目知识库。 4. 配置模型 在“模型设置”里配置问答模型、向量模型、TopK、Max Tokens 等参数。 这里配置模型是会让大模型回答的话，根据配置模型来进行回答，如果不配置，就默认后端使用的模型配置文件，自己使用的话，需要改成自己的api-key和对应模型id 5. 发起提问 系统会先在当前项目知识库中做混合检索，再把命中的证据交给模型回答，回答完成后，会给出直接答案和对应的测试分析。还可以进行本地回调，就是不依赖大模型，直接回答文档内容与文档位置。（但如果不依赖大模型就需要进行精确匹配了） 6. 查看依据 回答下方可以展开知识库依据，查看命中的分片和内容。 7. 生成脑图 如果回答适合结构化表达，可以点击“生成脑图”，把直接答案转换成业务脑图，回答完成后，会有一个生成脑图的按钮，可以直接点击生成。 十二、对测试团队的价值 1. 降低找资料成本 测试人员不用在多个文件里反复搜索，只要围绕当前项目提问，系统就会自动从已解析资料中召回相关内容。 2. 提高需求理解一致性 回答带引用，脑图带结构。团队可以围绕同一份证据讨论，而不是每个人各自理解一遍文档。 3. 帮助发现信息缺口 当资料不足时，回答会列出“信息不足项”。这可以反向推动需求补充，比如：状态定义不完整、触发条件不明确、异常流程缺失等。 4. 为测试用例设计打基础 需求问答不是用例生成的终点，而是用例设计前的理解层。 只有先把业务概念、流程、状态、规则、风险点弄清楚，后续生成或补充测试用例才更可靠。 十三、它不是万能答案机，而是一个可追溯的知识入口 需要明确的是，需求问答并不意味着大模型可以替代需求评审，也不能保证所有问题都自动得到完整答案。 > 在项目已解析资料范围内，尽可能检索出相关证据，并帮助用户把证据归纳成可读、可追溯、可讨论的回答。 如果资料本身缺失，系统应该提示信息不足；如果证据只覆盖部分内容，回答也应该谨慎表达。 十四、后续可以继续增强的方向 1. 接入 pgvector 或专用向量数据库 当前实现使用 JSONB 存储向量并在 Python 内计算相似度，适合功能可用和中小规模资料检索。 如果资料规模继续扩大，可以升级为 pgvector 或专用向量数据库，提高检索性能和索引能力。 2. 加入重排序模型 混合召回之后，可以进一步加入 rerank 模型，对候选证据进行二次排序，提高 TopK 证据质量。 3. 支持更多资料来源 4. 与测试用例生成联动 需求问答输出的业务概念、流程、状态和风险点，可以作为后续测试用例生成的上下文。 需求资料 → 知识解析 → 需求问答 → 风险识别 → 用例生成 → 用例评审 结语：让需求资料从“存起来”变成“用起来” 需求问答的意义，不是多一个 AI 聊天窗口，而是把项目里的需求资料转化为一个可以持续追问、可以引用依据、可以辅助测试分析的知识入口。 它让测试人员不必从一堆文档里重新翻找，让产品和研发可以围绕同一份证据对齐理解，也让后续的测试用例设计有了更可靠的上下文基础。 当需求资料可以被检索、被追问、被引用、被结构化表达时，它才真正从“文件”变成了“知识”。 附录：
这个除了需求问答外，还有一个有趣的玩法，就是蒸馏人，当把某个人事迹和习惯这些全部弄到一个项目中，形成知识库后，会变成那个人的回答，举个例子，比如马上要高考了，张雪峰老师事件想大家都知道了，但是可以把张雪峰老师蒸馏成知识库，你提问，发现它的回答真的有像那么一回事。
也可以蒸馏自己，让自己和自己对话，这个值得大家去讨论与发现。。。
夜雨聆风
