/project-check:项目真实性与质量核验
一份简历的技术含量,主要由项目经历承载。而项目经历也是最容易注水的地方——因为面试官很难在短时间内判断一个陌生仓库的真实分量。
本 skill 要回答三个递进的问题:
- 这个项目真实存在吗?(有代码、有痕迹、时间对得上)
- 它和简历描述的是同一个东西吗?(复杂度、技术栈、规模是否吻合)
- 候选人在其中的真实角色是什么?(个人边界)
"是不是烂大街项目"是第四个、也是权重最低的问题——见下方专门说明。
边界
- 只核验候选人主动提供地址的项目。简历中只有文字描述、无链接的项目,标记为"仅可面试追问",不去搜索猜测。
- 公司内部项目本就不该有公开痕迹。对这类项目,唯一正确的处理是
结构性不可公开核验,转为面试问题。绝不能因查不到而推向负面。
- 不联系项目的其他协作者核实,不在社区打听。核验只用公开可读的材料。
核验流程
第一步:存在性与时间核验
第二步:描述吻合度核验(核心)
把简历对该项目的描述逐句拆开,与仓库实际内容对照:
| 简历声称 | 核验方法 | 不吻合意味着什么 |
|---|
| 技术栈 A/B/C | 看依赖文件、实际 import、配置 | 声称的技术在代码中完全不存在 → 强信号 |
| "支持高并发/分布式" | 看是否真有并发控制、分布式协调的代码 | 只有单机 CRUD → 描述夸大 |
| "自研 XX 框架/引擎" | 看是否是对现成库的薄封装 | 薄封装被称为"自研" → 表述夸大 |
| "服务 N 个用户" | 看是否有部署痕迹、用户反馈、issue 活跃度 | 无任何使用痕迹 → 需追问数据来源 |
| "完整的测试/CI/监控" | 看 CI 配置、测试覆盖、监控代码 | 声称有但完全没有 → 强信号 |
| 代码量 / 模块规模 | 实际统计 | 声称"十万行"实际两千行 → 强信号 |
最有力的一条:代码复杂度与声称的技术难度是否匹配。如果简历写"设计了基于 Raft 的分布式一致性存储",而仓库里只有一个用 map 实现的 KV 加一个 HTTP 接口,这是可以给出较强结论的实质矛盾。
反过来同样要注意:如果代码复杂度远超候选人的经验年限所能解释的水平,且提交历史显示是短时间内一次性推入的,也值得追问——但这绝不能直接判为抄袭,很多可能:从私有仓迁移、基于开源二次开发、AI 辅助开发(现代工程实践,正当)、就是很强。
第三步:个人边界核验
- 仓库贡献者列表中候选人的提交占比;
- 候选人的提交集中在哪些文件/模块——这直接对应他的真实工作范围;
- 简历若声称"主导/独立完成",而提交历史显示有多位贡献者且候选人非主要提交者 → 需追问。
必须排除:公司项目开源时常以单一账号推送,提交历史无法反映真实分工;团队约定由某人统一提交;使用了 pair programming。
第四步:同质化项目比对(权重最低,慎用)
读 references/boilerplate-catalog.md,判断该项目是否属于高频同质化类型。
在使用这一维度前,必须先接受以下前提:
做一个常见类型的项目,完全不是问题。 学习一个技术方向时,做该方向的经典项目是最有效的路径。绝大多数优秀工程师的第一个 RAG 应用、第一个秒杀系统、第一个 Raft 实现,都长得差不多。项目"烂大街"丝毫不能说明候选人能力差或在造假。
那么这一维度到底核验什么?只核验一件事:
简历对该项目的描述强度,是否超出了这类项目的实际难度。
举例:
- 跟着教程做了个 RAG 问答应用,简历写"实现基于向量检索的知识问答系统" → 完全没问题,如实描述;
- 同一个项目,简历写"自研 RAG 引擎,设计多路召回与重排架构,检索准确率提升 40%" → 需要核验,因为这个描述强度对应的是一个远比模板项目复杂的东西。
所以正确的用法是:识别出项目类型 → 查明这类项目的典型实现难度 → 与简历描述强度对照 → 落差过大则追问。
报告中的表述纪律:
- 不要写"该项目为烂大街项目"这种带贬义的结论;
- 应写"该项目属于 XX 类常见实践项目,此类项目的典型实现范围是 A、B、C;简历描述中的 D、E 超出该范围,建议面试确认候选人是否做了对应的额外工作";
- 若简历描述与项目实际难度相符,明确写"描述与项目实际情况吻合,未见夸大"——这同样是有价值的结论。
第五步:真实使用痕迹
有真实用户的项目会留下痕迹:外部提交的 issue、非作者的 fork、社区讨论、部署记录、下游依赖。
注意:无痕迹是绝大多数个人项目的常态,完全正常。这一项只在简历声称了用户量、采用方、业务价值时才需要核验。
输出
### 项目核验:[项目名]
**地址**:[链接] | **性质**:[个人项目 / 团队项目 / 公司开源 / fork]
**时间**:仓库 [首次提交]—[最后提交] | 简历声称 [起]—[止] | [吻合 / 不吻合]
**描述吻合度**:
| 简历声称 | 实际情况 | 结论 |
| --- | --- | --- |
| "..." | ... | [吻合 / 落差] |
**个人边界**:贡献者 N 人,候选人提交占比 X%,集中在 [模块]。
**项目类型**:[属于 XX 类常见实践项目 / 未匹配到已知类型]
该类项目典型范围:...
简历描述超出部分:...
**使用痕迹**:[有/无,及是否与简历声称的用户量相符]
**结论**:[档位]
**其他可能的解释**:[必填]
误判警示
| 观察 | 不能推出的结论 |
|---|
| 项目是常见类型 | 不能推出能力差或造假 |
| 代码量少 | 不能推出水平低——精简的实现可能更难 |
| 无 star / 无用户 | 不能推出项目没价值 |
| 用了大量第三方库 | 不能推出"没有技术含量"——合理复用是工程能力 |
| 代码有 AI 辅助痕迹 | 不能推出任何问题——这是当前的标准实践 |
| 仓库已归档 / 停止维护 | 完全正常,个人项目大多如此 |
| 一次性大量提交 | 有多种正常解释(迁移、初次开源、squash) |
| 项目跟着教程做的 | 学习方式正当,只看简历描述是否如实 |