新聞

要做一個軟體專案，通常會經過這樣的流程：產品經理（PM）先整理需求，與資深工程師來回討論，釐清功能背後真正要解決的問題，再由資深工程師設計架構、拆解工作，最後與資淺工程師分工實作。

這套流程之所以通用，是因為軟體開發的難題是「判斷這個功能該怎麼做」。同一個功能，可以有很多種寫法，但哪一種比較符合既有系統架構？哪一種未來比較好維護？哪一種不會讓技術債越滾越大？都需要經驗判斷。

也因此，業界長期仰賴一種合作模式：資深工程師規畫架構與規格，再與新進工程師組隊實作。問題也在這，最懂架構、最懂系統脈絡的資深工程師，還是得花大量時間處理實作細節，比如寫程式、查語法、看文件、修編譯錯誤，也要與團隊成員溝通需求、確認進度、檢查方向。專案越大、人越多，溝通成本也越高。

但這種分工模式在AI輔助開發（AI Coding）出現後，開始鬆動了。

這正是前聯發創新基地技術經理陳宜昌的觀察。他點出，AI Coding帶來的最大變化是，一個人也有機會完成過去一個小型工程團隊才能做完的工作。前提是，這個人必須夠懂需求、懂架構，知道怎麼把工作切成AI能處理的範圍。

「一個人能做的事情，會變得非常多，」他說。AI Coding究竟如何把一個人的開發能力，放大到這種程度？

從懷疑到實戰：AI可以參與更多開發環節了

有趣的是，陳宜昌一開始並不看好AI Coding。他原本懷疑，AI頂多幫忙補幾段程式碼，能否真正輔助完成一個專案，還很難說。

真正讓他改觀的，不是公司要求，也不是管理層推動，而是社群朋友們不斷「推坑」。這些朋友持續分享AI Coding實戰經驗，也一直鼓勵他試試看。陳宜昌抱著姑且一試的心態實際動手，結果發現，AI Coding工具的能力遠超想像。

他後來乾脆組織一場線上讀書會，邀請更早投入AI Coding的開發者，分享工作流與踩坑經驗，再把這些方法帶回自己的專案中驗證。

現在，他自己的工作流程裡，大多數開發環節幾乎都有AI參與，從需求分析、架構討論、程式實作、測試、除錯，再到最後的品質檢查（QA）都不例外。

比如，在架構設計階段，AI就像是個隨時在線的討論對象。它未必能直接給出標準答案，但可以提出多種設計方案，供工程師衡量不同取捨。例如，這個模組要不要獨立？資料流要怎麼走？前後端要如何互動？哪些地方未來可能變成維護問題？

又或是，以他採用的測試驅動開發（TDD）作法為例，他先讓AI理解要做什麼，再請AI先寫測試，接著才實作程式碼。程式寫好後，再以測試驗證結果；如果測試不通過，AI再回頭修改程式，直到測試通過為止。

在這套流程裡，AI一邊寫程式，一邊根據測試結果修正問題，兼顧開發和初期品質把關者的角色。

不過，陳宜昌很快就發現，AI會寫程式，不代表就知道該怎麼寫。真正影響成果的，是工程師如何一步步引導它。

別只想寫完美Spec，程式碼本身也是AI的導航

很多人開始用AI Coding後，直覺地以為，只要把規格（Spec）寫得夠完整，就能讓AI一口氣做出整套系統。

陳宜昌認為，這只說對了一半。因為，AI不只看規格做事，還會讀既有程式碼。程式碼本身清不清楚、好不好讀、邏輯嚴不嚴謹，都會影響AI接下來的寫法。要是既有程式碼結構紮實、邏輯嚴謹，AI比較能沿著原本架構延伸；但若程式碼本身混亂，就算Spec寫得再完整，AI的產出也容易跟著失準。

尤其，處理大型專案時，更不該寫一份巨型Spec，期待AI一次生成系統。因為專案越複雜，細節越多，AI就越容易資訊過載；而寫一份鉅細靡遺的Spec，看似把需求交代清楚了，一旦開始生成，錯誤可能在不同模組間一起發酵，最後開發者還是得回頭重做。

陳宜昌建議，比較穩的做法是，開發者先把大型系統拆成幾個獨立元素，每個元素各寫一份小範圍Spec，讓AI先完成單一任務，再用測試確認結果。等各元素穩定後，再寫一份整合專用的Spec，把各個元素組合起來。

