Apex Diff Analyzer — 巅峰代码变更影响分析

技能概述

Apex Diff Analyzer 是 code-diff-analyzer 的增强版本，在保持原有功能的基础上，新增：

1. 量化风险评分模型：基于 CHID 实践案例的 5 维度综合评分体系，将风险从定性（高/中/低）升级为定量（0-100分）
2. JIT 缺陷预测洞察：基于 CC2Vec/JITLine 研究的预测性分析，提供决策支持
3. 学术数据支撑：引用权威研究数据，增强分析结论的可信度

触发条件

以下任意场景触发本技能：

• 用户提供 git diff 或 git log --oneline 输出内容
• 用户要求分析版本间的代码改动（如 v1.2.24 → v1.2.25）
• 用户需要评估 PR/MR 的影响范围
• CI/CD 流水线产出的 tagdiff.txt 需要分析（格式 A）
• 用户提供 compare_vX_to_Y.md 格式的结构化代码对比报告（格式 B）
• 用户询问"这次改动影响了什么"、"需要测试哪些功能"
• 用户要求生成变更报告（Markdown / HTML）
• 用户要求量化风险评分 或 预测性分析

分析工作流

Step 1 — 接收并识别变更内容

1.1 格式识别（优先执行）

输入的 diff 内容可能有以下两种格式，先判断格式，再解析内容：

格式 A：CI/CD 原始输出（tagdiff.txt）

特征：

• 头部为 echo 输出的纯文本行，如 构建编号: 19、版本比对: v1.2.24 -> v1.2.25
• 头部第 4 行为 仓库地址: https://gitlab.example.com/xx/xx/xxxx.git（含服务名称）
• Commit 记录部分紧跟 ======== Commit 记录 ========= 分隔符
• 代码 diff 部分紧跟 ======== 代码差异 ============ 分隔符

格式 B：结构化 Markdown 报告（compare_vX_to_Y.md）

特征：

• 头部为 Markdown 表格，包含「仓库名称」「对比类型」「源版本」「目标版本」「生成时间」「对比范围」
• Commit 变更清单为 Markdown 表格，含 Commit ID、提交信息、作者、时间四列
• 每个文件有独立的三级标题 ### 📄 filename
• 代码 diff 内容用 ```diff ``` 代码块包裹

1.2 信息提取（按格式分支处理）

Step 2 — 变更类型分类

对每个文件/模块的变更进行分类：

Step 3 — 变更代码 vs 新增代码分类

3.1 变更代码（Modified Code）

定义：对已有逻辑/行为的修改，可能改变现有功能的行为。

识别标志：

• 既有 -（删除行）又有 +（新增行）的 @@ 块
• 修改已有变量名、函数参数、条件逻辑
• 修改数据格式、阈值、常量

分析重点：变更前后行为差异、向后兼容性风险、下游依赖方影响

3.2 新增代码（Added Code）

定义：纯粹新增的逻辑/功能，不改变已有行为。

识别标志：

• 只有 +（新增行）没有 -（删除行）的 @@ 块
• 新增函数、新增配置项、新增文件
• 新增 if/else 分支

Step 4 — 模块依赖分析

根据变更文件的路径和职责，识别模块角色：

Step 5 — 定性风险评估

5.1 风险评估增强规则

// 伪代码规则
if (changesAuthCoreLogic(diff)) risk = "🔴 高";      // 认证核心逻辑
else if (changesPaymentFlow(diff)) risk = "🔴 高";    // 支付流程
else if (changesCoreRoute(diff)) risk = "🔴 高";      // 核心路由
else if (isDataFormatChange(diff)) risk = "🔴 高";    // 数据格式变更
else if (changesRouteConfig(diff)) risk = "🟡 中";     // 路由配置
else if (isPublicUtils(diff)) risk = "🟡 中";          // 公共工具
else if (isComplexNewFeature(diff)) risk = "🟡 中";    // 复杂新功能
else if (isStyleOnly(diff)) risk = "🟢 低";            // 仅样式
else if (isDocOnly(diff)) risk = "🟢 低";              // 仅文档
else risk = "🟢 低";                                    // 默认低风险

