Nox-Lumen AutoNox-Lumen Auto

bug-import

📦 已开源到 combo-skills

本技能已发布到公开仓库 Nox-Lumen-tech/combo-skills。 平台 chat 内一行装:/skill-install Nox-Lumen-tech/combo-skills/bug-import

一句话定位

bug-import 不是一个"把 Bug 导到知识库"的 ETL 技能。它是一个**"把 KB 里一条条独立的 Bug 记录,定时加工成可复用的 LTM 模式洞察"的技能——让 L2 代码审核时能命中模式**、而不只是命中关键词

为什么需要加工(不加工的后果)

不加工加工后
L2 审核时 RAG 从 KB 捞一堆 Bug 原文L2 直接命中"X 模块是缺陷热点"这条 fact
召回差、token 贵、信号弱高信噪比、直接给出可行动的判断
新人每次都要重新"悟"规律规律被结构化沉淀,新人直接获益
Bug 多了反而干扰(找不到重点)越多 Bug 加工出来的洞察越可信

单条 Bug 看不出模式,必须积累后才能聚合——这是为什么 bug-import 的加工环节是定时的、批量的,不是实时的。

三阶段流水线

Rendering diagram…

Phase 3:四维 LTM 加工(核心)

维度 ① module_hotspot — 模块热点

内容
触发条件同一 module 下累计 ≥ 3 条 Bug
产出 fact 模板"X 模块历史累计 N 个缺陷,主要集中在 Y 类问题,审核此模块代码变更时需重点检查 Y 相关逻辑"
confidence 基线0.6
confidence 加权Bug ≥5 +0.1;Bug ≥10 +0.1;有 critical +0.1;最大 0.95
tags["bug_pattern", "module:{module}", "pattern:{top_tag}"]

维度 ② cross_module_pattern — 跨模块系统性问题

内容
触发条件同一 pattern_tag≥ 2 个不同模块中出现
产出 fact 模板"Y 类问题在 N 个模块中均有出现,累计 M 个相关缺陷,属于项目级系统性风险"
confidence 基线0.65
confidence 加权涉及模块 ≥3 +0.1;总 Bug ≥5 +0.1;最大 0.95
tags["bug_pattern", "cross_module", "pattern:{pattern_tag}"]

维度 ③ file_hotspot — 高频缺陷文件

内容
触发条件同一 affected_file≥ 2 条 Bug 中出现
产出 fact 模板"F 是高频缺陷文件,历史关联 N 个 Bug,涉及问题类型:...,此文件有变更时需格外仔细审核"
confidence 基线0.7(比模块级更高——文件级更具体)
confidence 加权Bug ≥3 +0.1;有 critical +0.1;最大 0.95
tags["bug_pattern", "file_hotspot", "file:{path}"]

维度 ④ recurring_root_cause — 反复出现的根因模式

内容
触发条件同一根因关键词组合≥ 3 条 Bug 中重复出现(TF-IDF / 共现分析)
产出 fact 模板"项目中反复出现 '根因摘要' 类根因问题,涉及 X 等 N 个缺陷,建议审核中设立专项检查点"
confidence 基线0.6
confidence 加权关键词精确匹配 +0.15;涉及 Bug ≥5 +0.1;最大 0.95
tags["bug_pattern", "recurring_root_cause", "cause:{keyword}"]

四个维度互不冗余

它们是四个完全不同的审视视角——组合起来覆盖"横向模块-纵向跨模块-文件粒度-根因归因"四个切面。同一批 Bug 常常会产出多条维度的 fact,彼此互为补充而非重复。

增量 + 更新(不是每次重算)

Rendering diagram…
场景处理
模块 Bug 从 2 → 3新增 module_hotspot fact
模块 Bug 从 5 → 8,已有 fact更新 fact 内容和 confidence
Bug 被标 rejected / 误报下次 cron 重算,必要时降 confidence 或删除
同一模式 fact 已存在metadata.source_bug_ids 比对,更新而非新增

fact 结构(带溯源)

{
  "type": "fact",
  "content": "BMS 模块历史累计 8 个缺陷,主要集中在心跳超时处理...",
  "confidence": 0.85,
  "tags": ["bug_pattern", "module:BMS", "pattern:heartbeat_timeout"],
  "metadata": {
    "source_bug_ids": ["BUG-102", "BUG-118", "BUG-203", "..."],
    "extraction_type": "module_hotspot",
    "extraction_dimension": "module",
    "project": "BMS-v3",
    "ltm_extracted_at": "2026-04-23T06:00:00Z",
    "bug_count": 8,
    "severity_distribution": {"critical": 2, "major": 4, "minor": 2}
  }
}

