你叫 AI 幫你寫一段程式，它很自然地在最上面加了一行 npm install 或 pip install，裝了某個套件。你看了一眼名字，覺得挺合理的，順手就裝了。
這個動作，每天在全世界的螢幕前發生無數次。問題是，AI 建議你裝的那個套件，可能根本不存在。或者更糟，它存在，但裡面裝的是別人準備好的陷阱。這種手法有個名字，叫 slopsquatting。
AI 幻覺套件名稱是什麼
AI 語言模型寫程式碼的時候，跟寫文章一樣，會「猜」。猜下一個字該接什麼，猜這個功能通常用哪個套件。多數時候猜得很準，因為訓練資料裡看過太多次。但偶爾它會猜出一個聽起來完全合理、命名邏輯也符合慣例，這個世界上卻根本不存在的套件名字。這就是 AI 的幻覺，只是這次它捏造出來的，是一個看起來很正常的安裝指令。
問題不會停在「裝不到東西」這麼單純。駭客也會用 AI，也知道 AI 常常幻覺出哪些名字。他們搶在你之前，把那個根本不存在的名字註冊成真的套件，裡面塞進真正的惡意程式。你的 AI 助理沒有惡意，它只是記錯了名字。可是當你複製貼上那行安裝指令按下 Enter，你裝進電腦或伺服器的，就是駭客早就準備好的東西。
這跟傳統的打錯字裝錯套件不太一樣。打錯字裝錯的情況，套件名字通常跟正牌的差一兩個字母，有心人只要留意拼字就能防。slopsquatting 的假名字完全沒有拼錯，它遵守這個生態系統的命名慣例，聽起來甚至比某些真套件還正常。傳統靠比對相似字串抓可疑名稱的防護機制，常常直接放行。
三個真實案例
先看三個已經被安全研究人員記錄下來的真實案例，讓你知道這件事有多具體，不是紙上談兵。
第一個是 unused-imports。真正的套件叫 eslint-plugin-unused-imports，是前端開發者常用來清理沒用到的 import 語句的工具。AI 常常把名字簡化，直接幻覺出 unused-imports 這個更短、聽起來更順口的版本。有心人搶先把這個名字註冊起來，即使後來被平台列入安全警示，這個假套件被標記之後，每週還是有約兩百多次下載，代表持續有開發者或 AI 代理照著建議把它裝進專案裡。
第二個案例更能說明問題已經蔓延到自動化流程裡。安全研究人員發現一個叫 react-codeshift 的套件，是 AI 把兩個真實存在的工具 jscodeshift 跟 react-codemod 的名字混在一起，幻覺出來的產物。這個假名字的散播管道，不是單一次對話，而是透過 AI 生成的 agent 操作說明檔案，在開發者之間被複製、分叉，一路擴散進兩百多個程式碼倉庫。等於這個錯誤的安裝建議，已經寫進某些團隊的自動化腳本裡，每天都有 AI 代理在嘗試安裝這個從沒存在過的東西。
第三個案例年代稍早一些，但影響範圍最大，拿來當警惕特別有力。真正安裝 Hugging Face 命令列工具的指令，寫法比較長、比較不順口。AI 模型常常自己簡化成一個更短的名字 huggingface-cli。有安全研究人員為了驗證這個風險，把這個名字註冊起來當示範，短短三個月內就累積了約三萬次下載。更值得警惕的是，連一個具規模的開源專案，都在官方文件裡放上了這行照抄 AI 建議的安裝指令，把這個錯誤又往外傳播了一圈。
這三個案例有個共同點。這些假名字都不是誰刻意亂編出來的，而是 AI 在正常運作、正常猜測的過程裡自然產出的結果。攻擊者要做的，只是提前埋伏在那個 AI 特別容易猜錯的位置，等你送上門。
這其實是 Limitation 沒守住
回頭看這件事，正好對應到 DEL 框架裡最常被漏掉的那一格，Limitation。
AI 幫你寫程式的時候，你交辦的往往只有 Direction 跟 Expectation，也就是要它做出什麼功能、長什麼樣子。至於「這個套件是不是真的存在、來源可不可信」這件事，多數人從來沒有把它當成一條需要自己守住的線，只是預設 AI 會幫你把關。可惜 AI 沒有辦法幫你把這道關，它自己就是幻覺的來源。
這跟我在《Vibe Coding 前，我會先幫自己畫三條線》裡講的第一條線邏輯一樣，有些東西不能盲目信任 AI 的判斷，得自己先畫出界線。安裝套件這件事，就是那條線該畫的地方之一。也可以搭配《用 Limitation 守住你真正在意的那條線》一起看，理解為什麼「AI 沒講的地方，它會自己補」這件事，在寫程式碼的情境裡風險特別高。套件裝錯，補上去的不是一句話，而是一段能在你系統裡直接執行的程式。
裝套件前的自檢清單
把這件事變成習慣，不需要你懂太深的技術，只需要在按下安裝指令之前，多花一分鐘做幾個檢查。
第一，查官方 registry 上這個套件是不是真的存在。npm、PyPI 這些平台都有搜尋頁面，打開來看一眼，確認它真的在那裡，不是 AI 憑空講出來的名字。
第二，查發布時間跟下載量。一個真正被廣泛使用的套件，通常有一定的下載歷史，不會是上週才突然冒出來、下載數只有個位數的新面孔。發布時間太新、下載量卻聲稱很熱門，是值得停下來多看一眼的訊號。
第三，查原始碼倉庫。多數合法套件的頁面上會連結到 GitHub 或類似的原始碼倉庫，點進去看看維護者是誰，有沒有其他人在用，issue 區有沒有正常的討論。空空如也，或者完全找不到倉庫連結的，風險就高。
第四，查官方文件出處。真正該用的套件名稱，官方文件裡通常寫得清清楚楚。與其完全相信 AI 講的名字，不如花三十秒回頭對照官方安裝說明，尤其是那種聽起來被「簡化」過的名字，更值得多看一眼。
這四個檢查加起來花不到五分鐘，卻能擋掉絕大多數這類陷阱。
接回上線前的第六問
如果你看過《AI 幫你寫的程式碼，先問這五個問題再上線》那篇，這篇可以當成接在那五個問題後面的第六問。安裝套件前先確認它是不是真的存在、來源可不可信，跟上線前檢查權限、資料、金鑰是同一個層級的自我提醒，只是時間點更早，在你動手寫第一行程式碼之前就該養成的習慣。
AI 讓寫程式的門檻降到史上最低，速度也快到讓人幾乎忘記要停下來確認。可是正是這種「太順了」的感覺，最容易讓人把該畫的線省略掉。裝套件前多看一眼，是成本最低，卻常常被忽略的一條線。
如果你想從頭把 Direction、Expectation、Limitation 這三格怎麼填搞清楚，可以回到 DEL 框架這篇總覽，重新把整個方法論走一遍。
