在打開對話框、跟 AI 說「幫我做一個工具」之前，我會先花五分鐘做一件事。畫三條線。
這三條線是寫給我自己看的規則，AI 只是順便照著走。它們決定了接下來這場 vibe coding，我可以放心放手到哪裡，哪裡絕對不能放。很多人覺得這一步麻煩，想著先做出來再說，安全的事之後補就好。我理解這個念頭，但我在對資安要求很高的產業做第一線開發十多年，看過太多「之後補」變成「來不及補」的例子。
底線要畫在動手之前，不是出事之後。這篇就講我畫的這三條線，各配一個匿名化過的真實畫面，讓你知道踩線長什麼樣子。
第一條線：哪些資料絕對不能給 AI 碰
第一條線最直覺，卻也是最容易在趕時間的時候被自己鬆綁的一條。
有些東西，我不會貼進對話框，也不會讓 AI 直接讀取原始檔。客戶個資的原始檔案是一種，金鑰本體是一種，還沒公開的商業數字也是一種。這三類東西有個共同點，一旦流出去，沒有「刪掉重來」這個選項。
我聽過一個案例，一位工程師朋友幫忙處理一批使用者資料，為了讓 AI 幫忙寫清洗腳本，圖方便直接把整份原始 CSV 貼進對話框當範例，裡面幾百筆姓名、電話、地址一次進去。腳本是寫出來了，效率也提高了，但那份資料同時也永久留在了對話紀錄裡，離開了他原本能控管的範圍。他後來才驚覺，光是為了示範格式，其實根本不需要真的資料，隨便造幾筆假資料就夠 AI 理解結構了。
類似的情況我還看過一個更小、但一樣容易被忽略的例子。有人為了讓 AI 幫忙寫一份操作教學，隨手把畫面截圖貼上去，截圖裡剛好露出瀏覽器分頁列，上面掛著好幾個內部系統的網址、帳號名稱，甚至還有一個測試用的密碼提示欄位沒關掉。這幾樣東西單獨看都不算什麼大事，可是拼在一起，就等於幫外人畫出一張公司內部系統的地圖，包括用了哪些系統、帳號命名的邏輯、密碼大概怎麼設。他後來養成一個習慣，截圖前先把不相關的分頁全部關掉，把畫面裡看得到的欄位都檢查一遍，只留下真正要示範的那一小塊。
我的做法很簡單。需要示範資料格式的時候，用假資料。姓名寫王小明、地址寫某某路一段，數字隨便編，只要欄位長相一樣，AI 就看得懂該怎麼處理。真正的原始檔，不進對話框，也不讓 AI 的工具直接連進去讀。金鑰更是連提都不提，這件事之後我還會再講一次。
判斷方法很簡單，問自己一句：這份資料如果外流，我賠不賠得起。賠不起的，就不進 AI 的視野範圍。
第二條線：哪些權限絕對要人工簽核
第二條線討論的是「動作」，跟資料無關。AI 幫你寫程式沒問題，但有些「執行」的按鈕，必須由人親手按下去，不能授權給自動化流程。
刪除正式環境的資料，是一種。對外發送 email，是一種。動到金流付款設定，也是一種。這三件事的共同點是，一旦執行，影響的是別人，而且往往沒辦法悄悄收回。
有個很典型的驚險畫面。有位做自動化的朋友讓 AI 幫忙寫一段清理資料庫的腳本，測試環境跑得很順，效果符合預期。他把同一段程式碼直接搬到正式環境跑，本來以為只是清掉幾筆過期的測試紀錄，結果那段邏輯裡有一個他沒注意到的條件寫反了，一口氣刪掉了一整批正式用戶的紀錄。事後複盤，真正的問題出在他把「執行」這個動作外包出去了，自己沒有在按下去之前再看一眼會發生什麼事。
還有一個殺傷力比較小，但一樣值得記住的例子。有人設定讓 AI 幫忙處理客服信件的初步分類，圖方便，把「判斷完直接自動回覆並寄出」這個功能也一起打開了，想著先跑一陣子看效果再調整。結果某一天，一封語氣其實是在客訴的信件被誤判成一般詢問，AI 自動回了一封制式又冷淡的罐頭訊息出去。對方收到後更生氣，把回信截圖轉發到社群上抱怨。金額上沒有實際損失，但那種「代表你講話」的信任感，一次就扣掉不少，而且沒辦法收回。
我現在的規矩是，凡是會動到正式環境資料、會把訊息發出去給真實的人、或會碰到金流的動作，AI 可以幫我把腳本或流程準備好，但最後那個「執行」的按鈕，一定是我自己的手指按下去，而且按之前一定會問自己一句：這個東西如果跑錯了，後果我能不能承受。
第三條線：哪些事要先想清楚才能動手
第三條線最抽象，也是三條裡最重要的一條。它呼應 DEL 框架裡的 Limitation，動手之前，先想過「這個工具最壞會怎麼壞掉」。
很多人開始 vibe coding 的時候，滿腦子想的都是「它能做什麼」。功能列出來，一項一項讓 AI 生出來，做出來就開心，做不出來就換個問法再試一次。但很少人會停下來問另一個問題，如果這個工具被誤用，最壞的情況長什麼樣。
我自己有過一次教訓。做了一個小工具給合作對象用，方便他們自己上傳檔案。我當時只想著怎麼讓上傳體驗順，AI 也很配合，功能做得又快又漂亮。上線前我照著自己的習慣停下來想了一下最壞情況，才發現沒有任何限制檔案大小和數量的機制。如果有人惡意上傳幾百個超大檔案，儲存空間和費用都會在很短時間內被灌爆。這件事我沒有真的遇到，是因為在動手做之前，先花十分鐘想過這個問題，才把限制加了進去。想清楚跟遇到過，兩者省下的代價完全不同。
還有一種更容易被忽略的情況。有人做了一個串接外部資料源的小工具，AI 寫得又快又順，功能一次到位，測試的時候看起來完全沒問題。上線後才發現，工具沒有設定重試次數的上限，遇到對方伺服器偶爾回應變慢，就一直拼命重試，短短幾分鐘內打了對方伺服器好幾千次請求，等於在完全不知情的狀況下，對別人的系統做了一場小型攻擊。他事後補上一個簡單的重試上限和間隔時間，問題就解決了，只是那次真的把對方系統管理員嚇了一跳，還特地寫信來問怎麼回事。
要問的問題其實很簡單：這個東西如果被最壞心眼的人拿去用，會發生什麼事。如果被完全不熟悉電腦的人亂按一通，又會發生什麼事。想不出答案沒關係，先假設會出事，做一個最基本的擋，再開始寫功能本身。這一步不需要你懂很深的技術，只需要你願意在興奮地開始寫程式之前，先坐下來想五分鐘。
三條線收成一句話
哪些資料不能碰，哪些權限要人親手按，哪些事要先想清楚才動手。這三條線，我每次開始一場 vibe coding 之前都會先在腦子裡過一遍。花不到十分鐘，但省下的是事後可能要花好幾天處理的爛攤子。
畫完這三條線，你才真的準備好動手。真正開始讓 AI 寫程式，一路寫到準備上線，還會遇到更多細節要檢查，那部分我寫在《AI 幫你寫的程式碼，先問這五個問題再上線》裡，是接在這三條線之後的下一步。如果你想更完整理解 Limitation 這格怎麼用在日常任務上，也可以看《用 Limitation 守住你真正在意的那條線》。
