你有沒有做過這件事，打開 AI 的對話框，打一句「幫我做一個聯絡表單」，按下送出，幾秒鐘後一整包程式碼就出現在螢幕上。看起來很厲害，欄位有了，按鈕也有了，畫面甚至還配了色。你把它貼上網頁，測了幾次，好像能用。但心裡總有個聲音在問，這個東西真的可以放上線嗎，資料填進去以後跑到哪裡去了，我自己也說不清楚。
這種場景現在幾乎每天都在發生。用一句話讓 AI 寫程式，已經是很多人做東西的日常方式，業界叫它 vibe coding。這篇想講的是，這件事快是真的快，但快跟對之間，中間還隔著一段很多人跳過的距離。
快，不保證對
vibe coding 已經是常態了。現在有八成多的開發者，日常工作裡已經在用 AI 編程工具，這個數字還在往上走。像 Claude Code 這類工具的採用度持續上升，企業端 GitHub Copilot 的採用比例也是同類工具裡數一數二高的。這股風潮已經真的滲透進日常工作流程，成為很多人默認的做事方式。
但業界最近也開始出現一種反思的聲音，值得放在心裡。有研究指出，AI coding agent 在自動化的持續整合流程裡，大約有75%的機率，會把原本能正常運作的程式碼弄壞。這個數字聽起來很誇張，但它反映的是一個很實際的現象，AI 寫程式的能力已經很強，強到能一次生出一大段看起來完整的東西，但它對「這段改動會不會影響到別的地方」這件事，判斷力還遠遠不夠。
業界現在比較成熟的講法，是把 AI 當成輔助駕駛。方向盤還是要握在自己手上，尤其碰到安全性、資料存取、商業邏輯這幾塊，一定要停下來自己確認過，才能繼續往前開。
業界其實已經在往「講清楚需求」靠攏
有趣的是，越來越多研究和實務經驗，都指向同一個方向。Microsoft 的開發者工具研究發現，如果提示詞裡包含明確的規格描述，來回修改的次數可以減少68%。這代表一件事，把需求講清楚，能實際省下大量重工的時間。
業界也已經發展出一些類似的做法，像是「Spec-Driven Prompting」，先寫規格再讓 AI 動手，或是「RCTFC」這類框架，把角色、情境、任務、格式、限制拆開來講。這些方法背後的邏輯都一樣，模糊的需求換來模糊的產出，講清楚的需求才換得到能用的東西。
DEL 框架也是同一個邏輯，只是拆得更簡單，方向、期待、限制三格，就算你完全沒寫過程式，也能照著填。接下來用一個具體場景，走一次完整的 DEL。
實際示範：做一個讓客戶填資料的表單
假設你現在要做的東西，是一個給客戶填資料的表單。先看看只丟一句話會發生什麼事。
幫我做一個聯絡表單這句話 AI 當然接得住，也會生出程式碼，但它得自己幫你腦補一大堆沒講的東西。要幾個欄位、資料要寄到哪、填錯了要怎麼提示、資料存在哪裡，這些關鍵決定，全都被 AI 用預設值悄悄補上了，你完全不知道它幫你決定了什麼。這就是為什麼很多人拿到程式碼卻不敢直接上線，因為那些沒講清楚的地方，藏著你根本沒檢查過的風險。
換成 DEL，同一件事會變成這樣。
Direction，先講結果，不要先講動作。
不要只說「做一個表單」，要說清楚這個表單存在的目的和使用情境。
我要一個讓客戶填聯絡資訊的表單，用途是收集客戶的姓名、
email、電話，填完之後系統要能寄一封通知信到我的信箱。
使用者是不懂技術的一般客戶，手機瀏覽器要能正常填寫。這幾句話的重點，是清楚交代做完之後要達成什麼。誰要用、用在哪個裝置、結果要送到哪裡，這幾件事講清楚了，AI 才知道自己在幫誰做事。
Expectation，給範例，不給形容詞。
「做得專業一點」「介面要好看」這類形容詞，AI 沒辦法真的理解你腦子裡的畫面。改成具體的規則和範例。
欄位規則：
- 姓名：必填，文字
- email：必填，要驗證格式對不對
- 電話：必填，只能輸入數字，8到10碼
行為規則：
- 欄位填錯的時候，要在欄位下方顯示紅色文字提醒使用者
- 全部填對按下送出後，畫面要顯示「已收到，我們會盡快聯絡您」
- 送出中按鈕要顯示載入狀態，避免使用者重複按兩次這樣寫出來的規格，AI 不用猜，直接照著做就是你要的東西。同樣是動手做，這次你清楚知道自己會收到什麼，不用等程式碼生出來，才發現裡面藏著一堆你沒檢查過的預設決定。
Limitation，安全底線，先講清楚不能做什麼。
這格是三格裡最容易被跳過，卻也最重要的一格。
安全限制：
- 客戶填的資料不能存在前端程式碼或瀏覽器裡
- 這個表單不能有密碼欄位，如果之後需要密碼功能要另外討論
- 不能直接把資料寫進正式環境的資料庫，先寫進測試環境，
我確認過流程沒問題才會接上正式的沒有這幾句話，AI 很可能為了效率把資料暫存在瀏覽器裡，或是直接幫你接上你根本還沒設定好權限的正式資料庫。這些底線不講，AI 不會主動幫你顧到，它只會照著最省事的方式把功能做出來。
D/E/L 說清楚後，還有一步不能省
把方向、期待、限制都講清楚之後，AI 給出來的程式碼品質會差很多，這是真的。講清楚需求，換來的是「AI 給的東西更接近你要的」，能不能直接上線，還是要另外確認一次。
程式碼寫出來之後，還是要過人的眼睛檢查一次。哪些地方要特別看，我在《AI 幫你寫的程式碼，先問這五個問題再上線》裡整理成一份清單，接在這篇之後看剛好。另外像資料能不能給 AI 碰、哪些操作一定要人工按下去，這些屬於動手之前就該先想好的底線，寫在《Vibe Coding 前，我會先幫自己畫三條線》。
收尾
用一句話丟給 AI，換來的是一堆你沒檢查過的預設決定。用 DEL 把方向、期待、限制講清楚，換來的是一份你自己也看得懂、敢負責的規格。多花的那幾分鐘打字時間，事後省下的重工和上線出包要處理的爛攤子，划算很多。
如果你想完整了解 DEL 框架怎麼用在日常任務上，可以先看《DEL 框架》這篇總覽。想單獨深入 Expectation 這格怎麼給範例不給形容詞，可以看《用 Expectation 講清楚你要的樣子》。想了解 Direction 怎麼從結果反推任務，可以看《DEL 的 Direction：先講結果，不要先講動作》。想知道 Limitation 這格怎麼守住底線，可以看《用 Limitation 守住你真正在意的那條線》。
