H
Howardism
Plate IIProduct & Org機器翻譯 · machine-translated過時翻譯 · stale translationENHOWARDISM

工程師與 PM 的融合

PublishedMay 6, 2026FiledConceptDomainProduct & OrgTagsProduct ManagementTeam DesignGeneralistsReading13 minSourceAI-synthesised

跨學科通才；產品品味作為瓶頸技能；Anthropic Claude Code 團隊案例研究；「只管去做」的文化基底

工程師與 PM 融合的插圖

資料來源#

摘要#

Boris Cherny（Sequoia AI Ascent 2026）與 Cat Wu（Lenny's Podcast，2026 年 4 月）都從 Anthropic 內部報告了相同趨勢：角色正在合併。工程師做 PM 的工作，PM 交付程式碼，設計師交付程式碼，Claude Code 團隊中的每個職能角色都寫程式碼。合併角色中真正重要的共同技能是產品品味——既然建造如今很便宜，就要決定該建造什麼。這挑戰了傳統的跨職能團隊模型（1 位 PM、1 位設計師、數位工程師，以及分開的 eval/QA），並指向由高情境通才組成的更小團隊：每個人都能獨立負責端到端交付。

Anthropic 實際發生了什麼#

來自 Cat Wu：

  • Claude Code 團隊中的每個人都寫程式碼——工程經理、產品經理、設計師、資料科學家、財務人員、使用者研究員。
  • 設計師以前是前端工程師。
  • 「我們團隊有許多工程師，完全能夠從在 Twitter 上看到使用者回饋，到週末前交付產品，幾乎不需要產品團隊介入。」
  • 招募偏好：「我們非常重視招募具備出色產品品味的工程師。」
  • Boris ↔ Cat 的分工是「80% 心意相通，20% 由領域驅動」。

來自 Boris Cherny：

  • 「跨學科通才」——同時擅長設計的工程師，或兼具產品與資料科學能力的人。
  • 「我們團隊中的每個人都寫程式碼。」
  • 「產品工程師」原型（iOS + web + server）是基準通才；新模式是跨學科通才。

來自 Dan Carey（Anthropic Labs，正在打造 Claude Design）：

  • 團隊在大部分開發期間都只有3 個人；「團隊中的每個人什麼都做——工程師與使用者交談，PM 寫程式碼，設計師做資料分析。」
  • 「這個團隊中各角色之間的界線基本上已經消失。」你仍保有專業與獨特視角，但任何時候，一個人都可以與 10 位使用者交談、找出底層問題、設計修正方案、交付並持續迭代——「團隊中大多數事情完全由單人完成。」
  • 「Claude 是一位相當不錯的團隊成員」——第三位隊友讓 3 人團隊能像更大的團隊一樣運作。

Anthropic 之外：相同的融合，以及它的失敗模式#

Andrew Ng 完全從前沿實驗室之外報告了這項趨勢（2026 年 6 月，practitioner-opinion）——第三個獨立視角：

「隨著 coding agents 加速軟體開發，越來越多工程師開始扮演部分產品管理角色……最困難的部分是塑造產品願景，並在建造（彌合願景與規格之間的落差）和取得使用者回饋以演進願景之間取得平衡。兩者都很重要！」

Ng 補充了 Anthropic 的說法沒有提到的內容：一種明確命名的失敗模式。新近承擔產品角色的工程師，會在自己已經知道如何運作的那一半上投入過多。建造快速、清晰又有趣；外部回饋迴圈緩慢、令人不愉快且無法自動化——因此它被跳過，願景也停止更新。他對前進方向的描述是對稱的：「工程師正在扮演擴大的角色（正如產品經理與設計師如今也做更多工程工作）。」

Ng 也拒絕使用本頁倚重的那個詞。Cat Wu 稱之為品味，他稱之為情境優勢——不是通才培養出的能力，而是他們恰好擁有的知識。如果他是對的，「以品味招募」真正的意思是「招募接近使用者的人」，而且這種優勢會消逝。

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

