feat: 通用评审生态位 — 产出普通代码级问题 (generalFindings)

DESIGN.md

@@ -15,9 +15,12 @@ BanGD 是一个面向 **BanDB 数据库引擎（Go）垂类**的 AI PR 评审助
 | **PR 变更总结** | `changeSummary` | 用数据库架构语言概括"动了系统哪一层、改了什么不变量/数据结构"，而非逐行复述 diff |
 | **风险代码识别** | `findings[]` + `overallRisk` | 每条 finding 带文件/行号、严重度、类型（并发/内存/锁/存储/schema/性能/资源/错误处理/兼容）；`overallRisk`（高/中/低）供 triage |
 | **Review 建议生成** | `findings[].architecturalSolution` 等 | 每条按 `问题根因 → 为什么低级解法不够 → 架构级方案 → 代价/收益` 四段式给出建议 |
+| **普通代码级问题** | `generalFindings[]` | 任何称职通用评审者都会指出的、有 diff 证据的**确凿正确性/逻辑缺陷**（逻辑反、边界、空指针、吞错、资源泄漏等），普通修法即可、不走四段式——见 §七 |
 
 这个固定的四段式结构是质量的关键：它**强制模型把"症状"推进到"根因"再到"架构方案"**，从输出格式上杜绝了"加个锁就完事"的低级答案。
 
+`findings`（架构级）是 BanGD 的差异化价值；`generalFindings`（普通级）则确保它**不把通用 bug 拱手让给 Copilot**——两者并存，详见 §七。
+
 ---
 
 ## 二、模型选择
@@ -75,9 +78,26 @@ BanGD 是一个面向 **BanDB 数据库引擎（Go）垂类**的 AI PR 评审助
 
 1. **Agentic 周边代码读取**（最大质量杠杆，**已落地第一版**，见 §三.3）：当前是单轮规划 + 有界拉取。后续可做**多轮**（看到补读内容后再决定是否继续探索，loop-until-enough）、或升级为模型交错发起 `read_file` 的真正 tool-use 循环；并可引入仓库文件树（`listFiles`，限定到 diff 触及的目录以控 token）提高补读命中率。
 2. **评测语料集 + rubric 迭代**：用历史 PR + 专家评审度量 precision/recall，数据驱动地打磨 rubric 与范例。
-3. **对抗式验证**（**已落地**，见 §四"降误报"，`src/core/verify.ts`）：对每条 finding 派多个"反驳者"，严格多数否决则丢弃，系统性压低误报。后续可做**视角分化**（让每个反驳者从不同失败维度切入，而非同质重复），进一步提升过滤质量。
+3. **对抗式验证**（**已落地**，见 §四"降误报"，`src/core/verify.ts`）：对每条 finding 派多个"反驳者"，严格多数否决则丢弃，系统性压低误报。**架构级与普通级 finding 走同一套对抗式复核**（见 §七）。后续可做**视角分化**（让每个反驳者从不同失败维度切入，而非同质重复），进一步提升过滤质量。
 4. **RAG 知识库**：索引 BanDB 设计文档、历史评审决策、数据库系统模式，增强上下文理解。
 5. **行级 inline 评论**：用 `pulls.createReview` 把建议落到具体代码行，而非单条汇总评论，提升使用体验。
 6. **Probot App 形态**：常驻服务，支持记忆、增量评审、跨仓统计（端口已使其成为换壳工作）。
 7. **多智能体流水线**：找隐患 / 验证可行性 / 综合，分工提升深度与可靠性。
 8. **模型分档与增量评审**：便宜档初筛 + 强档深评；只重评新增 commit，进一步压低成本与延迟。
+
+---
+
+## 七、通用评审生态位（generalFindings）
+
+架构级 `findings` 是 BanGD 的差异化价值，但只产出架构级问题会留下一个缺口：**那些任何称职通用评审者都会指出的普通 bug**（分支条件写反、off-by-one、空指针、吞错、资源未释放、明显竞态写法）如果 BanGD 不报，就等于把这块生态位拱手让给 Copilot。所以评审**同时**产出第二类结果 `generalFindings`——普通代码级问题。
+
+设计上与架构级刻意区分：
+
+- **结构更轻**：`generalFinding` 只有 `file/line/severity/category/title/description/suggestion`（见 `src/core/schema.ts`），**不走四段式**——这些问题不值得"根因→低级解法不够→架构方案→代价/收益"的论证，指出位置 + 普通修法即可。
+- **自带 few-shot**：与每个架构维度一样，普通问题也有专门的范例（`prompts/examples/general-findings.md`），示范"该报什么"与"绝不该报什么"（红线）。它**不随维度门控**，每次评审恒定注入，落在 prompt-cache 的稳定块里，边际成本近乎为零。
+- **质量红线（写进系统提示词）**：只报**有 diff 证据、能定位具体出错点**的确凿正确性/逻辑问题；**不报**风格/命名/格式/"建议加测试"这类 nits；不与架构级 finding 重复；最多约 6 条，没有就返回空数组。红线的目的是**不让 BanGD 沦为嘈杂的通用 linter**——宁缺毋滥。
+- **同样经过对抗式复核**：`generalFindings` 与 `findings` 走同一套多反驳者、严格多数否决的验证（`verifyGeneralFindings`，反驳提示词换成"是否为真实正确性缺陷"），把普通级误报也压下去。
+- **投递方式不同**：架构问题以 **Issue** 跟踪（是需长期跟进的设计问题）；普通问题**只在 PR 汇总评论里内联列出**（是即时的 bug 提示，随 diff 失效，不必建 Issue）。
+- **可降级**：`generalFindings` 在 schema 里 `default([])`，模型遗漏该字段时不让整条评审降级为解析失败。
+
+这样 BanGD 在一次评审里既**占住通用评审生态位**（不漏普通 bug），又保住**垂类架构深度**这一差异化优势。

action.yml

@@ -23,11 +23,13 @@ inputs:
 
 outputs:
   finding_count:
-    description: 'Number of findings BanGD produced (after adversarial verification).'
+    description: 'Number of architecture-level findings BanGD produced (after adversarial verification).'
+  general_finding_count:
+    description: 'Number of ordinary code-level findings (the general-reviewer niche), after verification.'
   total_tokens:
     description: 'Total tokens consumed by this review run (routing + planning + review + verification).'
   dropped_count:
-    description: 'Findings dropped by adversarial verification as likely false positives.'
+    description: 'Findings (architecture + ordinary) dropped by adversarial verification as likely false positives.'
 
 runs:
   using: 'node20'