AI 寫程式的工作流怎麼建？從需求拆解到驗收的完整 SOP

你已經在用 Copilot、Cursor 或 Claude Code，問題不是「AI 會不會寫程式」，而是少了一套可重複、不會越用越亂的流程。答案是把開發拆成六步：需求拆解、讓 AI 先出 Planning、小步驟實作、跑測試、Code Review 與 Self-Check、Security Review 與效能檢查。每一步都有該由誰做、該驗收什麼的明確分工，AI 負責生成與重複性工作，人負責定義目標、審核方向與安全把關。

AI 在開發流程裡該扮演什麼角色？

先把定位講清楚：AI 本質上是一套基於大型語言模型（LLM）的高階文字接龍與模式識別系統，它看過大量程式碼後學會「接下來最可能出現什麼」，而不是真正理解你的商業邏輯。這個本質決定了它的強弱項。

它擅長語法結構、樣板程式（Boilerplate）、常見演算法、語言之間的轉譯，這些都是模式明確、重複性高的工作。但它不擅長架構設計、業務邏輯的確認,以及安全性把關——這些需要對專案脈絡與風險有真正的判斷,而不只是「看起來合理的延續」。

換個比喻：AI 像一個反應很快、肯加班、但沒有長期記憶也不懂公司規矩的超級實習生。你指令下得夠清楚,他能很快交出東西;但他不會主動確認「這樣做是不是符合公司規定」,也不知道上一個案子為什麼要那樣設計。這也是為什麼不能把 AI 當成全自動化系統丟著不管,而是要當助理或協作者,懂得怎麼問、怎麼驗證,才能真的提升生產力。

如果你還在用「丟一句需求讓 AI 生成整個功能」的方式工作,可以先看 Vibe Coding 的風險整理,再回來看下面這套流程怎麼把它收斂成可控的 SOP。

完整 SOP：六個步驟怎麼分工

1. 需求拆解與規格定義

這一步由人主導,AI 當討論對象。用自然語言跟 AI 討論需求,把 PRD(產品需求文件)貼進去,列出邊界條件、資料庫欄位需求、API 介面規格。

關鍵是先把模糊詞彙變成可測試的描述。「反應要快」要改寫成可測試的回應時間範圍;「只能本人讀取」要改寫成可驗證的授權規則。需求的語意常常在轉譯成程式的過程中流失,模糊詞彙(「快速處理」「保護敏感資料」「妥善處理錯誤」)留有多種解釋空間,AI 會挑一種解釋直接寫下去,而那種解釋未必是你要的。

這一步要驗收的是:預期行為、限制條件、驗收例子三樣東西是不是都寫清楚了。如果答不出「怎麼知道這個功能做對了」,就還沒準備好進下一步。

2. 讓 AI 先出 Planning,不要直接動手

這是整套流程裡最容易被跳過、但最關鍵的一步。不要一開口就叫 AI 改程式碼,先讓它分析專案、提出計畫,把任務拆解成小步驟,你確認方向沒錯之後才放它動手。

像 Claude Code 這類工具有專門的 Plan Mode,會先產出詳細計畫,再進入反覆問答階段讓你調整方向,確認沒問題才進入實作。這一步省掉的,是 AI 看到局部問題就動手重寫整個元件,或是光靠檔名猜根因的風險——這類「程式探索問題」的對策就是固定起始狀態、先探索並回報計畫、限制任務範圍,而不是任由它自由發揮。

這一步要驗收的是:計畫列出的修改範圍、檔案清單、步驟順序,是不是跟你想的一致。不一致就在這裡喊停,不要等實作完才發現方向錯了。

3. 小步驟實作

方向確認後,採「小步快跑」的方式讓 AI 動手,一次處理一個函式或一個明確範圍的任務,而不是整包丟出去。先生成骨架與樣板(設定檔、基礎 CRUD、基本路由),再逐步補核心邏輯。

有個實際案例是文章搜尋功能的開發:需求提出後,AI 先分析要修改哪些檔案,再按照之前談好的計畫完成實作。這種「先分析再動手」的節奏,是把風險壓在每一小步,而不是壓在最後驗收。

大型專案如果 AI 一直抓不到正確的檔案脈絡,問題通常不是 AI 不努力,而是 context(上下文)管理沒做好,可以參考 程式碼索引與 Context 預算的解法。

4. 跑測試