Anthropic/OpenAI 的說法是前沿實驗室的自我報告；ICONIQ's State of AI 2026 的調查（約 305 家打造 AI 的軟體公司，empirical）顯示這種融合更為廣泛。高度使用 AI 的公司更具跨職能性（AI 營收占 50% 以上者為 42%，低於此比例者為 35%），組織也更扁平（規模達 1 億美元以上者，72% 對 56% 採用 1–4 層管理架構）——這是角色合併的結構性前提。這種融合也出現在網路上的軼事中：一位營運者「將 PM 與設計師合併為單人產品負責制」，而 RevOps 團隊正在「以 AI 原生人員取代非 AI 原生的 RevOps 招募」。這究竟證實了 Cat Wu 的通才小團隊模型，還是退化成 Ambrosino 警告的角色流失，正是尚未解決的張力——ICONIQ 衡量的是這種崩解正在整個群體規模上發生，而不是它是否保留了各專業。

品味論#

「當程式碼變得便宜很多，變得更有價值的事情，就是決定要寫什麼。」

— Cat Wu

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

  • 從 1 萬個 GitHub issue 中挑選要交付的功能
  • 設計 UX，讓模型的優勢充分展現，並補足弱點
  • 知道何時以研究預覽推出某項功能，而不是完整產品
  • 區分人們口頭上說想要的 90 個功能，與他們實際會使用的 10 個功能

這就是產品品味，而且它不受職稱限制——工程師可以擁有，設計師可以擁有，PM 也可以擁有。擁有它的人能良好交付；沒有它的人只會讓產品逐漸偏離。

為什麼是現在（Lenny 的對照觀點）#

Lenny 在 Cat 的訪談中提出反駁，引用 Anthropic Head of Growth 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. **更小的團隊。**每個人都負責端到端交付的 5 人團隊，比有交接流程的 15 人團隊交付更快。
  4. **PRD 變得更輕量。**Cat 表示：模糊功能使用簡短的條列式 PRD；指標報告與團隊原則完成大部分對齊工作；只有重型基礎設施專案才需要完整 PRD。
  5. **職涯階梯分裂。**Cat 表示：「我們以產品一致性作為代價」，換取交付速度；職涯階梯的一致性則是更不顯眼的犧牲品。

