從一個人用 AI 到 AI Native 公司：
規格書是鷹架，不是藍圖

🧭 三個層次：團隊開發要算進一群 Agent

以前講團隊開發，講的是一群人怎麼分工；現在還得把一群 AI Agent 算進去。這是陳宜昌（YC）在 iThome 主辦的 Hello World Dev Conference 2026（HWDC）的主題演講，他把問題分成三個層次往上談：一個人用 AI、一個人帶一組 Agent Team、一群人跟一群 Agent 合作 —— 最後一層，就是他說的 AI Native 公司。

講者做了八年機器學習研發，曾任聯發創新基地（MediaTek Research）資深技術經理，帶隊開發 Breeze 系列繁體中文語言模型（他介紹為臺灣第一個繁中語言模型）；近幾個月離開聯發科，創辦 Noopher AI，目標是做成一家 AI Native 公司。演講用了他自己的兩個案例：與臺大李宏毅教授合作的語音聊天機器人，以及 Noopher AI 的內部開發流程。

📐 一個人＋AI：一份 5,000 行的規格書

從聊天框到 Coding Agent

2025 年 4 月，要 AI 寫程式還得靠聊天框。講者當時要寫一段程式，檢查兩段推理畫成的樹是否同構（判斷兩段思路是否相同），自己花了 4 小時寫不出來；把過程中整理的問題定義和測試貼進聊天框，半小時 AI 就寫好了。但這沒變成日常：沒有前面那 4 小時的準備，光是把 prompt 組織好就很難。

轉折是 2025 年 11 月底 Claude Opus 4.5 推出，Coding Agent 進到電腦裡，跟你改同一份程式碼。他測了幾個案例，「不用還好，一用就嚇一跳」，自覺晚了市場兩三個月，便辦了線上共學社群 Open Vibe Developers（8 場、每場三、四百人，講者自述），後來在 COSCUP 歸納出三條原則：規格先行、測試驅動開發（TDD）、照顧好 LLM 的 context。

失敗案例：寫了一個月的規格書

實戰專案來自他和李宏毅教授團隊合作、入選 ICLR 2026 的 TASTE（讓語音和文字做 token 級對齊）。他真正想做的是像 ChatGPT Voice Mode 那樣打開就能聊的語音聊天機器人，於是和李教授的兩位實習生做第二代 TASTE2：模型要從 batch mode 改成 streaming、要中文化、要做對話後訓練；後端要 streaming、async、多使用者，最麻煩的是動態調配 GPU —— GPU 天生用 batch 跑，上面的系統卻要 streaming。講者說，沒有 AI Coding，他們三個人不可能 8 個月做出來（講者自述）。

照規格驅動的做法，他們花了一個月寫出 5,000 行以上的規格書，每個細節都 review 過、想得到的 edge case 都寫了，後面還附一堆 reference 和測過的範例程式。結果 AI 生成跑了很久，連基礎的 module 都跑不起來，修了很久也找不到問題在哪。

講者的診斷：他們違反了自己的第三條原則。規格塞滿細節，context 沒有聚焦在眼前要解決的問題上，程式品質自然差。他叫停，回到軟體工程的老辦法 —— 拆問題：拆成三個 submodule，再用一個 orchestrator 串起來，每個模組一份小規格。規格小，AI 理解得好，第一個 submodule 一個早上、一小時就跑通；模組做好就有現成的程式碼，AI 看著 interface 去接，連最複雜的 orchestrator 都寫得很快，幾乎不需要規格。一兩天整個跑通。

結論就是本文標題：規格要當鷹架，不要當藍圖。藍圖是把所有細節想清楚、照圖施工；鷹架是蓋的時候拿來撐，蓋完就收掉，AI 看到的程式與規格才會乾淨。講者的說法是：不要以為規格是唯一的指引，好的程式碼是更強的指引，而且是可以驗證的指引。

⚖️ 海外開發者的兩個分歧

講者原本整理了更多海外開發者的觀點，因為時間只留下兩個分歧點。