Step 5b — 专项校验规则

5b.1 数据格式变更检测

触发条件：diff 中出现 JSON/Schema/接口/协议相关内容

输出：字段级对比表、向后兼容性评估、需同步更新的下游服务

5b.2 版本回退检测

触发条件：版本号从高版本变为低版本

输出：🚨 警告 标注、说明回退原因、标注回退影响的功能

5b.3 敏感信息泄露检测

触发条件：diff 中出现密码/密钥/API Key/私钥/数据库连接字符串等

输出：🚨 安全警告、具体行号（脱敏后）、建议使用密钥管理服务

5b.4 测试文件同步检测

触发条件：业务代码变更但无对应测试文件变更

输出：⚠️ 建议 补充测试用例

⭐ Step 5c — 量化风险评分计算（核心增强）

基于调研成果：CHID实践案例的5维度综合风险评分模型

评分维度与权重

评分公式

Risk_Score = 
    0.20 × Base_Risk_Score        # 基础风险（降低权重）
  + 0.15 × Change_Size_Score    # 变更规模（降低权重）
  + 0.10 × Module_Span_Score    # 模块跨度（降低权重）
  + 0.20 × Core_Module_Score    # 核心模块占比（提升权重）
  + 0.05 × Change_Density_Score # 变更密度（降低权重）
  + 0.15 × Buggy_History_Score  # 历史Bug频率（新增⭐）
  + 0.10 × Code_Churn_Score     # 代码流失率（新增⭐）
  + 0.03 × Mod_Freq_Score       # 修改频率（新增）
  + 0.01 × Author_Exp_Score     # 作者经验（降低权重）
  + 0.01 × Dormancy_Score       # 距上次修改（新增）

权重调整说明（基于CHID研究）：

• 历史度量（Buggy + Churn）占比 25%，接近核心模块权重
• 基础风险权重从 30% 降至 20%，增加数据驱动成分
• 作者经验权重极低（1%），符合研究结论

百分制转换

Percent_Score = (Risk_Score / 5.0) × 100

// 等级映射
if (Percent_Score >= 75) Level = "🔴 高风险"
else if (Percent_Score >= 50) Level = "🟡 中风险"
else Level = "🟢 低风险"

量化评分输出格式

{
  "量化风险评分": {
    "总分": 3.40,
    "满分": 5.0,
    "百分制": 68,
    "等级": "🟡 中风险",
    "等级说明": "综合评分68分，处于中等风险区间",
    "维度得分": {
      "基础风险": {
        "得分": 4.0,
        "说明": "涉及核心路由模块变更"
      },
      "变更规模": {
        "得分": 3.0,
        "说明": "中等规模变更 (50-100行)"
      },
      "模块跨度": {
        "得分": 2.0,
        "说明": "涉及2个文件"
      },
      "核心模块占比": {
        "得分": 4.0,
        "说明": "核心模块占比30-50%"
      },
      "变更密度": {
        "得分": 2.5,
        "说明": "平均20-30行/文件"
      }
    },
    "权重分布": "基础风险(30%) + 核心模块(25%) + 变更规模(20%) + 模块跨度(15%) + 变更密度(10%)"
  }
}

评分计算伪代码

