我如何作為技術主管建立一套結構化的 AI 輔助開發工作流程，真正的工作其實是在寫出第一行程式碼之前完成。
你打開聊天視窗，描述你想要的功能，反覆調整輸出，然後交付一個大致可用的產品。這感覺很快，功能從技術上來說是可行的。但沒有人，包括我自己，完全理解裡面到底是什麼。邊緣案例沒有人想到要處理，架構當下看起來合理，但無法承受下一個功能的衝擊。我越做越快，卻越來越不理解。
我一直遇到的問題是：如何在享受 AI 輔助帶來的速度優勢的同時，不失去讓軟體可維護的清晰度與目的性？簡短的答案是，真正的工作發生在寫程式之前。
AI 真正擅長的是什麼？實作。它真正不擅長的是什麼？弄清楚你到底想要什麼、抓出你忘了明確說明的假設，以及告訴你你的問題心智模型何時錯了。這是你的工作，永遠都是你的工作。
我做出的最有價值的改變是：把每個功能先當作一個思考問題，再當作實作問題。這個工作流程設計來強迫這種思考在寫任何程式碼之前發生，並用 AI 來壓力測試這些思考，而不是跳過它。
這個工作流程是從 Mark Pocock 的技能中調整而來，配合我使用。
一切從我自己寫的一份文件開始，使用簡單語言，沒有固定格式。我描述問題、對解決方案的初步想法、我知道的限制，以及我不確定的地方。這不是交付物，沒有人會看，只有我自己。它的唯一目的是把思考從腦中釋放出來，形成我可以檢視的形式。
後續所有工作的品質完全取決於這一步的品質。模糊的計畫會產生模糊的產品需求文件（PRD），進而產生模糊的議題，最後產生技術上可執行但不符合預期的程式碼。
這份自由形式的計畫成為結構化訪談流程的輸入。該技能會探索程式碼庫以了解現況，然後不斷詢問我關於計畫的每個面向，沿著設計樹的每個分支走訪，逐一解決決策間的依賴關係。這是抓出壞點子的步驟。不是因為 AI 比我聰明，而是因為被迫回答關於自己計畫的具體問題會揭露你在敷衍的地方。「當使用者未驗證時，這個功能怎麼表現？」「如果這個操作部分失敗會怎樣？」「你說這會取代現有功能，依賴現有行為的使用者怎麼辦？」
輸出是一份結構化的 PRD 文件，包含問題陳述、解決方案描述、詳細的使用者故事清單、實作決策（模組、介面、資料結構變更、API 合約）、模組設計、測試決策，以及明確的範圍外項目。所有內容都是明確的。使用者故事是後續所有工作的骨幹。它們必須具體到能在後續定義議題範圍時，明確推導出驗收標準。
PRD 轉換成一組議題，採用垂直切片（vertical slices），這種切片貫穿每個整合層端到端，而非只切單一層的水平切片。只觸及資料庫或只觸及 UI 的切片不是有效切片。每個議題都應該交付一條狹窄但完整的路徑，可以獨立展示或驗證。每個議題被分類為 AFK（AI 可實作且變更可無人介入合併）或 HITL（實作過程中某點需要人類決策）。盡可能偏好 AFK 以保持工作流暢，不成為我注意力的瓶頸。
在寫任何東西之前，該技能會呈現擬議的拆解，並詢問：粒度是否合適？依賴關係是否正確？是否有需要合併或拆分的？議題依依賴順序撰寫，方便用真實編號交叉引用。
每個議題包含簡潔的端到端行為描述、一段「如何驗證」說明確切確認切片完成的方法、Given/When/Then 格式的驗收標準（含錯誤案例）、阻塞清單，以及回溯到所對應使用者故事的參考。所有內容都存在檔案中。我在不同平台工作，有時用 GitHub，有時用 GitLab，保持工作流程基於檔案而非特定工具。
每個議題拆解成具體且有序的任務，每個任務對應一次專注的 AI 工作階段。這個限制是刻意的：如果任務無法在一次會話完成，代表它太大。該技能會探索議題觸及的程式碼庫特定部分，找出現有模式，並產生帶有類型（WRITE、TEST、MIGRATE、CONFIG、REVIEW）、明確輸出與依賴順序的任務清單。先資料結構後邏輯，先邏輯後 API，先 API 後 UI，測試穿插進行而非最後批次。
任務描述的關鍵設計決策是：它們是寫給執行 AI 的指令，而非給人類開發者的筆記。每個任務指定要觸及的檔案、要遵循的現有模式，以及完成時的輸出樣貌。沒有程式碼片段，只有意圖，不是實作。
每個任務描述都是自包含的提示。當我準備實作任務時，我會開啟一個新的會話，貼上任務描述和父議題作為上下文。任務描述就是為此目的撰寫，指定範圍、參考正確檔案與模式，並定義完成標準。每個任務都從乾淨的上下文開始是刻意的。長時間累積上下文的會話容易偏離：模型開始根據已做過的決策，而非任務需求做決定。用明確範圍的任務重新開始，產出品質穩定優於持續長會話。對於 REVIEW 任務，也就是標記需要人類決策的，我會停下來做決定，更新任務檔案結果，然後繼續。這些時刻是工作流程發揮價值的關鍵：決策是在上下文中有意識地做出，而非埋沒在長篇生成中。
每個 PR 在合併前都經過結構化的六階段審查。這些階段涵蓋邏輯錯誤、操作順序、不良實踐、安全性、魔術字串與數值，以及模式改進。
操作順序在 AI 生成的程式碼中特別值得注意。模型傾向產生正確的動作，但有時順序錯誤：例如在提交交易前發送通知、在應該記錄的動作後寫審計日誌、在驗證輸入前變更狀態。這些錯誤在審查時容易被忽略，因為程式碼乍看之下沒問題。
審查針對檔案或差異進行，而非整個功能。範圍刻意狹窄，在 PR 階段抓出問題遠比之後發現便宜。
功能結束時，會進行跨模組審核，檢視只能從整體實作評估的問題。不是個別錯誤，那些應該在每個 PR 被抓出，而是系統性問題：模組間不一致、早期引入後錯誤複製的模式、孤立時成立但整體破裂的安全假設。
審核會先讀完整實作再標記問題，這正是重點。它依嚴重性分組發現，給出功能是否安全留在生產環境的明確整體判斷，並在做任何變更前徵求批准。已合併代碼上的無監督修正風險高於開發中修正。
這套流程不容易快速建立。規劃與 PRD 步驟需要真實時間，且總是有誘惑跳過它們直接寫程式。這套流程只有在你真心相信寫程式前的思考時間比除錯時間便宜時才有價值。
它也不是工程判斷的替代品。AI 在每步都會提出合理但不適合你特定情況的建議。審查步驟存在正是因為 AI 輸出需要根據它不知道的知識驗證：你的團隊慣例、使用者實際行為、程式碼庫中隱藏的複雜度。
這個流程的每一步都有相同結構：AI 產出東西，你帶著完整上下文審查，然後才建立。AI 加速產出，審查永遠是你的責任。
流程設計讓審查盡可能有效：評估議題時有 PRD 可對照；評估任務時有議題可對照；審查程式碼時有驗收標準可對照。
如果你看到這篇文章的結尾，至少值得給你一個我的技能連結。請參考我的 GitHub 倉庫。