source_bug_ids溯源关键:L2 审核时命中这条 fact 后,可以反查这 8 条原始 Bug 作为审核证据。

容量保护(防 LTM 爆炸)

维度上限超出处理
单次 cron 产出 fact 数100 条按 confidence 降序取前 100
单条 fact content 长度1000 字符截断
单条 fact source_bug_ids 数量50取最近的 50 条

L2 审核命中示例(端到端)

下面用一个真实 PR 场景串起来:从代码提交、L2 拉 LTM 检索、命中 file_hotspot fact、到最终审核报告标注。

前置:KB 里已有的历史 Bug

假设三个月前,Bug 导入阶段录入过这些(节选):

Bug ID文件根因严重度
BUG-118bms/heartbeat.c心跳 timeout 后未清定时器,重连后残留上一轮 timermajor
BUG-203bms/heartbeat.c断连回调与心跳发送线程并发访问 session 状态critical
BUG-301bms/heartbeat.c异常分支未关闭 socket,句柄泄漏major
BUG-412bms/heartbeat.c心跳间隔配置为 0 时进入死循环minor

上一个 LTM cron 周期里,Phase 3 加工器按维度 ③(file_hotspot)产出了一条 fact:

{
  "type": "fact",
  "content": "bms/heartbeat.c 是高频缺陷文件,历史关联 4 个 Bug,涉及问题类型:心跳定时器泄漏、线程并发访问、异常分支资源泄漏、边界值处理。此文件有变更时需格外仔细审核。",
  "confidence": 0.9,
  "tags": ["bug_pattern", "file_hotspot", "file:bms/heartbeat.c"],
  "metadata": {
    "source_bug_ids": ["BUG-118", "BUG-203", "BUG-301", "BUG-412"],
    "extraction_type": "file_hotspot",
    "bug_count": 4,
    "severity_distribution": {"critical": 1, "major": 2, "minor": 1}
  }
}

场景:开发者提了一个看似"简单"的 PR

PR 标题:fix(bms): adjust heartbeat timeout from 3s to 5s

diff 片段:

--- a/bms/heartbeat.c
+++ b/bms/heartbeat.c
@@ -42,7 +42,7 @@ static void bms_start_heartbeat(session_t *s) {
     pthread_mutex_lock(&s->lock);
     s->hb_enabled = true;
-    s->hb_interval_ms = 3000;
+    s->hb_interval_ms = 5000;
     schedule_timer(&s->hb_timer, s->hb_interval_ms, on_hb_tick);
     pthread_mutex_unlock(&s->lock);
 }
@@ -71,6 +71,9 @@ static void on_hb_timeout(session_t *s) {
-    close_session(s);
+    if (s->hb_enabled) {
+        close_session(s);
+    }
 }

表面看只是调整了心跳间隔 + 加了个 hb_enabled 的保护判断,只有 4 行改动

L2 审核执行流程

Rendering diagram…

关键一步:code-review 构建上下文时调用

unified_search(
  sources=["fact"],
  tags_include=["bug_pattern", "file:bms/heartbeat.c"],
  min_confidence=0.7
)

命中 fact 后,按 metadata.source_bug_ids 反查 KB 读回 4 条原始 Bug 原文作为证据链喂给 LLM。

审核员在 html-report 看到的报告

## 审核发现
 
### ⚠️ Severe · bug_pattern_match · bms/heartbeat.c:73
 
**命中历史模式**(来自 LTM · confidence 0.9):
> bms/heartbeat.c 是高频缺陷文件,历史关联 4 个 Bug,涉及问题类型:
> 心跳定时器泄漏、线程并发访问、异常分支资源泄漏、边界值处理。
 
**本次 PR 改动的风险点**
 
1. **心跳间隔从 3000 → 5000(line 45)**
   参考 BUG-412(边界值处理):心跳间隔配置为 0 时会死循环。
   本次虽然不是改成 0,但建议补一个入参校验确保新值在合法区间
   (例如 [1000, 60000]ms),防止后续配置下发时意外归零。
 
2. **on_hb_timeout 新增 `if (s->hb_enabled)` 判断(line 72-74)**
   参考 BUG-203(线程并发访问):本文件历史上有回调与心跳发送线程
   并发访问 session 状态的问题。
   **`s->hb_enabled` 的读取没有在锁保护内**——bms_start_heartbeat 写它时