function calculateQuantitativeRisk(diff_analysis, historicalMetrics) {
    // 1. 基础风险得分（从Step 5映射）
    const baseRiskMap = { "🔴 高": 5, "🟡 中": 3, "🟢 低": 1 };
    const baseRisk = baseRiskMap[diff_analysis["风险等级"]];

    // 2. 变更规模得分
    const totalLines = countDiffLines(diff_analysis["diff"]);
    const changeSizeScore = mapToScore(totalLines, [20, 50, 100, 200], [1, 2, 3, 4, 5]);

    // 3. 模块跨度得分
    const fileCount = diff_analysis["files"].length;
    const moduleSpanScore = mapToScore(fileCount, [1, 2, 3, 5, 10], [1, 2, 3, 4, 5]);

    // 4. 核心模块占比得分
    const coreFiles = diff_analysis["files"].filter(f => isCoreModule(f));
    const coreRatio = coreFiles.length / fileCount;
    const coreModuleScore = mapToScore(coreRatio * 100, [10, 30, 50], [1, 3, 4, 5]);

    // 5. 变更密度得分
    const avgDensity = totalLines / fileCount;
    const densityScore = mapToScore(avgDensity, [5, 10, 30, 50], [1, 2, 3, 4, 5]);

    // ⭐ 6. 历史度量得分（P0改进）
    let buggyScore = 1, churnScore = 1, modFreqScore = 1, authorExpScore = 3, dormancyScore = 1;
    
    if (historicalMetrics) {
        // 6a. Buggy History 评分（最强预测因子）
        const buggyRatio = historicalMetrics.buggyRatio || 0;
        buggyScore = mapToScore(buggyRatio * 100, [0, 10, 40, 70], [1, 2, 4, 5]);

        // 6b. Code Churn 评分
        const churnRate = historicalMetrics.churnRate || 0;
        churnScore = mapToScore(churnRate, [0, 2, 5, 10], [1, 2, 4, 5]);

        // 6c. 修改频率评分
        const modCount = historicalMetrics.modificationCount || 0;
        modFreqScore = mapToScore(modCount, [0, 5, 20, 50], [1, 2, 3, 5]);

        // 6d. 作者经验评分（反向：经验越少风险越高）
        const authorExp = historicalMetrics.authorExp || 0;
        authorExpScore = mapToScore(authorExp, [0, 10, 50, 200], [5, 3, 2, 1]);

        // 6e. 距上次修改时间评分（越久越危险）
        const daysSince = historicalMetrics.daysSinceLastChange || 0;
        dormancyScore = mapToScore(daysSince, [0, 30, 90, 365], [1, 2, 3, 5]);
    }

    // 7. 综合评分（增强版公式）
    const totalScore = (
        0.20 * baseRisk +
        0.15 * changeSizeScore +
        0.10 * moduleSpanScore +
        0.20 * coreModuleScore +
        0.05 * densityScore +
        0.15 * buggyScore +        // ⭐ 新增
        0.10 * churnScore +        // ⭐ 新增
        0.03 * modFreqScore +      // ⭐ 新增
        0.01 * authorExpScore +    // ⭐ 新增
        0.01 * dormancyScore      // ⭐ 新增
    );

    // 8. 百分制转换
    const percentScore = (totalScore / 5.0) * 100;
    const level = percentScore >= 75 ? "🔴 高风险" : 
                  percentScore >= 50 ? "🟡 中风险" : "🟢 低风险";

    return {
        "总分": round(totalScore, 2),
        "百分制": round(percentScore, 1),
        "等级": level,
        "维度得分": { 
            baseRisk, changeSizeScore, moduleSpanScore, 
            coreModuleScore, densityScore,
            buggyScore, churnScore, modFreqScore,  // ⭐ 新增
            authorExpScore, dormancyScore             // ⭐ 新增
        }
    };
}

⭐ Step 5d — JIT 缺陷预测洞察（核心增强）

基于调研成果：CC2Vec/JITLine 研究（Zhou et al., 2021）

预测性分析规则

JIT 预测洞察输出格式

{
  "JIT缺陷预测洞察": {
    "预测标签": "🟡 中等风险预测",
    "风险指标": [
      "涉及路由配置变更",
      "变更规模中等 (50-100行)"
    ],
    "预测依据": [
      "🔴 核心路由模块变更 — JIT研究表明此类变更是最强缺陷指示器",
      "🟡 变更规模超过建议阈值 — 建议拆分为更小的PR"
    ],
    "建议": "建议投入额外代码审查资源，关注回归测试覆盖",
    "效果参考": {
      "描述": "基于JIT缺陷预测研究 (CC2Vec/JITLine)",
      "Top-20%覆盖": "75%-88%的真实缺陷",
      "AUC参考范围": "0.72-0.83",
      "研究来源": "Zhou et al. (2021), IEEE TSE"
    }
  }
}

JIT 预测伪代码

