研发负责人手里的报表已经不少但那些数据可能未被充分利用。研发可能缺少一条用自然语言直接取数的链路。研发数据的三个断层需求状态留在项目管理工具Jira、禅道里代码提交与合入在 GitLab、工蜂工时另走一套系统。一个迭代复盘要同时打开三个后台导出 Excel用 VLOOKUP 按模块名对齐编码差一位就匹配不上。想看哪个模块 bug 最多要现查而且查一次只回答一个问题。缺陷按模块聚合要写一段聚合 SQL 或拖一个看板换一个问题又得重做。迭代速率velocity的定义是每轮关闭的故事点之和但不同团队对关闭的口径不一致有的算合入主干有的算测试通过口径不统一让横向对比失真。数据通常并不缺少瓶颈可能在于取数环节。等人工把三套数据拼完迭代可能已经结束发现的问题可能来不及在本轮纠正。字段注释映射模型解析缺陷数靠一层字段注释映射。大模型只负责理解自然语言业务词落到哪张表哪列、怎么聚合由这层映射决定缺陷数对应 defects 表 status 为 open 的记录计数吞吐对应每轮关闭的需求故事点求和速率对应 velocity 的计算口径。这层元数据由懂业务的人定义写进系统的字段词典。映射到位自然语言才能转成准确的 SQL。这一步是 NL2SQL 落地里常被低估的一道关。缺少映射模型可能只能凭训练语料猜字段名遇到企业自定义表结构比如缺陷表叫 bug_track 而非 defects就会拼错列。维护有成本。表结构变更、字段改名都要同步更新注释否则问数结果悄悄失真。工程上建议把字段映射纳入版本管理和数据库变更一起评审。混合检索与图表问数引擎内部同时跑两条检索。语义向量检索用 BGE-M3 把问题转成 1024 维向量按余弦相似度找相近的历史问答与指标说明容错性较高问法不标准时也有可能命中。关键词检索走 Elasticsearch 的 BM25对缺陷数velocity这类精确术语做严格匹配。两条路的量纲不可直接相加。余弦分落在 [-1,1]BM25 无上界朴素加权会被大尺度的量纲主导。工程上用 RRF倒数排名融合按排名融合或上 cross-encoder 做精排让两种信号平等参与。这有助于混合检索比单路更稳定也在很大程度上影响进模型的片段是否准确。结果要可视化为结论不只是返回数字。模块间缺陷数对比可自动生成柱状图迭代速率随时间变化可生成折线图。图表由系统根据问题类型选择用户通常无需手动绘制。BGE-M3 向量存储占用较小通常可在普通内存预算内。知识图谱下钻多轮追问靠知识图谱承接。系统把项目、模块、版本、缺陷做成实体节点用 Neo4j 存关系模块属于项目缺陷挂在模块下版本串联一批缺陷。用户先问整个项目缺陷分布再问支付模块呢图谱沿关系把范围收窄到该模块通常无需重复说明上下文。这种下钻用 Cypher 表达路径查询。从项目节点出发沿包含关系找到子模块再沿产生关系聚合缺陷计数路径推理有助于发现关联某模块缺陷集中在一个第三方依赖版本上。图谱有助于让结论从数字呈现转向结构呈现。实时可见问数有助于将研发状态从周报变为可按需查询问题有可能更早被发现。知识图谱的下钻有助于指向根因。支付模块缺陷集中在某个第三方依赖版本图谱把缺陷多和依赖版本连起来负责人据此升级该依赖或排专项修复而不是笼统加人。某开发吞吐掉一半追问发现是需求在迭代中途频繁变更解决动作变成冻结需求窗口而非催进度。风险模块有可能在缺陷爆发前被识别因为趋势折线把缓慢爬升提前暴露。总量超标才有人注意可能已经较晚如能提前发现斜率变陡处理窗口可能仍然存在。复盘用数据替代印象争论减少管理动作落在字段层面。小艾智能体可支持这套架构落地研发问数场景。它的动态 Agent 编排系统可通过 REST API 节点对接项目管理与代码平台可用 Data Extractor 节点抽取需求、缺陷、工时字段字段注释写入技能系统的 Markdown 配置可完成业务词映射。向量检索引擎可基于 MilvusZilliz 开源向量数据库与 BGE-M3北京智源研究院发布提供语义与全文混合检索知识图谱系统可基于 Neo4jNeo4j 公司图数据库支撑项目到模块到版本的多轮下钻自然语言问数结果可生成柱状图与折线图报告可支持导出进迭代复盘。整套流程可支持私有化运行研发数据可在本地处理。研发的节奏在很大程度上依赖能发现问题、解决问题的数据而非仅靠汇报转述。当负责人能用一句话获取模块缺陷分布、用一次追问下钻到根因管理有望从“事后知道”走向“当下处理”。
