工程師與 PM 的融合

資料來源#

• Andrew Ng: The Biggest Opportunities in AI Aren't Where You Think
• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next
• Designing with Claude: From prompt to production
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
• State of AI 2026: The Builder's Economy
• Thread by @AndrewYNg
• Why Netflix is betting on systems thinkers—not specialists—in the AI era | Elizabeth Stone (CPTO)

摘要#

Boris Cherny（Sequoia AI Ascent 2026）和 Cat Wu（Lenny's Podcast，2026 年 4 月）都從 Anthropic 內部觀察到同一趨勢：職務正在融合。工程師承擔 PM 工作，PM 撰寫並交付程式碼，設計師也交付程式碼；Claude Code 團隊每個職能角色都會寫程式。融合後的職務共同仰賴一項關鍵能力：產品品味——既然打造產品的成本已經很低，判斷該打造什麼便成了要務。這挑戰了傳統的跨職能團隊模式（一位 PM、一位設計師、數位工程師，另有獨立的 eval/QA），並指向由少數高脈絡通才組成的小團隊，讓每個人都能各自負責從頭到尾的交付。

Anthropic 實際上發生了什麼#

以下是 Cat Wu 的說法：

• Claude Code 團隊人人都寫程式——工程經理、產品經理、設計師、資料科學家、財務人員、使用者研究員都包括在內。
• 設計師以前是前端工程師。
• 「我們團隊有很多工程師，完全有能力從頭到尾獨立完成：在 Twitter 上看到使用者回饋，到週末前推出產品，幾乎不需要產品團隊介入。」
• 招募偏好：「我們非常重視聘用具有出色產品品味的工程師。」
• Boris 和 Cat 的分工是「80% 心有靈犀，20% 由領域分工驅動」。

以下是 Boris Cherny 的說法：

• 「跨領域通才」——工程師也擅長設計，或兼具產品與資料科學能力。
• 「我們團隊人人都寫程式。」
• 「產品工程師」的典型組合（iOS、網頁、伺服器）只是通才的基本門檻；新的模式是跨領域通才。

以下是 Dan Carey（Anthropic Labs，打造 Claude Design）的說法：

• 開發期間大多時候團隊只有三個人；「團隊裡每個人什麼都做——工程師和使用者交談，PM 寫程式，設計師做資料分析。」
• 「這個團隊的職務界線基本上已經消失。」每個人仍保有自己的專業和獨特觀點，但任何時候，一個人都能訪談 10 位使用者、找出根本問題、設計解法、推出產品並持續迭代——「團隊裡大多數事情都完全由個人獨立完成。」
• 「Claude 是很不錯的團隊成員」——第三位隊友讓三人團隊能像更大的團隊一樣運作。

Anthropic 以外：同樣的融合，以及它可能出現的失誤#

Andrew Ng 從完全不屬於前沿實驗室的外部觀察到這個趨勢（2026 年 6 月，practitioner-opinion）——第三個獨立觀察角度：

「隨著程式碼代理程式加快軟體開發，愈來愈多工程師開始承擔部分產品管理職責……最難的是塑造產品願景，並在打造產品（填補願景與規格之間的落差）和取得使用者回饋、演進願景之間取得平衡。兩件事都很重要！」

Ng 也指出 Anthropic 的說法未提及的一種明確失誤模式。新近承擔產品職責的工程師，會在自己熟悉的那一半投入過多心力。打造產品很快、成果清晰，也很有趣；外部回饋迴路卻很慢、令人不快，而且無法自動化——於是它被略過，願景也就不再更新。他對趨勢方向的描述是對稱的：「工程師的角色擴大了（正如產品經理和設計師現在也承擔更多工程工作）。」

Ng 也不採用本頁著重的那個詞。Cat Wu 稱之為品味，他稱之為脈絡優勢——這不是通才刻意培養的能力，而是他們恰好掌握的知識。如果他說得對，「因品味而聘用」真正的意思就是「因貼近使用者而聘用」，而這種優勢會隨時間消退。