function generateJITInsights(diff_analysis) {
    const insights = [];
    const riskIndicators = [];
    const predictions = [];

    // 规则1：核心模块检测
    const corePatterns = [
        { pattern: /auth|permission|role|acl/i, label: "认证权限模块" },
        { pattern: /payment|billing|order|transaction/i, label: "支付交易模块" },
        { pattern: /router|route|navigation/i, label: "路由导航模块" },
        { pattern: /config|constants|settings/i, label: "配置常量模块" }
    ];

    for (const {pattern, label} of corePatterns) {
        if (pattern.test(diff_analysis["description"])) {
            riskIndicators.push(`涉及${label}变更`);
            predictions.push(`🔴 核心模块(${label})变更 — JIT研究表明这是最强缺陷指示器`);
        }
    }

    // 规则2：规模检测
    const changeLines = countDiffLines(diff_analysis["diff"]);
    if (changeLines > 400) {
        predictions.push("🟡 变更规模超过400行，建议拆分为更小的PR");
    } else if (changeLines > 200) {
        riskIndicators.push("中等规模变更");
    }

    // 规则3：跨文件检测
    const fileCount = diff_analysis["files"].length;
    if (fileCount > 10) {
        predictions.push("🔴 涉及10+文件变更，跨文件风险较高");
    } else if (fileCount > 5) {
        riskIndicators.push("涉及多个文件");
    }

    // 规则4：数据格式变更
    if (hasDataFormatChange(diff_analysis)) {
        predictions.push("🔴 数据格式变更，下游兼容性风险高");
    }

    // 综合预测
    const highRiskCount = predictions.filter(p => p.startsWith("🔴")).length;
    const prediction = highRiskCount >= 2 ? "🔴 高风险预测" :
                       highRiskCount === 1 ? "🟡 中等风险预测" : "🟢 低风险预测";
    
    const recommendation = highRiskCount >= 2 ? 
        "建议资深开发者参与Code Review，增加测试覆盖" :
        highRiskCount === 1 ?
        "建议投入额外代码审查资源" :
        "可按常规流程处理";

    return {
        "预测标签": prediction,
        "风险指标": riskIndicators,
        "预测依据": predictions,
        "建议": recommendation,
        "效果参考": {
            "描述": "基于JIT缺陷预测研究",
            "Top20覆盖": "75%-88%真实缺陷",
            "AUC范围": "0.72-0.83"
        }
    };
}

⭐ Step 5e — 学术数据深度支撑（Phase 3）

基于调研成果：Kamei et al. (2013)、Zhou et al. (2021)、CHID实践案例

5e.1 JIT 缺陷预测核心发现

5e.2 缺陷集中性分布

┌─────────────────────────────────────────────────────────────┐
│                    缺陷分布 "二八定律"                        │
├─────────────────────────────────────────────────────────────┤
│  高风险变更 (Top 20%)  ═══════════════════════════ 70% 缺陷  │
│  低风险变更 (Bottom 80%) ═══════════════════ 30% 缺陷        │
└─────────────────────────────────────────────────────────────┘

解读：缺陷并非均匀分布，少量高风险变更承载了大部分缺陷。
      JIT预测的目标正是识别这 Top 20% 的高风险变更。

5e.3 SZZ 算法基准数据

局限性说明：

• Ghost Commits：某些bug引入时没有留下可追溯痕迹 → 召回率上限~45%
• Tangled Commits：一次提交混合多种变更类型 → 精确率难以大幅提升

5e.4 风险指标有效性排序

基于多研究数据综合评估：

5e.5 推荐阈值标准

5e.6 效果参考数据

JIT缺陷预测效果对比：

传统指标 vs 深度学习：

5e.7 局限性说明

⭐ Step 5f — 历史度量提取（P0 改进）

基于调研成果：历史度量是比规模指标更强的缺陷预测因子

5f.1 需提取的历史度量

5f.2 提取实现（伪代码）

