代码审核总览

双层审核架构

📦 整套 12 个 skill 已开源

L2 主导的 code-review + 10 个 L1 静态分析 skill + 配套数据补给 bug-import（用户自己积累 bug 的官方流水线），全部开源到：

github.com/Nox-Lumen-tech/combo-skills

平台 chat 内一行装一个：

/skill-install Nox-Lumen-tech/combo-skills/code-review
/skill-install Nox-Lumen-tech/combo-skills/bug-import
/skill-install Nox-Lumen-tech/combo-skills/ruff
/skill-install Nox-Lumen-tech/combo-skills/checkstyle
…

LTM 沉淀：Bug 模式池 + 反馈池

代码审核之所以能"越用越准"，靠两端往 LTM 写：

通路	谁写入	memory_type	tags anchor	写入时机
① Bug 模式（实时学习）	`code-review` Step 6（每次审完 agent 自己调）	`fact`	`bug_pattern` + `source:agent_realtime`	本次审核发现的新模式
② Bug 模式（历史聚合）	`bug-import` Phase 3 加工器	`fact`	`bug_pattern` + `source:bug_import_aggregator`	历史 Bug 库导入后周期聚合
③ 误报 / 漏报反馈	`code-review` Step 6（用户给反馈时）	`error_pattern`	`false_positive` / `missed_issue`	用户标记某 finding 是误报或漏报

通路 ① ② 同池同 tag —— L2 下次审核 Step 2 检索时一次拿全：

unified_search(sources=["fact"], tags_include=["bug_pattern"], min_confidence=0.7)
unified_search(memory_type="error_pattern", query="<变更关键词>")  # 通路 ③

命中后报告以 bug_pattern_match 类别（severity: severe）呈现。

为什么 Bug 模式不走 error_pattern

平台合法 memory_type 共 5 个：fact / preference / program / error_pattern / chunk_node。其中 error_pattern 同时承载审核反馈（误报/漏报）和平台/工具运行时错误两类语义——同一个池，靠 tags 软分流。
代码 Bug 模式有意走 fact + tags=["bug_pattern"] 旁路，避免和"工具反复失败"、"运行时通信错误"这些非业务噪声共池污染搜索结果。bug-import 加工器一开始就走的这条路；本次方案让 code-review 实时通路也对齐过去——两条通路写到同一个干净的 Bug 模式池。

「bug_pattern 是 tag 不是 memory_type」—— 这是 SKILL 之间的约定，不是平台硬编码字段。agent 写记忆时 tags 完全自由，所以代码 Bug 模式的业务分类（module:CarSyncShare、pattern:heartbeat_disconnect 等）完全由 agent 自定义，平台不预先约束。详见 code-review · LTM 沉淀。

combo agent 的代码审核能力分层解耦：

Rendering diagram…

层次	做什么	不做什么
L1 静态分析	确定性规则检测（语法、规范、已知漏洞模式）	需要理解上下文的判断
L2 语义评审	需求 vs 代码符合性、设计一致性、Bug 模式匹配	静态检查（那是 L1）

两层分工

L1 — 由 9 个静态分析 skill 协同

语言	工具链页
Python	bandit / ruff / mypy / semgrep
Java	checkstyle / pmd / spotbugs
C / C++	clang-tidy / cppcheck
Kotlin	detekt

所有 L1 工具输出统一的 CodeEvidence JSON，供 L2 引用。

L2 — 由 code-review 主导

L2 是 LLM 驱动的深度审核，对照需求文档 / 设计文档 / 编码规范 / Bug 历史做语义理解。它不做静态检查（交给 L1），不做代码仓库交互（交给 integrations），不做规范配置生成（交给 standards-converter）。

L2 的八大审核类别

类别	严重度
`requirement_not_implemented`	fatal
`requirement_deviation`	severe
`design_inconsistency`	severe
`standard_violation`	general
`security_risk`	severe
`performance_issue`	general
`bug_pattern_match`	severe
`design_compliance_violation`	general

典型场景

场景	层次	触发
PR / MR 预检	L1 + L2	Gerrit/GitLab/GitHub/Gitee 集成自动触发
批量扫描	L1	定期任务
安全审计	L1（bandit/semgrep）+ L2	周期性或合规要求
MISRA / ISO 26262 合规	L2 + standards-converter 下发的规范	汽车项目强制