Vibe coding：用途與限制

給大家動手開發的空間

企業 CTO 可以協助更多人，把專業知識轉成軟體構想。邀請財務、營運、業務和工程人員參與，提供時間、合成資料、沙箱 API 與支援。

讓大家使用不同工具探索，同時明確規定安裝、帳號和允許輸入的界線。瀏覽器中的開發工具、程式設計助手或本機代理程式，都能協助測試想法。選擇工具，不代表獲准上傳公司資訊或連接真實系統。

公布簡單流程，讓有用原型能交給工程或平台團隊。建立者提供問題、工作流程範例和觀察到的價值，不必因此成為服務的資安與維運團隊。

先確定需要學到什麼

Vibe coding 通常從描述想要的軟體開始。你接受生成的程式碼，再根據看得到的結果，決定下一次修改。這個詞有不同定義；本指南指的是，指導工作的人不一定了解每項實作決策。

這種方式能幫助學習。簡單介面可以顯示核准流程步驟太多，暫時性指令碼可以用來評估檔案格式，原型則提供具體設計供大家討論。即使捨棄程式碼，也能保留這些認識。

先定義一個能觀察答案的問題，例如：「團隊主管能理解這個核准流程嗎？」這個問題範圍明確。要求建立費用管理系統，則還包括資料保護、存取控制、維運和責任歸屬。

星期二做出的銀行應用原型

以下是虛構範例。星期二，財務同事使用 Lovable，以虛構銀行交易建立儀表板。它會分類支出、顯示未付款發票，讓團隊能討論有用的工作流程。

有人提議連接公司的銀行帳戶。即使應用程式仍標為「原型」，後果也已改變。

視 API 而定，讀取權限可能揭露餘額、交易紀錄、客戶名稱或付款參考資訊。如果連線還允許付款，錯誤就可能轉移真實資金。應確認實際權限範圍；銀行連線不一定包含付款權限。

展示不能證明使用者只能查看獲授權的帳戶。隱藏按鈕不會落實權限。OWASP 說明了缺少帳戶或紀錄檢查，如何暴露其他使用者的資料。

在付款 API 中，**等冪性（idempotency）**表示重複請求不會重複產生預期效果。Stripe 記載了一種實作方式。檢查實際服務提供者的行為、限制和重試規則。回復應用程式版本，無法撤回銀行已處理的付款。

這個範例不是 Lovable 有缺陷的證據。Lovable 自身的安全指引要求保護機密值、執行伺服器端檢查、測試資料政策，並持續審查。對任何開發工具、代理程式或人工撰寫的應用程式，都應採用相同證據標準。

連接真實系統前，先檢查存取權

繼續使用合成資料和沙箱帳戶測試工作流程。授予真實存取權之前，請服務、資安和平台負責人驗證應用程式及其執行環境。

使用銀行或服務提供者核准的連線流程。只授予必要帳戶的存取權與必要權限。將私密存取憑證保存在核准的機密值儲存系統，不要放進提示詞或瀏覽器程式碼。需要付款時，明確分配付款核准權限與限額。驗證如何撤銷存取、調查失敗，以及回應可疑活動。

這些決定必須在機密輸入或真實存取憑證進入系統前完成。等到正式發布，可能已經太晚。繼續學習資料邊界與企業基礎設施。

擴大使用前，先定義責任

使用虛構資料的實驗，可以存在很短時間，也可以只供少數人使用。其他人開始依賴應用程式時，就必須定義使用責任。

1. 指定負責人。
2. 確認允許的使用者與資料。
3. 定義失敗時的處理方式。
4. 將原始碼和設定保存在儲存庫。
5. 驗證其他人能檢查並重現系統。

不是每個指令碼都需要企業平台。不涉及敏感資料的個人格式化工具，所需控制比付款核准應用程式少。評估錯誤後果，並檢查能否偵測錯誤及復原其影響。

擴充原型前，區分對問題的理解與實作證據。你可以保留介面、替換內部程式碼，也可以限制預期用途，或讓原型繼續作為暫時實驗。

展示後，仍需規劃弱點處理

成功展示可能掩蓋嚴重的維護缺口。即使程式碼沒有變動，相依項目也可能出現新的弱點公告。發布時的掃描，只描述某個時間點。

如果應用程式繼續使用，就必須有人持續找出、評估並修補弱點。修補必須部署到正式環境，並通過驗證。只有掃描器、沒有回應流程，暴露的風險仍未解決。

檢查實際工具和設定提供什麼。後續的持續弱點管理會說明完整流程，包括掃描失敗和已部署版本。

讓下一次變更容易審查

交給代理程式一項小變更，並明確列出驗收標準。說明它能執行哪些操作。檢查產生的 diff，執行能拒絕錯誤實作的檢查。發布責任明確前，部署應保留為獨立決定。

NIST 安全軟體開發框架說明了更廣泛的安全開發實務。評估缺失控制時，可以拿來參考。你不必背誦框架，而是要在軟體影響他人前，找出缺少哪些證據。