Github Audit

---
name: github-audit
description: GitHub/GitLab 贡献真实性核验：逐个查看 PR 的实际 diff、按领域与深度分类统计、核对贡献量级与"Contributor/核心贡献者/Maintainer"类表述是否相符，识别刷绿、刷 PR、刷 star 与领域错配（如自称 AI Infra 实则全是前端提交）。凡是要评估某人 GitHub 的含金量就使用本技能——包括用户说"他这个 GitHub 怎么样""这个 contributor 有多少水分""开源经历值多少""帮我看看这个账号"时。也在 /resume-audit 需要核验代码托管材料时调用。
---

# /github-audit：GitHub 贡献真实性核验

简历上的"开源贡献"是最容易被误读的一栏：仓库越有名，HR 越容易高估；而 GitHub 的公开数据恰恰能让这件事被精确核实。

本 skill 的核心原则是：**看 diff，不看数字**。PR 数量、star 数、绿格子密度都可以被廉价地做出来，唯有每个 PR 实际改了什么代码无法伪装。

## 边界

- 只访问候选人在简历或沟通中**主动提供**的账号/仓库链接。**绝不根据姓名、拼音、邮箱前缀去搜索猜测账号**——同名账号极多，误认的后果是把无关的人的行为归到候选人头上。
- 只读公开信息。不尝试访问私有仓库，不通过任何手段推断私有活动。
- 不核验与技术能力无关的内容（候选人 star 过什么项目、follow 了谁、在什么议题下发过言）。这些既不相关也涉及隐私。
- GitHub 活跃度低**完全不是**负面信号。大量优秀工程师的产出全在公司内网。只有当简历**主动声称**了开源贡献时，本核验才适用。

## 核验流程

### 第一步：确认账号归属

在核验任何内容前，先确认这个账号确实是候选人的。可接受的归属证据：简历中直接写明的链接、账号 profile 中与简历一致的姓名/学校/公司信息、个人网站与账号的互相链接。

归属存疑时**停止核验**，在报告中写"账号归属无法确认，未做核验"。宁可不查，不可查错人。

### 第一步半：速查粗筛（先做这个，再决定细看哪些）

逐个开 PR 看 diff 准确但慢。先按 [references/quick-metrics.md](references/quick-metrics.md) 花几分钟做量化粗筛，决定把精力投在哪里：

1. **先查两项硬证据**（若简历声称 Maintainer / 核心作者）：目标仓库根目录有无 `MAINTAINERS`/`CODEOWNERS`/`OWNERS` 且名单含候选人；Releases 页有无候选人作为发布者。这两项能最快证实高强度身份主张。
2. **按 owner 分叉**：在 `github.com/pulls?q=is:pr+author:{用户名}+is:merged` 里，先剔除打向**自己**仓库的 PR，剩下的才是可核验的外部贡献。
3. **看比例，不看个例**：统计外部 PR 中文档类的占比（用 Files changed 的文件后缀机械判定）。
4. **蹭明星项目核验**：声称贡献过某知名项目时，直接看 `/{org}/{repo}/commits?author={用户名}` 的 commit 数。

粗筛结果决定细看范围：占比异常或身份主张强的，再进入第二步逐个开 diff。

### 第二步：贡献类型分布（核心）

**先读这条纪律**：**单个小 PR 不构成任何信号。** 实测中 58% 的开发者都至少有一个琐碎的外部 PR，而"多数 PR 都琐碎"的只有 0.4%。任何惩罚"提过小 PR"这个事件的判断，都是为了抓极少数人而误伤绝大多数人。

因此报告里**不要写"该 PR 为 T0 级"，要写"N 个外部 PR 中 T0/T1 占比 X%"**。造假是账号历史的**比例属性**，不是单个 diff 的**事件属性**。

打开候选人在**外部项目**（非自己的仓库）的 PR，查看实际 diff。**建议按两个正交轴分类**——类型轴（文档 / 表现层 / 核心代码，可按文件路径机械判定）× 深度轴（下表）。把"改 README 里的架构说明"和"改架构代码"放在同一个梯子上会失真：

| 类型 | 判定标准 | 含金量 |
| --- | --- | --- |
| **T0 文本类** | 错别字、标点、Markdown 格式、坏链接、注释排版 | 正当贡献，但不构成技术能力证明 |
| **T1 文档类** | 补充文档内容、示例说明、翻译、README 结构调整 | 说明读懂了项目，有一定理解 |
| **T2 配置/构建类** | CI 配置、依赖升级、构建脚本、lint 规则 | 需要一定工程理解 |
| **T3 测试类** | 补充测试用例、修复 flaky test | 需要理解被测逻辑 |
| **T4 缺陷修复** | 修复实际 bug，含逻辑改动 | 实质技术贡献 |
| **T5 特性/架构** | 新增功能、重构模块、性能优化、参与设计讨论 | 强技术贡献 |

**关键判断**：把统计结果与简历表述对照。

