Build vs. Buy 正在反轉：AI 讓「自建」變成更聰明的選擇

本文整理自《Open Source Startup Podcast》2026 年 4 月播出的單集。

{{< spotify "episode/16XYNGopatgVbDwgTHgTch" >}}

{{< apple-podcast "tw/podcast/e193-managing-100s-of-agents-with-maestro/id1548524534?i=1000760356283" >}}

---

當「買」不再是理所當然

企業軟體市場有一條長期不變的預設邏輯：如果市場上有現成的解決方案，就買；只有在需求非常獨特、或者涉及核心競爭力的時候，才值得自己建。這條邏輯背後的理由很充分：自建軟體需要招人、維護、升級，如果負責的工程師離職，整個系統可能就斷了。購買套裝軟體把這些風險轉嫁給供應商，用授權費換穩定。

但 AI coding agent 的出現正在從根本改變這個等式。開源 agent 編排平台 Maestro 的創建者佩德拉姆．阿米尼（Pedram Amini）觀察到，他看見越來越多企業和開發者選擇「建」而非「買」，因為「規模經濟已經到位了。使用門檻夠低，你可以把它做成完全符合你特定工作方式的樣子。」這不是一個人的直覺判斷，而是正在產業各個角落同步發生的結構性變化。

Amini 的背景讓這個觀察更有說服力。他過去 20 年在資安產業做創業和產品，經常面對客戶的 build vs. buy 質疑。「以前做資安新創的時候，你去跟客戶提案，他們腦子裡想的是：我該買你這個方案，還是自己內部建一個？」他回憶。「一般來說，結論是偏向買的，因為自建的維護成本和人員流動風險太高。但我覺得這個天平如果還沒完全翻轉，至少已經在翻轉的路上了。」

Stripe 的啟示：每家公司都會有自己的 Agentic 工作流

Amini 在訪談中特別提到 Stripe 近期公開的技術部落格，詳述了他們如何建立內部的 agentic coding 系統。那套系統高度客製化，以 Slack 為介面，結合了各種專屬的自動化流程和品質管控機制。Amini 的評價是：「超級客製化（super bespoke）。任何在這個領域的人都該去讀一下。」

這個案例的啟示不在於 Stripe 的具體做法，而在於它揭示的趨勢方向。一家有能力購買任何企業工具的公司，選擇了自己打造整套 AI 開發工作流。原因很簡單：每個團隊的程式碼架構不同、協作模式不同、品質標準不同，通用型工具永遠只能滿足最大公約數的需求。而現在，用 AI 來填補通用工具和真實需求之間的差距，成本已經低到足以讓「自建」重新成為理性選擇。

這個現象不只發生在 Stripe 這種科技巨頭。Amini 觀察到，光是和 Maestro 類似定位的開源專案就有至少十幾個，而且持續冒出來。「我看過好幾個長得很像 Maestro 的專案出現，我甚至主動聯繫那些作者，問他們要不要合併。但大家都想繼續做自己的版本。」這不是重複造輪子的浪費，而是需求真的不同。每個開發者、每個團隊對 agent 的配置、觸發條件、品質把關流程都有自己的偏好，而這些偏好很難被一個統一的產品完全覆蓋。

為什麼 AI 改變了 Build vs. Buy 的經濟邏輯

要理解這個翻轉，需要拆解「自建」過去最大的三個成本來源，然後看 AI 如何削減它們。

第一是開發速度。過去自建一套內部工具，從需求分析到上線可能需要數月。但 Amini 示範了一個新的節奏：白天和 AI 討論需求，讓內建的「信心指標」達到 80%，然後自動產出開發規格文件，夜間讓 agent 無人值守地執行。一個中等複雜的功能大約 6 小時就能從概念走到初版。當開發速度從「月」壓縮到「天」，自建的時間成本就不再是決策的阻礙因子。

第二是維護負擔。傳統自建工具最大的風險是「如果寫這段程式碼的人走了怎麼辦」。但在 AI 輔助開發的時代，程式碼本身的可維護性提升了，因為 AI 鼓勵（甚至強制）你寫清楚的文件和設定檔。Amini 把所有的 agents.md、Claude.md 設定檔都放在 repo 裡，「這樣任何人 fork 這個專案，都能用和我一樣的方式開發。」當知識不再鎖在某個人的腦袋裡，而是編碼在設定檔和規格文件中，人員流動的風險就大幅降低。