2026 年 8 月：融合擴展到產品與工程之外，並出現一項招募測試。在面向大眾的訪談中（Andrew Ng: The Biggest Opportunities in AI Aren't Where You Think，Silicon Valley Girl，2026-08-28，practitioner-opinion），Ng 點出 Cat Wu 描述的瓶頸——「打造產品的成本大幅下降，所以挑戰轉向決定要打造什麼……我一直稱之為產品管理瓶頸」——並以貼近使用者，而非品味，作為解方：「能和客戶交談、培養判斷該打造什麼的品味，接著用 AI 打造並快速迭代的創辦人、工程師和產品經理。」他描述的融合方向與本頁不同：不是工程師吸收產品工作，而是每種職能都吸收工程工作。「我所有的行銷人員都會寫程式。所以，面試行銷人員時，我們會問他們做過什麼。」其中一人打造了一款桌面應用程式，能在他撰寫文章時爬梳相關研究；一位 CFO 寫了腳本來開啟文件、檢查一致性並標記需要關注的地方；招募團隊裡則有「招募工程師……坐在招募團隊裡的專業工程師。」他把這概括為一組職稱——「招募工程師、行銷工程師、人資工程師」——以及從團隊 AI 工程技能地圖得到的發現：「愈來愈多職缺描述似乎都希望應徵者展現很強的主動性」；相對地，有些經理會告訴員工「待在自己的職責範圍內」。這就是 Cat Wu 所說的「動手去做」成為職缺描述關鍵字。仍須保留必要的折扣：這是一位雇主描述自己所挑選團隊的說法（他說「我的團隊可能……稍微走在趨勢前面」），而「你做過什麼」是招募篩選條件，不是對通過篩選的行銷人員實際產出的衡量。至於非工程師打造產品在整體人口中究竟是普遍做法，還是選才造成的效果，則是印刷術式的軟體民主化仍待回答的問題。

前沿實驗室之外的調查（ICONIQ，2026 年第二季）#

Anthropic/OpenAI 的說法是前沿實驗室的自述；ICONIQ 的 State of AI 2026 調查了約 305 家打造 AI 產品的軟體公司（empirical），顯示這種融合更為普遍。AI 業務占比高的公司，跨職能程度更高（AI 營收占比達 50% 以上者為 42%，低於此比例者為 35%），組織也更扁平（規模達 1 億美元以上時，72% 將管理層級控制在 1 至 4 層，低比例組別則為 56%）——這些都是職務融合的結構前提。交流案例也呈現出這種融合：一位業者「把 PM 和設計師的職責合併，由一人負責產品」，RevOps 團隊則「用 AI 原生人員取代不熟悉 AI 的 RevOps 招聘人員」。這是否印證了 Cat Wu 的小型通才團隊模式，還是會退化成 Ambrosino 警告的專業能力流失，正是尚待釐清的張力——ICONIQ 衡量的是大規模的職務融合正在發生，而不是融合後是否仍保留各項專業。

企業規模的觀點：有邊界的流動性（Netflix）#

Elizabeth Stone（Netflix CPTO，2026 年 7 月，practitioner-opinion）也在維基記錄中最大型的非實驗室組織確認了這項趨勢，並且最明確地談到其界線。她在 Netflix 聽見職務混淆帶來的挫折（「我現在到底該做什麼？」），並將其視為「形成期之前的震盪期」。PM、設計師和資料科學家如今「可以在工程師真正需要走到最前線之前，把產品開發生命週期推進得更遠」。但只有在業務問題明確，而且工程夥伴知情時，這種流動性才獲得認可——「這不是把一堆義大利麵丟到牆上看看會不會黏住」——她也劃出實驗室說法未曾強調的界線：「我認為這代表任何人都該把程式碼交付到正式環境嗎？大概不該。」

