37j Issue 工作流与 AI 绩效分析

没有 Issue：
  commit: "fix: update user model"  ← AI 只能猜这是在干嘛

有 Issue：
  Issue #42: "用户注册后邮箱验证失败"
  commit: "fix: update user model (closes #42)"  ← AI 知道这是在修一个具体的 bug

---
name: 功能需求
about: 新功能
title: '[Feature] '
labels: feature
---
 
## 做什么
{一句话描述}
 
## 为什么
{解决什么问题 / 带来什么价值}
 
## 完成标准
- [ ] {标准 1}
- [ ] {标准 2}

---
name: Bug
about: 缺陷报告
title: '[Bug] '
labels: bug
---
 
## 问题
{一句话描述}
 
## 复现
{怎么触发}
 
## 期望
{应该是什么样}

---
name: 维护
about: 重构、升级、配置变更
title: '[Chore] '
labels: chore
---
 
## 做什么
{一句话描述}
 
## 原因
{为什么要做}

开发者在飞书群：
  @Agent 创建 issue：修复 Safari 下课程进度条显示问题

Agent 自动执行：
  1. 解析消息，提取标题和类型（bug）
  2. 通过 GitHub MCP 创建 Issue
  3. 回复飞书消息，附 Issue 链接

# code-issue-create
 
从飞书消息中提取信息，自动在 GitHub 创建 Issue。
 
## 触发条件
用户消息包含"创建 issue"、"提 issue"、"新建 issue"、"记一个 bug"、"要做一个"。
 
## 执行步骤
1. 从用户消息中提取：
   - 标题（必填）
   - 类型：feature / bug / chore（AI 自动判断）
   - 描述（可选）
   - 仓库（如果团队有多个仓库，从记忆中读取默认仓库或让用户指定）
2. 通过 GitHub MCP 创建 Issue，自动添加对应标签
3. 如果是 bug 类型，追问复现步骤（可选）
4. 回复飞书消息，附 Issue 链接
5. 将 Issue 信息写入记忆
 
## 输出格式
✅ Issue 已创建
- #42 [Bug] Safari 下课程进度条显示异常
- 仓库：hackquest/web-app
- 链接：https://github.com/hackquest/web-app/issues/42
 
## 权限要求
- GitHub MCP（Issue 创建权限）
- 飞书消息读取权限

# 推荐格式
git commit -m "feat: add solana course page (#42)"
git commit -m "fix: progress bar on safari (#43)"
git commit -m "chore: upgrade next.js to v16 (#44)"
 
# 关闭 Issue 的关键词
git commit -m "fix: progress bar display (closes #43)"
git commit -m "fix: progress bar display (fixes #43)"

飞书群说一句话 ──→ Agent 创建 GitHub Issue
                         │
                         ▼
                   开发者认领 Issue
                         │
                         ▼
              开发（AI Coding / 手写）
                         │
                         ▼
              commit message 带 #Issue编号
                         │
                         ▼
              push 到 GitHub（可选：创建 PR）
                         │
                         ▼
              Issue 自动关闭（closes #xx）
                         │
                         ▼
              AI 绩效分析系统采集数据

"""
GitHub 开发者月度数据采集
采集 Issues、Commits、PRs 数据，输出结构化 JSON 供 AI 分析
"""
import os
import json
from datetime import datetime, timedelta
from github import Github  # PyGithub
 
gh = Github(os.environ["GITHUB_TOKEN"])
repo = gh.get_repo("your-org/your-repo")
 
# 时间范围：最近 30 天
since = datetime.now() - timedelta(days=30)
until = datetime.now()
 
 
def collect_issues(assignee: str) -> list[dict]:
    """采集某人被指派的 Issue"""
    issues = repo.get_issues(
        assignee=assignee,
        state="all",
        since=since
    )
    return [{
        "number": i.number,
        "title": i.title,
        "labels": [l.name for l in i.labels],
        "state": i.state,
        "created_at": i.created_at.isoformat(),
        "closed_at": i.closed_at.isoformat() if i.closed_at else None,
        "cycle_days": (i.closed_at - i.created_at).days if i.closed_at else None,
    } for i in issues if i.pull_request is None]  # 排除 PR
 
 
