跑不起來的假 import 反而好抓；怕的是看起來像真的、但 API 被它腦補。
你昨天用 coding-AI 寫的東西，今天才發現結果不對
你叫 coding-AI 工具寫一段 Python / Node.js 小腳本，拿來畫圖、爬資料、串 API，一秒就生完。你心想：哇，這不就省半天。結果一跑，跳出 `ModuleNotFoundError`。再回頭看上面三行 import：一個 PyPI 根本沒有，一個 npm 搜不到，一個名字看起來像官方套件，但其實早就改名。AI 還很淡定，像剛剛不是它凸槌(hallucination,AI 一本正經亂講)亂掰的一樣。
為什麼它會掰得這麼自然？
結論先講：coding-AI 不是套件管理器，也不是官方文件搜尋器。它比較像「看過很多程式碼的人」，會根據前後文猜下一個看起來合理的 import。問題是，套件命名本來就很像咒語：`openai`、`google-auth`、`@something/sdk`、`python-dotenv`，差一個 dash、底線、命名範圍(scope)，結果就差很遠。
假 import 其實是比較好抓的凸槌(hallucination,AI 一本正經亂講)。Simon Willison 提過一個很實際的觀察：假套件這種凸槌(hallucination,AI 一本正經亂講)不是最危險的，因為多半一跑起來就爆。更麻煩的是「套件是真的，但方法名稱(method)、參數、回傳格式是 AI 腦補的」，程式可能跑過一次，到了線上服務(production)才開始怪怪的。
所以別把重點放在「AI 怎麼又騙我」。比較有用的判斷是：這個 import 有沒有可驗證來源？版本是不是還活著？AI 用的 API 是現在版本支援，還是它從舊文章、舊文件、相似套件裡拼出來的？
它通常會用 3 種方式混進來
第一種：名字很像真的。Python 常見是 dash / underscore 互換，Node.js 常見是命名範圍(scope)被亂加，例如看起來像 `@vendor/client`，但官方其實叫另一個名字。AI 不是故意整你，它只是選了一個「語意上很合理」的名字。合理，不等於真的存在。
第二種：套件是真的，但已經改名或已停用(deprecated)。你問它寫「串某服務的 SDK」，它可能拿舊版範例給你，import 還存在，但 README 第一行寫著已停止維護。這種最煩，因為安裝可能成功，直到你照它的方法(method)呼叫，才發現文件對不上。
第三種：官方文件連結也會被掰。AI 可能丟一個看起來超正規的文件網址(docs URL)，路徑、版本號、頁面標題都像真的。點開是 404，或是導到舊版文件。這時候不要跟它爭辯「你剛剛不是說官方嗎」，直接用搜尋和套件登錄庫(registry)查，省血壓。
今天就能補穩的 4 個動作
第一步，先查套件登錄站(registry)，不要先貼進專案。Python 看 PyPI，Node.js 看 npm，順手確認下載量、更新時間、維護者(maintainer)、README。不是說下載量少就不能用，而是你至少要知道它是冷門新套件、已停更套件，還是 AI 掰出來的空氣套件。
第二步，把匯入(import)拆成「套件名」跟「使用方式」兩件事驗證。安裝成功只代表套件存在，不代表 AI 給的 API 用法是對的。用最小腳本測一個方法(method)：建立客戶端(client)、呼叫一個最簡單的函式、印出回傳。不要一開始就把它塞進整段流程裡，錯了會很難拆。
第三步，看到陌生套件就叫 AI 附來源，但別只看它附的來源。你可以直接問：「這個套件的官方套件登錄站(registry)連結、目前版本、對應匯入名稱(import 名稱)是什麼？」然後自己點開查。AI 回得越自信，越要做這一步。自信不是證據，只是語氣。
第四步，把版本固定住，並把替代方案寫在旁邊。確認可用後，在 `requirements.txt`、`pyproject.toml`、`package.json` 裡固定版本範圍。旁邊留一行註解或文件：為什麼用這個套件、官方文件在哪、如果已停用改用哪個。未來你或同事回來看，不會再被 AI 重新帶去另一個平行宇宙。
拿走的一句話
看到可疑的 import，先去套件登錄庫(registry)查；確認是真套件，再查 API。別讓「看起來合理」的名字，直接變成專案依賴。
