隨著 AI 工具普及，Vibe Coding 已成為開發者的新常態：只要指令正確，就能快速實現想像中的功能。然而，會動不等於穩定，缺乏架構思考的程式碼在面對不穩定的 API 、破碎的配置或極端的使用場景時，往往脆弱不堪。
這正是 Vibe Coding 和 軟體工程的本質區別：前者追求的是當下執行，後者追求的是長期可靠。
Veracode 的研究指出，AI 生成的程式碼中有 45% 潛藏安全缺陷；史丹佛大學的調查更顯示，依賴 AI 的開發者不僅容易寫出低安全性的程式碼，甚至會對這些程式碼過度信任。面對這股浪潮，解決之道在於審查：應將 AI 產出視為起點（草稿），而非終點（完稿）。
資深媒體人與 AI 專家 Corey Noles 近期分享了在 Vibe Coding 時必問的 10 個問題，旨在幫助開發者的思維從「會動就好」轉向專業工程。這些提示詞（Prompts）可以直接應用在 IDE 或 AI 助理中，確保每一行程式碼都經得起現實推敲。
1. 像對待「值班工程師」一樣解釋變更
提示詞：
請總結這次變動了什麼、行為上有哪些差異，以及最糟情況下哪些地方會壞掉。 Summarize what changed, what behavior changed, and what could break.
- 這樣問的原因： 變更的重點不是寫了多酷的功能，而是這段更動會不會讓你在凌晨兩點收到系統報警，如預設值改變、資料庫遷移等。
2. 挖掘隱藏的假設
提示詞：
請列出這段程式碼對輸入值、執行順序、時間、環境變數及外部服務做了哪些假設？ List assumptions about inputs, ordering, time, environment, and external services.
- 這樣問的原因： 「假設」是沉默的未爆彈。例如假設 API 永遠不會超時、假設輸入欄位一定存在、假設系統時間永遠是遞增的。
3. 定義信任邊界與威脅模型
提示詞：
列出此變更的進入點、涉及角色、核心資產、潛在濫用案例與對應的緩解措施。 Entry points, roles, assets, abuse cases, and mitigations for this change.
- 這樣問的原因： AI 生成的 App 往往外表光鮮，內裡卻缺乏對「不信任輸入」的防禦，容易導致權限提升或注入攻擊。
4. 盤點每個入口的權限驗證
提示詞：
請標示出任何缺乏「伺服器端強制控管」（Server-side enforcement）機制的路由。 Flag any route that lacks server-side enforcement for Authn/Authz.
- 這樣問的原因： 這是「Demo 沒問題」變成「個資大外洩」的最常見路徑。永遠不要相信前端傳來的權限狀態。
5. 追蹤不受信任的輸入路徑
提示詞：
資料庫寫入 、Shell 指令、樣板、反序列化、HTML 輸出——請秀出這些流程路徑。 DB writes, shell, templates, deserialization, HTML output—show me the paths of untrusted input.
- 這樣問的原因： 用於追蹤有害和會污染系統的資料流，如果 AI Agent 無法清晰地追蹤出完整路徑，那就是你該進行人工檢查的訊號。
6. 敏感資料的流向監控
提示詞：
哪些敏感欄位被收集、儲存或記錄了？請標出任何可能導致資料過度收集或日誌洩漏的地方。 Fields collected/stored/returned/logged; highlight over-collection and log leakage.
- 這樣問的原因： 寫檢討報告時，很常出現的一句話就是：「我們當時沒發現系統會把密碼/Token 寫進 Log 裡。」
7. 失效模式的處理
提示詞：
說明這段程式碼的逾時設定、重試與退避機制、斷路器和冪等性處理。當外部服務掛掉時會發生什麼？ Timeouts, retries/backoff, circuit breakers, idempotency—what happens when X is down?
- 這樣問的原因： AI 極度擅長寫正常流程，但在面對資料庫連線爆滿或網路波動時，卻常表現得像個新手。
8. 生成證明承諾的測試案例
提示詞：
請生成測試案例，包含：正常流程、關鍵邊緣案例，以及針對每個信任邊界的一個惡意輸入測試。 Generate tests: Happy path + top edge cases + one 'evil input' test per trust boundary.
- 這樣問的原因： 測試是為了留下一張證據，證明程式碼確實履行了它宣稱的功能。
9. 找出維護債，如重複邏輯、不必要的依賴項
提示詞：
建議可重構的重複邏輯，並找出哪些新增的依賴項其實可以被移除。 Suggest reuse/refactors; identify new deps that could be removed.
- 這樣問的原因： 防止專案在 AI 生成過程中因複雜度失控而淪為沒人敢碰的「鬼屋」。
10. 確保部署與觀測的安全性
提示詞：
列出啟動所需的環境變數校驗、遷移安全檢查、必要的日誌監控，以及回滾步驟。 Required env vars validated, migrations safe, logs/metrics exist, and rollback steps documented.
- 這樣問的原因： 上線不代表結束。當出事時，你是否能第一時間發現、第一時間止血，並且事後能解釋事發原因。
如果覺得沒時間測試上面的10個提示詞，那麼在按下部署鍵前，至少先詢問自己以下5個問題：
- 我能否在不依賴 AI 的情況下，清晰解釋這段程式碼的運作邏輯？
- 它會被惡意利用嗎？
- 在超時、重試機制，那些 AI 最常忽略的邊緣案例下，它會掛掉嗎？
- 它在高併發或巨量資料下會崩潰嗎？
- 我能安全地運行它嗎？
下次 Vibe Coding，別在「程式能跑」的那一刻就急著慶功。試著多走一步，追求那份讓工程師睡得安穩的穩定性吧！
延伸閱讀：影片｜Vibe Coding是什麼？3款好用AI工具＋6步驟教學，程式小白上手必懂！ Vibe Coding 很好用，但有「哪些坑」千萬要注意？從一張流程圖看懂隱藏風險
資料來源：The Neuron
本文初稿為AI編撰，整理．編輯/ 黃若彤
