The Best Fluffy Pancakes recipe you will fall in love with. Full of tips and tricks to help you make the best pancakes.
五種角色原型（Prototyper／Builder／Sweeper／Grower／Maintainer）是團隊人才的觀察框架，出自 Boris Cherny（Anthropic Claude Code）。剛提出在該篇貼文中，引起熱烈討論。這套方法不取代工程師、PM、設計師、資料科學家等職稱，而是疊上一層「角色層」，幫團隊看見每個人真正創造價值的方式。
跳脫職稱盲點，用「角色層」看見團隊的真正產出
關於五型角色和現有的組織架構，如何協作？我們可以從這個新型態的人才管理分類學到哪些？（五型角色Ｘ 組織職務）可以先看這一篇「五種角色原型，重新定義職場職稱」。
打破 0 到 N 的斷層，讓五型角色在產品生命週期完美交棒
這裡會繼續分享，如果拿掉職稱，改用五型角色，那在原本公司中的所有價值任務流程（註1)中，這些角色會怎麼跑這些任務流程？原作者Boris Cherny是在軟體產業服務（Anthropic Claude Code），在軟體業，討論的是產品從0到1，再從1到N的開發的流程：探索與構想、原型與驗證、建置與落地、成長與優化、整頓與簡化、維護與穩定。
五型角色Ｘ產品開發流程，每一種角色除了自己的本職任務，還會參與到下一階段部分任務，很容易就做到銜接順暢。
【跨界洞察】借鏡豐田 TPS，把「不漏接的交接精神」內建在角色設計中
面對新的概念、想法，Sandy除了閱讀，還會思考，這個想法提出，是想要解決什麼樣的問題？有什麼優點可以學習借鏡？
在日本，豐田生產方式（TPS）裡有個核心概念叫「自工程完結」——每個工序都要在自己這一關把品質做到位，不把問題往下游丟；再搭配大野耐一那句「後工程就是你的客戶」，交棒的人心裡想的不是「我做完了」，而是「下一手拿到能不能直接開工」。Boris 這個五型角色的設計，剛好呼應了同樣的精神：不是把工作丟過牆，而是每個角色主動把交接的那一小段補上，讓下一手接到就能跑，不用回頭補問。
>> 大野耐一（TPS）的做法和Boris Cherny兩者的對照，相同的是兩人都不靠「口頭提醒要交接好」，而是把順暢銜接設計進系統本身——一個設計進流程，一個設計進角色。
因此，試著套用到目前公司組織內最常見的16種主要價值流程中的幾個，試試看這樣的概念，可行性的邊界在哪裡？不同產業可以萃取出哪些好的take-out（學習的地方）。
這裡指的價值任務流程，包括從新品到上市、從首購到終身價值、從夥伴關係到付款、從記帳到報表、從取得到報廢…等等16條主要價值流程。
五型角色原型，原始出處
大野耐一（TPS）的做法和Boris Cherny兩者的對照
共同點是：兩人都不靠「口頭提醒要交接好」，而是把順暢銜接設計進系統本身——一個設計進流程，一個設計進角色。
大野耐一（TPS）的做法：用「制度與現場機制」逼出自工程完結
他不是靠人的自覺，而是設計了一整套讓人「不得不」在自己這關做到位的機制：
- 安燈系統（Andon）：發現異常就拉線停線，問題當場暴露、當場解決，不讓瑕疵流到下一站。
- 標準作業：每一工序的動作、時間、品質基準都寫死，做完長什麼樣有明確定義。
- 後工程領取（Pull system / Kanban）：下游來拿，上游才做，逼上游交出「下游真的能用」的東西，而不是自己想做什麼就做什麼。
- 五個為什麼：問題發生時往根因追，避免同一個坑讓下一手再踩一次。
一句話總結：大野耐一是用「流程設計」讓交接自然順暢——把品質內建在工序裡（Built-in Quality）。
Boris Cherny 的做法：用「角色本質」讓銜接自然發生
他走的是另一條路——不靠流程綁，而是靠角色的天性就會往下一棒延伸：
- Prototyper：本質是快速試錯，做完原型自然想看「能不能真的建起來」，順勢把手交給 Builder。
- Builder:本質是把東西建起來，建到一個程度就會想「怎麼長大」，自然銜接到 Grower。
- Grower:本質是放大成效，長到一定規模就會發現「太亂了要整理」，順勢交給 Sweeper。
- Sweeper:本質是收斂簡化，整頓完就進入「穩穩維持」，交棒給 Maintainer。
- Maintainer:本質是守住系統，守到看見新機會，又回頭啟動 Prototyper。
每個角色本職任務的終點，剛好就是下一個角色本職任務的起點，所以不是「被規定要交接」，而是「做著做著自然就交出去了」。
| 大野耐一 | Boris Cherny | |
|---|---|---|
| 著力點 | 工序(流程) | 角色(人的本質) |
| 機制 | 制度、標準、拉動系統 | 五型的天性與擅長區 |
| 銜接怎麼發生 | 被流程規範出來 | 被角色本能推出來 |
| 內建的是 | 品質 | 交棒 |
原文出處：
常見問題 FAQ
Q1. 這篇跟母文章講的五種原型，內容一樣嗎？差在哪？
不一樣。母文章走「產品成熟度」軸線談制度層——Role Layer 怎麼疊在部門之上、怎麼寫進 JD 與績效。這篇走「任務流程」軸線談執行層——一件事在原型之間怎麼接棒。母文章解答「怎麼把五種原型併入組織」，這篇解答「怎麼在日常任務上讓五種原型接力」。
Q2. 我的團隊沒有 6 個階段這麼多，只有 3 段，還套得上嗎？
套得上。6 段是完整生命週期的展開，實務上很多小團隊只跑其中 3-4 段。判斷方式：把手上專案的任務流畫出來，看它經歷了哪幾段，就找對應原型。如果你們產品還在探索期，主要就是原型者 ＋ 建造者兩種角色；如果已經上線在成長期，就多一個成長者。不必湊滿 6 段。
Q3. 傳統部門要拆掉嗎？改成「原型組」？
不要。母文章裡明確說過：一旦把「Sweeper Team」寫進組織圖，這套框架就從活的語言變成僵化職位標籤。正確做法是保留原本部門，把五種原型當跨部門組隊的語言——每次開專案時多問一句「這個階段缺哪一種原型？」
Q4. 為什麼「整頓與簡化」在 AI 時代特別重要？
因為 AI 讓「做出來」變快，如果團隊只是不斷把新產出塞進產品，結局是過度技術債、難以維護的架構、沒人用的功能。清理者的價值——取捨與克制——會直接決定產品能不能活下去。傳統 KPI 只獎勵新增功能、不獎勵刪除，這個結構性缺陷在 AI 時代會被放大。
Q5. 我是 team lead，明天就要開始用，第一步做什麼？
用上一段「三步驟」的 Step 1：攤出你手上一個專案的任務流程，畫出 6 段。哪一段空著、哪一段擠爆，就是你的診斷。半天內就會看到結果。不需要先讀完整套五種原型定義——邊做邊補。
本文出處分層：五種原型的定義、「一個人通常橫跨 2–3 種」、原型與職稱脫鉤，出自 Boris Cherny（Anthropic Claude Code 負責人）原文觀察。6 段任務流程 × 5 種原型的接力對照、傳統部門 vs 原型接力的 4 個差異、企業價值流適配對照、產業對照表，為延伸設計。「AI 讓做出來變容易、稀缺變成清理與維護」的觀察，參考 Anthropic 公開文件與數位時代 BusinessNext 轉譯報導。
