新創老闆自己用 AI 做出可執行的原型，確認方向後再交給工程師整合上線，可以讓創意驗證與正式開發分開，既保有速度也維持品質。蒲公英創意商業研究所是一家 AI 應用新創，主打 MAXO 這個商業顧問平台。依公司負責人在 2025 年底受訪時的說法，團隊從二十多人縮到六人，其中三位工程師精簡為一位，營收約為二十多人時期的三倍。這篇文章整理分工前後的差異、這種做法成立的條件，以及功能變得太容易做之後，如何避免產品變成拼裝品。
這家公司原本遇到什麼問題？
MAXO 團隊初期約二十多人，各自負責不同系統，預算有限、薪資偏低，管理成本與人員流動成為隱形成本，需求在工程師之間轉譯也讓開發過慢。
蒲公英創意商業研究所過去做過 AI 心理諮詢好閨蜜、AI 酷牧師，受訪時主打 MAXO，結合商業顧問思維、行銷模型理論與 AI 技術，替企業提供行銷與經營策略建議。
公司成立初期有二十多人，預算有限，薪資結構偏低，人員流動率高。人數變多之後，負責人除了推動產品與市場，還要花大量時間處理員工之間的衝突與情緒，這些隱形成本成了組織的負擔。
另一個問題來自溝通。負責人不是軟體專業出身，他提出新點子時，工程師常回覆「技術上做不到」，但他無法判斷這是真的做不到，還是不想做、不會做，或沒真正理解他想解決的問題。對主打 AI 的新創公司來說，開發半年才完成的系統，可能已經錯過最佳時機，所以流程太慢是致命傷。
他們怎麼調整人力配置與流程？
公司把三位工程師精簡為一位，把薪資總額集中給這位必須善用 AI 寫程式的工程師；新點子則由老闆先用 AI 做原型，確認方向後才交工程師整合。
負責人做了兩個調整。第一個是人力：三位工程師的員額縮減為一位，原本三個人的薪資總額集中給這一位，唯一的要求是熟悉並善用 AI 寫程式。他觀察到兩個效果：較高的薪資讓員工更願意長期投入、更願意與老闆密切配合；加上 AI 輔助，這位工程師的產能高於過去聘請的三位未使用 AI 開發的工程師總和。
第二個是流程：有新想法時，不再由工程師先做原型，而是老闆自己用 Vibe Coding 建立可執行的原型，快速測試市場需求與使用情境；確認「就是這個方向」之後，才把已經跑得動的原型交給工程師，由工程師負責架構優化、品質把關與正式上線。
| 項目 | 調整前 | 調整後 |
|---|---|---|
| 團隊人數 | 二十多人 | 六人 |
| 工程師 | 三位，薪資偏低 | 一位，集中三人薪資總額，要求善用 AI 寫程式 |
| 誰先做原型 | 工程師 | 老闆用 AI 自己做 |
| 工程師負責什麼 | 從原型到上線的整條流程 | 架構優化、品質把關、正式上線 |
| 老闆需要判斷什麼 | 無法確認工程師回覆的「做不到」是否屬實 | 先用原型驗證方向，再決定要不要投入工程資源 |
老闆先做原型、工程師後整合的調整，把創意驗證與正式開發分開，驗證階段求快，正式上線階段求穩。
成果是什麼？這些數字該怎麼讀？
受訪者確認成果指的是營收，約為二十多人時期的三倍，人力縮減約七成；比較期間未提供，也沒有利潤或人均產值的數字。
下表整理受訪者的說法與本文的處理方式。
| 項目 | 受訪者的說法 | 本文如何看待 |
|---|---|---|
| 人力 | 從二十多人縮減為六人，縮減約 70% | 公司同意公開；以受訪時的自述為準 |
| 成果指標 | 營收約為二十多人時期的三倍 | 指標已確認為營收；比較的期間未提供 |
| 受訪時間 | 2025 年底 | 數字反映該時間點的自述 |
三點要注意。第一，這些都是公司負責人的自述，沒有第三方查核。第二，營收變多不能直接歸因於人力調整，產品、市場與定價都會影響結果。第三，營收三倍不代表利潤三倍，文中沒有成本與利潤數字，讀者不能把它當成利潤成長。
這種分工適合什麼樣的公司？
這種分工適合需要快速驗證市場、產品迭代快的 AI 應用新創，且老闆具備產品判斷力，並有一位善用 AI、願意為品質負責的核心工程師。
| 條件 | 為什麼重要 |
|---|---|
| 需要快速驗證市場、迭代速度快 | AI 技術與市場變動快，開發太久會錯過時機 |
| 老闆有產品判斷力，能分辨哪些功能值得做 | 原型很容易做，判斷做什麼才是困難的部分 |
| 有一位善用 AI 的核心工程師 | 原型交接之後的架構、品質與上線仍需要工程判斷 |
| 工程師的薪資與責任相稱 | 受訪者認為集中薪資能提高投入度，也更願意與老闆配合 |
| 原型與正式系統有明確的界線 | 避免把驗證用的原型直接當成正式系統上線 |
最後一點尤其重要。Anthropic 的 Claude Code 官方文件建議，給 AI 一個它能自己執行的檢查，例如測試，若無法驗證就不要上線（Anthropic，Claude Code Best practices）。老闆做的原型能驗證方向，不代表資安、權限與測試已經完成，這正是工程師接手的原因。
功能變得很容易做之後，怎麼避免產品越做越亂？
受訪者認為 Vibe Coding 最大的陷阱，是想到什麼就叫 AI 做什麼；要先寫需求說明書、定義目標與完成標準，否則功能越加越雜。
負責人反覆強調這一點。如果沒有先完成需求說明書、沒有先定義目標與完成標準，只會陷入反覆修改、卡關與無止盡重來。他的原則是：先想清楚目標再動手，不能邊做邊改、沒有結構地亂試。
他也提醒另一個風險。AI 讓開發功能變得太容易，如果缺乏清楚的產品定位與市場需求掌握，就容易不斷新增彼此差異大、方向不一致的功能；當功能增加的速度超過策略整合的能力，產品會逐漸失去一致性，變成堆疊各種想法的拼裝品。
負責人的觀察與產品管理的討論相呼應。InfoWorld 的評論文章指出，挑戰已從「沒時間做想做的功能」，變成「沒時間決定不做什麼」，並認為開發者能快速加入功能，可能繞過原本的審查流程（Nick Hodges，InfoWorld，2026 年 4 月）。
下表是我整理的新增功能前檢查，不是受訪者的清單。
| 動工前先問 | 沒有答案時的風險 |
|---|---|
| 這個功能解決哪一種使用者的什麼問題？ | 功能越加越多，卻沒有人在用 |
| 怎樣算做完？驗收條件是什麼？ | 反覆修改，沒有結束點 |
| 與現有產品定位一致嗎？ | 產品變成拼裝品 |
| 做了這個，要放棄什麼？ | 沒有取捨，資源被分散 |
| 誰負責後續維護與下架？ | 功能變成沒人管的負擔 |
常見問題
老闆自己用 AI 做原型，還需要工程師嗎？
需要。受訪者的做法是老闆先做原型，確認方向後由工程師負責架構優化、品質把關與正式上線。原型驗證方向，不能取代資安、測試與長期維護。
把三位工程師換成一位高薪工程師，一定比較好嗎？
不一定。這是受訪公司在特定條件下的選擇：產品迭代快，且那位工程師善用 AI。受訪者認為較高薪資提高了投入度，但這不是所有公司都適用的結論。
營收三倍是怎麼算的？
依受訪者的說法，是六人團隊的營收約為二十多人時期的三倍，比較的期間與營收口徑沒有進一步提供，也沒有利潤的數字。
老闆做原型的最大風險是什麼？
想到什麼就請 AI 做什麼，沒有先定義目標與完成標準，導致功能增加的速度超過策略整合，產品變成拼裝品。受訪者的對策是先寫需求說明書。
沒有技術背景的老闆，要怎麼判斷工程師說的「做不到」？
受訪者的方式是自己先用 AI 做出可執行的原型，用成品與工程師討論可行性，而不是只靠口頭描述。
資料來源與說明
本文整理自我在撰寫書稿期間，對公司負責人的訪談，受訪時間為 2025 年底，內容為受訪者自述，公司同意公開公司名稱與縮編數字。人力與營收變化未經第三方查核；營收比較期間與口徑未提供。公司與產品的公開資訊引自官方網站。
參考資料
- 蒲公英創意商業研究所，〈MAXO〉，官方網站，存取日期：2026 年 10 月 19 日。
- Anthropic，〈Best practices for Claude Code〉，現行文件，存取日期：2026 年 10 月 19 日。
- Nick Hodges，〈A new challenge for software product managers〉，InfoWorld，2026 年 4 月 29 日，存取日期：2026 年 10 月 19 日。
延伸閱讀
- 社工先做出原型，再交工程師整合：AI 如何改善需求溝通？：同樣是原型先行、IT 整合，主角換成領域專家。
- 程式寫得更快，專案為什麼仍然很慢？從等待、交接與審查找瓶頸：為什麼人多與交接多會讓專案變慢。
關於作者
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2026-10-19