def collect_commits(author: str) -> list[dict]:
    """采集某人的 commit"""
    commits = repo.get_commits(author=author, since=since, until=until)
    result = []
    for c in commits:
        # 获取 diff 统计
        stats = c.stats
        files = [f.filename for f in c.files] if c.files else []
        result.append({
            "sha": c.sha[:8],
            "message": c.commit.message.split("\n")[0],  # 只取第一行
            "date": c.commit.author.date.isoformat(),
            "additions": stats.additions if stats else 0,
            "deletions": stats.deletions if stats else 0,
            "files_changed": len(files),
            "files": files[:10],  # 最多记录 10 个文件
            "linked_issue": extract_issue_number(c.commit.message),
        })
    return result
 
 
def extract_issue_number(message: str) -> int | None:
    """从 commit message 中提取 Issue 编号"""
    import re
    match = re.search(r'#(\d+)', message)
    return int(match.group(1)) if match else None
 
 
def collect_developer_data(github_username: str) -> dict:
    """采集单个开发者的完整月度数据"""
    issues = collect_issues(github_username)
    commits = collect_commits(github_username)
 
    return {
        "developer": github_username,
        "period": f"{since.strftime('%Y-%m-%d')} ~ {until.strftime('%Y-%m-%d')}",
        "issues": {
            "total": len(issues),
            "closed": len([i for i in issues if i["state"] == "closed"]),
            "by_type": {
                "feature": len([i for i in issues if "feature" in i["labels"]]),
                "bug": len([i for i in issues if "bug" in i["labels"]]),
                "chore": len([i for i in issues if "chore" in i["labels"]]),
            },
            "avg_cycle_days": avg([i["cycle_days"] for i in issues if i["cycle_days"]]),
            "details": issues,
        },
        "commits": {
            "total": len(commits),
            "with_issue_link": len([c for c in commits if c["linked_issue"]]),
            "link_rate": safe_pct(
                len([c for c in commits if c["linked_issue"]]), len(commits)
            ),
            "total_additions": sum(c["additions"] for c in commits),
            "total_deletions": sum(c["deletions"] for c in commits),
            "active_days": len(set(c["date"][:10] for c in commits)),
            "details": commits,
        },
    }
 
 
def avg(nums: list) -> float | None:
    return round(sum(nums) / len(nums), 1) if nums else None
 
 
def safe_pct(a: int, b: int) -> str:
    return f"{round(a / b * 100, 1)}%" if b > 0 else "N/A"
 
 
# 采集团队所有成员
team = ["zhangsan", "lisi", "wangwu"]
report = [collect_developer_data(user) for user in team]
 
# 输出 JSON 供 AI 分析
with open("dev_report.json", "w") as f:
    json.dump(report, f, ensure_ascii=False, indent=2)

{
  "developer": "zhangsan",
  "period": "2026-07-01 ~ 2026-07-31",
  "issues": {
    "total": 12,
    "closed": 10,
    "by_type": { "feature": 5, "bug": 4, "chore": 3 },
    "avg_cycle_days": 3.2,
    "details": [
      {
        "number": 42,
        "title": "[Feature] 新增 Solana 课程模块",
        "labels": ["feature"],
        "state": "closed",
        "created_at": "2026-07-03T10:00:00",
        "closed_at": "2026-07-10T16:00:00",
        "cycle_days": 7
      }
    ]
  },
  "commits": {
    "total": 47,
    "with_issue_link": 38,
    "link_rate": "80.9%",
    "total_additions": 3200,
    "total_deletions": 890,
    "active_days": 19,
    "details": [
      {
        "sha": "a1b2c3d4",
        "message": "feat: add solana course page (#42)",
        "date": "2026-07-05T14:30:00",
        "additions": 450,
        "deletions": 20,
        "files_changed": 8,
        "files": ["src/pages/courses/solana.tsx", "src/api/courses.ts"],
        "linked_issue": 42
      }
    ]
  }
}

AI 分析 Prompt：
以下是开发者 zhangsan 在 2026 年 7 月的所有 commit 记录。
请将这些 commit 聚类为"功能块"，每个功能块代表一个完整的功能开发或 bug 修复。
对每个功能块评估：
1. 功能块名称（一句话描述）
2. 包含的 commit 列表
3. 复杂度（大/中/小）
4. 类型（feature/bug/chore）

