【初級】Vibe Coding 的第一道防線：為什麼你必須建立 venv 虛擬環境？

一開始玩 Vibe Coding 時，最常遇到的問題之一就是 「環境炸掉了」。

開發時， AI 會幫我們安裝一堆庫（Library）。常見的錯誤是無腦地在全域環境執行 pip install。

很快就會發現，原本運作良好的專案莫名其妙開始崩潰，或是電腦的 Python 環境變成一團理不清的亂碼 (((o (ﾟ▽ﾟ) o)))。

今天我想聊聊一個在開發過程中，如同「飯前洗手」一樣基礎、卻常被忽略的動作：** 建立 venv 虛擬環境 **。

什麼是 venv？想像它是專案的「數位防潮箱」#

簡單來說，venv 是一個獨立的資料夾，它把你的專案與電腦的全域系統（Global System）隔離開來。

把電腦的 Python 環境想像成一間 公用廚房 ：

• 沒有 venv：大家都在同一個流理台上煮飯。你為了做泰式料理買了魚露，結果下一個做完蛋糕的人發現流理台上全是難纏的魚露味，蛋糕就毀了。
• 有了 venv：每個專案都有一個自己的 專屬料理室 。你在裡面裝什麼、灑什麼、搞得再亂，都不會影響到隔壁專案或作業系統。

實戰案例：VoiceVault 的「版本禁區」#

我的 VoiceVault 專案把 Python 版本鎖死在 python 3.10.14。

在開發 VoiceVault 時，核心功能依賴 OpenAI 的 Whisper 模型進行語音轉文字。然而，在實測中我們發現：Whisper 在 Python 3.11 以上的版本存在嚴重的相容性問題 。

如果沒有用 venv，而電腦裝了 Python 3.11 以上的版本，執行 pip install 後，就會因為底層套件編譯錯誤而無法正常使用。

這就是為什麼在 VoiceVault 專案中，必須要：

  # 透過 pyenv 指定特定版本，並搭配 venv 隔離
pyenv local 3.10.14
python -m venv .venv

透過鎖定版本，能確保在處理語音轉文字時，系統是穩定運作，而不被其他程式給干擾。

如果不建立 venv，實際上會遇到什麼慘劇？ 除了上述的版本衝突外，主要還有兩個致命傷：

1. 版本的「諸神黃昏」#

假設你今天請 AI 寫了一個用到 Gemini API 的腳本，AI 幫你裝了 google-generativeai 的 1.0 版本。

隔了一個月，你又寫了一個新專案，AI 說：「嘿！現在有 2.0 版了，比較強！」於是你又 pip install --upgrade 升級了。

結果：當你回頭想執行第一個月的腳本時，它直接死給你看。因為 2.0 版改了語法，原本的程式碼已經不認得了。

2. AI Agent 的「集體幻覺」#

如果你使用的是 Antigravity 或 Cursor 這種強大的 AI IDE，它會讀取你的環境來提供建議。如果你的全域環境塞滿了幾百個互不相干的庫，AI 會開始分不清楚你到底在寫哪一個專案，進而給你錯誤的代碼建議。

這就是我在 【中級】還在手動糾正 AI 嗎？用 .agent 資料夾打造專屬架構師 中提到的「上下文貧血」的另一種形式 —— 環境雜訊過多。

真正的 Vibe Coding：讓 AI 當你的「環境守門員」#

當你開始一個新專案時，不要自己敲指令，直接丟給 AI 這段話：

「這是我要開發的 [專案名稱/功能]。請幫我檢查當前路徑是否已建立 .venv？如果沒有，請直接執行指令幫我建立並啟動。另外，請根據我的需求，主動建議需要『鎖定版本』的核心套件，並產出 requirements.txt。」

為什麼這樣做更強大？ 版本預判：AI 知道某些新套件（如 LangChain 或 OpenAI SDK）版本更新極快，它會主動建議你鎖定在某個穩定版本，避免未來代碼跑不動。

環境一致性：AI 會檢查你的 Python 版本是否符合專案需求。如果你的系統是 Python 3.12 但專案需要 3.10，它會先提醒你，而不是陷你於不義。

完全零手動：在支援執行終端機指令的 AI 編輯器中，你只需要點擊「Run」，環境就搞定了。

從現在起，建立你的開發防護邊界#

如果你現在手邊有一個進行中的小專案，試著檢查一下它是否正跑在全域環境裡。 如果是，現在就嘗試與AI協作，建立一個 .venv，並把那些相容性地雷（像是 Whisper 或特定版本的 SDK）給隔離起來吧！