用 AI 做產品，要依序過五關：需求探索與價值定義、體驗設計與視覺化、工程開發與架構建立、品質管控與上線部署，以及維運、成長與數據分析。AI 幫忙最多的是第三關，也就是把設計變成會動的程式；其他四關仍然要由人決定做什麼、做到什麼程度算完成、出事時誰負責。這篇文章把軟體開發生命週期整理成這五關，說明每一關要回答的問題，以及 AI 能做和人必須做的事，最後提供一份給非工程師的上線前檢查表。
軟體開發生命週期是什麼？
軟體開發生命週期（SDLC）是團隊設計並建置軟體的流程；AWS 將它分成規劃、設計、實作、測試、部署與維護六個階段。
AWS 的說明把軟體開發生命週期定義為團隊用來設計並建置高品質軟體、兼顧成本與時間效率的流程，並列出六個階段：規劃（估算成本與資源、整理需求成規格文件）、設計（選擇技術方案與工具）、實作（寫程式）、測試（自動與手動測試找出錯誤）、部署（把測試過的版本移到正式環境），以及維護（修正錯誤、處理客戶問題、監控效能與安全）（AWS，What is SDLC）。
美國國家標準與技術研究院（NIST）的《安全軟體開發框架》（SSDF，SP 800-218）則指出，安全的開發做法通常要加到每一種開發流程模型裡（NIST，2022 年 2 月）。也就是說，安全不是最後才補的一關，而是每一關都要有的事。
本文把這個流程歸納成五關，並用蓋房子來比喻：AI 像一台能把設計圖直接列印成建築的 3D 列印機，扛下搬磚與灌漿的苦力活，但你還是那位決定房子要蓋給誰、長什麼樣、要不要交屋的建築師。
五關各自要回答什麼問題？
五關各回答一個問題：產品值不值得做、使用者用起來順不順、系統怎麼建、能不能安全上線，以及上線後怎麼持續成長。
| 關卡 | 要回答的問題 | 蓋房子的比喻 | 對應 AWS 階段 |
|---|---|---|---|
| 一、需求探索與價值定義 | 誰會付錢？為什麼需要？解決什麼痛點？ | 這個案子值不值得蓋、賣給誰 | 規劃 |
| 二、體驗設計與視覺化 | 使用者第一次看到會不會想留下？操作順不順？ | 規劃格局與動線 | 設計 |
| 三、工程開發與架構建立 | 怎麼把設計變成會動的系統：前端介面、後端邏輯、資料庫 | 正式施工 | 實作 |
| 四、品質管控與上線部署 | 會不會當機？大量使用者同時用會不會崩潰？有沒有資安漏洞？ | 驗屋與安全測試 | 測試、部署 |
| 五、維運、成長與數據分析 | 上線後怎麼根據數據優化流程、推出新功能、降低流失？ | 物業管理與增值經營 | 維護 |
第一關沒想清楚，後面所有投入都可能變成成本；第四關省略，後續修繕的成本通常更高。
AI 能幫你做哪幾關？哪些必須由人決定？
AI 在第三關能做最多，其他四關它能協助整理、草擬與檢查，但優先順序、驗收標準與責任歸屬，仍然必須由人決定。
下表是我的整理，不是 AWS 或 NIST 的內容。其中部分做法有 Anthropic 的 Claude Code 官方文件佐證，已標明來源。
| 關卡 | AI 可以協助 | 必須由人決定與負責 |
|---|---|---|
| 一、需求與價值 | 反問你規格、整理成文件；官方文件建議可以請 Claude 先訪談你、再寫出完整規格檔，之後開新對話照規格實作（Anthropic，Best practices） | 做不做、先做什麼、目標客群與付費意願 |
| 二、設計與視覺化 | 產生畫面草稿、調整版面 | 品牌風格、使用者流程是否真的順手 |
| 三、開發與架構 | 寫前後端、資料庫與串接 | 架構是否能撐住未來的變更、資料怎麼存 |
| 四、驗收與上線 | 撰寫與執行測試；官方文件建議一律給 AI 可執行的驗證，無法驗證就不要上線（Anthropic，Best practices） | 什麼叫通過、能不能對外、權限與資安責任 |
| 五、維運與成長 | 查紀錄、彙整異常、分析使用數據；官方文件建議用命令列工具查外部服務（Anthropic，Best practices） | 看到數據後要改什麼、要不要下架或重做 |
每一關都有人必須承擔的決定。AI 做得越多，人越需要把「怎樣算完成」寫清楚，因為 AI 只會做被明確說出的事。
上線前的檢查表有哪些？
上線前至少要確認五件事：需求與驗收條件已寫下、畫面經真人試用、資料與權限已檢查、測試能重複執行，以及有人負責維運。
下表是我的整理建議，適合沒有工程背景、要把 AI 做的工具交給同事或客戶使用的人。
| 關卡 | 上線前要能回答的問題 |
|---|---|
| 一 | 這個工具給誰用？做完怎麼判斷成功？驗收條件有沒有寫下來？ |
| 二 | 至少兩位沒參與開發的人試用過嗎？他們卡在哪裡？ |
| 三 | 資料存在哪裡？金鑰與密碼是否沒有寫在程式碼裡？程式碼有沒有版本紀錄可以回復？ |
| 四 | 有沒有一組可以重複執行的測試？權限是否只開給該看的人？公開網址放得下這份資料嗎？平台的使用條款允許公司用途嗎？ |
| 五 | 出錯時誰看紀錄、誰修？用什麼數據判斷這個工具有沒有被使用？ |
上線前檢查表不會讓產品保證沒問題，但能擋住最常見的情況：程式寫完、卻沒有人能上線、沒有人能維護。
本分類的案例，各自卡在哪一關？
本分類的案例分別卡在不同關卡：有人卡在上線前的檢查，有人卡在開發中的修不好，有人卡在需求在人與人之間走樣。
以下只標示每個案例對應的關卡，完整經過請看各篇文章。
| 對應關卡 | 案例與重點 |
|---|---|
| 一、二 | 社工先做出原型，再交工程師整合：用原型取代文件溝通，需求與設計在同一個東西上確認 |
| 三 | 需求分析師用 AI 做出完整網站：開發途中修不好、跑版與改壞功能時的處理 |
| 四 | AI 一天寫完工具，為什麼上線卻卡了近一個月？、法律背景者用 Lovable 做合約系統：部署、平台條款與敏感資料的檢查 |
| 四、五 | 一人公司用 AI 做產品：測試、營運紀錄與取捨 |
| 整體 | Vibe Coding 是什麼？：先釐清定義與適用範圍 |
常見問題
軟體開發生命週期一定是五個階段嗎？
不是。AWS 的說明列出規劃、設計、實作、測試、部署與維護六個階段，不同組織的分法也不同。本文的五關是我為了好記，把它整理成需求、設計、開發、驗收上線與維運成長。
用 AI 寫程式，可以跳過需求與設計嗎？
不建議。AI 能很快做出東西，但需求不清楚時，做得越快，偏離越遠。官方文件也建議先把規格寫清楚，再讓 AI 實作。
非工程師最容易漏掉哪一關？
第四關。程式能在自己的電腦上跑，不代表能讓同事使用，也不代表資料與權限已經檢查過。上線前的檢查表就是為了這一關。
安全是最後才做的一關嗎？
不是。NIST 的《安全軟體開發框架》指出，安全做法通常要加進每一種開發流程模型，所以每一關都要有對應的檢查。
AI 能取代整個開發團隊嗎？
本文沒有這樣的結論。AI 在第三關貢獻最大，其他關卡仍有必須由人決定與負責的事，詳細討論見〈程式寫得更快，專案為什麼仍然很慢？〉。
資料來源與說明
五關的歸納與蓋房子的比喻是我的整理，並非業界標準；各階段名稱與定義引自 AWS 與 NIST 的公開說明，AI 能協助的項目引自 Anthropic 官方文件，查閱日期為 2026 年 10 月 19 日。上線前檢查表是我的建議，沒有經過大規模驗證。
參考資料
- Amazon Web Services，〈What is the software development lifecycle (SDLC)?〉，現行頁面，存取日期：2026 年 10 月 19 日。
- National Institute of Standards and Technology，〈Secure Software Development Framework (SSDF) Version 1.1（SP 800-218）〉，2022 年 2 月，存取日期：2026 年 10 月 19 日。
- Anthropic，〈Best practices for Claude Code〉，現行文件，存取日期：2026 年 10 月 19 日。
延伸閱讀
- Vibe Coding 是什麼？三種定義、適用範圍，與企業及個人案例的閱讀路徑：先釐清定義與適用範圍，再依情況挑選本分類的文章。
- 做公司工具該選整合式 AI 平台，還是自己搭開發環境？：第三、四關的環境與部署，該選哪一種工具。
關於作者
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2026-10-19