结对写代码时，AI 很爱给一种“干净解法”：装一个库，三行调用，问题消失。有时这确实是正道；有时则是把一个五分钟能写完的小函数，换成十年后还要付账的依赖。
我吃过亏：当时图省事装了包，后来发现维护停滞、传递依赖一堆、许可证也不理想。卸载比安装痛。所以现在但凡 AI 说“建议安装某某”，我会先走一套很短的查验，再决定装不装。
先问自己：这是能力缺口，还是懒得写
查验的第零步不是搜包，而是判断需求本身。
若是加密、图像处理、成熟协议实现——自己造轮子风险更大，倾向用维护良好的库
若是拼接查询字符串、简单重试、薄封装——先看标准库或现有工具能不能扛
我会明确问 AI：“不用新依赖，用标准库怎么写？代价是什么？”它若给不出合理的无依赖方案，只是单方面推销某个包，我反而更警惕。安装是选项，不是默认。
图：第零步：能力缺口还是懒得写——用库 vs 无新依赖（原创示意图）
查验清单：我实际看的几项
清单不长，通常十分钟内能过完。过不完就先不装，改用手写或已有依赖。
1. 是否还在维护
看最近发版时间、issue 响应、是否声明停止维护。不是追求每周一更，而是确认没进“名义开源、实际无人理”的状态。AI 推荐的包有时是它训练期里的“明星”，现实里可能已经冷了。
2. 版本与兼容
锁定它建议的版本是否和当前语言/框架主版本相容。我会自己打开发布说明，扫 breaking change，而不是只听“装最新就行”。最新不等于最合适。
3. 传递依赖与体积
看依赖树深度、有没有重复引入大型框架。前端尤其明显：一个“小工具”可能拖进半个生态。后端则要小心悄悄引入的 native 绑定或重型运行时。
4. 许可证
商业产品或对公司合规敏感时，GPL 系、不清晰许可证、附加字段限制，都要提前看。AI 很少主动提醒这一条，除非你问。
5. 安全与名声
至少扫一眼是否有已知高危漏洞记录、是否同名抢注风险、下载量是否异常到可疑。我做不到专业审计，但能避开最粗的坑。
6. 可替换性
假设半年后要换掉，调用面是否被包在一层适配里？若业务代码到处直接 import 具体厂商 API，将来迁移成本会爆。
图：装依赖前短清单：维护、版本、传递依赖、许可证等（原创示意图）
怎么跟 AI 对话，才不容易被带偏
我常用的提问模板是：
“列出不引入新依赖的三种做法，并给代价”
“若必须用库，给两个候选，对比维护状态、许可证、包体积、API 稳定度”
“假设我们选 A，写出最小调用示例和我需要自己 wrap 的边界”
注意第二点：我要两个候选，不要一个。单一推荐最容易变成权威口吻。有对比，我才能问“为什么不是 B”。
它若开始用“业界标准”“最佳实践”压人，我会要求：“请指出具体依据，比如官方文档某节或该库 README 的适用场景；没有依据就标成推测。”很多推销话术经不起这一问。
试装也要可控：先沙箱，再进主工程
决定“值得试”之后，我也不会直接在主分支 install。习惯是：
新分支或临时目录做最小复现
锁文件进版本库，避免“我这边能跑”
写一个五分钟可删的 spike，验证 API 是否真如宣传般简单
满意后再正式引入，并补一层薄封装（若调用点会扩散）
AI 生成的安装命令，我还会盯一眼是否包含多余的全局参数、奇怪的 registry、或把调试包装进生产依赖。命令本身也要审，不只是包名。
几个我会直接说“不”的信号
为了省十几行代码引入重型框架级依赖
推荐的包近一年无提交，且 issue 堆着明显断更信号
功能与现有依赖高度重叠，只是 API 更“好看”
需要我在业务里到处散落它的注解/魔法配置，入侵性过强
说不清许可证或要求额外商业授权却含糊带过
有一次它建议用某个“全能工具包”处理一个很窄的格式转换。我对了维护记录和依赖树，最终自己写了四十行。四十行我读得懂；那个包我读不完。
图：直接说不的信号：重型依赖、停更、重叠、入侵、许可证含糊（原创示意图）
装了之后：把“为何装”写下来
查验通过并合并后，我会在 PR 或模块 README 留一句极短的理由：选了谁、相对谁、主要风险是什么。这不是形式主义，是给未来卸载或升级的人留地图。
若是 AI 强烈推荐、我半信半疑但业务要赶工，我会标成“临时引入，到期复习”。到期日可以是下个迭代。没有到期日的“临时”，最后都会变成永久。
和“安全左移”的一点关系
供应链问题近年被谈得很多。我没有能力在每次加依赖时做完整 SBOM 审计，但个人最低线是：
不装来路不明的包
不关锁文件
不在不知情时扩大依赖面
对 AI 的安装建议保持默认怀疑
这些做不到“绝对安全”，但能明显减少“随手装、长期悔”的次数。Agent 若有自动执行 install 的权限，这条还要再收紧：安装类动作进人类确认点，下文另写。
收尾
AI 建议装新依赖时，我的顺序是：
先问有没有无新依赖方案
用短清单查维护、版本、传递依赖、许可证、安全信号、可替换性
要两个候选，逼出对比
沙箱试装，命令也审
正式引入时留下“为何装”
先查版本与维护，再决定装不装。 安装只要几秒，卸载和背债往往按年计。让 AI 出主意可以，签字装进主工程的人，还是得是我。
和“生成代码”比，依赖建议为何更危险
生成错一段业务代码，删掉重来通常还行。错误依赖则可能：
锁进传递漏洞
污染全公司的私服缓存叙事（“我们一直在用”）
让后人以为“这是标准答案”而继续扩散调用
所以我对 AI 的依赖建议，审查严格程度高于普通代码草稿。代码草稿是内容，依赖是结构；结构错了，内容再漂亮也贵。
问 AI 时我还会追的细节
除了两个候选，我常追问：
这个包的核心维护者是个人还是组织？个人维护不一定差，但单点风险要心里有数
是否有官方或基金会背书？没有也不等于不能用，只是权重不同
API 是否频繁大改？看大版本节奏，不看星标数
是否和现有日志、指标、错误处理风格合得来？合不来就会出现第二套惯例
星标数我看，但不当主证据。星标会骗人，发版记录和 issue 质量更实在。
内部包与公共包一视同仁
有人觉得“内部二方包就免检”。我不同意。内部包同样可能停更、同样可能许可证不清（比如从外部拷了代码没声明）、同样可能传递依赖失控。AI 若建议“用公司内部的某某组件”，我一样走清单，只是多问一句：文档和负责人是谁，出问题找谁。
拒绝之后怎么继续推进
查验失败不等于需求失败。常见出路：
手写最小实现，标注技术债与触发“再评估依赖”的条件
用已有依赖的另一组 API 拼出来
把需求降级：先不做完美，做能上线的窄路径
我会让 AI 帮我走这三条的草稿，但“装包”这条路暂时关掉。关掉之后它有时会突然变得更会写代码——说明之前那条路太好走了。
记录模板（我贴在 PR 里的）
依赖：package@version
候选对比：A vs B（链接）
选择理由：……
许可证：……
传递依赖风险：……
卸载条件：若 …… 则考虑替换
写不满也没关系，写过就比没写强。未来的你会感谢现在的三分钟。
小结再强调一次
AI 让“装个包”变得像聊天一样轻。工程上它依旧该是重决策。先查版本与维护，再决定装不装——这句话我会反复对自己说，尤其是赶工的晚上。
2026-10-14鱼鱼