研发管理：项目进度与缺陷问数

研发负责人手里的报表已经不少，但那些数据可能未被充分利用。研发可能缺少一条用自然语言直接取数的链路。

研发数据的三个断层

需求状态留在项目管理工具（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 配置可完成业务词映射。向量检索引擎可基于 Milvus（Zilliz 开源向量数据库）与 BGE-M3（北京智源研究院发布）提供语义与全文混合检索，知识图谱系统可基于 Neo4j（Neo4j 公司图数据库）支撑项目到模块到版本的多轮下钻，自然语言问数结果可生成柱状图与折线图，报告可支持导出进迭代复盘。整套流程可支持私有化运行，研发数据可在本地处理。

研发的节奏在很大程度上依赖能发现问题、解决问题的数据，而非仅靠汇报转述。当负责人能用一句话获取模块缺陷分布、用一次追问下钻到根因，管理有望从“事后知道”走向“当下处理”。