以一些範例來討論AI Coding新時代的團隊開發

從人與人協作，走向人與Agent協作

Noopher AI執行長暨創辦人YC在Hello World Dev Conference分享，AI時代的團隊開發，已不再只是一群人之間如何分工，而是一群人與一群AI agent如何共同完成事情。他用三個層次展開：先談一個人如何用好AI，再談一個人如何帶領Agent team，最後延伸到一群人與一群Agent如何形成AI native的comPMny。

YC有超過八年的機器學習研發經驗，研究與開發橫跨語言、語音、視覺等非結構化模型，也曾在聯發科的AI研究院聯發創新基地擔任資深技術經理，帶領Breeze 系列開發。如今創辦Noopher AI，目標是以技術與研究能力，重新處理知識傳遞、知識整合等真實問題。

個人實戰：AI會寫程式，但問題定義仍是門檻

YC回顧2025年4月使用聊天框寫程式的經驗。當時他要處理reasoning中的dependency同構檢查：把一串有相依關係的決策畫成樹，再判斷兩棵樹的思維模式是否同構。這類問題不只難寫，也高度依賴具體情境。

• 他先花了四小時，仍沒有完成程式。
• 之後把問題定義與過程中建立的測試一併交給聊天框，AI大約半小時就寫出品質不錯的程式。
• 這讓他確認AI寫程式很強，但也看見前提：人得先完成問題組織、定義與測試準備，這些工作本身不輕鬆。

到了2025年11月底，Claude的Opus 4.5與Coding Agent讓互動方式出現轉折。Agent可以進到電腦環境、看見同一份程式碼並一起修改。YC起初懷疑自動化的上限與後續除錯成本，但實測後認為它足以改變開發習慣，也促使他發起Open Vibe Developers共學社群。八場線上活動每場都有三、四百人參與，反映台灣開發者已高度關注AI coding。

YC在COSCUP整理出三個至今仍適用的原則：規格先行、測試驅動開發，以及照顧好LLM的Context。不過，後續TASTE2專案也讓他發現，這些原則若用得太僵化，反而可能造成反效果。

Open Vibe DevelopersClaudeOpus 4.5Coding Agent規格先行測試驅動開發LLM Context

TASTE2的教訓：Spec是鷹架，不是鉅細靡遺的藍圖

TASTE源自YC在2024年提出的研究想法：讓語音與文字做到Token級別對齊，以利語音語言模型訓練；他與李宏毅老師及博士生合作完成技術研究，並獲選ICLR2026。YC的初衷不只在論文，而是希望做出能像ChatGPT Voice Mode般直接對話的語音聊天機器人。

為了往產品推進，YC與兩位實習生開發TASTE2。工程複雜度隨之升高：模型要從Batch Mode改為Streaming Mode，還要中文化與對話後訓練；後端則要處理模型與系統的Streaming、asynchronous、多使用者支援，以及最棘手的GPU動態調配。團隊大量使用AI Coding，YC認為若沒有它，三人很難在八個月內完成這套系統。

一開始，團隊認真採取Spec Driven：花一個月寫出超過5000行的Spec，主文件外還有大量參考資料與測試程式碼範例，連edge cases都盡量補齊。但依規格生成程式碼後，連基礎module都無法跑起來，修了很久也難定位問題。

問題不在於Spec無用，而是團隊把它當成必須一次寫完所有細節的藍圖。YC後來回到軟體工程的基本功：先把大問題拆成三個submodule，再用orchestrator串起來；每個module各自使用小而聚焦的Spec逐一完成。結果，第一個可用submodule在早上一小時內就跑通，後續由既有程式碼與清楚介面引導AI完成串接，整體一、兩天就跑通。

「spec的確是重要的，但是你不要把spec的地位看成像是藍圖一樣，而是你應該把spec當作鷹架。」
— YC

• 小而聚焦的Spec能讓AI更好理解任務，提升產出程式碼品質。
• 完成的程式碼本身是更強、也更可驗證的引導；它不該被大量文字規格取代。
• 鷹架的用途是協助建造，任務完成後可以收起來，不必讓過往細節持續干擾後續Context。

Spec或原型、讀多少程式碼：依任務與系統狀態判斷