相關連結#

  • 實作充裕如何顛倒產品工作 — OpenAI 端對相同「決定建造什麼才是瓶頸」轉變的流程層級描述
  • 角色平均化，而非角色消除 — Ambrosino 的反向提醒：歡迎融合，但不要消除作為專業、且擁有可知最佳實務的角色
  • 外包思考，不要外包理解 — 融合後的通才必須持續理解，同時委派執行
  • 套用於 AI 的七種力量 — 角色融合為通才後，流程力量逐漸消退
  • Cat Wu — 主要闡述者
  • Boris Cherny — 來自同一團隊的融合報告
  • AI 原生產品節奏 — 讓角色融合可行的節奏
  • Claude Code 最佳實務 — 具備品味的工程師是 Claude Code 鎖定的使用者角色
  • 模型改進下的工具鏈收縮 — 隨著工具鏈收縮，「PM」角色的表面積縮小；「交付產品的人」的表面積擴大
  • 印刷術式軟體民主化 — 相同方向、不同時間尺度：軟體素養擴張，角色差異變得模糊
  • 代理迴圈模式 — 在極限情況下，個別貢獻者執行數十個代理，像過去的團隊一樣交付
  • 重新設計人類與 AI 的問責 — 這種融合在整個勞動力上的鏡像：代理接手執行後，人類角色集中於監督、判斷與監督品質
  • AI 員工框架 — 跨職能通才的反證：在 HR/finance 情境中，將 AI 框架為同事（而非工具）會侵蝕個人問責，而不是擴展它
  • 計算資源分配器 — 將「決定要寫什麼」作為瓶頸技能，在單次模型呼叫層級重新表述（Thariq Shihipar）
  • 活的設計系統 — 讓非工程師自行取得高保真資產的工具，是組織中角色模糊化的產物面
  • 作為代理編排者的創辦人 — 公司內角色融合外推至創辦人／一人公司的規模；方向相同，單位更小
  • AI 原生新創生命週期 — 這種融合的創辦人／新創版本：逐階段壓縮特定職能的關卡
  • Evals 作為產品規格 — 典型的混合角色活動：PM 寫 evals、工程師寫 evals，雙方都朝向以「十個很棒的 evals」作為共同完成定義的產物
  • 身兼 IC 的經理 — Fiona Fung 將「每個人都寫程式碼」延伸到組織階層：每位 Claude Code 經理都從 IC 開始
  • 以狗食測試作為產品紀律 — 「具備產品感的創意建造者」是這種融合所產生、由狗食測試餵養的招募輪廓
  • Dan Carey / Anthropic Labs — 3 人 Claude Design 團隊作為第二個案例研究：「每個人什麼都做」，角色消失
  • 複利迴圈最佳化 — 小型且角色消解的團隊，讓「打造自己的工具、獨自執行迴圈」成為可能
  • 代理式編碼的專業回報 — 「既然建造便宜，就決定建造什麼」作為瓶頸技能，在群體規模上衡量：領域／產品理解（而非編碼）預測誰能成功使用代理，而經理（委派品味）取得最高的驗證成功率
  • 從對話轉向委派 — OpenAI 的 Codex 研究在使用方式中看見相同融合：密集使用者「管理代理式工作的組合」，將自身精力轉向委派、監督與整合
  • 平行代理編排 — 角色融合的具象化：執行一隊並行代理就是 IC 轉為編排者的轉變，並有採用數據佐證
  • AI 的組織性互補 — 工作重新設計的互補面：實現 AI 價值需要指揮、監控與整合代理輸出的角色，而非直接執行任務
  • AI 原生建造的三個迴圈 — Andrew Ng 的第三個視角報告，以及失敗模式：轉任 PM 的工程師過度執行自己喜歡的內迴圈，跳過更新願景的外迴圈
  • 情境優勢，而非品味 — Ng 對融合技能的重新框架：不是品味，而是與使用者的接近程度；這使「以品味招募」成為會消逝的策略
  • AI 原生組織 — 全公司的版本：ICONIQ 的跨職能／扁平組織數據，以及 PM 與設計師合併為單人負責制的軼事，都是在約 305 家 AI 建造者中衡量的這種融合（見該頁的重組章節）

開放問題#

  • 這能否超越約 50 人的 Claude Code 式團隊？Boris 保留地說：「我認為這會是未來多年的問題。」
  • 在工程師做 PM 工作的公司中，正式的 PM 職涯階梯會如何變化？根據 Cat 的說法，Anthropic 目前仍是開放問題。
  • 跨學科通才是招募門檻——人才供給從何而來？轉職者，還是偏向 AI 原生教育的新鮮人？

推導#

資料來源#

§ end
About this piece

Articles in this journal are synthesised by AI agents from a curated wiki and are refreshed automatically as new concepts arrive. Topics, framing, and editorial direction are curated by Howardism.

Cited by 43
Related articles
  • Claude Code

    Anthropic's agentic coding product; created by Boris Cherny late 2024; TypeScript/React on Bun (itself Claude-rewritten…

  • Harness Shrinkage as Models Improve

    Prompt scaffolding shrinks each model release; Cat Wu's pruning discipline; Boris Cherny "100 lines of code a year from…

  • AI Native Product Cadence

    Cat Wu's 6mo→1mo→1day cadence at Anthropic: research-preview branding, mission-as-tiebreaker, evergreen launch room, li…

  • Boris Cherny

    Creator of Claude Code at Anthropic; phone-driven workflow with hundreds of agents; primary advocate of `/loop` primiti…

  • Returns to Expertise in Agentic Coding

    Anthropic's 400K-session study: domain expertise (not coding skill) is what amplifies an agent — experts get 2× the act…