async function extractHistoricalMetrics(diffAnalysis, repoPath) {
    const metrics = {};
    
    // 遍历每个变更文件
    for (const file of diffAnalysis.files) {
        const filePath = file.path;
        
        // 1. Buggy History（历史bug修复次数）
        const buggyCommits = await gitLog(repoPath, {
            grep: 'fix:|bug:|patch:|hotfix:',
            '--follow': true,
            '--': filePath
        });
        const buggyCount = buggyCommits.length;
        const buggyRatio = buggyCount / (await getTotalCommits(repoPath, filePath));
        
        // 2. Code Churn（代码流失率）
        const churnStats = await gitLog(repoPath, {
            '--numstat': true,
            '--follow': true,
            '--': filePath
        });
        const totalChurn = churnStats.reduce((sum, entry) => 
            sum + (parseInt(entry.additions) || 0) + (parseInt(entry.deletions) || 0), 0);
        const churnRate = totalChurn / (await getFileAgeInDays(repoPath, filePath));
        
        // 3. 修改频率
        const modificationCount = (await gitLog(repoPath, {
            '--oneline': true,
            '--follow': true,
            '--': filePath
        })).length;
        
        // 4. 作者经验（当前commit作者）
        const author = diffAnalysis.commitAuthor;
        const authorExp = (await gitLog(repoPath, {
            '--author': author
        })).length;
        const authorSuccessRate = await calculateAuthorSuccessRate(repoPath, author);
        
        // 5. 距上次修改时间
        const lastModTime = await getLastModificationTime(repoPath, filePath);
        const daysSinceLastChange = (Date.now() - lastModTime) / (1000 * 60 * 60 * 24);
        
        metrics[filePath] = {
            buggyCount,
            buggyRatio: parseFloat(buggyRatio.toFixed(4)),
            totalChurn,
            churnRate: parseFloat(churnRate.toFixed(2)),
            modificationCount,
            authorExp,
            authorSuccessRate: parseFloat(authorSuccessRate.toFixed(2)),
            daysSinceLastChange: Math.round(daysSinceLastChange)
        };
    }
    
    return metrics;
}

// 辅助函数：计算作者成功率
async function calculateAuthorSuccessRate(repoPath, author) {
    const allCommits = await gitLog(repoPath, { '--author': author });
    const mergedPRs = await getMergedPRsForAuthor(author); // 需对接Git platform API
    return mergedPRs.length / allCommits.length;
}

5f.3 历史度量评分映射

function mapHistoricalMetricsToScore(metrics) {
    const scores = {};
    
    // 1. Buggy History 评分（最强预测因子）
    // 依据：Buggy History > 40% 为高缺陷文件（CHID研究）
    scores.buggyScore = mapToScore(
        metrics.buggyRatio * 100, 
        [0, 10, 40, 70],  // 0% / 10% / 40% / 70%+
        [1, 2, 4, 5]        // 对应评分
    );
    
    // 2. Code Churn 评分
    // 依据：流失率 > 5% 为高流失文件（CHID研究）
    scores.churnScore = mapToScore(
        metrics.churnRate,
        [0, 2, 5, 10],      // 0 / 2 / 5 / 10+ 行/天
        [1, 2, 4, 5]        // 对应评分
    );
    
    // 3. 修改频率评分
    scores.modFreqScore = mapToScore(
        metrics.modificationCount,
        [0, 5, 20, 50],      // 0 / 5 / 20 / 50+ 次
        [1, 2, 3, 5]          // 对应评分
    );
    
    // 4. 作者经验评分（反向：经验越少风险越高）
    scores.authorExpScore = mapToScore(
        metrics.authorExp,
        [0, 10, 50, 200],    // 0 / 10 / 50 / 200+ 次提交
        [5, 3, 2, 1]          // 反向评分
    );
    
    // 5. 距上次修改时间评分（越久越危险）
    scores.dormancyScore = mapToScore(
        metrics.daysSinceLastChange,
        [0, 30, 90, 365],    // 0天 / 1月 / 3月 / 1年+
        [1, 2, 3, 5]          // 越久风险越高
    );
    
    return scores;
}

5f.4 增强版综合评分公式

