Vibe Coding 新依赖准入：先证明它真的比现有能力更必要

“解析一个 ISO 日期并显示相对时间”交给 AI 后，它可能立即建议安装一个完整日期库；“重试一次 HTTP 请求”又引入另一个包。Demo 很快通过，但仓库因此多出传递依赖、安装代码、许可证、更新通知和退出责任。依赖不是免费的一行 import，也不能因为包真实存在就证明项目需要它。

Vibe Coding 框架与模板选型比较的是项目基础和 starter；本篇只处理一个明确代码依赖的准入决定。结论可以是采用、限范围采用、延后，也可以是使用运行时或仓库已有能力。

先写能力缺口，不写候选包名

用外部可观察行为描述需求：输入范围、输出、错误、性能/体积预算、支持运行时、浏览器或服务端边界、国际化、安全和维护期限。不要写“需要 lodash”或“需要一个好用的校验库”；包名会把问题提前锁成某个答案。Vibe Coding 任务上下文包可承载这些约束和未知项。

从当前仓库查三层现有能力：语言/运行时标准库，已安装直接或传递依赖，内部共享模块。只有传递依赖并不意味着可以直接 import；它可能随上游升级消失，应由真正需要它的 workspace 显式声明。npm explain 能说明某个已安装包为何出现在树中，但“能解释引入路径”不等于“证明业务必要”。

搜索已有调用、重复 helper 和平台 API 后，建立基线方案：不新增依赖时需要多少代码、要承担哪些边界、现有测试能否覆盖。十行代码不天然优于成熟库，成熟库也不天然优于十行清晰实现。密码学、解析复杂格式、时区数据库等高复杂能力通常不应随手自制；一个稳定枚举映射也不应为“以后可能用”引入大包。

用最小纵向探针比较候选

候选集合保持小：现有能力、一个主要包、必要时一个不同权衡的替代。先核对精确注册表、包名和发布者，防止把 AI 生成的相似包名直接安装。每个候选固定版本，在隔离目录或临时变更中实现同一组行为测试，不把候选 API 扩散到业务代码。

探针覆盖正常、边界、非法输入、取消/超时和目标运行时。记录公开 API 复杂度、类型质量、错误语义、tree-shaking/服务端边界、必要配置和测试可替换性。包体或速度只有在当前构建与真实输入下测量才有意义，不引用营销数字，也不为了得出“零依赖更快”虚构基准。

随后展开实际闭包：直接、传递、peer、optional、平台制品和安装脚本。npm 的 dependencies、devDependencies、peerDependencies 等字段有不同发布和安装语义，分类要根据运行需要决定。生产代码需要的包不能藏在 dev 依赖里，纯构建工具也不应默认进入运行镜像。仓库依赖图驱动的改动规划可以计算受影响 workspace 和构建目标，但不替业务 owner 决定价值。

把长期责任放进同一张决定表

采用成本至少包含：版本与运行时支持、维护/漏洞响应、许可证审查、安装/构建执行面、锁文件变化、产物来源、bundle/镜像影响、升级测试和替换路径。AI 供应链安全提供风险全景；这里要求每项落到这个精确包和版本，未知项保持阻断或有 owner 的例外。

决定记录包含 capability ID、需求版本、候选精确版本、探针命令与结果、采用理由、被拒绝理由、允许 import 的模块边界、owner、复审触发器和退出条件。常见触发器包括运行时新增同等能力、包停止支持目标版本、维护身份变化、许可证变化或关键漏洞长期无修复。

证据不足但又需要继续探索时，采用限时试用而不是永久准入：只允许非关键路径和合成数据，禁止生产凭证，固定版本与摘要，设到期日和转正所需证据。到期未补齐时自动移除试验能力；不能因为已有调用方逐渐增加，就把沉没成本当成必要性证明。

准入后把包包在最窄的 adapter/utility 后，业务模型不直接传播供应商类型。测试固定产品需要的行为，不把整个第三方 API 快照成合同。首次加入仍按依赖升级与锁文件兼容门审查 manifest 与 lockfile 原子差分，并通过编程 Agent 的改动验证门运行受影响验证。

若不采用，删除探针和候选 lockfile 变化，保留简短决定，避免下次 AI 重复建议同一个包却不知道过去为何拒绝。若需求尚不清楚，先用显式小实现或接口占位并设复审点，不把依赖当成探索需求的手段。

新依赖的完成标准不是 install 成功，而是能力缺口真实、现有方案已检查、候选按同一行为比较、实际闭包和长期责任有人承担。先证明“为什么需要”，Vibe Coding 的速度才不会被未来每一次升级、安全告警和删除工作反向收取。