AI 生成的依赖名看起来像真的，并不意味着包存在；包存在，也不意味着它提供代码正在调用的接口。依赖真实性审查至少要区分三个问题：名称与版本能否找到，来源是否符合项目要求，所需 API 是否确实可用。
以一个 TypeScript 的 CSV 导入功能为设计场景。助手新增了某个解析库，并写出 parseRows() 调用。审阅者不应只检查 package.json 里有没有依赖，还要确认锁定版本的公开导出、模块形式和运行时要求。
报告写事实来源
可要求每个新增依赖提供以下证据：包名、精确版本、使用位置、对应版本的官方文档入口、锁文件条目，以及接口核对方式。若包来自企业镜像或私有仓库，来源必须按项目配置解释，不能默认公开注册表是唯一正确来源。
npm 的只读元数据查询可以帮助确认注册表返回的版本与字段。示例中的变量应先由受控任务输入提供：
npm view "$PACKAGE@$VERSION" version engines exports --json
查询成功说明注册表返回了元数据，不表示包已完成安全审查，也不证明所有声明与运行行为一致。无法访问私有源时，应写明未验证，不要改查同名公开包来冒充确认。
三道核对彼此独立：元数据回答“找到了什么”，锁文件回答“项目将解析什么”，接口验证回答“代码实际需要什么”。
对照锁文件和使用点
package.json 通常表达版本范围，锁文件记录解析结果。审查时比较新增直接依赖与相关间接依赖，解释为什么锁文件发生变化。若只是一个导出器修复却更新了大量无关包，不能用“自动生成”作为充分理由。
接着查看使用点。文档中只有默认导出，生成代码却使用命名导入；示例属于另一主版本，代码却锁在旧版；浏览器 API 被放进服务端路径。这些情况都可能在“包确实存在”之后出现。
验证范围写准确
类型检查可以发现一部分接口不匹配，但动态路径、可选依赖和运行时环境仍需合适的验证。一个最小调用应使用合成输入，检查输出形状与错误行为，避免为了验证依赖而连接真实业务系统。
不要在报告里杜撰维护者身份、下载趋势或漏洞结论。来源文档没有提供的信息就保持未知。若任务没有授权安装新依赖，先保留审查结果和可替代方案，不能把审查流程变成自动安装流程。
最后把“名称已确认”“接口已确认”“环境验证未完成”等事实分别记录。一个总的“依赖正常”会掩盖仍未处理的条件。
参考：npm view、package-lock.json。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/2401_83508463/article/details/169835593