`s->lock`,但 on_hb_timeout 读它时没加锁,可能读到中间态。
   建议将这段判断放入 `pthread_mutex_lock(&s->lock)` 保护。
 
3. **关联历史 Bug**(点击跳 KB 原文):
   - [BUG-118](#) · 心跳 timeout 后未清定时器
   - [BUG-203](#) · 断连回调与心跳发送线程并发访问 session 状态 ← **与本次改动强相关**
   - [BUG-301](#) · 异常分支未关闭 socket
   - [BUG-412](#) · 心跳间隔配置为 0 时进入死循环 ← **与本次改动强相关**
 
**建议**:本次 PR 表面是简单的数值调整,但落在历史缺陷热点文件上,
需要在评审中同步核查心跳相关的 3 个历史风险维度(定时器生命周期 /
并发保护 / 边界值校验),不要只看 diff 本身。

有 bug-import vs 无 bug-import 的对比

维度无 bug-import(只靠 L1 lint + LLM 读 diff)有 bug-import(L2 命中 LTM fact)
能发现的问题语法/风格/明显空指针+ 历史模式匹配、Bug 溯源、项目级风险
对"只改 4 行"的 PR"LGTM,风格无问题""此文件是缺陷热点,4 行改动触及 2 类历史 Bug 模式"
审核员负担要自己回忆历史 Bug系统直接给出历史 Bug 链接和风险维度
新人的审核质量取决于新人经验新人直接获得老手级别的审视框架
误杀率容易误杀(lint 规则过严)低(由多年真实缺陷统计背书)

一句话:L1 让代码"符合规范",L2 + bug-import 让代码"避开这个项目踩过的坑"——审核不再从零开始怀疑,而是带着历史规律去审

原始 JSON 审核输出(供集成 CI / ALM 回写参考)

如果要集成到 CI pipeline 或通过 alm-integration 写回缺陷单,L2 产出的结构化输出长这样:

{
  "pr_id": "PR-2341",
  "findings": [
    {
      "category": "bug_pattern_match",
      "severity": "severe",
      "file": "bms/heartbeat.c",
      "line": 73,
      "evidence": {
        "ltm_fact_id": "ltm-fact-7821",
        "ltm_confidence": 0.9,
        "source_bug_ids": ["BUG-118", "BUG-203", "BUG-301", "BUG-412"],
        "matched_pattern": "file_hotspot + concurrent_access"
      },
      "advice": "s->hb_enabled 读取未加锁,参考 BUG-203 可能存在竞态..."
    }
  ]
}

使用流程

Rendering diagram…

触发方式

/bug-import 把 Jira 项目 ABC 过去一年的已关闭 Bug 导入

自然语言示例:

  • "导入 Bug 数据"
  • "上传缺陷记录 CSV"
  • "导入 Jira bug"
  • "历史 bug 分析"
  • "缺陷模式提取"

触发约束

约束说明
不要一次导万条分批次导入,避免 LTM 提取任务压力过大
注意权限某些 Bug 含敏感信息,导入前确认是否脱敏
租户隔离导入的 Bug 严格归属当前租户,不跨租户污染
LTM 是定时的首次导入后,下一个 cron 周期(默认 6h)才会产出 fact

常见问题

Q:为什么是定时而不是实时?

单条 Bug 本身看不出模式。维度 ① 要求 ≥3 条,维度 ④ 要求 ≥3 条根因关键词重合,这些必须在积累之后才能计算。实时加工产生的 fact 要么是"1 条 Bug → 不足以下结论"、要么是"反复在半成品 fact 之间 update",既浪费算力又污染 LTM

Q:如果某条 fact 后来发现是错的(Bug 被标误报)会怎样?

下次 cron 会重算

  • 如果误报 Bug 占比高,confidence 下降
  • 如果降到阈值以下,自动删除该 fact
  • 溯源 source_bug_ids 会排除掉误报条目

Q:两个模式 fact 撞在一起(比如 "BMS 模块热点" 和 "BMS 某文件热点")会不会冗余?

不会——这两条是维度 ① 和维度 ③ 的产出,粒度不同:前者告诉审核员"这个模块整体要小心",后者告诉审核员"这个文件要格外仔细"。L2 审核时两条都会命中,形成"层层加码"的审核强度,不是冗余。

与其他技能的关系

Rendering diagram…
搭配作用
code-reviewPhase 3 产出的 fact 的消费端
memory-sdkLTM 读写底层 API
alm-integration发现新问题时写回缺陷单
html-report把命中的 fact 可视化

相关概念

On this page