她對專業的主張則為全面融合提供了制衡，也呼應了 Ambrosino：各職能的相對優勢依然存在——資料科學家知道資料是否可信，PM 知道要做什麼是否界定得當，工程師則了解如何做（規模、品質、部署後果）。「我仍然認為精湛的專業能力非常重要……優秀工程人才仍然稀缺，優秀的資料科學人才仍然稀缺，出色的創意仍然稀缺。」角色能說更多種語言，但專業的核心依然存在。組織層面上，她仰賴的推動條件是基礎設施，而非協調：唯一真實來源的資料、正式環境防護措施，以及反覆重申的人類責任（「即使是代理程式寫了程式碼……也不代表人就不必負責」）——詳見系統思維勝過專業分工。

品味論點#

「寫程式碼的成本大幅降低後，決定要寫什麼就更有價值。」

— Cat Wu

程式碼生成成本正在下降。瓶頸往上游移：

• 從 10K 個 GitHub 問題中挑出要推出的功能
• 設計 UX，展現模型的優勢並彌補其弱點
• 判斷何時應以研究預覽的形式推出功能，何時應做成完整產品
• 分辨人們嘴上說想要的 90 項功能，和他們實際會用的 10 項功能

這就是產品品味，而且不受職稱限制——工程師、設計師、PM 都可能具備。具備這種品味的人能把產品好好推出；缺乏品味的人推出的產品則會偏離方向。

為什麼是現在（Lenny 的不同看法）#

在 Cat 的訪談中，Lenny 提出反方觀點，並引用 Anthropic 成長主管 Amol Avasare 先前的一集節目：Amol 表示他需要更多 PM，因為工程師推出產品的速度太快，設計師和 PM 跟不上——每天都有新功能。

Cat 同意情況可能如此，但 Claude Code 偏好的路徑是聘用具有品味的工程師：這類人少聘一些，擴大其影響力，減少協調交接。

兩種說法並不矛盾，而是描述不同的團隊型態：

• **Cat 的模式：**高自主性通才組成的小團隊（Claude Code，約數十人）
• **Amol 的模式：**規模較大的組織中，工程師進展快速，需要 PM/設計支援以跟上步調（Growth、GTM、Enterprise）

不對稱之處：人類的 EQ 仍然重要#

Cat 指出尚未融合的工作：仰賴默會知識、常識和 EQ 的工作——知道與利害關係人溝通的適當場合、感覺得出產品是否準備好推出，也知道什麼才算公平的取捨。模型在這些方面有所進步，但還未達到所需程度；人類仍在產品發佈的各環節之間提供連結。

「動手去做」#

Cat 的人生座右銘：

「工作職稱都是虛構的。只要了解限制條件，就能想出自己能做什麼，然後試著快速去做，從錯誤中學習；如果做錯了，就道歉或修正。」

這是讓職務融合得以運作的文化基底。如果職務界線由 JD 劃定，就沒有人會跨職能行動。如果「需要做什麼就去做」成為常態，融合便會自然發生。

讓「動手去做」不致陷入混亂的，是使命一致性。Cat 說：「如果有兩個互相競爭的優先事項，我們會討論哪一個對 Anthropic 的使命更重要。這讓我們更容易決定該優先處理哪一件。決定之後，所有人都會支持我們選出的那一項。」

影響#

1. **不分職務，依產品品味聘用。**Cat 表明的門檻是：任何人只要能展現出色的產品品味，就符合條件。
2. **積極推動跨職能訓練。**如果你的設計師不交付程式碼，那是組織的選擇，不是限制。
3. **組成更小的團隊。**每個人都能負責端到端工作的五人團隊，交付速度勝過需要交接的十五人團隊。
4. **PRD 簡化。**Cat 說，模糊功能只需簡短的條列式 PRD；指標報告和團隊原則就能完成大部分共識工作；只有大型基礎設施專案才需要完整 PRD。
5. **職涯階梯將分化。**Cat 說，為了交付速度，「我們犧牲了產品一致性」；職涯階梯的一致性則是較不受注意的代價。

延伸閱讀#