這套做法不是紙上談兵，而是陳宜昌在一項大型專案踩坑後，總結出的AI Coding心法。

從5,000行Spec學到的一課：複雜專案要先拆模組，再讓AI各自開發、整合

這項大型專案是，陳宜昌與兩位學生近期開發的語音聊天機器人。該專案的研究基礎來自他們先前在國際AI頂級會議ICLR發表的論文成果，目標是把研究成果落地成一個能即時對話，且擁有情緒變化的語音聊天機器人。

一開始，他們走過一條很多人直覺會選的路：先把規格寫清楚，再讓AI照著開發。

當時，他們使用類似SpecKit前身的上下文工程框架（Context Engineering Framework）。這類做法的邏輯很直覺，先把Spec訂好，再進入開發。於是，他們把能想到的細節都寫進規格裡，包括模型要怎麼設計、工程架構怎麼安排、每個元件該做什麼，甚至最後負責指揮各模組的協調器（Operator）該怎麼運作，一項一項交代清楚。

結果，這份Spec寫到5,000行。

照理說，規格寫到這麼細，AI應該更容易實作。實際執行後，程式碼還是出錯了，而且最麻煩的是，不知道錯在哪。因為，這些程式碼不是一段段產出，而是AI根據Spec一口氣生成；一旦系統跑不起來，就很難判斷是模型設計、模組介面、協調器邏輯，還是某個細節讓AI誤解了。

他們一開始以為是Spec不夠細緻。於是又回頭補充，花了大概一個禮拜，把規格寫得更完整。陳宜昌和兩位學生甚至把Spec攤在螢幕上，一行一行、逐項檢查，確認是不是還有什麼沒交代清楚。

檢查到最後，幾乎想不到還有哪裡沒寫清楚了。

但再跑一次，AI生成的系統還是跑不動。

陳宜昌這時才意識到，問題不是Spec不夠完整，而是這種做法不適合處理複雜系統。把所有需求寫進一份巨型Spec、期待AI一次生成完整專案，看起來很俐落，實際上是把所有複雜性集中到同一個生成階段。只要某個環節出錯，就可能牽動整套系統，除錯也變得非常困難。

後來，他決定換一種方式：不叫AI一口氣生成一套系統，而是先拆分任務。

於是，他把系統拆成3個主要模組。首先是負責聲音接收與前處理的模組；再來是負責中間對話的語音語言模型，能根據聲音資訊和過去對話歷史，即時生成接下來要說的內容；第三個模組負責語音合成，把語音語言模型輸出的回應轉成可以播放的聲音，並送到前端。前端則提供錄音按鈕、播放介面等使用者操作元件。

有了這三個模組，還需要一個總指揮，也就是Orchestrator，來協調各模組運作、與前端互動。

拆分後，事情變簡單了。每個模組的Spec不再承擔整套系統的複雜性，只要把各自的任務寫清楚即可。AI不必一次理解所有模組如何互動，而是先把一個範圍有限、責任清楚的元件做出來。

接下來，陳宜昌用測試驅動開發模式來實作每個模組。也就是AI先寫測試，再寫程式碼，接著跑測試；如果測試失敗，就根據錯誤回頭修正。多數時候，AI可以自己完成這個循環；如果卡住，再人工介入判斷，是測試寫錯、需求描述不清，還是程式遇到特殊狀況。

每個模組都通過測試、表現穩定後，就能進入整合階段。這時，他們寫了一份整合用的Spec，讓AI來處理模組間的串接，最後再做端對端測試，確認整個流程從錄音、理解、生成回應到語音播放，都能如預期運作。

除錯時，陳宜昌還有一套做法，善用日誌（Log）作為線索。他會在系統關鍵節點打入重要Log，當程式出錯時留下足夠資訊，將錯誤訊息和Log交給AI，請它判斷錯誤來源、修改程式。甚至，還能讓AI自己反覆執行、看Log、修程式再執行，人類工程師則在旁邊監督方向是否正確。

這次經驗，讓他重新理解AI Coding的用法。AI不是不能處理複雜專案，而是需要開發者先拆解系統、定義模組邊界，再讓AI在小範圍內開發、測試、修正，最後才把各模組組裝起來。

可以說，AI Coding的真正用法，是工程師先把問題拆清楚，再讓AI在可控範圍內，完成實作與驗證。