{commit_list_json}

你是一个资深代码审查员。请对以下 Git diff 进行代码评审，从 5 个维度打分（1-5 分）。

评审维度：
1. 正确性：代码逻辑是否正确，是否有明显 bug
2. 可维护性：命名是否清晰，结构是否合理，是否容易理解
3. 安全性：是否有安全隐患（注入、XSS、硬编码密钥、权限检查缺失）
4. 健壮性：是否处理了边界情况、错误处理是否完善
5. 规范性：是否符合项目代码规范（如果提供了 CLAUDE.md 则参考）

对每个维度给出 1-5 分和一句话理由。最后给出综合评分（5 个维度的加权平均）。

权重：正确性 30%，可维护性 25%，安全性 20%，健壮性 15%，规范性 10%

Commit: {commit_message}
Diff:
{diff_content}

{
  "commit": "a1b2c3d4",
  "message": "feat: add solana course page (#42)",
  "scores": {
    "correctness": { "score": 4, "reason": "逻辑正确，但缺少课程不存在时的 404 处理" },
    "maintainability": { "score": 5, "reason": "组件拆分合理，命名清晰" },
    "security": { "score": 3, "reason": "API 端点缺少权限校验中间件" },
    "robustness": { "score": 3, "reason": "缺少 loading 和 error 状态处理" },
    "convention": { "score": 5, "reason": "符合项目 App Router 约定" }
  },
  "weighted_score": 3.95,
  "summary": "功能实现完整，但安全性和健壮性需要加强"
}

额外评审维度（AI Coding 场景）：
6. AI 代码审查：这段代码是否有典型的 AI 生成痕迹？
   - 是否有未使用的导入或变量
   - 是否引入了不必要的新依赖
   - 是否有过度抽象（需求只要一个简单函数，却生成了完整的类层次结构）
   - 是否有 copy-paste 痕迹（与项目中已有代码高度相似但未复用）
   - 类型系统是否被绕过（any、类型断言）
   
给出 1-5 分：
5 = 代码经过充分审查和精简，无 AI 生成的典型问题
3 = 有少量 AI 生成痕迹但不影响功能
1 = 明显是 AI 生成后未经审查直接提交

你是一个技术团队的绩效分析助手。请根据以下开发者的月度 GitHub 数据，
生成绩效分析报告。

评价维度和权重：
- 产出（35%）：功能块交付数（加权）+ 工作结构
- 效率（15%）：Issue 周期 + 节奏稳定性
- 质量（50%）：代码评审评分 + 回退率 + 技术债净变化

团队背景：
- 30 人以下的开发团队
- 深度使用 AI Coding（Cursor / Claude Code / Kiro）
- 没有标准的 Code Review 流程
- 刚建立 Issue 工作流

注意事项：
1. 分析结果是参考，不是判决。要指出数据的局限性
2. 不要只看数字，要结合上下文解读（比如某人 commit 少可能是在做架构设计）
3. 对 AI Coding 场景要特别关注代码质量维度
4. 给出具体的改进建议，而不是笼统的评价

开发者数据：
{developer_data_json}

代码评审结果：
{code_review_results_json}

请输出以下格式的报告：

# 开发者月度绩效分析：{name}
 
**分析周期**：{period}
**分析模型**：{model_name}
**数据来源**：GitHub Issues + Commits + AI Code Review
 
---
 
## 一、总览
 
| 维度 | 评分 | 等级 | 说明 |
|------|------|------|------|
| 产出 | {score}/5 | {level} | {one_line_summary} |
| 效率 | {score}/5 | {level} | {one_line_summary} |
| 质量 | {score}/5 | {level} | {one_line_summary} |
| **综合** | **{weighted_score}/5** | **{level}** | |
 
## 二、产出分析
 
### 功能块交付
本月完成 {feature_count} 个功能、{bug_count} 个 bug 修复、{chore_count} 个维护任务。
 
按复杂度加权后的产出分：{weighted_output_score}
 
| 功能块 | 类型 | 复杂度 | Issue | 关联 commit 数 |
|--------|------|--------|-------|---------------|
 
