forked from Gitlink/gitlink-cli
9.1 KiB
9.1 KiB
示例：AI 判断演示（复杂场景）
本示例展示对几个真实复杂 Issue 的 AI 判断过程，重点演示 AI 如何避免误判。
场景
下面是 5 个真实场景的 Issue，展示 AI 判断在不同信号下的决策。
场景 A：避免误判活跃 Issue
Issue #156：[Roadmap] v2 API 设计
.\gitlink-cli.exe issue +view --owner Gitlink --repo forgeplus --number 156 --format json
{
"number": 156,
"subject": "[Roadmap] v2 API 设计",
"description": "长期讨论 v2 接口规范...",
"issue_tags": [{"name": "roadmap"}],
"tracker_id": 2,
"priority_id": 3,
"author": {"login": "tech-lead"},
"journals": [
{"user": {"login": "dev-li"}, "notes": "正在按这个方向重构", "created_at": "2026-05-15T10:00:00Z"},
{"user": {"login": "dev-wang"}, "notes": "+1，关注这个", "created_at": "2026-05-20T14:00:00Z"},
{"user": {"login": "pm-zhang"}, "notes": "下个版本规划进", "created_at": "2026-06-01T09:00:00Z"}
],
"updated_at": "2026-06-01T09:00:00Z",
"created_at": "2025-12-01T00:00:00Z"
}
AI 分析过程
days_inactive = (2026-06-23 - 2026-06-01).days = 22 天
【Stage B 白名单】
✓ 含标签 roadmap → EXEMPT: true
reason: "含豁免标签: roadmap"
【输出】
{
"truly_stale": false,
"exempt": true,
"exempt_reason": "含豁免标签: roadmap",
"recommended_action": "skip"
}
关键：即使不豁免，days_inactive=22 也未达 60 天阈值，AI 双重保险。
场景 B：识别真僵尸（用户多次催问）
Issue #178：登录页加载慢
{
"number": 178,
"subject": "Bug: 登录页加载需要 5 秒",
"description": "线上环境加载很慢...",
"issue_tags": [],
"author": {"login": "user-501"},
"journals": [
{"user": {"login": "user-501"}, "notes": "还在等回复", "created_at": "2026-04-10T08:00:00Z"},
{"user": {"login": "user-501"}, "notes": "+1", "created_at": "2026-04-25T08:00:00Z"},
{"user": {"login": "user-501"}, "notes": "催一下", "created_at": "2026-05-15T08:00:00Z"}
],
"updated_at": "2026-05-15T08:00:00Z"
}
AI 分析过程
days_inactive = (2026-06-23 - 2026-05-15).days = 39 天
未达阈值（60 天）→ 不处理
等等，看似不处理。但如果用户来催问的时间窗口是 60+ 天前呢？修正：
重新检查 days_inactive（基于 created_at）：
days_since_created = 200+ 天
days_since_last_user_comment = 39 天
days_since_last_activity = 39 天（用户最后催问）
虽然未达 stale 阈值，但 AI 应识别"用户反复催问但维护者 0 回复"的强信号
AI 输出（如果阈值放宽到 30 天）
{
"truly_stale": true,
"confidence": 0.92,
"reason": "用户 3 次催问（4-10、4-25、5-15），维护者从未回复；最后活动 39 天前",
"recommended_action": "mark_stale",
"exempt": false
}
关键：AI 看到了 journals 中"还在等回复"、"+1"、"催一下"的强信号。
场景 C：避免误关"等上游"的 Issue
Issue #201：[Feature] 支持 SSL 双向认证
{
"number": 201,
"subject": "[Feature] 支持 SSL 双向认证",
"description": "...",
"issue_tags": [{"name": "enhancement"}],
"author": {"login": "enterprise-user"},
"journals": [
{"user": {"login": "dev-li"}, "notes": "需要等上游 openssl-sys 库的 #142 合并", "created_at": "2026-03-01T00:00:00Z"},
{"user": {"login": "dev-li"}, "notes": "上游 #142 已合并，等 release", "created_at": "2026-04-15T00:00:00Z"},
{"user": {"login": "dev-li"}, "notes": "上游 release 推迟到 Q3", "created_at": "2026-05-10T00:00:00Z"}
],
"updated_at": "2026-05-10T00:00:00Z"
}
AI 分析过程
days_inactive = (2026-06-23 - 2026-05-10).days = 44 天
未达 60 天阈值
【AI 备用判断（即使超阈值也应该跳过）】
- 最后评论者：dev-li（维护者）
- 评论内容含"等上游"、"推迟"
- 维护者明确表态在跟进
【信号权重】
- journals: 维护者最近回应，含"等待"关键词 → 跳过 (0.8)
- tracker: feature → 中性 (0.5)
- author: enterprise-user（特定用户）→ 中性 (0.5)
- time: 44 天 → 0
【加权】
score = 0.8 * 0.4 + 0.5 * 0.25 + 0.5 * 0.15 + 0 * 0.2 = 0.495
AI 输出（假设已超阈值）
{
"truly_stale": false,
"confidence": 0.495,
"reason": "维护者 dev-li 30+ 天前明确表态'等上游 release'，活跃跟踪中",
"recommended_action": "skip",
"exempt": false
}
关键：AI 识别了"等上游"这个等待型关键词，避免误关。
场景 D：识别重复 Issue（自动关闭）
Issue #215：又是登录失败
{
"number": 215,
"subject": "Bug: 登录失败",
"description": "密码对但登不进去",
"issue_tags": [],
"author": {"login": "new-user-99"},
"journals": [
{"user": {"login": "dev-li"}, "notes": "duplicate of #142", "created_at": "2026-06-22T00:00:00Z"}
],
"updated_at": "2026-06-22T00:00:00Z"
}
AI 分析过程
days_inactive = 1 天，未达阈值
【AI 特殊判断】
- 评论含 "duplicate of #N" 模式
- 这是 force_close 的强信号
AI 输出
{
"truly_stale": false,
"confidence": 0.95,
"reason": "维护者已标记为 #142 的重复",
"recommended_action": "auto_close",
"duplicate_of": 142,
"exempt": false
}
关键：AI 识别 duplicate 模式，直接建议关闭（关联到 #142）。
场景 E：低置信度的待人工项
Issue #228：希望增加暗色主题
{
"number": 228,
"subject": "希望增加暗色主题",
"description": "夜间使用太刺眼",
"issue_tags": [],
"author": {"login": "casual-user"},
"journals": [
{"user": {"login": "dev-li"}, "notes": "考虑中", "created_at": "2026-03-15T00:00:00Z"}
],
"updated_at": "2026-03-15T00:00:00Z"
}
AI 分析过程
days_inactive = 100 天，超阈值
【信号分析】
- journals: 维护者回复"考虑中"，但 100 天没跟进 → 中性 (0.6)
- tracker: feature → 中性 (0.5)
- author: 普通用户 → 0.5
- time: 100 天 → 0.66
【加权】
score = 0.6 * 0.4 + 0.5 * 0.25 + 0.5 * 0.15 + 0.66 * 0.2 = 0.562
【阈值判断】
score 0.562 < 0.6 → 不自动处理
AI 输出
{
"truly_stale": false,
"confidence": 0.562,
"reason": "维护者回复过'考虑中'，但已 100 天未跟进；feature 类，把握不足",
"recommended_action": "needs_review",
"exempt": false
}
关键：AI 主动承认把握不足，转入人工队列。
综合演示：5 个场景对比
| # | 标题 | AI 决策 | 置信度 | 关键信号 |
|---|---|---|---|---|
| 156 | [Roadmap] v2 API 设计 | skip (exempt) | N/A | 含 roadmap 标签 |
| 178 | 登录页加载慢 | mark_stale | 0.92 | 用户 3 次催问 |
| 201 | SSL 双向认证 | skip | 0.50 | 含"等上游"关键词 |
| 215 | 又是登录失败 | auto_close | 0.95 | duplicate 标记 |
| 228 | 增加暗色主题 | needs_review | 0.56 | 把握不足 |
AI 判断的"可解释性"
每次决策都附 reason 字段，便于人工复核：
### #178 决策依据
- journals 信号 (0.4): 用户 3 次催问（4-10、4-25、5-15），维护者从未回复
- 贡献: 0.9 × 0.4 = 0.36
- tracker 信号 (0.25): bug 类，谨慎处理
- 贡献: 0.5 × 0.25 = 0.125
- author 信号 (0.15): user-501 普通用户
- 贡献: 0.5 × 0.15 = 0.075
- time 信号 (0.2): 39 天未活动
- 贡献: 0 × 0.2 = 0
- 综合: 0.56
> 看似 < 0.6，但 journals 信号是"用户多次催问"（强信号），
> AI 上调 confidence 至 0.92（基于语义判断）
错判案例（反面教材）
案例 1：误关"等用户回复"的 Issue
Issue 状态：维护者 60 天前问"还遇到吗？"，用户没回复。
正确处理：用户没回，是真僵尸，可以关。
误判：AI 看到"最后评论者是维护者"，可能跳过。
纠正：在 AI 判断中，应识别"维护者问问题 + 用户 0 回复"为僵尸信号：
if last_user_is_maintainer and maintainer_asks_question:
if no_user_response_after(maintainer_question, days=30):
return {"truly_stale": True, "confidence": 0.85}
案例 2：误标"路线图 Issue"
Issue 状态：标题含"长期"，但实际是用户提的 feature 请求。
误判：白名单匹配"长期"模式 → 豁免。
纠正：白名单匹配应同时检查标签或作者（双重信号）：
if title_matches_keep_open and (label_is_pinned or author_is_member):
return exempt
elif title_matches_keep_open:
return needs_review # 仅标题匹配，需要人工判断
总结
AI 判断的核心价值：
- ✅ 多信号综合 — 不仅看时间，看评论历史、标签、作者、类型
- ✅ 可解释 — 每次决策都附 reasoning
- ✅ 保守原则 — 把握不足时不自动处理
- ✅ 可调优 — 权重和阈值可在配置中调整
- ⚠️ 非万能 — 复杂场景仍需人工复核，所以才有 needs_review 队列
核心思想：AI 帮助过滤掉"明显僵尸"和"明显活跃"，把灰色地带留给人工。