project-checklisted

# /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