bug-import
本技能已发布到公开仓库 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 的加工环节是定时的、批量的,不是实时的。
三阶段流水线
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,彼此互为补充而非重复。
增量 + 更新(不是每次重算)
| 场景 | 处理 |
|---|---|
| 模块 Bug 从 2 → 3 | 新增 module_hotspot fact |
| 模块 Bug 从 5 → 8,已有 fact | 更新 fact 内容和 confidence |
Bug 被标 rejected / 误报 | 下次 cron 重算,必要时降 confidence 或删除 |
| 同一模式 fact 已存在 | 用 metadata.source_bug_ids 比对,更新而非新增 |
fact 结构(带溯源)
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-118 | bms/heartbeat.c | 心跳 timeout 后未清定时器,重连后残留上一轮 timer | major |
| BUG-203 | bms/heartbeat.c | 断连回调与心跳发送线程并发访问 session 状态 | critical |
| BUG-301 | bms/heartbeat.c | 异常分支未关闭 socket,句柄泄漏 | major |
| BUG-412 | bms/heartbeat.c | 心跳间隔配置为 0 时进入死循环 | minor |
上一个 LTM cron 周期里,Phase 3 加工器按维度 ③(file_hotspot)产出了一条 fact:
场景:开发者提了一个看似"简单"的 PR
PR 标题:fix(bms): adjust heartbeat timeout from 3s to 5s
diff 片段:
表面看只是调整了心跳间隔 + 加了个 hb_enabled 的保护判断,只有 4 行改动。
L2 审核执行流程
关键一步:code-review 构建上下文时调用
命中 fact 后,按 metadata.source_bug_ids 反查 KB 读回 4 条原始 Bug 原文作为证据链喂给 LLM。
审核员在 html-report 看到的报告
有 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 产出的结构化输出长这样:
使用流程
触发方式
自然语言示例:
- "导入 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 审核时两条都会命中,形成"层层加码"的审核强度,不是冗余。
与其他技能的关系
| 搭配 | 作用 |
|---|---|
| code-review | Phase 3 产出的 fact 的消费端 |
| memory-sdk | LTM 读写底层 API |
| alm-integration | 发现新问题时写回缺陷单 |
| html-report | 把命中的 fact 可视化 |
相关概念
- 核心概念 · Memory 记忆系统 — 加工路径 —
bug-import是这套通用加工范式的第一个实现 - 核心概念 · Cron 定时调度 — Phase 3 的触发机制
- 核心概念 · Skill 技能体系