分歧一：先寫規格，還是直接做原型？

• 規格派 Matt Pocock：用 grill-me skill 讓 AI 一直問你問題，問到雙方對齊，再寫規格、照規格開發。
• 原型派 Boris Cherny（Claude Code 的創造者與負責人）：不寫規格，寫 prompt 先做一版，測完有問題就改，一直迭代。原型一定很多問題，沒關係，出來之後要嘛把細節修對，要嘛看著原型重做一份 —— 原型就是規格。（Boris 的其他心法見〈Claude Code 怎麼用才對？〉。）

講者自己看狀況：任務難描述就走原型，好描述就走規格。規格寫完可以放著讓它跑，你去喝咖啡；做原型則得一直坐在 terminal 前跟 AI 互動。所以規格省時間，原型省掉一開始討論規格的過程 —— 他坦白說討論規格其實很難，AI Agent 講的語言跟人不太一樣，光是理解它的思路就不容易。

分歧二：AI 寫的程式碼，人要看多少？

四人說法不同，講者歸納的共識是：少看程式碼，多做監督與驗證。Step 05 會看到，他的公司把這個共識推到「人只鎖住三道關卡」。

🎫 一個人帶 Agent Team：人定架構、逐單對齊

第二個層次：一個人怎麼用好一群 AI。Noopher AI 的一張工單是這樣走的：

拆單最重要的是每一單都不要重疊，這是後面能一次跑好幾張單的前提。grill-with-docs 跟 grill-me 一樣讓 Agent 一題一題問到對齊，但會多留兩份檔案。講者舉例：系統上面有 meta-agent、下面有一群 member agent，兩個詞各是什麼意思，寫進 CONTEXT.md 詞彙表；「meta-agent 不碰程式、只負責指揮，member agent 才動手」是一個技術決策，寫進 ADR（Architecture Decision Record，架構決策紀錄）。這兩份文件是系統的「燈塔」：AI 自己跑時有疑惑會先查它們，文件代替你回答；沒有它們，AI 一遇到問題就回頭問你，你得一直講同樣的事。背後的邏輯是 DDD（領域驅動設計）：程式的結構與命名跟著業務領域走，嘴上談的和寫出來的是同一套名字，在 Agent 時代特別容易跟 AI 對齊。至於規格，就是鷹架，放在 issue 上，做完關單，之後大多不再看。

第一個月：我是不是 AI 的小弟？

Noopher AI 創立的第一個月，講者坐在電腦前把單拉下來，請 AI 寫計畫，看了覺得不錯就讓它執行。中途它零星發問：太複雜看不懂的，他同意；很簡單的，AI 通常判斷得不錯，他也同意 —— 「就是哪次不同意這樣」。Review 他寫成一個 skill：跑單元與整合測試、做 spec review，再加上圖下方說明的變異測試 —— 講者的說法是，改反之後測試沒亮紅燈，就一定有問題。報告出來，他還是每次都同意，然後進入下一輪。

一個月後他開始懷疑：我是不是在幫 AI Agent 服務的小弟？他做的事非常制式，坐著等、按同意，注意力沒有放在自己能發揮的地方。他要的是流程自己走、卡住才來問他 —— 於是開始試 Agent Team。（TDD 怎麼防止 AI 偷改測試，見〈被下載 700 萬次的五行字〉。）

🔧 兩版都失敗之後：oat-agents

講者的比喻是：老闆不要微觀管理。叫員工一直寫報告、回報進度，做開發的能量就被分掉了。回到第一性原理，需要的不是看板，而是看得到員工的電腦：其實第一版就夠了，只要再加一個看見每個 Agent 在做什麼的機制，把資訊流管好（後來他甚至設了一個助理 Agent 幫他看、再匯報）。找遍開源專案沒有類似的，他就自己寫了 oat-agents，以 MIT 授權開源：