第三是規模化的難度。過去只有大公司有資源自建工具，因為需要專職團隊。但 Amini 的案例顯示，一個人加上 AI agent 的生產力可以匹敵一個小型工程團隊。他在 90 天內產出了超過百萬行程式碼，Maestro 目前 85% 的程式碼仍是他本人寫的（或者更精確地說，由他指揮 AI 寫的）。當「一個人就能維護一套複雜系統」成為可能，自建工具不再需要養一個團隊。

非工程師也能「建」：門檻正在消失

但這裡還有一個更大的變化：「自建」的門檻不再限於工程師。Amini 分享了一個令人驚訝的案例：他的一個朋友是醫療新創的負責人，技術背景但不是工程師。經過兩個一小時的 Maestro 教學後，這個人的產出超越了他自己的工程團隊。不是超越其中一個人，是超越整個團隊。

「如果你知道自己想要什麼、能清楚表達你想要什麼、而且願意花時間使用產出並持續迭代，你就能解決問題。」Amini 如此解釋這個現象。「打磨到生產級，意味著你是這個產品的頭號使用者。你建出來之後自己用，每個按鈕都按、每條路徑都走、每個不對的地方都描述給 agent 聽，讓它修正、部署，然後重複，直到達到生產品質。」

這段話揭示了 build vs. buy 翻轉的更深層意義：過去「建」需要的是工程能力，現在需要的是需求表達能力和品質判斷力。一個對領域有深刻理解的產品經理或業務主管，加上 AI 工具，可能比一個不了解業務脈絡的全端工程師更能「建」出好用的內部工具。技能的重心從「寫程式碼」轉移到了「清楚表達需求 + 有耐心地測試和迭代」。

我的觀察：「客製化」是新的標準配備

我自己的工作流就是這個趨勢的縮影。我用 Claude Code 搭配一整套自訂的 hooks、Markdown 規格文件和自動化腳本來做內容生產。這套系統沒有任何一個現成的 CMS 或寫作工具能完全取代，因為它融合了我個人的寫作風格規範、翻譯詞庫、Hugo 部署流程和三遍審校 checklist。一年前，建立這套東西需要請一個工程師幫忙；現在我自己和 Claude Code 就搞定了。

從 Claude Code 的使用經驗來看，Amini 提到的「provider lock-in」（工具鎖定）是真的。我在 Claude Code 裡建立的 hooks、skills、memory 設定和 CLAUDE.md 檔案，形成了一個高度客製化的工作環境。這些東西不容易遷移到其他平台，但這恰恰也是它的價值所在：它是為我的特定工作方式量身打造的，任何通用工具都做不到這個程度的貼合。

這讓我想到一個更宏觀的觀察：我們可能正在從「標準化工具 + 客製化流程」的時代，走向「客製化工具 + 標準化介面」的時代。過去，每個人用同一套 Notion 或 Google Docs，但用法各異。未來，每個人（或每個團隊）用自己打造的工具，但透過 MCP 這類開放協定互相串接。工具本身變成可拋棄、可重建的，真正有價值的是你對需求的理解和對品質的判斷。

這不是「套裝軟體已死」，而是重新分工

需要澄清的是，build vs. buy 的翻轉不代表所有套裝軟體都會消失。更精確的說法是：通用型、橫向的工具（email、行事曆、基礎 infra）仍然值得購買，因為它們的使用模式高度標準化。但垂直型、涉及核心工作流的工具，會越來越傾向自建。

Amini 自己就是最好的例子。他不會自己寫一個 email 客戶端或一個 GitHub，但他為自己打造了一整套 agent 編排系統，因為這是他核心工作流中最關鍵的一環，沒有任何通用產品能完美契合。「我覺得每家公司都會有自己的細微差異做法，」他判斷，「這可能就是為什麼你看到像 Maestro 這樣的工具大爆發。」

對於企業決策者來說，這意味著需要重新思考技術投資的分配。過去大量預算花在購買和整合第三方工具，未來可能需要更多投資在「讓內部人員具備 AI 協作能力」上。買一套工具是一次性決策，但培養團隊用 AI 自建工具的能力，是持續產生回報的投資。而且這種能力一旦建立，就不會被任何供應商的定價策略或產品方向轉變所綁架。