Vibe Coding 包健康审查：按精确版本核对维护、发布与漏洞证据

AI 常用“维护活跃、社区成熟、每周大量下载”解释包选择。这些描述可能过时，也可能把同名 fork、组织迁移或另一个 major 版本的数据混在一起。下载量可被镜像、CI 和机器人放大；最近发布可能只是自动依赖更新；没有已知漏洞也可能意味着没有报告或扫描数据不足。

包健康审查的对象必须是“注册表 + namespace/name + 精确版本 + 制品摘要 + 检查时间”，不是一个显示名。Vibe Coding 官方文档版本锚点要求文档与代码代际对齐；同样，项目主页当前状态不能自动代表锁文件里的旧版本。

先确认包、源码与发布身份

从受控注册表读取版本、dist tag、发布时间、tarball、integrity、repository、license 声明、engines、依赖与维护者元数据。npm view 是查询 npm 注册表元数据的官方命令之一，但输出字段仍是注册表声明，不是独立证明。核对仓库 URL、发布 tag/commit 和 release notes 能否对应；重名、仓库转移、删除后重发或 tarball 无可追溯源码时标为明确风险。

记录当前维护主体与发布权限可见证据：组织账号、维护者集合变化、签名/provenance、2FA 或受信发布机制的公开状态。不能从 Git commit 作者直接推断 registry 发布者，也不能因一个签名有效就跳过 identity policy。编程 Agent 插件供应链审查处理高权限扩展；普通库权限较小，但发布身份与精确制品绑定原则相同。

把健康拆成互不替代的信号

维护信号包括目标分支是否接受修复、issue/PR 是否有分类与回应、版本是否支持当前运行时、弃用和迁移是否有说明、release 是否能从源码构建。不要设置“一月内必须发布”之类通用阈值：成熟小库多年不变可能合理，快速变化的安全解析器半年无响应可能危险。结合项目用途记录为什么某个节奏可接受。

安全信号从 OSV、生态官方 advisory、项目公告和当前锁定版本查询，保存数据库时间与查询结果。OSV 提供漏洞数据 schema 与 API，但任何数据库都可能延迟或缺失；结果为零应写“截至某时未匹配到记录”，不写“无漏洞”。命中后核对受影响版本范围、修复版本、可达代码和临时缓解，不能只按 CVSS 自动裁决业务风险。

OpenSSF Scorecard 等自动检查可以发现分支保护、危险工作流、依赖更新或发布实践线索。分数用于定位问题，不作为单一准入阈值；检查不适用于某种项目时记录原因，也不把“满分”翻译为代码安全。许可证、行为正确性、恶意 maintainer 和未来可维护性仍需其他证据。

兼容信号来自实际探针：目标 Node/浏览器/平台能否干净安装、导入和运行，声明的 ESM/CJS/类型入口是否匹配，peer 与 optional 依赖是否在支持矩阵内。相关 manifest/lockfile 验证复用依赖升级与锁文件兼容门，不因“版本没变”长期复用旧机器的 node_modules。

评估团队能否接住最坏情况

健康不只是上游是否优秀，还包括项目能否在上游失效时继续。记录依赖的业务关键度、暴露面、替代候选、adapter 边界、缓存的精确制品和内部修复能力。一个关键但不可替换、无人理解的包，即使当前活跃也有高集中风险；一个小而冻结、接口窄且可 fork 的包可能更可控。

建立 packageHealthReview：身份摘要、证据 URL/命令、各信号的事实、未知项、项目解释、决定、owner、到期日与触发器。事实和决定分栏，例如“过去 12 个月无 release”是观察，“对本项目不可接受”需要结合未解决兼容问题说明。AI 可以归集材料，不能把 star、commit 数做加权小数产生伪精确排名。

复审由事件触发：新版本/弃用、安全公告、maintainer 或仓库迁移、registry owner 变化、provenance 消失、目标运行时升级、许可证声明变化。定期复审只是兜底。出现信息冲突时先冻结升级，已部署版本按实际风险决定限制能力、替换或内部修复，不自动拉取 latest。

Vibe Coding 假设与未知账本可追踪缺失证据；编程 Agent 的改动验证门保证处置补丁不靠删测试通过。最终可接受结论可以是“证据不足但非关键路径，限时试用”，前提是限制、owner 与退出日期真实执行。

包健康不是给开源项目贴好坏标签，而是判断一个精确制品在当前用途下是否有足够来源、维护、安全与接管证据。把热度降为线索，把未知保留下来，团队才能在 AI 推荐变化时复算决定，而不是反复相信一句“社区很成熟”。