• Task Crossover——在人口規模、科技業以外衡量到的融合：43.5% 的特定職業 ChatGPT 工作使用，其實屬於另一職業的工作；而交叉比例在最小型工作空間中最高——職務融合追隨的是組織規模精簡，不只是 AI 能力
• Implementation Abundance Inverts Product Work——OpenAI 一方對同一變化的流程層級說法：「決定要打造什麼成了瓶頸」
• 角色平均化，而非角色消失——Ambrosino 提出的反向提醒：歡迎融合，但不要抹去那些具有可知最佳實務的專業角色
• 外包你的思考，不要外包你的理解——融合後的通才必須保有理解能力，同時委派執行工作
• AI 時代的七大力量——角色融合為通才後，流程優勢逐漸消退
• Cat Wu——主要論述者
• Boris Cherny——同一團隊對融合趨勢的另一份報告
• AI Native Product Cadence——讓職務融合成為可能的節奏
• Claude Code Best Practices——Claude Code 以具有品味的工程師作為目標使用者
• 模型進步帶來的 harness 精簡——harness 愈小，「PM」角色的範圍愈小，「能交付產品的人」的範圍愈大
• 印刷術式的軟體民主化——方向相同，時間尺度不同：軟體素養擴大，職務差異模糊
• Agent Loop Pattern——到極限時，個別貢獻者能運行數十個代理程式，達成過去需要整個團隊才能完成的交付
• Human-AI Accountability Redesign——這種融合在全體工作者中的映照：代理程式承擔執行後，人類角色便集中在監督、判斷和監督品質上
• AI 採用的心理成本——在非前沿、受監管企業中觀察到的融合；改變方向的是建築師轉為工程師。一位建築師描述使用 Claude Code：「我突然隨身多了一位開發人員。」同事則提供了不那麼好聽的機制說明：「他們不再有開發人員對他們說不。」改變的不是建築師的技能，而是原本限制其職責範圍的人為關卡消失了；這正好反映了本頁所述品味與判斷故事的另一面：當某個職務過去受限於他人的執行能力時，融合就會率先從那裡開始。在這個案例中，採用 AI 後受益的是建築師，承擔代價的則是工程師
• AI Employee Framing——跨職能通才模式的反證：在人資/財務情境中，把 AI 描述成同事而非工具，會削弱個人責任，而不是擴大個人職責
• Compute Allocator——把「決定要寫什麼」這項瓶頸技能，重新表述為個別模型呼叫層級的問題（Thariq Shihipar）
• Living Design System——讓非工程師自行取得高保真素材的工具，是組織內職務界線模糊化的實際產物
• 創辦人作為代理程式編排者——把公司內職務融合延伸至創辦人／一人公司規模；方向相同，單位更小
• AI-Native Startup Lifecycle——創辦人／新創版的融合：逐階段縮減各職能專屬關卡
• Evals 即產品規格——典型的混合職務活動：PM 寫 evals、工程師寫 evals，雙方都以「十個優質 evals」作為共同的完成定義
• 經理作為個別貢獻者——Fiona Fung 將「人人都寫程式」延伸至組織階層：每位 Claude Code 經理都從個別貢獻者做起
• 以自我使用推動產品紀律——「兼具創造力、能打造產品且有產品感」是這種融合所催生、由自我使用回饋培養的招募特質
• Dan Carey／Anthropic Labs——以三人 Claude Design 團隊作為第二個案例：「每個人什麼都做」，職務界線已經消失
• Compounding Loop Optimization——小型且職務界線消失的團隊，讓「自己打造工具，獨自跑迴圈」成為可能
• 代理程式程式設計中的專業回報——「既然打造很便宜，決定要打造什麼」是瓶頸技能，且已在人口規模上受到衡量：領域／產品理解（而非寫程式）能預測誰善用代理程式，經理（具備委派品味）則有最高的已驗證成功率
• Conversation-to-Delegation Shift——OpenAI 的 Codex 研究在使用方式中觀察到相同融合：密集使用者「管理一系列代理程式工作」，將自身心力轉向委派、監督和整合
• Parallel Agent Orchestration——將職務融合具體化：運行一組並行代理程式就是個別貢獻者轉為編排者的改變，並附有採用數據
• AI 的組織互補條件——職務重設的互補條件：要實現 AI 的價值，需要能指揮、監督及整合代理程式產出的職務，而非直接執行任務
• AI 原生打造的三個迴圈——Andrew Ng 的第三方觀察，以及失誤模式：工程師轉任 PM 後，過度投入自己喜歡的內部迴圈，卻略過更新願景的外部迴圈
• 脈絡優勢，而非品味——Ng 對融合技能的重新詮釋：關鍵不是品味，而是貼近使用者；因此「因品味而聘用」是一種會隨時間消退的策略
• AI-Native Organization——整間公司的版本：ICONIQ 的跨職能及扁平組織數據，以及 PM 與設計師合併為一人負責產品的案例，都是對約 305 家 AI 開發公司中這種融合現象的衡量（見該頁的重組段落）
• 系統思維勝過專業分工——Stone 對組織層級融合的回答：配置鋪設完善的工作路徑與設計系統，讓流動的職務仍能一致地交付；並聘用能建立這些系統的系統思考者
• 卓越即營運系統——Netflix 支撐流動性的文化基底，與「動手去做」相呼應：以信任與責任取代職務界線
• Elizabeth Stone——企業規模的觀點：認可職務流動性，維持正式環境交付界線，專業人才仍然稀缺
• 承諾產物鏈——將融合寫入 SDLC 的職務描述。在 Anthropic 的 Applied AI 作業手冊中（vendor-claim，2026-08-21），產品負責人會審查自己未撰寫的需求與設計規格，在工程師看到之前，先與具名負責人逐一解決標記出的政策疑慮，再決定是否繼續建置——這本來是審查工程師的工作流程，如今交由產品職務負責，而文件列出的先決條件是*「不需要工程技能」*。同一份文件也呈現融合的另一半：工程師的建置階段包括撰寫計畫與提出問題，之後才會生成任何程式碼。