增强版 Risk_Score = 
    0.20 × Base_Risk_Score        # 基础风险（降低权重）
  + 0.15 × Change_Size_Score    # 变更规模（降低权重）
  + 0.10 × Module_Span_Score    # 模块跨度（降低权重）
  + 0.20 × Core_Module_Score    # 核心模块占比（提升权重）
  + 0.05 × Change_Density_Score # 变更密度（降低权重）
  + 0.15 × Buggy_History_Score  # 历史Bug频率（新增⭐）
  + 0.10 × Code_Churn_Score     # 代码流失率（新增⭐）
  + 0.03 × Mod_Freq_Score       # 修改频率（新增）
  + 0.01 × Author_Exp_Score     # 作者经验（降低权重）
  + 0.01 × Dormancy_Score       # 距上次修改（新增）

权重调整说明：

• 历史度量（Buggy + Churn）占比 25%，接近核心模块权重
• 基础风险权重从 30% 降至 20%，增加数据驱动成分
• 作者经验权重极低（1%），符合CHID研究的发现

5f.5 Git 提取命令参考

# 1. 提取文件的 Buggy History
git log --oneline --grep="fix:\|bug:\|patch:" --follow -- path/to/file

# 2. 提取文件的 Code Churn
git log --numstat --follow --format="%H" -- path/to/file | \
  awk 'NF==3 {add+=$1; del+=$2} END {print "Additions:", add, "Deletions:", del}'

# 3. 提取文件的修改次数
git log --oneline --follow -- path/to/file | wc -l

# 4. 提取作者历史提交量
git log --oneline --author="Author Name" | wc -l

# 5. 提取距上次修改时间
git log -1 --format="%ct" -- path/to/file

5f.6 历史度量输出格式

{
  "历史度量数据": {
    "packages/base/src/views/authentication/login.vue": {
      "Buggy_History": {
        "bug相关提交数": 3,
        "总提交数": 15,
        "bug比率": "20.00%",
        "评分": 2.0
      },
      "Code_Churn": {
        "总流失行数": 450,
        "日均流失率": 0.5,
        "评分": 1.0
      },
      "修改频率": {
        "修改次数": 15,
        "评分": 2.0
      },
      "作者经验": {
        "历史提交数": 42,
        "成功率": "68.00%",
        "评分": 2.0
      },
      "距上次修改": {
        "天数": 3,
        "评分": 1.0
      }
    }
  },
  "历史度量贡献": {
    "Buggy_History": "+0.30分",
    "Code_Churn": "+0.10分",
    "修改频率": "+0.06分",
    "作者经验": "+0.02分",
    "距上次修改": "+0.01分",
    "合计贡献": "+0.49分"
  }
}

Step 6 — 输出分析报告

6.1 报告结构

按照以下结构输出报告：

1. 版本信息表格
2. 量化风险评分横幅（新增 ⭐）
3. 风险等级横幅（保持原有）
4. JIT 缺陷预测洞察（新增 ⭐）
5. 历史度量数据（新增 ⭐ P0改进）
6. 变更总览表
7. 代码差异详情
8. 分类影响分析（变更代码 + 新增代码）
9. 数据格式变更详解（如有）
10. 专项检测结果
11. 分优先级测试建议表
12. 资深开发者建议
13. 方法论说明（新增 ⭐）

6.2 报告增强示例

## ⭐ 量化风险评分

| 维度 | 得分 | 权重 | 说明 |
|------|------|------|------|
| 基础风险 | 4.0 | 30% | 🔴 涉及核心路由模块 |
| 变更规模 | 3.0 | 20% | 中等规模 (50-100行) |
| 模块跨度 | 2.0 | 15% | 涉及2个文件 |
| 核心模块占比 | 4.0 | 25% | 核心模块占比30-50% |
| 变更密度 | 2.5 | 10% | 平均20-30行/文件 |
| **综合评分** | **3.40** | 100% | **68分 / 🟡 中风险** |

> 📊 **预测洞察**：综合评分68分，处于中等风险区间。依据JIT缺陷预测研究，预计此次变更的缺陷引入风险处于中等水平，建议关注回归测试覆盖。

## ⭐ JIT 缺陷预测洞察

