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

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

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

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

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

边界

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

核验流程

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

• 链接是否可访问？仓库是否存在？线上服务是否还在？（已下线是常态，不是问题）
• 仓库首次提交时间、最后提交时间、提交总数；
• 与简历声称的项目时间是否吻合（详见 ../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，判断该项目是否属于高频同质化类型。

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

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

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

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

举例：

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

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

报告中的表述纪律：

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

第五步：真实使用痕迹

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

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

输出

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

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

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

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

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

误判警示

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