GitHub Issue 反馈简报

从 higress-group/himarket 仓库收集 GitHub Issues，整理为结构化简报，并提供优先级建议。

前置条件

• gh CLI 已安装并完成认证（gh auth status 验证）
• 对 higress-group/himarket 仓库有读取权限

工作流程

步骤 1：确定参数

使用 AskUserQuestion 询问用户（如未通过参数指定）：

• 时间范围：最近 7 天 / 30 天 / 90 天 / 自定义天数（默认 7 天）
• 是否包含 PR：默认仅 Issue，不含 PR

将用户选择的天数记为 $DAYS。

步骤 2：抓取数据

依次执行以下命令，收集 open 和 recently closed 的 issues：

# 获取 open issues（最多 50 条）
gh issue list --repo higress-group/himarket \
  --state open --limit 50 \
  --json number,title,labels,createdAt,updatedAt,author,body,comments,url

# 获取最近关闭的 issues（用于去重比对）
gh issue list --repo higress-group/himarket \
  --state closed --limit 50 \
  --json number,title,labels,createdAt,closedAt,updatedAt,author,body,comments,url

步骤 3：过滤与分类

时间过滤： 只保留 createdAt 在最近 $DAYS 天内的 open issues 作为主要分析对象。

按类型分类（基于 labels 和内容关键词判断）：

步骤 4：去重处理

对 open issues 进行去重，标记以下情况：

1. 已有关闭的同类 issue：在 closed issues 中搜索标题相似度高的（关键词重叠 ≥ 50%），标记为"历史已处理"
2. open issues 之间重复：多个 open issue 描述同一问题，合并为一条并注明重复 issue 编号
3. 判断依据：标题关键词匹配 + 问题描述核心内容对比

去重结果中标注：

• [新] - 全新的反馈
• [重复-已关闭 #N] - 与已关闭的 #N 相似，可能需要确认是否复现
• [重复-open #N] - 与 open 的 #N 是同一问题

步骤 5：生成简报

按以下模板生成简报内容：

# HiMarket 社区 Issue 简报

> 统计周期：YYYY-MM-DD ~ YYYY-MM-DD
> 数据来源：https://github.com/higress-group/himarket/issues
> 生成时间：YYYY-MM-DD HH:MM

## 概览

| 指标 | 数量 |
|------|------|
| 周期内新增 open issues | N |
| 其中去重后有效 issues | N |
| Bug Report | N |
| Feature Request | N |
| Question / 咨询 | N |
| 其他 | N |

## 🔴 Bug 报告

### 高优先级
> 影响核心功能、有多人反馈、或影响面广的 bug

| # | 标题 | 报告者 | 日期 | 状态 |
|---|------|--------|------|------|
| #N | 标题 | @user | YYYY-MM-DD | [新] |

### 一般 Bug

| # | 标题 | 报告者 | 日期 | 状态 |
|---|------|--------|------|------|
| #N | 标题 | @user | YYYY-MM-DD | [新] |

## 💡 功能请求

### 高票需求
> 多人请求或与项目方向一致的需求

| # | 标题 | 报告者 | 日期 | 👍 | 状态 |
|---|------|--------|------|----|------|
| #N | 标题 | @user | YYYY-MM-DD | N | [新] |

### 其他需求

| # | 标题 | 报告者 | 日期 | 状态 |
|---|------|--------|------|------|
| #N | 标题 | @user | YYYY-MM-DD | [新] |

## ❓ 问题与咨询

| # | 标题 | 报告者 | 日期 | 已回复 |
|---|------|--------|------|--------|
| #N | 标题 | @user | YYYY-MM-DD | ✅/❌ |

## 🔁 去重记录

以下 issue 与历史已关闭或其他 open issue 存在重复：

| 当前 Issue | 重复类型 | 关联 Issue | 说明 |
|------------|----------|------------|------|
| #N | 已关闭重复 | #M | 简述相似点 |
| #N | open 重复 | #M | 简述相似点 |

## 📊 趋势分析

- **最活跃领域**：哪个模块/功能收到最多反馈
- **反馈趋势**：与前一周期相比，issue 数量是上升还是下降（如有数据）
- **社区活跃度**：新贡献者数量、issue 回复率

## 🎯 建议与优先级

### 建议立即处理
1. **#N - 标题**：原因说明（如影响核心流程、多人反馈）

### 建议近期规划
1. **#N - 标题**：原因说明（如社区呼声高、实现成本低）

### 建议长期关注
1. **#N - 标题**：原因说明（如方向性需求、需要架构调整）

### 可关闭/归档
1. **#N - 标题**：原因说明（如与已关闭 issue 重复、已过时）

步骤 6：输出

1. 终端输出：直接在对话中展示完整简报
2. 保存文件：将简报保存到 reports/issue-briefing-YYYY-MM-DD.md（相对项目根目录）

mkdir -p reports

告知用户文件保存路径。

优先级判断依据

按以下维度综合评估 issue 优先级：

注意事项

• Issue body 可能很长，分析时关注标题、前 500 字和 labels
• gh 命令的 --json 输出可能很大，用 jq 提取必要字段
• 若 issue 数量超过 200，提醒用户缩小时间范围
• 简报中的 issue 链接使用完整 URL 格式便于点击
• 去重判断宜宽松，宁可标记再让用户确认，不要遗漏
• 中英文 issue 都需要处理，分类时兼顾两种语言的关键词