YC接著整理海外開發者的兩個分歧。第一個是先寫Spec，還是直接做原型。Matt提出的grill me，重點是讓AI持續提問，直到人與AI對齊後再寫出Spec。與其簡化地把Matt歸為「規格派」，更精確的理解是：這套做法把對齊本身變成開發前的重要工作。

另一邊，Claude Code的Leader兼創造者Boris傾向直接做原型：先寫一版、測試、發現問題再修改，不必先產出Spec；必要時甚至可看著原型重做。YC採取情境式選擇：任務難以描述時，原型能更快暴露問題；任務容易描述時，Spec能讓執行過程更省人力，但前期與AI討論Spec本身也有理解成本。

第二個分歧是AI寫出的程式碼到底要看多少。Simon Willison會先讓AI大量產生程式，再用AI導覽、理解程式；AutoGPT的開發者則主張重點是派工與驗收，不必過度閱讀程式。DHH認為應看系統狀態：新系統的原型可少看，複雜的Legacy codebase則要看得更多。Andrej KarPMthy也認為Vibe Coding較適合拋棄式專案，專業工作仍需監督與驗證。

• 原型期可把重心放在功能能否驗證、介面是否正確與使用情境是否跑通。
• 系統愈成熟、愈複雜，愈需要理解關鍵程式與風險區域。
• 人不必放棄理解，而是把有限注意力從逐行審查，移往驗證、監督與決策。

Agent team工作流：架構、人機對齊與可執行的拆單

在Noopher AI的做法中，先由人與人討論出大致架構，不急著填滿細節；接著請AI拆單，並盡量讓每張單不重疊，例如前後端分開、module分開。這樣才能提高平行開發的空間，避免Agent彼此踩到同一塊工作。

每張任務單會用grill-with-docs進行對齊，讓Agent逐題發問後產出Spec，並放進GitHub issue，接著以TDD實作與驗收。任務完成後，issue會關閉；這也呼應Spec作為鷹架的觀念：它在建造過程中提供支撐，而非永遠占據開發者的注意力。

grill-with-docs另外保留兩份可持續使用的文件。context.md統一詞彙，例如清楚定義Meta Agent與Member Agent；ADR則記錄架構決策，例如Meta Agent只負責指揮、不直接操作程式，而Member Agent實際執行工作。這些內容讓Agent遇到疑問時能先查文件，而不是反覆向人追問同一件事。

這套設計背後採用DDD的邏輯：程式結構與命名跟著業務領域走。當人討論的名詞、文件中的定義與程式中的結構一致，人與AI更容易對齊，也更有機會走向較高程度的自動化。

GitHub issuegrill-with-docscontext.mdADRMeta AgentMember AgentDDDTDD

從人工盯流程，到低負擔的Agent監控

YC創辦Noopher AI的第一個月，曾經親自替每張單啟動Agent、看計畫、回答零星問題，再要求單元測試、整合測試、Spec review與變異測試。變異測試會刻意改動關鍵邏輯，例如把小於改成大於，檢查測試是否確實亮紅燈。流程看似完整，但人變成守在電腦前等待、同意、再等待，注意力被大量瑣碎操作吃掉。

他先嘗試Claude Code原生的sub-agent，設計planner、worker、reviewer，並用worktree隔離執行環境，由主視窗擔任meta-agent調度。因任務拆得夠開，確實可以同時跑多張單；但所有訊息都湧入唯一主視窗，若中間錯過一個A或B的提問，sub-agent便停下等待。平行度提高了，人類的認知負荷卻沒有真正下降。

後來他借鑑看板流，讓任務在backlog、to do、doing、review、done之間移動，並在ticket記錄思路與決策。看板確實讓人一眼掌握Agent進度，但也帶來新問題：Agent除了完成任務，還得理解看板規則、更新狀態與寫紀錄。YC曾以Fable投入一個月、約10億等級token嘗試修好這套系統，仍持續遇到零星錯誤。

YC從中得到的反思很直接：不要把對人的微觀管理搬到Agent身上。真正需要的是讓每個Agent專心做事，同時有一個不干擾工作的資訊流與監控機制；甚至可再由一個助理Agent整理各Agent的工作狀態，再向人匯報。

