为什么选择做这个项目，最初要解决什么需求？

选择门店经营分析这个方向，是想解决区域经理临时取数时反复沟通、指标口径容易丢失的问题。原流程是先看固定报表，遇到“本月各门店的净销售额是多少”这样的临时问题，再请数据人员写 SQL，或者导出明细汇总。换一个日期、门店范围或指标，就需要重新确认条件。

固定报表能覆盖日常看数，但这个场景还需要在已有指标和维度之间灵活组合。直接让通用模型写 SQL 也不够，因为它不知道门店别名和退款归属，查出一个数字不代表算对了。

所以首版目标是让用户用自然语言查询已定义的经营指标，限定门店与日期范围，返回 SQL 和查询结果，口径不清时先补问。底座选用电商问数，复用元数据检索与 SQL 生成链路；我负责门店指标与上下文适配的设计，把净销售额、退款日期和别名接入这条链路。先把这类查询做准，再考虑扩大指标范围。

这个项目的起点是售后查资料时，找到相关内容之后，还要判断它能不能用于眼前这台设备。工程师原来需要核对型号和固件版本，再翻维修手册、查故障关键词。相近型号都可能出现“启动后报警”，但适用的检查步骤可能不同，单靠关键词很容易把资料混在一起。

文件目录和普通知识库能帮助找内容，却还需要把设备档案、手册生效范围和检索结果接起来。尤其是语义相似度高的片段，也可能来自另一个型号，不能直接作为维修依据。

因此我把首版限定为按设备条件查适用手册、回答故障问题并给出出处；缺少关键条件就补问，没有适用资料就返回缺口。Java 路线基于 Ragent 的固定知识问答流程，复用入库、多路检索和引用；我负责设备与手册匹配及检索适配的设计，让各条召回通道都遵守允许手册范围。选择这个项目，是因为业务规则能明确落到检索过程里，也能用具体故障问题检查是否生效。

我选择产业情报研读这个方向，关注的是材料搜集之后怎样形成能核查的结论。研究人员原来要在公开网页、已有数据库和内部文档之间查资料，把重点摘进笔记，再组织成报告。真正难的往往是确认这些材料说的是不是同一家公司、同一件事和同一个时间范围。

搜索引擎能找到页面，通用模型能整理文字，但一条消息的多处转载可能被当成多份佐证，“发布样机”也可能在摘要里变成“已经交付”。报告写完之后，读者还需要知道每个结论究竟依据哪段原文。

所以首版按一个明确主题和截止日期组织研究，交付带原文位置与日期依据的初稿，保留冲突和缺失的信息。底座采用深度研搜，复用资料搜集、任务委派和文件生成；我负责来源适配与证据组织的设计，把企业、产品、事件和时间对应清楚，再将证据关联到结论与段落。先让一份初稿可核查，材料更新后的局部重写再单独推进。

这条路线要解决的是设备档案和知识平台之间的衔接。售后工程师原来先查设备型号、版本，再到资料库里选手册、输入故障问题，最后核对回答引用的资料是否适用。每次查询都要由人把设备条件带到资料查询中，漏掉版本就可能得到不适用的建议。

RAGFlow 已提供文档解析、切分和检索，可以复用；业务还缺少“这台设备对应哪些平台文档”的映射，以及信息不足、版本冲突和无资料时的处理。因此首版选择外部 Python 服务接入设备档案，确定适用手册后代理片段检索，核对来源，再组织带出处的答复。

我负责设备资料适配服务的设计，包括设备到手册、手册到平台文档的映射，以及受限请求和响应核对。首版只把按设备查资料这件事接通：缺条件补问，无适用手册时停止请求，有手册但没有故障证据时保留缺口。这种分工把文档处理交给平台，把设备规则和查询分支放在业务服务中。