通用方法 · 熟练
它写的 import，五个里有一个不存在
幻觉换了落点：从句子搬到了包名
让 AI 写代码的人迟早会撞上这件事：它给你的 import 看起来完全合理，装的时候却告诉你「找不到这个包」。更麻烦的是——这个包名可能已经被别人注册走了，就等着你装。这一页给的是一条三道闸的验收线：第一道在它给完代码之后、你装之前（逐个包名去真实仓库核一次），第二道在装之前（看这个包有没有历史、维护者是谁、最近有没有动过），第三道在跑之前（把「它推荐」与「我要用」分开记）。关键动作只有一个：把「包名」当成为一条独立的事实来验收，而不是当成代码的一部分顺手复制。
方法 · 一图看懂
1
先把包名列出来 — 让它把这一轮代码里所有外部依赖单独列一张表（包名 + 用途 + 是谁写的），⛔ 不接受「混在代码里我自己看」
2
逐个去真实仓库核 — 每一行都去对应生态的官方检索页搜一次：存在 ⇒ 记维护者与最近更新时间；不存在 ⇒ 当场标红，不进安装步骤
3
存在也要看「像不像」 — 有个历史、有维护者、近期有提交才算过关；只有名字对但内容空、或首页写着「同名占位」的，按不存在处理
4
分成两栏记账 — 「我确认要用的」与「它推荐但我还没核的」分开放；后者永远不进自动化安装脚本
原理 · 为什么有效
幻觉的形态会跟着你使用它的方式搬家。你让它写句子，它编的是事实；你让它写代码，它编的是名字 —— 而名字比事实更危险，因为名字能被注册。语言模型生成包名时走的是「这个位置该出现一个什么样的字符串」，不是「这个字符串指向哪个真实项目」；两者在大多数时候重合，所以它大多数时候是对的，这正是它危险的地方。⇒ 所以这条方法不试图判断「它这次对不对」，而是把验收动作固定成一个与模型能力无关的步骤：任何外部依赖，装之前都要有一次独立的存在性核对。核对成本是几秒钟，不核的成本是一次供应链事故。
适用场景
适合谁：用 AI 写脚本 / 小工具 / 自动化的人 —— 尤其是不熟这个语言生态、看到 import 就顺手装的人。不适合谁：你已经在用锁文件（lockfile）并从私有仓库安装、且所有依赖都由人审过 —— 那种流程里这条已经不是薄弱点；以及纯前端零依赖的单文件页（没有外部依赖可核）。
自测 · 5 问
这一轮的外部依赖有没有一张独立清单，而不是散在代码里
每一个包名有没有在对应生态的官方检索页里被搜过一次（不是靠记忆认出来）
搜到的那个包有没有历史、有没有明确维护者、最近一年有没有动过
有没有把「同名但内容可疑」的包与「不存在」的包分开标（两者的处置不同：前者是换一个，后者是根本不用）
自动化安装脚本里，有没有混进「它推荐但我没核过」的包
怎么上手 · 验证步骤
最快的一次上手：把你最近一次让 AI 写的脚本拿出来，只做一件事 —— 把 import / require / dependencies 里的外部包名逐个搜一遍。但凡有一个搜不到，你就已经省下了第一次事故。做完这一步，再把「装之前先搜一次」写进你让 AI 写代码的那段固定指令里。
收口只问一个数字：这一轮我搜了几个包名？ 包名数 = 我搜过的次数，才算过了这一关；如果代码里有 6 个外部包而我搜了 2 个，那这一轮仍属未验收。