「我希望流程他可以自己走，他卡住的時候再來問我就好了。」
— YC

基於這個需求，YC自行開源Alt Agents，採MIT條款。它以簡潔TUI呈現Meta Agent與一群Member Agent的工作狀態，團隊規則與角色可用Plugin自訂；底層沿用原生Claude Code與Codex，不額外引入新的Harness，降低Agent的額外負擔。

系統也整合worktree檔案管理與Pod環境隔離，讓每個Session專心處理自己的任務。TUI在同一畫面呈現資訊流、各Agent的運行狀態、Token消耗與成本；若需要介入，使用者可透過tmux進入特定Session直接互動。目標不是讓人事無鉅細地下指令，而是以低成本理解現況，只在必要時介入。

AI原生組織：AI負責執行，人負責全局決策

YC認為，組織設計應先承認AI Agent的長處與限制。AI擅長高效率執行、平行化、細心且穩定地做重複任務，例如變更資料型別時，能系統性地同步修改所有相關位置，避免人容易漏改的低級錯誤。它適合流程化、機械式且可驗證的工作。

不過AI要服務的是人的目標，而人與AI要做到對齊並不容易。AI常快速鑽進細節、忽略大局；面對技術選型，也可能困在既定選項中，難以主動跳出框架找到更好的第三條路。因此，AI強在執行，人仍強在全盤決策、定義目標與持續校正方向。

• 執行團隊由AI主控，負責實作、測試、除錯與review；人不直接寫程式碼。
• 決策團隊由人負責，處理技術選型、架構方向與取捨。
• 人還要持續讓AI理解目標與全局，避免它只在局部細節中最佳化。

決策不只是在會議中選A或B。YC舉例，AI曾把某個架構問題收斂成A、B二選一，但他想到第三種解法；即使提示AI再想一次，AI仍沒有主動找出來。這也說明，人類的價值不只是審核AI答案，而是提出AI尚未建立的框架與選項。

理解工程與探索工程：人不能因AI代工而失去系統感

AI寫得愈快，人愈不能與程式脫節。YC將此稱為理解工程：如果人不理解系統，就無法做出好決策，也無法帶領執行團隊走對方向。過去新人可以只改一小段程式、依賴資深同事指出檔案位置；現在新人一進來就得帶著AI改動整個系統，因此更早需要掌握全局。好消息是，AI也能反過來協助理解大型codebase。

在理解之上，是探索工程。人可以帶著對系統與原型的理解，做出A、B、C、D等不同版本，透過測試比較結果，決定產品下一輪迭代；也可以從既有原型延伸搜尋相關資訊，再快速做新原型驗證。即使走過錯誤決策，經驗也會回寫到原型中，逐步疊出更好的版本。

• 人與人分工時，scope應盡量切開，避免彼此打架。
• 原型開發時，優先鎖定驗證、前後端與module介面，以及系統use case。
• 程式碼可少看，但不能放棄系統理解；理解是做決策與探索的前提。

重點回顧：AI時代最稀缺的是判斷力

YC將整場分享收束成三個工作流轉變：一個人用AI時，把Spec當鷹架，完成後收起來；一個人使用Agent team時，讓Agent專心做事，人只需看見脈絡並在必要時介入；一群人與一群AI協作時，實作交給AI，人則聚焦理解、探索與決策。

他特別提醒，AI Agent會做事，不等於一定能產生成果。人必須對標市場、客戶與成果，據此決定如何派工。看似矛盾的是：AI替人實作後，人反而更需要理解整個專案，因為人的責任已從親手完成工作，轉向持續對齊與持續決策。

「在AI時代最重要的其實是判斷力，決定做什麼的判斷力。」
— YC

這份判斷力包含眼光與品味，也包含從AI產生的大量雜訊中找出真正訊號、在發散組合中做出正確選擇的能力。其基礎是個人的認知，而AI可以協助拓寬認知、加速學習與累積經驗。YC以自己創業後學習會計與記帳、再用AI Coding寫系統處理帳務為例，說明AI不只可以代工，也能成為跨域學習與快速試驗的加速器。

執行團隊決策團隊驗證介面use case市場客戶成果訊號與雜訊眼光品味