# 策展 · X (Twitter) 🔥🔥🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Boris Cherny (@bcherny) · 平台：X (Twitter) · 日期：2026-06-29

> 原始來源：https://x.com/bcherny/status/2071379474277613732

## 中文摘要

Boris Cherny 歸納 Claude Code 團隊五種職能原型。

**職能原型分類**
Boris Cherny 觀察到隨著工程、產品、設計與資料科學（DS）等領域界線逐漸模糊，團隊成員的角色正演變為五種核心原型，且這些原型不再受限於傳統的職稱：
- Prototyper（原型開發者）：負責構思全新創意，產出大量概念，即便多數最終未進入市場。
- Builder（建構者）：能迅速將原型或創意轉化為具備生產等級的產品或基礎設施。
- Sweeper（清理者）：專注於優化 UI、簡化程式碼與系統架構，移除冗餘功能並提升效能。
- Grower（成長推動者）：針對已有產品進行迭代，致力於提升產品市場契合度（PMF）。
- Maintainer（維護者）：負責成熟系統的長期營運，確保其在擴展過程中的安全性、可靠性與執行效率。

**團隊配置策略**
Boris Cherny 指出，健康的團隊組成應根據產品所處的生命週期進行動態調整：
- 產品初期（尚未達成 PMF）：需要具備 Prototyper、Builder 與 Sweeper 能力的人才。
- 成長期（已達成 PMF）：重心轉向 Builder、Sweeper、Grower，並適度配置 Maintainer。
- 成熟期（強勢 PMF）：以 Sweeper、Grower 與 Maintainer 為主，輔以少量 Builder。

**職能界線的批判與反思**
Kun Chen 對於將個人定義為特定原型提出質疑，認為這會限制個人的發展潛力：
- 角色僵化風險：一旦將自己歸類為特定原型，容易導致思維定勢，阻礙自我質疑與成長。
- 專案生命週期需求：個人的角色應隨專案進程演變，從初期的開發者轉變為中後期的清理者與維護者；若過度自我設限，將被迫在專案發展過程中放棄參與。
- 多工處理的必要性：在同時處理多個專案時，個人必須具備在不同場景扮演不同角色的彈性，而非受限於既定的職能邊界。

**AI 對職能的影響**
針對 Pachu 提出「若程式撰寫已由 AI 解決，是否還需要 Builder 與 Sweeper」的疑問，Boris Cherny 回應：
- AI 的輔助角色：Claude 目前在 Builder 與 Sweeper 相關任務上表現優異，且未來能力將持續提升。
- 職能的普適性：Boris Cherny 強調，這些原型並非工程領域專屬。以 Anthropic 為例，資料科學家（DS）同樣分佈在這些原型中，打破了過去 DS 僅被視為「數據處理人員」或僅能被自助式分析工具取代的刻板印象。

**未來展望**
Boris Cherny 與 Kun Chen 皆同意，未來的職能將不再依循傳統的領域專業劃分。成功的關鍵在於保持彈性，專注於達成目標所需的任務，而非糾結於日益模糊的職位邊界。

## 標籤

Claude Code, 其他, Anthropic, Claude