尚待回答的問題#

• 這種模式能否擴展到約 50 人以上、類似 Claude Code 的團隊？Boris 保留態度：「我想這會是未來數年都要面對的問題。」
• 在工程師承擔 PM 工作的公司裡，正式的 PM 職涯階梯會變成什麼樣子？根據 Cat 的說法，Anthropic 尚無定論。
• 跨領域通才是招募門檻——人才從哪裡來？轉職者，還是偏好 AI 原生教育的新鮮人？

衍生文章#

• 學習與 AI 協同工作：軟體工程師實用指南——把工程師與 PM 的融合轉化為個人職涯技能指引（將產品品味視為瓶頸技能組）
• 使用 AI 工具的看法與軟體工程師職務的未來——職務融合是軟體工程師職務未來綜合分析的核心支柱

資料來源#

• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next
• Thread by @AndrewYNg——Andrew Ng，The Batch（2026-06-30），practitioner-opinion：工程師承擔部分 PM 職務，以及平衡失誤
• State of AI 2026: The Builder's Economy——ICONIQ Growth，State of AI 2026: The Builder's Economy（2026-07-08，empirical）：§「人才與組織」中的跨職能／扁平組織數據，以及 PM 與設計師合併為一人負責產品的案例——前沿實驗室以外、人口規模上的融合
• Why Netflix is betting on systems thinkers—not specialists—in the AI era | Elizabeth Stone (CPTO)——Lenny's Podcast（2026-07-19，practitioner-opinion）：Netflix 規模的確認與防護措施——形成前的震盪期、工程介入前走得更遠、正式環境交付界線、專業人才稀缺
• Andrew Ng: The Biggest Opportunities in AI Aren't Where You Think——Andrew Ng 接受 Marina Mogilko 訪問，Silicon Valley Girl（2026-08-28，practitioner-opinion）：「產品管理瓶頸」、面試行銷人員時詢問做過什麼的門檻、行銷人員／CFO／招募工程師案例，以及從技能地圖得出的職缺描述主動性要求（未提供數據）