AI 编程助手很擅长补出看起来合理的安装命令，但“看起来像一个包名”不代表它真实存在、仍在维护，或来自可信维护者。更糟的是，攻击者可能提前注册与热门包相近的名称，等开发者复制模型建议后把恶意依赖引入项目。
把模型建议当作候选，不是命令
安装前先验证包在官方仓库是否存在、维护者是谁、版本历史是否正常、许可证是否兼容、依赖树包含什么。对于内部项目，优先从批准的镜像、制品库或软件目录选择，而不是让开发者直接访问公共仓库。模型回答中的链接和版本号也应被视为待核查信息。
拼写仿冒不只是一两个字符差异。大小写、连字符、下划线、相似 Unicode 字符和组织名伪装都可能造成误导。代码审查应关注新增依赖的来源与用途，而不仅是代码是否能运行。锁文件能固定已解析版本，但不能替代第一次引入时的审查。
在 CI 中建立自动门槛
可以对新增依赖执行允许列表、许可证检查、漏洞扫描、维护活跃度和下载来源验证。高风险依赖要求人工审批；依赖更新通过 PR 提交并产生可复现构建。不要让 Agent 具备直接修改生产依赖清单和推送主分支的权限。
这与“AI 是否会写代码”是两个问题。一个补全能力很强的工具，如果会稳定推荐不存在或不可信的包，仍可能给团队带来昂贵的排障和供应链成本。测试集应加入真实包、已废弃包、虚构包和近似包名，观察工具是否表达不确定性并提供可验证来源。
当模型调用由 top-api.cc 统一管理时，可以记录建议来自哪个模型和提示版本，方便回放误导建议。依赖验证、镜像策略和最终安装权限仍必须由开发工具链独立执行。
审查清单
- 包名、组织和版本是否在官方源存在；
- 是否为相似拼写或 Unicode 仿冒；
- 许可证、维护状态和依赖树是否符合要求；
- 是否经过内部镜像和锁文件固定；
- CI 是否拦截未批准的新依赖；
- Agent 是否被限制在分支和 PR 范围内。
参考资料：软件供应链安全、包管理器安全指南和 AI 编程工具的依赖建议实践。安装命令应在受控环境验证后再进入生产项目。
借助 top-api.cc 保留模型调用元数据，可以提高复盘效率；真正的防线仍是包验证、审批和可复现构建。
Leave a Reply