Project Check

---
name: project-check
description: 项目经历真实性与质量核验：核对项目实际代码与简历描述是否吻合、复杂度与声称难度是否匹配、个人贡献边界、是否有真实使用痕迹，并比对同质化项目难度基准表判断简历描述强度是否超出该类项目的典型范围。凡是要判断一个项目的真实分量就使用本技能——包括用户说"这项目有多难""是不是套模板的""这个项目能说明什么水平""他是不是真做过"时。
---

# /project-check：项目真实性与质量核验

一份简历的技术含量，主要由项目经历承载。而项目经历也是最容易注水的地方——因为面试官很难在短时间内判断一个陌生仓库的真实分量。

本 skill 要回答三个递进的问题：

1. **这个项目真实存在吗？**（有代码、有痕迹、时间对得上）
2. **它和简历描述的是同一个东西吗？**（复杂度、技术栈、规模是否吻合）
3. **候选人在其中的真实角色是什么？**（个人边界）

"是不是烂大街项目"是**第四个、也是权重最低的问题**——见下方专门说明。

## 边界

- 只核验候选人主动提供地址的项目。简历中只有文字描述、无链接的项目，标记为"仅可面试追问"，不去搜索猜测。
- 公司内部项目**本就不该有公开痕迹**。对这类项目，唯一正确的处理是`结构性不可公开核验`，转为面试问题。绝不能因查不到而推向负面。
- 不联系项目的其他协作者核实，不在社区打听。核验只用公开可读的材料。

## 核验流程

### 第一步：存在性与时间核验

- 链接是否可访问？仓库是否存在？线上服务是否还在？（已下线是常态，不是问题）
- 仓库首次提交时间、最后提交时间、提交总数；
- 与简历声称的项目时间是否吻合（详见 [../resume-audit/references/timeline-consistency.md](../resume-audit/references/timeline-consistency.md)）；
- 仓库是原创还是 fork。

### 第二步：描述吻合度核验（核心）

把简历对该项目的描述逐句拆开，与仓库实际内容对照：

| 简历声称 | 核验方法 | 不吻合意味着什么 |
| --- | --- | --- |
| 技术栈 A/B/C | 看依赖文件、实际 import、配置 | 声称的技术在代码中完全不存在 → 强信号 |
| "支持高并发/分布式" | 看是否真有并发控制、分布式协调的代码 | 只有单机 CRUD → 描述夸大 |
| "自研 XX 框架/引擎" | 看是否是对现成库的薄封装 | 薄封装被称为"自研" → 表述夸大 |
| "服务 N 个用户" | 看是否有部署痕迹、用户反馈、issue 活跃度 | 无任何使用痕迹 → 需追问数据来源 |
| "完整的测试/CI/监控" | 看 CI 配置、测试覆盖、监控代码 | 声称有但完全没有 → 强信号 |
| 代码量 / 模块规模 | 实际统计 | 声称"十万行"实际两千行 → 强信号 |

**最有力的一条**：**代码复杂度与声称的技术难度是否匹配**。如果简历写"设计了基于 Raft 的分布式一致性存储"，而仓库里只有一个用 map 实现的 KV 加一个 HTTP 接口，这是可以给出较强结论的实质矛盾。

反过来同样要注意：如果代码复杂度**远超**候选人的经验年限所能解释的水平，且提交历史显示是短时间内一次性推入的，也值得追问——但这**绝不能**直接判为抄袭，很多可能：从私有仓迁移、基于开源二次开发、AI 辅助开发（现代工程实践，正当）、就是很强。

### 第三步：个人边界核验

- 仓库贡献者列表中候选人的提交占比；
- 候选人的提交集中在哪些文件/模块——这直接对应他的真实工作范围；
- 简历若声称"主导/独立完成"，而提交历史显示有多位贡献者且候选人非主要提交者 → 需追问。

**必须排除**：公司项目开源时常以单一账号推送，提交历史无法反映真实分工；团队约定由某人统一提交；使用了 pair programming。

### 第四步：同质化项目比对（权重最低，慎用）

读 [references/boilerplate-catalog.md](references/boilerplate-catalog.md)，判断该项目是否属于高频同质化类型。

**在使用这一维度前，必须先接受以下前提**：

> **做一个常见类型的项目，完全不是问题。** 学习一个技术方向时，做该方向的经典项目是最有效的路径。绝大多数优秀工程师的第一个 RAG 应用、第一个秒杀系统、第一个 Raft 实现，都长得差不多。项目"烂大街"**丝毫不能说明**候选人能力差或在造假。

那么这一维度到底核验什么？只核验**一件事**：

> **简历对该项目的描述强度，是否超出了这类项目的实际难度。**

举例：
- 跟着教程做了个 RAG 问答应用，简历写"实现基于向量检索的知识问答系统" → **完全没问题**，如实描述；
- 同一个项目，简历写"自研 RAG 引擎，设计多路召回与重排架构，检索准确率提升 40%" → **需要核验**，因为这个描述强度对应的是一个远比模板项目复杂的东西。

所以正确的用法是：**识别出项目类型 → 查明这类项目的典型实现难度 → 与简历描述强度对照 → 落差过大则追问**。

**报告中的表述纪律**：
- 不要写"该项目为烂大街项目"这种带贬义的结论；
- 应写"该项目属于 XX 类常见实践项目，此类项目的典型实现范围是 A、B、C；简历描述中的 D、E 超出该范围，建议面试确认候选人是否做了对应的额外工作"；
- 若简历描述与项目实际难度相符，明确写"描述与项目实际情况吻合，未见夸大"——这同样是有价值的结论。

### 第五步：真实使用痕迹

有真实用户的项目会留下痕迹：外部提交的 issue、非作者的 fork、社区讨论、部署记录、下游依赖。

**注意**：无痕迹是绝大多数个人项目的常态，**完全正常**。这一项只在简历声称了用户量、采用方、业务价值时才需要核验。

## 输出

```markdown
### 项目核验：[项目名]

**地址**：[链接] | **性质**：[个人项目 / 团队项目 / 公司开源 / fork]
**时间**：仓库 [首次提交]—[最后提交] | 简历声称 [起]—[止] | [吻合 / 不吻合]

**描述吻合度**：
| 简历声称 | 实际情况 | 结论 |
| --- | --- | --- |
| "..." | ... | [吻合 / 落差] |

**个人边界**：贡献者 N 人，候选人提交占比 X%，集中在 [模块]。
**项目类型**：[属于 XX 类常见实践项目 / 未匹配到已知类型]
  该类项目典型范围：...
  简历描述超出部分：...
**使用痕迹**：[有/无，及是否与简历声称的用户量相符]

**结论**：[档位]
**其他可能的解释**：[必填]
```

## 误判警示

| 观察 | 不能推出的结论 |
| --- | --- |
| 项目是常见类型 | 不能推出能力差或造假 |
| 代码量少 | 不能推出水平低——精简的实现可能更难 |
| 无 star / 无用户 | 不能推出项目没价值 |
| 用了大量第三方库 | 不能推出"没有技术含量"——合理复用是工程能力 |
| 代码有 AI 辅助痕迹 | 不能推出任何问题——这是当前的标准实践 |
| 仓库已归档 / 停止维护 | 完全正常，个人项目大多如此 |
| 一次性大量提交 | 有多种正常解释（迁移、初次开源、squash） |
| 项目跟着教程做的 | 学习方式正当，只看简历描述是否如实 |