TNT-Likely 单 Issue 深度分析技能
做什么
对一条 GitHub issue 做透彻分析,回答四个问题:
- 是不是真问题? —— bug 真实存在 / 使用误解 / 已被修复 / 无法复现
- 要不要修 / 要不要做?
- 优先级多高? 4.(功能请求)合理吗?契合产品吗?
和 github-issue-triage 技能互补:triage 是宏观全量排序,本技能是单点深挖。常见组合:triage 选出可疑/高价值的,再用本技能逐个做透。
流程
1. 拉取 issue 全文
env -u HTTPS_PROXY -u HTTP_PROXY -u https_proxy -u http_proxy -u ALL_PROXY -u all_proxy \
gh issue view N --repo OWNER/REPO \
--json number,title,body,labels,comments,reactionGroups,state,author
读完整 body 加所有评论 —— 评论里常有复现补充、维护者回应、重复线索、版本信息。
2. 判类型
bug / 功能请求 / question(使用问题) / 重复 / 信息不足。先定性,再走对应分支。
3a. 如果是 Bug —— 必须用代码验证,别只信描述
- 在 codebase 定位相关代码,确认 bug 真实存在(找到会出错的那几行)
- 讲清:根因(哪行、为什么错)、影响面(谁会中招、多频繁)、能否复现(给最小路径)、是否已被其它改动修掉
- 区分:真 bug / 配置或使用问题 / 环境特定 / 描述不实
- 危害分级:数据正确性错误、崩溃 最高;偶发体验问题低
- 给是否需要修的明确结论 + 修复思路 + 工作量(S/M/L)
实战参照:有的 issue 报"AI 解析失败",定位到
amount as num?强转字符串直接崩 —— 真 bug,可定位可修;有的报"自动记账没反应"实为通知权限没开 —— 使用问题,引导即可,不动代码。结论必须落到代码或事实,不能凭描述拍脑袋。
3b. 如果是功能请求 —— 评估合理性,而非照单全收
- 契合度:符合产品定位与现有信息架构吗?会不会把 app 撑成四不像?
- 普遍 vs 小众:看呼声(👍/💬)+ 是不是只有提出者一个人的特殊流程
- 已有替代:现有功能能否绕过 / 组合实现?
- 可行性 / 成本:技术工作量?有无平台 / 合规限制(如某些权限上架受限)
- 拆分:大需求拆成"先做最痛的小核心"
- 结论:建议做 / 可做但不急 / 不建议做(给理由)/ 需求方补充信息
4. 输出结构
## #N <标题>
- 类型:bug / feature / question / …
- 结论:<真 bug 建议修 / 合理,P1 建议做 / 使用问题,引导即可 / 不建议做:…>
- 依据:<代码定位 file:line / 呼声 / 契合度分析>
- 优先级:🔴P0 / 🟡P1 / 🟢P2 / ⚪P3 + 一句理由
- 工作量:S / M / L
- 下一步:<修复思路 / 拆分方案 / 要追问的信息>
可直接作为 issue 评论草稿交给用户,但不自动发评论、不改 issue 状态。
红线
- bug 结论必须有代码依据 —— 不能只凭 issue 描述断言"是 bug"
- 功能请求诚实评估,该说"不建议做"就说清理由 —— 不当老好人照单全收
- 只读:不自动评论 / 关闭 / 改 label,产出供人决策