选型开源组件时，"据说这项目很火""听说不维护了"这类转述信息真假混杂。本文给出一套可落地的核查方法：只用 GitHub REST API，对一个项目做六个维度的实时取证，把"传闻"变成"有据可查的事实"。
一、核心原则：不猜，去查 大模型对具体仓库的记忆往往过时甚至混淆，star 数、提交记录、安全公告都在实时变化。所以核查的第一原则是：任何事实性结论都必须来自本次实时 API 查询，并标注采集时间。
二、六维核查框架
- 存在性：仓库真的存在吗？归属官方组织还是同名个人？是否已归档？
- 上线与迭代：何时创建？最近还在推送吗？发过多少版本？
- 安全与漏洞：什么协议？有无安全策略？依赖清单？安全公告？
- 功能：能做什么？技术栈构成？目录结构？
- 评价：star/fork 结合项目年龄看，开放 issue 多不多？
- 元数据：语言、体积、默认分支、主页。
三、关键 API 端点与取证要点
- 仓库基本面：GET /repos/{owner}/{repo} 返回 created_at（创建时间）、pushed_at（最近推送）、license、archived、stargazers_count 等，一个请求就能拿到存在性、上线时间、协议与活跃度的基础证据。
- 官方性判定：GET /users/{owner} 重点看 type 字段是 Organization 还是 User。官方组织账号（如 microsoft、Tencent）与同名个人仿冒账号是两回事，这是识别仿冒仓库的关键一步。
- 迭代活跃度：GET /repos/{owner}/{repo}/commits 和 /releases 采样最近提交的时间分布，加上 release/tag 列表，能判断项目是"持续迭代"还是"只挂不更"。
- 安全取证：GET /repos/{owner}/{repo}/security-advisories 注意：这个端点对匿名请求常返回 404/403，需要设置 GITHUB_TOKEN 提升权限。另外检查根目录有无 SECURITY.md（/contents/SECURITY.md）。
- 技术栈：GET /repos/{owner}/{repo}/languages 返回各语言字节数分布，比 README 自述更真实。
四、实战案例：vectorize-io/hindsight 核查结果
用上述方法对一个 AI Agent 记忆类项目做完整核查（采集时间 2026-09-26），关键证据： · 存在性：真实存在，归属 vectorize-io 组织（Organization 类型），未归档； · 迭代：创建于 2025-10-30，最近推送 2026-09-25，近三天采样 100 条提交，发布 20 个版本（最新 v0.10.1 @ 2026-09-21）——高频活跃； · 安全：MIT 协议，有 SECURITY.md，依赖清单含 package.json 和 pyproject.toml（可进一步做依赖漏洞扫描），安全公告查询受限未查到； · 评价：29853 star、3155 fork、129 个开放 issue——注意项目上线不到一年，这个 star 增速属于爆发级； · 技术栈：Python 为主（约 22.7MB），TypeScript 次之，含 Rust 组件。
五、三个容易踩的坑
- 无公告 ≠ 无漏洞：没查到安全公告只能说明"未查询到"，不能说"确认安全"；
- star 要结合年龄看：上线 3 个月 7000 star 和上线 5 年 7000 star，含义完全不同；
- 警惕同名仿冒：搜索时可能命中同名个人仓库，务必核对 owner 类型。
六、小结 六维核查的本质是用 API 取证替代道听途说，10 分钟就能完成一个项目的尽调。笔者已把这套流程封装成自动化脚本，并挂到对话式 AI Agent 工具 AiPy 里做成专项技能，现在一句话就能跑完全流程并生成带证据链接的报告，建议把端点清单存成脚本模板，选型时直接复用。
