程式能跑不等於穩定！Vibe Coding時必問的10個問題：完整提示詞一次收|數位時代 BusinessNext

隨著 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個問題：