The Best Fluffy Pancakes recipe you will fall in love with. Full of tips and tricks to help you make the best pancakes.
這篇是子文章（導讀）。母文章：五種角色原型，重新定義職場職稱；實戰篇：五型人才如何接力任務、又如何跟現有部門並存。本篇解答「這套框架是誰提出的、在講什麼」，並幫你決定往哪篇深讀。
「專案卡住了，再招一個工程師吧。」——這可能是團隊最常見、也最貴的誤診。Boris Cherny 五種原型給了另一種診斷方式：團隊缺的常常不是「人」，而是某一種「創造價值的方式」。這篇導讀用最短的篇幅講清楚兩件事：五種原型是誰提出的、內容是什麼；然後依你的需求分流——想改制度（JD、績效、人才盤點）走一條路，想明天就用在手上專案走另一條。十分鐘讀完，你會知道自己該點開哪一篇。
Boris Cherny 是誰？這套原型從哪來
Boris Cherny 是 Anthropic 的 Claude Code 負責人。他在對產品團隊組成的觀察中提出：團隊裡真正的分工單位不是職稱，而是五種「角色原型」——Prototyper（原型發想者）、Builder（建造者）、Sweeper（整理者）、Grower（成長者）、Maintainer（維運者）。
他的原文觀察包含四個核心主張：五種原型的定義、每個人通常橫跨 2–3 種原型、原型與職稱脫鉤，以及不同產品階段需要不同的角色配比。
要先說清楚的是出處分層：以上四點出自 Boris Cherny 本人；至於怎麼把五種角色原型疊進組織（Role Layer、角色雷達、Primary／Secondary／Shadow 標註、四層模型）、怎麼在任務流程上接力（6 段流程對照、team lead 三步驟），是母文章與實戰篇的延伸設計，不是 Boris 的主張。讀的時候把這條線記住，引用才不會張冠李戴。
Boris Cherny 五種角色原型是什麼：先認得這五個人
五種角色原型可以攤在「產品成熟度」一條軸上看——左邊靠廣度與速度，右邊靠深度與耐力，Sweeper 卡在中間，靠品味與克制：
| 角色原型 | 創造價值的方式 | 偏好階段 | 成功指標 |
|---|---|---|---|
| Prototyper 原型發想者 | 大量發想、快速驗證，多數點子不上線 | 前期 | 學習速度、假設驗證 |
| Builder 建造者 | 把點子補成生產級產品、如期交付 | 前期 | 交付速度、品質 |
| Sweeper 整理者 | 簡化、下架、清技術債，敢刪 | 全期 | 技術債降低、體驗提升 |
| Grower 成長者 | 數據驅動迭代、衝 PMF | 後期 | 留存、轉換、營收 |
| Maintainer 維運者 | 顧穩定、安全、效能 | 後期 | SLA、安全性、穩定度 |
關鍵在於：原型描述的是「如何創造價值」，不是「做什麼工作」。「工程師」是專業，可能同時是 Builder＋Sweeper；「PM」可能是 Grower＋Prototyper。職稱與原型是多對多的關係——這一點是整套框架的地基。
你以為缺人，其實缺的是角色
回到開頭那句「再招一個工程師」。用五種角色原型重看，會發現多數團隊的卡點不是人數，而是原型失衡：所有人都在做同一段，沒人在收拾。
一個典型場景：團隊裡五個人全是 Builder，功能出得飛快，但介面越來越亂、技術債越堆越高、沒人知道哪些功能可以刪。這時再招一個工程師（大概率又是一個 Builder），只會讓問題加速——你缺的是 Sweeper，不是第六個 Builder。
AI 時代讓這個誤診更貴。當 PM、設計師、工程師都能直接產出可操作原型，「做出來」的門檻降到接近零，稀缺反而變成清理與維護——而傳統 KPI 只獎勵新增功能，會系統性懲罰 Sweeper 與 Maintainer。診斷方式從「這件事該給哪個部門」換成「這個階段缺哪一種原型」，是 Boris Cherny 五種原型最直接的實用價值。
兩條深讀路線：改制度走母篇，明天就用走實戰篇
認得五個人之後，兩篇深讀文章各接一條路線，依你現在的問題選：
路線一・我想改制度（JD、績效、人才盤點）→ 讀母文章
《五種角色原型，重新定義職場職稱》走「產品成熟度」軸線，談制度層：怎麼在不動組織圖的前提下疊一層 Role Layer、怎麼用角色雷達與 Primary／Secondary／Shadow 做人才盤點、探索期／PMF 期／規模期各要什麼角色配比、每種原型該用什麼方式管理，最後收在 Mission→Role→Skills→Profession 四層模型。適合主管、HR、組織設計者。
路線二・我想明天就用在專案上 → 讀實戰篇
《五型人才如何接力任務、又如何跟現有部門並存》走「任務流程」軸線，談執行層：一件事從探索到維護的 6 段流程各由哪個原型主導、上線後成長者／清理者／維護者為什麼是並行不是序列、哪些企業價值流套得上（哪些強套會誤導決策），最後給 team lead 半天能跑完的三步驟。適合 team lead、專案負責人。
兩篇不重複：母文章解答「怎麼把五種原型併入組織」，實戰篇解答「怎麼在日常任務上讓五種原型接力」。都要讀的話，建議先母後子。
開始之前的三個提醒
別把原型變成部門。一旦「Sweeper Team」被寫進組織圖，這套框架就從活的語言變成僵化的職位標籤，跟它要解決的問題背道而馳。正確用法是保留原本部門，把原型當跨部門組隊的語言。
別給人單一標籤。每個人通常橫跨 2–3 種原型，且會依產品階段切換。用「Primary＋Secondary」標註比「你就是個 Maintainer」貼近真實，也不會把人釘死。
先檢查你的 KPI。如果績效制度只算「這季上線了什麼」，你正在懲罰願意刪冗餘功能、預防 outage 的人——技術債只是還沒爆。這是導入五種原型前最值得先修的一件事。
常見問題 FAQ
Q1. Boris Cherny 是誰？
Anthropic 的 Claude Code 負責人。他從產品團隊組成的觀察中提出五種角色原型，主張分工單位是「創造價值的方式」，不是職稱。
Q2. Boris Cherny 五種角色原型是哪五種？
Prototyper 發想、Builder 建造、Sweeper 簡化、Grower 迭代成長、Maintainer 維運。五種對應產品從探索到成熟的不同階段需求。
Q3. 哪些是 Boris 的原始主張、哪些是延伸設計？
原始主張：五種角色原型定義、一人跨 2–3 種、原型與職稱脫鉤、階段配比。Role Layer、角色雷達、6 段接力、三步驟為兩篇深讀文的延伸設計。
Q4. 五種角色原型會取代職稱嗎？
不會。職稱描述專業，原型描述創造價值的方式，兩者是多對多關係。原型是疊在職稱之上的角色層，不是新職稱，也不該變成部門。
Q5. 我該先讀母文章還是實戰篇？
想改 JD、績效、人才盤點等制度，讀母文章；想明天就套進手上專案，讀實戰篇。兩篇都讀建議先母後子。
出處分層：五種角色原型定義、一人橫跨 2–3 種、原型與職稱脫鉤、階段配比，出自 Boris Cherny（Anthropic Claude Code 負責人）原文觀察。制度層與執行層的展開為母文章與實戰篇的延伸設計。
原文出處