### 工作结构
feature {f_pct}% / bug {b_pct}% / chore {c_pct}%
解读：{interpretation}
 
## 三、效率分析
 
### Issue 周期
- 平均周期：{avg_cycle} 天
- 最快：{min_cycle} 天（{fastest_issue}）
- 最慢：{max_cycle} 天（{slowest_issue}）
 
### 节奏
- 活跃天数：{active_days}/22 个工作日
- 最长断档：{max_gap} 天
- 提交时间分布：工作时间 {work_pct}% / 非工作时间 {off_pct}%
 
## 四、质量分析
 
### AI 代码评审
- 月度平均评分：{avg_review_score}/5
- 最高分 commit：{best_commit}（{best_score}）
- 最低分 commit：{worst_commit}（{worst_score}）
- 主要扣分项：{top_deduction_reasons}
 
### 回退/修复率
- 被 revert 的 commit：{revert_count}/{total_commits}（{revert_rate}）
- 引入后续 bugfix 的 commit：{bugfix_count}
 
### 技术债
- 新增技术债信号：{debt_added}
- 消除技术债信号：{debt_removed}
- 净变化：{debt_net}（{debt_trend}）
 
## 五、AI Coding 专项（如适用）
 
- 死代码引入：{dead_code_count} 处
- 新增依赖：{new_deps_count} 个（{necessary_count} 个必要 / {unnecessary_count} 个可疑）
- any 类型使用：{any_count} 处
- 测试覆盖：新功能 {test_coverage_pct}% 带了测试
 
## 六、改进建议
 
1. {suggestion_1}
2. {suggestion_2}
3. {suggestion_3}
 
## 七、数据局限性声明
 
本报告基于 GitHub 数据自动生成，存在以下局限：
- 无法衡量架构设计、技术方案讨论等非代码贡献
- 无法衡量 Code Review 中给他人的帮助（如果没有 PR 流程）
- AI 代码评审可能存在误判，建议结合人工判断
- 工作量不等于价值，10 行关键代码可能比 1000 行模板代码更重要

# 开发者月度绩效分析：张三
 
**分析周期**：2026-07-01 ~ 2026-07-31
**分析模型**：Claude Sonnet 4
**数据来源**：GitHub Issues + Commits + AI Code Review
 
---
 
## 一、总览
 
| 维度 | 评分 | 等级 | 说明 |
|------|------|------|------|
| 产出 | 4.2/5 | 良好 | 完成 5 个功能 + 4 个 bug 修复，产出量高于团队平均 |
| 效率 | 3.8/5 | 良好 | 平均周期 3.2 天，节奏稳定 |
| 质量 | 3.5/5 | 合格 | 代码评审均分 3.9，但技术债有净增长 |
| **综合** | **3.8/5** | **良好** | |
 
## 二、产出分析
 
### 功能块交付
本月完成 5 个功能、4 个 bug 修复、3 个维护任务。
 
| 功能块 | 类型 | 复杂度 | Issue | commit 数 |
|--------|------|--------|-------|----------|
| Solana 课程模块 | feature | 大型 | #42 | 12 |
| 课程搜索优化 | feature | 中型 | #45 | 6 |
| 用户 Dashboard 改版 | feature | 中型 | #48 | 8 |
| 移动端适配 | feature | 小型 | #51 | 3 |
| API 缓存层 | feature | 中型 | #53 | 5 |
| Safari 进度条 bug | bug | 小型 | #43 | 2 |
| 登录超时问题 | bug | 小型 | #46 | 1 |
| 课程排序异常 | bug | 小型 | #49 | 2 |
| 支付回调丢失 | bug | 中型 | #52 | 4 |
| Next.js 升级 | chore | 中型 | #44 | 3 |
| 依赖安全更新 | chore | 小型 | #47 | 1 |
| CI 配置优化 | chore | 小型 | #50 | 2 |
 
加权产出分：大型×3 + 中型×2×4 + 小型×1×4 = 3+8+4 = 15（团队平均 10）
 
### 工作结构
feature 42% / bug 33% / chore 25%
解读：以功能开发为主，bug 修复占比偏高，建议关注代码质量以减少后续 bug。
 
## 三、效率分析
 
