在阿里云开发者社区分享一套开源组件选型的尽调方法：在引入任何 GitHub 项目之前，用六个维度做结构化核查，每个维度给出明确的问题、证据来源和判断要点，把选型决策从"看 star 拍脑袋"变成"看证据做判断"。
一、为什么选型需要尽调流程
技术选型引入一个开源项目，实际是在引入一份长期依赖：它的维护状态、安全基线、社区健康度都直接影响下游系统。而现实中的选型决策往往依据转述信息——"据说很火""听说官方出品"，这些说法无法追溯也无法验证。尽调方法论的起点是：只相信可实时取证的证据。
二、六维核查流程（附证据来源清单）
环节一：存在性与官方性核查
要回答的问题：仓库是否存在？归属谁？是官方还是仿冒？是否归档？
证据来源：仓库详情接口（owner 类型、archived 字段）、owner 用户信息接口（Organization 或 User）。
判断要点：官方组织账号与同名个人账号必须区分，这是仿冒识别的关键。
环节二：上线时间与迭代活跃度
要回答的问题：何时创建？最近是否仍在推送？版本发布节奏如何？
证据来源：created_at / pushed_at 字段、提交记录采样、release 与 tag 列表。
判断要点：用"创建于 X，最近推送于 Y"的句式给出活跃度结论，比"应该还在维护"可信得多。
环节三：安全基线核查
要回答的问题：开源协议是什么？有无安全策略？依赖清单是否可查？有无已知漏洞？
证据来源：license 字段、SECURITY.md 是否存在、依赖清单文件（package.json / pyproject.toml 等）、安全公告接口。
判断要点：区分"仓库自身配置"（有无协议、有无安全策略）与"外部漏洞事实"（公告、CVE）；未查到公告时如实标注"未查询到"，不等于"没有漏洞"。
环节四：功能与技术栈
要回答的问题：它到底能做什么？语言构成如何？
证据来源：仓库描述与 topics、语言构成接口（按字节统计，比自述真实）、README、根目录结构。
环节五：社区健康度
要回答的问题：star/fork/watcher 数量？issue 活跃度？贡献者规模？
判断要点：star 必须结合项目年龄解读——同样的数字，爆发期项目和长尾项目含义完全不同。
环节六：元数据归档
要回答的问题：默认分支、仓库体积、主页等基础信息是否齐全。
判断要点：元数据本身不决策，但缺失或异常（如默认分支为空）往往是风险信号。
三、实战案例记录
以一个 AI Agent 记忆类项目（vectorize-io/hindsight）为例，2026-09-26 实测核查：真实存在、Organization 归属、MIT 协议、有 SECURITY.md；创建于 2025-10-30、最近推送 2026-09-25、累计 20 个 release、近三天采样 100 条提交；29853 star 结合不到一年的项目年龄判断为高活跃爆发期；语言构成 Python 为主、含 TypeScript 与 Rust。整个核查约 10 分钟完成。
四、方法论沉淀（可复用清单）
· 核查顺序固定：存在性 → 官方性 → 迭代 → 安全 → 功能 → 评价；
· 每个结论必须附带证据来源与采集时间；
· 事实与推断分开表述：API 返回的是事实，"靠不靠谱"是推断；
· 报告里保留"核查局限说明"：速率限制、权限缺失、待验证项。
· 工程化落地：把端点查询封装为脚本后挂载到对话式 AI Agent（笔者使用 AiPy）作为专项技能，核查流程即可按需自动执行。
五、小结
这套六维尽调流程的本质，是把选型决策的证据链补齐。配合 AI 编程助手把端点查询做成脚本模板，单项目核查成本可以压到 10 分钟以内，建议纳入团队的技术选型 SOP。
