如果 AI 已經不只是幫忙寫 Code,而是可以參與需求、規劃、測試與 Review,那我們是不是應該重新思考整個 Software Development Lifecycle?
昨天聊到當寫 Code 不再是最大的瓶頸,原本被開發時間蓋住的問題就會一個個浮出來。
今天就來看看,如果 AI 真的成為開發流程中的協作者,整個 Software Development Lifecycle 會變成什麼樣子。

圖片來源:AWS — AI-Driven Development Life Cycle (AI-DLC)
AI-DLC 全名 AI-Driven Development Life Cycle,是 AWS 在 2025 年提出的一套 AI 原生軟體開發方法論,和傳統開發最大的不同,不只是「多了 AI」,更重要的是人和 AI 的工作方式變了,讓 AI 從「輔助工具」變成開發流程中的核心協作者,而我們則負責關鍵的決策與驗證。
可以把它想成一個循環:
Intent → AI Plan → AI Clarify → Human Validation → AI Execute → Human Review
AI 可以負責把一個模糊的需求逐步拆解、提出問題、產生計畫並執行;但在關鍵節點,仍然需要人類去做確認,而這個循環會在不同的開發階段不斷重複。
也就是說,AI-DLC 並不是把人從流程中拿掉,而是重新分配 Human 和 AI 在流程中的工作。
這三個概念背後有一個共同前提:
AI 可以持續執行,但不能取代人的決策。
所以流程中必須設計明確的 Human Validation / Review 節點,讓 AI 在關鍵決策前停下來,由人來確認方向是否正確。

圖片來源:AWS — AI-Driven Development Life Cycle (AI-DLC)
Inception|構思
透過與 AI 對話細化需求,將模糊的 Business Intent 逐步轉化為明確的 Requirements、Stories 與 Units of Work。這個階段的重點不是立刻寫 Code,而是把「想做什麼」講清楚。
Construction|建構
AI 根據已確認的 Context 與規格,協助提出架構、產生程式碼與測試。
人類則負責技術決策、確認設計,以及 Review AI 的產出。
Operations|營運
AI 協助 Infrastructure as Code(IaC)、Deployment 與後續營運工作。
了解 AI-DLC 的概念後,接下來我想把它拆成兩條線來實作。
Spec、Plan、Test:這些會直接進入後面的 Meeting Notes System 實作流程。
它們負責回答:
Command、Skill、Hook、MCP、Plugin:這些則是我使用 Claude Code 時,用來建立 AI 開發工作環境的機制。
它們負責回答:

Development Process 定義「怎麼開發」,AI Collaboration 則負責讓 Claude 能夠按照這套方式工作。
明天:AI 可以幫我們規劃、執行,但前提是它必須知道「我要做什麼」。那我們要怎麼把一個模糊的 Intent,變成 AI 可以持續依據的 Specification?