每完成一個函式,立即要求 AI 編寫涵蓋邊界條件的單元測試,不要等整個功能做完才補測試。延續上面的搜尋功能案例,新增搜尋測試後執行完整測試,結果是測試全部通過、沒有失敗——但這不是故事的結尾,下一段會解釋為什麼。

測試要分層做,各層檢查的東西不一樣:單元測試檢查小範圍邏輯,整合測試檢查模組間的資料與介面,端對端測試確認使用者重要流程走得通,程式分析工具掃描常見錯誤與安全問題,安全測試則做輸入模糊測試、弱點掃描或滲透測試。每種方法都有自己的適用範圍與盲點,搭配起來能從不同角度補強證據,但沒有任何一項能單獨保證系統可靠。

要特別提醒:測試覆蓋率不等於可信程度。覆蓋率和測試案例是否驗證到對的預期,是兩件事——AI 很可能產出數量多、覆蓋率漂亮,卻驗證錯誤預期的測試。而且如果程式碼和測試出自同一個模型,兩者可能共享同樣的錯誤假設,不能把它們當成互相獨立的證據。

5. Code Review 與 Self-Check

這一步把 AI 當成「技術純熟但粗心的新人」來審查,重點檢查:有沒有硬編碼機敏資訊、SQL 注入風險、記憶體洩漏、效能瓶頸。

進階一點的工具已經能把這一步半自動化。例如先跑 /simplify 做重構優化,同時並行 /security-review 做安全檢查,之後進入 Review 循環:每隔一段時間自動偵測 PR、檢查 Review 狀態、取得留言、修正程式碼、執行測試、commit 並 push、標記已解決、再重新觸發 Review,一直循環到沒有新留言為止。有開源專案維護者實際用這套流程,把原本要花半天的工作縮短到一到兩小時,過程中 AI 會依照 Copilot Review 的留言自動反覆修改,但最後一關,仍然是開發者自己人工審閱拍板。

這一步也是為什麼光看測試結果不夠的原因:測試通過不代表沒有安全漏洞,程式能正常執行不代表設計合理。如果你想要更系統化的審查項目,可以對照 AI 寫程式碼的 Code Review 檢查清單。

6. Security Review 與效能檢查

最後一關專門處理 AI 容易忽略、但出問題代價最高的兩類風險。

安全面要留意兩件事:一是絕對不要把資料庫連線字串、API 金鑰、客戶個資、商業機密原始碼貼進公開的 AI 聊天介面;二是 AI 生成的程式碼可能無意間參照了受特定授權(例如 GPL)約束的開源專案,商業專案上線前應做授權掃描。企業採購 AI 輔助工具時,也該確認服務條款是否明文寫著「使用者輸入資料不會被用於訓練公開模型」。

國際上的 NIST SP 800-218(安全軟體開發框架)也建議把安全做法融入既有的開發生命週期,依不同階段決定該做哪些程式碼分析與測試,而不是等到上線前才補一次安全檢查。

為什麼 AI 寫的程式碼「看起來對」卻可能是錯的?

前面提到 AI 的本質是文字接龍與模式識別,這解釋了幾種典型的翻車方式:

• 虛構假設:AI 可能假設不存在的 API、宣稱測試通過卻根本沒輸出結果、只測了最順利的那條路徑(Happy Path),或是把一次手動測試成功就當成完整驗收。
• 安全越界:把機密資訊寫進 log、照著外部文件裡藏的惡意指令行動、沒經過確認就部署或修改正式資料。對策是縮小 AI 工具能用的權限、把外部內容一律當成不可信的資料看待、在關鍵動作前設一個明確的人類決策點。
• 過度自信:讓一個 AI 審查另一個 AI 的輸出,結果兩邊看到的都是同一份不完整的需求,互相確認了同一個錯誤。對策是 Review 意見必須引用具體的程式位置、觸發條件、重現方法,不能只給結論。

另外一個容易被忽略的風險是:設計理由可能沒有跟著程式碼一起留下來。接手的人很難判斷某個寫法是刻意的設計決定,還是 AI 生成時的偶然結果,這會讓之後的除錯和升級成本變高——所以 Code Review 階段最好順手把「為什麼這樣寫」記下來,不只是記「改了什麼」。

Prompt 怎麼寫,決定每一步的產出品質