| 预测标签 | 🟡 中等风险预测 |
|---------|----------------|
| 风险指标 | 涉及路由配置变更、变更规模中等 |
| 预测依据 | 🔴 核心路由模块变更 — JIT研究表明此类变更是最强缺陷指示器 |
| 建议 | 建议投入额外代码审查资源，关注回归测试覆盖 |
| 效果参考 | Top-20%高风险变更可覆盖 **75%-88%** 真实缺陷 |

## 方法论说明

### 风险评估依据

| 研究来源 | 核心发现 | 应用 |
|---------|---------|------|
| Kamei et al. (2013) | 前20%高风险变更包含约70%缺陷 | 量化评分识别Top高风险 |
| Zhou et al. (2021) JITLine | AUC 0.72-0.83 | JIT预测洞察 |
| CHID (ESE 2024) | 6大度量指标体系 | 评分维度设计 |
| SZZ算法基线 | 召回率20%-45% | 规则增强弥补局限 |

### 缺陷集中性分布

高风险变更 (Top 20%) ═══════════════════════════ 70% 缺陷 低风险变更 (Bottom 80%) ═══════════════════ 30% 缺陷

### 关键阈值参考

| 阈值类型 | 建议值 | 研究依据 |
|---------|-------|---------|
| 高流失文件 | > 5% | CHID实践验证 |
| PR规模上限 | ≤ 400-500行 | 代码审查有效性研究 |
| 强制Review | ≥ 75分 | JIT预测最佳区间 |

### JIT预测效果参考

| 指标 | 数值 | 说明 |
|------|------|------|
| AUC | 0.72-0.83 | 当前最佳模型水平 |
| Top-20% Recall | 75%-88% | 高风险变更覆盖能力 |
| 精确率 | 18-28% | 相比基线显著提升 |

### 局限性说明

- 本报告基于规则推断，未使用机器学习模型训练
- 预测性洞察为基于规则的推断，非数据驱动的精确预测
- 量化评分基于静态规则，实际效果需结合项目数据校准
- 建议结合项目实际情况调整权重配置

6.3 JSON 分析格式

变更代码分析格式：

{
  "分析类型": "变更代码",
  "变更文件": "文件路径",
  "变更描述": "对XX进行了XX修改",
  "变更前": "旧代码片段",
  "变更后": "新代码片段",
  "行为差异": "变更导致XX行为从A变为B",
  "向后兼容": "兼容/不兼容/需验证",
  "影响范围": {
    "直接影响": ["功能1", "功能2"],
    "潜在影响": ["功能3（不确定）"]
  },
  "风险等级": "高/中/低",
  "测试建议": "需验证XX场景下XX行为是否正确"
}

新增代码分析格式：

{
  "分析类型": "新增代码",
  "变更文件": "文件路径",
  "新增内容": "新增了XX功能/字段/逻辑",
  "业务场景": "用于XX场景",
  "集成点": "与XX模块集成/被XX调用",
  "边界条件": ["条件1", "条件2"],
  "影响范围": {
    "直接影响": ["新增功能X"],
    "潜在影响": ["现有功能Y（不确定）"]
  },
  "风险等级": "高/中/低",
  "测试建议": "需覆盖XX场景的XX测试"
}

6.4 HTML 报告生成

当用户要求生成报告文件时，按照 references/html-report-template.html 模板生成独立的 HTML 文件。

HTML 报告增强：在原有模板基础上新增：

<!-- 量化风险评分横幅 -->
<div class="quantitative-risk-banner">
    <div class="score-circle">{{PERCENT_SCORE}}</div>
    <div class="score-details">
        <div class="dimension-scores">
            <!-- 5维度得分条形图 -->
        </div>
    </div>
</div>

<!-- JIT预测洞察卡片 -->
<div class="jit-insight-card">
    <div class="prediction-tag">{{PREDICTION_TAG}}</div>
    <div class="prediction-basis">{{PREDICTION_BASIS}}</div>
</div>

输出路径：{workspace}/apex_diff_report_{项目名}_v{新版本}.html

参考资源

• 详细输出示例：references/output-examples.md
• 提示词模板：references/prompt-template.md
• HTML 报告模板：references/html-report-template.html

版本历史