| 简历表述 | 实际分布 | 结论 |
| --- | --- | --- |
| "为 XX 项目贡献文档修正" | T0/T1 为主 | 已核实 —— 如实描述 |
| "XX 项目 Contributor" | T0/T1 为主 | 疑似 —— 技术上成立但易致误解，建议面试澄清贡献性质 |
| "XX 项目核心贡献者 / 参与核心模块设计" | 全部 T0/T1 | **部分属实** —— 表述与实际贡献量级存在明显落差 |
| "主导 XX 模块重构" | 有对应 T5 PR 且已合并 | 已核实 —— 核验通过 |

**必须写进报告的免责说明**：T0/T1 贡献是完全正当且对社区有价值的开源参与，不应被贬低。本核验针对的**只是表述与实际的落差**，不是贡献本身。

### 第二步半：领域归属（简历有方向自称时**强制**）

上一步的类型分级（文档/表现层/核心代码 × T0–T5）测的是**贡献分量**，**测不出贡献领域**。`.tsx` 是"核心代码类"满分——但它是前端。

简历一旦出现方向性自称（AI Infra、推理优化、分布式存储、某某 Runtime Owner），**必须**按 [references/domain-attribution.md](references/domain-attribution.md) 统计**改动行数的领域分布**，并与自称对照。

速记：**按路径判领域，不按语言**；`.py` 可能是训练脚本也可能是 Web 后端，`.ts` 可能是前端也可能是 Node 服务。

### 第三步：识别刷量模式

读 [references/contribution-red-flags.md](references/contribution-red-flags.md)，逐条比对。重点看：

- **广度优先型**：在大量不同仓库各提 1 个极小 PR，追求"参与项目数"而非深度；
- **知名度导向**：所选仓库高度集中在 star 数最高的明星项目，且改动均极小——目标是简历上能写出的仓库名；
- **时间聚集**：全部贡献集中在求职季前的短窗口内，此前此后无活动；
- **合并状态混淆**：简历写"贡献被采用"，但 PR 实际状态是 open 或 closed（未合并）。这一条可以给出较强结论，因为 PR 状态是客观的。

### 第四步：自有仓库核验

对候选人自己的仓库（简历上作为项目展示的）：

- **提交历史形态**：是长期渐进式开发，还是少数几个巨型 commit 一次性推上来？后者常见于把已完成代码（含他人代码）一次性导入。这**不必然**有问题（从私有仓库迁移、初次开源都会这样），但值得追问。
- **首次 commit 时间 vs 简历声称的项目时间**：明显矛盾时构成硬证据。
- **是否为 fork**：fork 来的仓库若在简历中被表述为自研项目，是明确问题。注意区分：基于开源项目做二次开发并说明来源，是正当行为。
- **代码风格一致性**：整个仓库的命名、注释、错误处理风格是否统一。风格断层可能意味着代码来源混杂——但**不能据此下结论**，团队协作、AI 辅助、不同时期的自己都会造成风格差异。

### 第五步：Star 与关注度核验（谨慎）

若简历以 star 数作为成果指标：

- 查看 stargazers 列表的账号特征——大量注册时间接近、无任何其他活动、无头像的账号，是刷 star 的信号；
- 查看 star 的增长曲线是否存在异常陡峭的孤立尖峰；
- 注意区分：项目被某个技术周刊、热榜、大 V 转发也会造成尖峰，这是正常的。

**这一维度极易误判，结论上限为"疑似"**，且必须写明其他可能性。

## 输出

```markdown
### GitHub 贡献核验

**核验对象**：[账号链接]，归属确认方式：[如何确认是候选人本人]
**核验范围**：外部项目 PR N 个（已全部打开查看 diff）、自有仓库 M 个

**贡献类型分布**：
| 类型 | 数量 | 代表 PR |
| T0 文本类 | 12 | [链接]（改动：README 3 处错别字） |
| T4 缺陷修复 | 1 | [链接]（改动：修复 XX 空指针） |
| ... |

**简历表述对照**：
- 简历原文："..."
- 实际情况：...
- 结论：[档位]
- 其他可能的解释：...

**其他发现**：[时间聚集 / fork 情况 / 合并状态 等]

**本维度免责**：文档类贡献是正当的开源参与；本核验只针对表述与实际的落差。
```

## 常见误判警示

| 观察 | 不能推出的结论 |
| --- | --- |
| 绿格子稀疏 | 不能推出"不写代码"——公司代码不在 GitHub |
| 绿格子全绿 | 不能推出"高产"——也不能推出"刷的"，需看提交内容 |
| PR 数量少 | 不能推出"能力差"——一个高质量 PR 胜过百个 typo |
| 只有 typo PR | 不能推出"造假"——只能说明表述若为"核心贡献者"则不符 |
| 代码风格不统一 | 不能推出"抄的"——多种正常原因均可致此 |
| 仓库无 star | 不能推出"项目差"——star 与质量弱相关 |
| 深夜/周末提交多 | 不能做任何推断——涉及作息隐私，且与能力无关 |