籠統的指令只會換來籠統的結果,這六步 SOP 裡每一步給 AI 的 Prompt,建議至少包含四個部分:設定角色與技術堆疊、清楚定義輸入與輸出、規範限制條件與錯誤處理、要求附帶測試與說明。再搭配提供完整上下文——錯誤訊息、相關程式片段、套件版本號都丟進去,而不是讓 AI 自己猜環境。

更結構化一點的寫法,可以固定包含五個元素:目標、背景、限制、輸出格式、評估標準。這套結構在需求拆解和 Planning 兩個階段特別有用,因為那兩步的產出品質,幾乎直接決定後面實作和測試會不會走偏。想看更多角色化的提示詞範本,可以參考 Claude 提示詞範本與長期協作交接做法。

Human-in-the-Loop:哪些決策一定要人拍板

責任要分清楚才不會互相推:提出需求的人負責確認目標與驗收條件,產生程式碼的人要能說明變更內容與依據,審查者核對差異、測試結果與安全影響,發布負責人確認風險有沒有達到可以接受的門檻才批准上線,維運負責人則負責觀察部署後的實際表現。

如果你導入的是多個 AI 代理協作(而不是單一助理),要先界定清楚每個代理能存取哪些程式庫、憑證、環境,能執行哪些命令,以及哪些動作必須停下來等人工核准。部署前一定要保留人工批准點,設好可行的回復方式,並檢查代理之間傳遞的資料與輸出有沒有異常。對於高風險或關鍵任務系統,審查要求要跟著失效後果提高,多加獨立測試、資安審查、人工核准、部署監控,以及確認緊急回復機制真的能用。

判斷要不要用多代理架構,不是代理越多越好,而是依任務複雜度決定需不需要 Research、Coding、Testing、Review 這樣的角色分工;簡單任務硬套多代理反而拖慢速度。如果連要不要上 AI Agent 都還沒想清楚,可以先看 該用工作流還是 AI Agent 這篇。

開發者本身也要具備技術架構能力才能善用 AI——AI 是加速器,不是導航。它給的架構方向可能不符合專案長期規劃,需要開發者主動否決;它產出的程式看起來能跑,但設計模式不適當時也需要手動調整。整體來說,AI 比較適合重構、寫測試、產生樣板程式碼、處理重複性工作、第一輪 Code Review;全新系統的架構設計和複雜業務邏輯的核心模組,決策權始終在人。

紀錄要留什麼,才算真的「驗收過」

很多團隊的驗收紀錄只留一句「已測試」或一個綠色勾選,這種紀錄出事時幫不上忙。至少要能辨認:改了哪個版本、在什麼測試環境跑的、什麼時候執行、測試資料的範圍、通過條件是什麼。如果測試依賴外部服務、特定權限或固定的測試資料,這些前提也要寫清楚,不然別人重跑一次會對不上結果。發現問題時,標示嚴重程度、該由誰處理、預定怎麼處置,也比單純記錄「有幾個 bug」更有用——重點是能追溯到修正與重測,而不是紀錄堆得多。

給個人與團隊的落地檢查表

• 需求階段有沒有寫出可測試的驗收例子,而不是停在「快速處理」「妥善處理錯誤」這種模糊描述?
• 動手實作前,有沒有先看過 AI 的 Planning 並確認修改範圍?
• 每個函式或任務單元完成後,有沒有馬上補邊界條件的單元測試,而不是堆到最後一次補?
• 測試是不是分層做了(單元、整合、端對端、程式分析、必要時的安全測試),而不是只看單元測試過了就結案?
• Code Review 有沒有把 AI 當「粗心的新人」檢查硬編碼機密、注入風險、記憶體洩漏、效能瓶頸?
• Security Review 是不是獨立於功能測試之外執行,而不是「測試過了就等於安全」?
• 有沒有明確寫下哪些動作需要人工核准(尤其是部署、改正式資料、存取憑證)?
• 驗收紀錄有沒有留下版本、環境、時間、測試資料範圍、通過條件,而不只是一個勾選?

AI 寫程式的能力已經不是問題,問題是流程有沒有在每一步放對驗收點。把六步 SOP 跑熟之後,你會發現工作重心真的從「下指令讓 AI 寫出要的 Code」,變成「描述目標、定義規則、安排工作、驗證結果」——這也是在不確定性越來越高的開發環境裡,維持品質唯一可靠的方法。