最近的 Lenny‘s Podcast（如下），訪談了 LinkedIn 產品長 Tomer Cohen，其中有一個發人省思的資訊，就是 LinkedIn APM（Associate Product Manager）計畫將結束，改成 APB（Associate Product Builder）計畫。
Tomer Cohen 直言：「只會寫 PRD、畫流程圖，卻無法親手創造產品的人，不再是未來的領袖。」 這也象徵舊時代的落幕。
過去二十年，為了應對軟體複雜度，我們建立了複雜的分工：產品經理定義問題、設計師定義互動與畫面、工程師實作。這種「流水線」模式在實作成本極高的時代，是必要的風險控管。然而，當生成式 AI 讓實作門檻大幅下降時，這套分工體系因層層交接產生的巨大損耗，反而成了效能最大的瓶頸。
這篇文章，讓我們深入探討這場從「分工」到「建造」的革命，究竟是如何發生的。
進入正題。
我目前在做電子報讀者問卷調查，希望了解各位讀者的想法與偏好！想麻煩你花個 5 分鐘，幫我填個問卷！謝謝！
一、為什麼需要 Builder？
在傳統流程中，一個想法從產品經理的腦中到最終上線，需要經過多次轉譯（商業目標 → PRD → UIUX → 程式碼）。每一次轉譯都伴隨著資訊落差。我們花費大量時間在對齊與解釋，這些「協作摩擦力」往往超過了實際「動手做」的時間。生成式 AI 工具（如 Cursor, v0, Lovable）的核心價值，在於消除「想法」與「實作」之間的摩擦力。
近期，許多矽谷意見領袖開始嘗試改變，提倡 Product Builder 的概念：
Tomer Cohen (LinkedIn CPO)： 他在 Lenny’s Podcast 中強調，傳統流程導致了過度專業化（Microspecialization）。Builder 模型是為了讓開發者回歸「第一性原理」，具備跨職能的 Vision, Empathy, and Judgment。
Julie Zhuo (Sundial Co-founder, Ex-Meta Design VP)： 她指出「傳統軟體開發已死」，未來的核心競爭力將從「手作工藝」(Craft) 轉向「品味與策展」(Taste & Curation)。
Claire Vo (LaunchDarkly CPO)： 她身體力行，身為高管卻利用週末寫出 ChatPRD，主張產品經理應成為 AI 的駕駛員，直接掌控產品細節。
我們接下來看看這在日常工作中是如何體現的。
二、Builder 的一週 vs. 傳統的一週
關於 Builder 模式，我觀察內部團隊與問了一些朋友，發現新的 Builder 模式跟傳統模式有許多不同。為了具象化這個概念，以下列出兩種模式在面對同一個任務時的差異。
傳統模式的一週：線性推進與高度協作
這是一個標準的產品團隊，注重流程協作。
週一 (Alignment)： 確認商業目標，評估可行性與規範。
週二 (Documentation)： 產品經理撰寫 PRD。
週三 (Design Review)： 設計師產出 Design Mockup 。工程師指出元件限制，建議修改設計。
週四 (Spec Review)： 規格定案。工程師開始規劃架構與拆票。
週五 (Planning)： Sprint Planning，將任務排入下週。
結果： 產出了文件與共識（這已經算快的了），但沒有一行可執行的程式碼。
Builder 模式的一週：平行迭代與極速驗證
這是一個利用 AI 賦能的小型 Pod，注重速度與成果。
週一 (Prototyping)： 利用 vibe coding 工具，直接生成第一個粗略但可互動的版本 (v0.1)。
週二 (Feedback)： 丟給使用者或利害關係人試用，收集回饋與數據。
週三 (Refine)： 根據反饋，利用 vibe coding 工具修改介面與功能。
週四 (Review)： 帶著可運作的 v0.2 找資深架構師審查資安與效能。
週五 (Launch)： 微調樣式，部署至 Staging 進行流量測試。
結果： 經歷數次迭代，並已有一個可供用戶使用的 MVP。
看到這你可能覺得，這也太神了吧！
其實，效率的提升只是表象，真正驅動這種速度的，是角色行為本質的改變。
三、角色的演化：技能邊界的消融與融合
AI 時代最顯著的變革，不在於職稱的改變，而在於角色行為本質的改變與職能邊界的模糊化。傳統的「分工」—產品經理的文件、設計師的設計圖稿、工程師的程式碼——正在被 AI 弭平。
在 Builder 模式下，我們不再侷限於單一技能，而是利用 AI 作為輔助，直接跨入其他職能的專業領域：
產品經理也能動手實作 (The Building PM)： 過去，產品經理驗證想法靠的是嘴巴和文件。現在，產品經理可以利用 v0 或 Lovable 直接生成可互動的前端原型，甚至用 Cursor 寫出簡單的後端 API。懂實作的產品經理將能以十倍速驗證商業假設。
設計師也能交付程式碼 (The Coding Designer)： 過去，設計交付的是靜態的 JPG 或 Figma 連結，還要來回與工程師對齊像素。現在，設計師利用 AI 可以直接產出高品質的程式碼。未來的設計交付物是「可運行的介面」，設計師將直接對最終產品的體驗負責。
工程師也能主導產品 (The Product Engineer)： 過去，工程師是被動接收需求的實作者。現在，當寫程式碼變得極快，工程師有更多時間去理解用戶需求與商業目標。具備產品感 (Product Sense) 的工程師不再需要詳細的規格書，他們能直接將用戶洞察轉化為系統架構，從「碼農」進化為「建築師」。
LinkedIn 實戰案例：Trust Agent 與全端閉環
為了證明這並非理論，Tomer Cohen 分享了 LinkedIn 內部的 「Trust Agent」案例。
在過去，要處理平台上的詐騙檢測，需要跨部門的漫長協作：PM 寫規格、資料科學家跑模型、工程師寫規則。轉型後，LinkedIn 建立了一套內部 AI 工具庫。一位 Product Builder 能夠直接使用 Trust Agent 模組構建檢測邏輯，並利用 Maintenance Agent 自動修復構建錯誤。這位 Builder 不需要等待後端資源，獨自完成了「構建-測試-修復」，將原本數週的流程大幅縮短。
當然，新的模式也伴隨著風險，我們必須了解這個模式最合適的情境，以及隨之而來的問題。
四、現實的挑戰：場景與機制
Builder 模式雖好，但絕非萬靈丹，我們需要一些界線與機制。
1. 適用情境：速度 > 完美
在這些情況下，Builder 模式能發揮最大價值，因為「驗證的價值」遠高於「程式碼的優雅度」：
0 到 1 的 MVP 開發： 當產品還在尋找 PMF (Product-Market Fit) 時，最重要的是「快」。寫出能跑的 Code 比寫出完美的 Code 更重要。
內部工具 (Internal Tools)： 如後台管理系統、數據儀表板。這類需求通常被工程團隊排在優先級最後，Builder 利用 AI 可以在幾小時內搞定，大幅提升營運效率。
一次性行銷活動頁： 生命週期短，不需要長期維護，適合快速生成與拋棄。
產品探索 (Prototyping)： 在正式開發前，先做出一個「高保真」的可互動版本來測試用戶反應，避免工程團隊浪費時間開發沒人要的功能。
2. 不適用情境 ：風險控管 > 速度
在追求極致速度前，必須先評估風險。以下場景應維持傳統的嚴謹分工：
高風險領域： 醫療器材、航空軟體、自動駕駛。容錯率為零，安全審查高於一切。
核心交易系統： 銀行結算核心、高頻交易、支付網關。邏輯的準確性與一致性遠比開發速度重要。
極大規模協作： 當程式碼庫涉及數百人同時協作，或需維護長達十年的 Legacy Code 時，嚴格的規範與權限管理仍是必須。
3. 平衡機制：雙軌制與守門員 (The Gatekeeper Model)
對於大多數網路產品，我們可以採用雙軌制來平衡速度與品質：
沙盒區 (The Sandbox)： Builder 利用 AI 快速生成 MVP。這些程式碼嚴禁直接進入核心程式庫，僅用於證明市場需求。
核心區 (The Production)： 當 MVP 驗證成功，需正式併入時，必須經過資深工程師嚴格的 Code Review，確保資安與架構合規。
了解適用的情境與保護機制後，接下來的問題是：我們該如何組織這些 Builder？
五、團隊組合策略：打造你的戰鬥小隊 (The Pods)
我認為全能 Builder 是風毛麟角，是很難尋的，所以在組織中，「混合型 Pod」 可能是更務實的作法。
組織內的 Builder vs. 一人公司 (Solopreneur)
一人公司 (One-Person Unicorn)： 追求的是極致的個人效率。他們通常使用 No-Code 或全新的技術，沒有歷史包袱，目標是快速變現。
組織內的 Builder (Organizational Builder)： 追求的是規模化槓桿。他們必須在現有的架構（Legacy Code）、合規要求（Compliance）與品牌規範下工作。因此，他們更需要 Pod（小隊） 的形式來互補技能，而非單打獨鬥。
實戰 Pod 模式建議：
A. UX Heavy Pod (體驗驅動型)： 適合 UX 很關鍵的產品。成員為產品設計師 + 前端工程師。將產品經理角色內化，體驗至上。例如 Linear 早期完全不設產品經理，依賴具備產品品味的工程師與設計師協作。
B. Data/Platform Heavy Pod (資料、邏輯密集型)：成員為 技術產品經理 + 後端工程師。利用 AI 做驗證、測試而非生成 UI。
C. Highly Uncertain Pod (0-1 探索型)： 適合 MVP，成員僅 1-2 位 Builder，大量使用 No-Code/AI 工具加速驗證。
不同的產品，可能會有不同的角色組合。跟過往不同的是，這個組合將是人少質精的精銳部隊。
六、行動指南：給 AI 時代的個人與組織
最後我們來看個人與組織具體該如何開始行動。
給個人：成為通用的 Builder
打破邊界： 不要再說「我不會寫 Code」或「我不懂商業」，通才（Generalist）的價值在於整合多專業解決問題。
掌握創造系工具： 停止紙上談兵。用 Cursor/Windsurf 輔助寫程式，用 Lovable/v0 生成產品原型，將模糊想法轉化為可互動原型。
系統性思維： 產出變容易後，「知道為什麼」、「會問問題」更重要。
給組織：打造 Builder 友善的環境
招聘重定義： 面試加入實作題：「利用 AI 在 30 分鐘內做出可互動 Prototype」。尋找多專長的人才。
建立黃金樣本： 建立內部 AI Library，提供符合規範的元件與 API 模板，讓 AI 調用標準化積木，降低技術債。
啟動 Pod 試點： 挑選非核心專案，給予小隊 AI 權限並免除繁瑣的流程，觀察迭代速度。
小結
AI 是通才的賦能者，讓我們第一次能用「產品本身」來溝通，而不是用「文件」來溝通。
AI 時代，工具已經就位，這場革命不是要讓每個人都變成工程師，而是釋放被繁瑣流程困住的創造力，請回歸到我們的初衷：Build something people love.
我們下個月見！