### Issue 周期
- 平均周期：3.2 天
- 最快：0.5 天（#46 登录超时问题）
- 最慢：7 天（#42 Solana 课程模块 — 大型功能，周期合理）
 
### 节奏
- 活跃天数：19/22 个工作日（86%）
- 最长断档：2 天（7/14-7/15，团队 outing）
- 提交时间分布：工作时间 82% / 非工作时间 18%
 
## 四、质量分析
 
### AI 代码评审
- 月度平均评分：3.9/5
- 最高分：#53 API 缓存层（4.6 — 设计合理，错误处理完善）
- 最低分：#51 移动端适配（3.1 — 缺少响应式断点测试，硬编码了多个像素值）
- 主要扣分项：安全性（API 权限校验缺失 3 处）、健壮性（错误处理不完善 5 处）
 
### 回退/修复率
- 被 revert：0 次
- 引入后续 bugfix：2 次（#43 的修复不完整，后续 #49 再次修复了相关问题）
- 回退率：2/47 = 4.3%（正常范围）
 
### 技术债
- 新增：TODO 3 处、any 2 处、硬编码 4 处 = 9 处
- 消除：TODO 1 处、旧 hack 2 处 = 3 处
- 净变化：+6（需关注，技术债在积累）
 
## 五、AI Coding 专项
 
- 死代码：2 处未使用的导入（#48 Dashboard 改版）
- 新增依赖：2 个（date-fns 必要，lodash.debounce 可用原生替代）
- any 使用：2 处（#51 移动端适配中的事件处理）
- 测试覆盖：5 个新功能中 3 个带了测试（60%）
 
## 六、改进建议
 
1. **安全性**：建议在 API 路由中统一添加权限校验中间件，
   而不是在每个端点单独处理。本月有 3 处遗漏
2. **测试覆盖**：移动端适配和 Dashboard 改版缺少测试，
   建议 AI 生成功能代码时同步要求生成测试
3. **技术债**：本月净增 6 处技术债信号，建议每周花 1-2 小时
   专门清理 TODO 和 any 类型
 
## 七、数据局限性声明
 
本报告基于 GitHub 数据自动生成，存在以下局限：
- 张三本月参与了 3 次架构讨论会，这些贡献未体现在数据中
- 张三帮助新人王五解决了多个技术问题，这些 mentoring 贡献无法量化
- AI 代码评审可能存在误判，建议结合 manager 的日常观察

# team-dev-performance
 
自动采集 GitHub 数据，结合 AI 代码评审，生成开发者月度绩效分析报告。
 
## 触发条件
- 定时触发：每月 1 日 10:00（分析上月数据）
- 手动触发：用户消息包含"绩效分析"、"开发者报告"、"月度评估"
 
## 执行步骤
1. 从人员表获取所有开发角色的成员及其 GitHub ID
2. 对每个开发者：
   a. 通过 GitHub MCP 采集上月的 Issues（assigned + closed）
   b. 通过 GitHub MCP 采集上月的 Commits（author 匹配）
   c. 对每个 commit 的 diff 执行 AI 代码评审（采样：commit 数 > 30 时随机抽 30 个）
   d. 统计回退率（搜索 revert commit）
   e. 统计技术债变化（扫描 diff 中的 TODO/any/硬编码）
3. 计算各维度评分
4. 生成个人绩效报告
5. 生成团队对比报告
6. 发送个人报告到各自飞书私聊
7. 发送团队报告到管理层群
 
## 团队对比报告模板
 
📊 开发团队月度绩效对比（{month}）
 
| 成员 | 产出 | 效率 | 质量 | 综合 | 趋势 |
|------|------|------|------|------|------|
 
📈 团队趋势：
- 平均产出分：{avg} （上月 {last_month}，{trend}）
- 平均质量分：{avg} （上月 {last_month}，{trend}）
- 团队技术债净变化：{total_debt_net}
 
## 隐私保护
- 个人详细报告只发给本人和直属 manager
- 团队对比报告只发给管理层
- 不在公开群展示个人排名
 
## 权限要求
- GitHub MCP（Issues + Commits 读取）
- 飞书多维表格读取（人员表）
- 飞书消息发送（私聊 + 群聊）
- LLM API（代码评审）