• 結構簡單：一個 meta-agent 帶一群 member agent；團隊有哪些角色、照什麼規則運作，全用 plugin 自訂。
• Agent 沒有額外負荷：用的就是原生 Claude Code 和 Codex，沒有引入新的 harness（執行框架）。
• 隔離：worktree 管檔案、pod 隔離執行環境，每個 session 只專心做自己的任務。
• 看得見、接得手：TUI（文字介面）一個畫面列出每個 Agent 的狀態、token 數與花費；想下命令就透過 tmux 直接登入那個 session。

🏢 AI Native 公司：AI 執行，人決策

最後一層：一群人跟一群 Agent。講者說，先弄清楚 AI Agent 擅長與不擅長什麼，才建得起組織。

• 擅長：執行力高、可平行，而且非常細心。以前改一個變數的資料型別，人常忘了改別處；AI Agent 通常每個該改的地方都會改到。流程化、機械式的任務特別適合它。
• 不擅長：對齊。它很容易一頭鑽進細節、不談大局，你得一直提醒「先談大局」；也正因為細心，容易困在細節裡，技術選型時很難跳脫框架。

他舉了個例子：討論架構時，AI 說只能在 A、B 之間二選一。他覺得有第三條路，提示「你再想一下」，AI 還是想不出來；等他講出第三種解法，AI 馬上說「哇，你說的對，這個太簡潔了」 —— 他形容這是花式吹捧。結論：AI 強在執行，人強在全盤決策與跟 AI 的對齊。所以 Noopher AI 把團隊徹底拆成兩個：

執行團隊完全由 AI 主控，人不寫程式碼。決策團隊除了做決策，還有兩件演講特別強調的事：

• 理解工程：人跟程式脫節，就做不出好決策。講者當菜鳥時，公司動輒幾萬行程式碼，接到單就問待了十幾年的老鳥，老鳥說「改這個檔案、那個檔案就好」，照做真的就完成了。現在的新人沒這麼好過：你的任務是領導 AI 寫程式，一進公司就得懂整個系統 —— 好在也能用 AI 幫你看懂公司那一萬行程式碼。
• 探索工程：帶著理解去看原型，做 A、B、C、D 幾版改進，用測試知道哪版好，決定下一步；或讓 AI 上網找相關資訊，再做一個新原型去試。走過的錯誤決策全部回到原型，疊出更好的版本。

打造原型時，他們幾乎不看程式碼，只卡上圖中間的三道關卡；其中介面那一關，講者說「這些我們會下去看，把它鎖死」。講者也坦白：這是原型期的做法，公司脫離原型期之後可能不同，「不過我還沒走到這一步」。他的三點小結：

1. 徹底切分執行與決策，執行全交給 AI。好的 Agent 執行團隊像生產線：持續運作、能最佳化、能學習，跟人對齊，隨時看得懂。
2. 人定義目標：以市場、客戶與成果為標竿。AI Agent 只會「做」，做跟成果是兩件事；要的成果，決定人怎麼派工。
3. 人跟人的 scope 盡量拆開，每個人都要理解整個系統。重心從親手做，變成持續對齊、持續決策。

這就是講者說的弔詭：AI 替你實作了，你反而要更了解整個專案。

編按：小團隊明天就能用的開工檢查表

🧭 一句話總結：AI 時代最重要的是判斷力

三個層次各一句：一個人用 AI，規格當鷹架，蓋完就收；一個人帶 Agent Team，Agent 專心做事，人負責看見脈絡；一群人加一群 Agent，實作交給 AI，人負責理解、探索與決策。

講者最後的看法是：AI 時代最重要的是判斷力 —— 決定做什麼的判斷力，靠的是眼光與品味；過程中的判斷力，則是在 AI 給的大量雜訊與發散選項裡找出真正的訊號。這些都憑個人的認知，而 AI 可以拓寬認知：他創業後沒請會計師和記帳師，自己靠 AI 學會計與記帳，再用 AI Coding 寫一套系統自己作帳。他的結語：這是充滿機會的時代，拓寬你的認知，然後跑起來。