前面講了 SSDLC 六個階段各在做什麼，也講了很多人的工具其實都走過這些階段，只是每站都少了點東西。

今天講用 Vibe Coding 開發的時候，這六個階段分別要怎麼套進去。
也有人叫這個 AI-assisted SDLC，意思就是當人工開發變成 AI 開發，中間的安全流程不應該消失。

先說一下，我個人習慣用 Claude Code，所以都以它為例子。換成其他 AI 應該也都有對應的做法。

AI 開發現在百家爭鳴，青菜蘿蔔各有所好，沒有什麼是一定的。但站在我的角色和工作場域來看，公務用途還是建議避開有資通安全疑慮的產品。有人會說用其他的不也一樣？的確差不多，差別只在合規和法律問題，而這兩個剛好是出事的時候最重要的。

主要分兩個步驟

先在 Web 對話把需求釐清。

你打算做什麼、不想做什麼、角色、資料流、開發的規則和要求，反覆推翻重來都沒關係。
這階段討論得越仔細，後面的開發越順、會越符合你要的。

需求釐清了，再定架構。

正式環境是什麼系統？Linux 還是 Windows？開發和測試環境是什麼？這一定要先講清楚，因為它決定了 AI 會用什麼語言幫你寫、環境要裝哪些套件、整個框架長什麼樣。

或許你跟我一樣以前是學C++、組合語言、資料結構，但已經10年沒碰程式撰寫，已經是個 Coding 門外漢。
不清楚在現代用什麼語言、什麼框架、資料存哪、有哪些元件、彼此怎麼接。
這些現在可以靠 AI 先幫你規劃，但建議在這兩個階段做交叉質詢：問了 Claude，拿同樣的問題去問 ChatGPT；Claude 產的文件給 GPT 看、GPT 產的給 Claude 看、也可以丟給 Gemini 或其他的再看一次。

最後你再確認後整理出一份都認為沒問題的開發文件，可能是.md .docs .txt都沒關係，最重要的紀錄專案目標跟需求跟細項。

最後最後一定要記得確認需求。
例如我的目標是收一般使用者做出來的靜態檔案，那功能裡就不該出現任何執行使用者程式碼的地方。

請注意

這兩個階段一定要把你對「安全」的要求講進去，不是只有產品本身的功能。
大概可以分四塊來看：

AI 的行為
AI 可以做什麼、不能做什麼；裝套件要不要先問。
機敏資料
帳密、金鑰放哪、不能放哪；不進程式碼、不進版本控制；搬到正式環境的要求，例如不能跟測試環境相同、要怎麼在正式環境重新產生。
程式碼本身
輸入要驗證、輸出要編碼、權限最小化、不用已知有漏洞的套件版本、不用 eval 和 innerHTML 這類危險寫法、錯誤訊息不吐內部資訊、要有紀錄。也就是安全編碼的基本要求。
程式碼的版本控制
每次改版的紀錄方式，跟如果異常了怎麼恢復每個階段做完就 commit 一次、改了什麼要留紀錄、出問題能退回上一版。

有人說我又不懂資安，這些我都不懂啊。其實只要多問一句：

「在開發這個系統的過程中跟完成後，要如何確保系統安全、程式安全？」

為什麼要講？
有人說現在 AI 很聰明，都會幫我們想好。
指令跟限制越少越好

我只能說：要確欸！

我用到現在我認為是用這樣觀點來看

把它當作一個你新聘的員工，你不把需求說清楚，它想的跟你要的真的會一樣嗎？它會給你一個能動的東西，但過程中想裝什麼就裝、想連哪就連、密碼直接寫在程式裡，因為那樣最快。等到最後產品要上架了，原始碼掃描、應用層弱點掃描跑出一堆紅字，你再回頭改會超級崩潰。

所以這兩個步驟看起來只是在聊天，但聊的內容決定了後面 AI 會怎麼做。
所以我個人認為這階段是最重要的事情

就像去餐廳吃飯。你可能不能只跟服務生說「我要吃東西」，他要知道你想吃什麼、幾個人、有沒有不吃的、會不會過敏、要不要辣、有沒有預算。你講得越清楚，端上來的才越可能是你要的；你只說「隨便」，廚房只能猜，端上來一桌你不吃的，你還怪餐廳難吃。

AI 開發也一樣。你只說「幫我做一個上架平台」，它只能猜。猜出來的東西能吃，但不是你要的，也不一定乾淨，因為你沒說它就不會想到。你把需求、環境、安全要求講清楚，它才做得出你要的那道菜。