github-review-report

用途

github-review-report 用于从 GitHub 仓库的 Pull Request 中提取代码评审内容，并生成中文格式的 Excel 代码走查报告。它适合以下场景：生成中文格式的代码评审报告、按时间段（本月、上周、近 15 天）追踪评审活动、将评审数据导出为包含特定列的中文 Excel、借助 AI 对评审进行智能分析（生成问题描述与影响分析）而非简单截断、使用 Excel 模板保持格式一致。

不适用场景：本地 git 仓库分析（应使用 git log）、不带评审摘要的普通 PR 统计、Issues 或其他 GitHub 制品、仅基于关键词的简单分类（无 AI 理解）。

主要能力

两阶段工作流：数据采集与 AI 分析分离。采集阶段仅使用 GitHub API 并保留评审原文；分析阶段对每条评审调用 AI 生成结构化字段。
时间范围解析：将相对时间表达（如“这个月”“上周”“这半个月”“这个星期”或精确日期范围）转换为绝对日期区间。
PR 数据拉取：使用 gh pr list 与 gh pr view，可通过 base:master 等条件过滤分支。
版本更新 PR 过滤：跳过仅更新版本的 PR（标题形如 Update version to X.Y.Z、Bump version to X.Y.Z、Version X.Y.Z）以及由 deepin-ci-robot 提交的提交。
评审人过滤：使用 fnmatch 模式进行包含/排除匹配，先排除后包含。默认排除 deepin-ci-robot、sourcery-ai、sourcery-bot 等自动化账号。
人工优先于 AI：同一 PR 同时存在人工与 AI 评审时，仅保留人工评审；若仅有 AI 评审则保留。
AI 分析：对每条有效评审生成是否为有效评审、核心问题点、问题类型（15 种）、严重程度（严重/一般）、问题来源（commit log=1、代码=2、注释=3，默认代码）、中文问题描述（≤50 字）、影响分析（≤20 字或“无”）等结构化字段。
模板化 Excel 生成：读取模板文件后仅追加数据行，保留宽度、颜色、字体、边框、表头样式等格式。要求使用字体“CESI宋体-GB18030”以确保中文正常渲染；模板缺失时以编程方式创建仅含列的基础结构。

使用方式

解析时间范围：在 generator.py 中使用 parse_time_range() 将相对时间转为绝对日期。
拉取 PR（数据采集）：例如：

gh pr list \
  --repo linuxdeepin/dde-cooperation \
  --state merged \
  --search "merged:${start_date}..${end_date} base:master" \
  --json number,title,author,createdAt,mergedAt,mergedBy,baseRefName,url,reviews,comments

此阶段只采集数据，不对评审做摘要或处理，存储原文。使用 is_version_update_pr() 过滤版本更新 PR。

过滤评审人：使用 should_include_reviewer()，先排除后包含；包含需匹配包含模式且不匹配任何排除模式。仅校验评审人身份，不校验评审内容质量。提出人为提交评审评论者，解决人为提交/合并 PR 者（mergedBy 字段）。
获取 PR 详情：例如：

gh pr view ${pr_number} --repo linuxdeepin/dde-cooperation \
  --json reviews,comments

采集全部评审，但仅将有效评审送入 AI。

提取评审原文：不做摘要，保留原始内容供 AI 分析。
AI 分析：对每条有效评审构建提示词并调用 AI 模型，解析返回的 JSON 结果。可用模型包括 Claude、OpenAI、DeepSeek 及本地 LLM；若 AI 不可用，则按原文原样输出（无分析）。
加载模板：读取 resources/模块名-代码走查报告-template.xlsx，校验必需列，缺失时创建基础模板并设置字体。
生成 Excel：合并模板与处理后的数据并输出，例如 {module_name}-代码走查报告-{yyyymmdd}.xlsx。

AI 提示词模板（保持原样）：

你是代码review专家。请分析以下GitHub review内容，并提供结构化分析：

**原始Review内容:**
${original_review_content}

**Review上下文:**
- PR标题: ${pr_title}
- Review者: ${reviewer}
- Review时间: ${review_time}

**任务:**
1. 判断这是否为有效的代码review（不是简单的批准或自动评论）
2. 提取核心问题点
3. 分类问题类型（从15种类型中选择）
4. 评估严重程度（严重或一般）
5. 判断问题来源（commit log=1, 代码=2, 注释=3）
   - 默认为"代码"（2）
   - 只有当review明确提到注释问题才选"注释"（3）
   - 只有当review明确提到commit信息/格式问题才选"commit log"（1）
6. 生成中文问题描述（≤50字）
7. 生成影响分析（≤20字）
8. 如果无明显影响，填"无"

**输出格式（JSON）：**
```json
{
  "is_valid_review": true/false,
  "problem_type": 1-15,
  "problem_source": 1/2/3,
  "problem_description": "中文问题描述≤50字",
  "impact_analysis": "中文影响分析≤20字（或"无"）",
  "confidence": high/medium/low,
  "reasoning": "简要说明判断依据"
}


## 报告列结构

报告列包括：序号、包名、仓库地址、代码提交地址、问题来源、问题描述、严重程度、影响分析、问题类型、提出人、提出时间、解决人、计划解决时间、实际解决时间、提出人确认是否验收通过、问题状态。其中严重程度规则为问题类型 8（安全）与 12（内存）标记为“严重”，其余为“一般”；问题状态在合并时为 Close，否则为 Open；提出人确认是否验收通过固定为“是”。

## 适用场景与限制

适用于需按照中文格式和模板定期产出 GitHub 代码评审走查报告的团队，尤其是使用 gh CLI 且能接入 AI 模型的环境。限制包括：仅面向 GitHub PR 评审，不处理本地 git 仓库、Issues 或其他制品；依赖 gh CLI 与 AI 模型可用性；模板需符合要求的列与字体；AI 不可用时仅输出原文而无分析。

技能介绍

用途

主要能力

使用方式