最近部門經理在研讀《穀倉效應》(The Silo Effect)，第七章提到克里夫蘭醫學中心為了打破穀倉現象所做的改革，剛好跟 Scrum 團隊的設計不謀而合。趁這個機會，把他們的做法整理出來跟大家分享，順便用 AI coding 時代的角度重新看一次——這些幾十年前的組織智慧，在 AI 大量產出程式碼的今天，反而更值得拿出來對照。
什麼是穀倉效應
穀倉效應是一種文化現象。根據維基百科的定義，它指的是企業內部因為缺少溝通，部門間各自為政，只有垂直的指揮系統，沒有水平的協同機制，就像一個個穀倉，各自擁有獨立的進出系統，卻缺少穀倉與穀倉之間的溝通和互動。[1]
在現今專業分工、強調效率的環境下，這個現象更明顯。大家為了追求自己角色或局部的最佳化，反而忽略了整體最佳化，也忽略了應該交付給客戶的價值。
舉例來說：傳統開發方法因為專業分工，切出了 RD、QA、Ops 等角色，每個人都只想把自己手上的工作做好做快。RD 希望需求最好不要變，這樣才能一次開發到位；RD/QA 只想把產品交付出去，不太管這東西部署起來方不方便、會不會影響客戶日常作業。
正是為了改善「角色之間不溝通、不以客戶方便為導向」這個問題，才有了 Agile 和 DevOps 這些做法——讓 RD、QA、Ops 合為一體，以交付價值為導向，三者緊密合作。
克里夫蘭醫學中心是誰
克里夫蘭醫學中心是世界最著名的醫療機構之一，集醫療、研究、教育三位一體，是提供專業醫療和最新治療方案的非營利機構。
它被美國以及全世界公認為頂級醫療中心之一，尤其在醫療技術、醫療管理系統，以及心血管疾病治療方面表現突出。它的心臟病診療計畫連續 21 年入圍全美最佳，在《美國新聞與世界報導》評選的年度最佳醫院中常常名列前茅；泌尿外科、胃腸科、腎臟科和風濕病科位居全美第二，其他幾個科室也都名列前茅。[1]簡單說，就是一整個強到爆。
觸發改革的那個問題
書中提到，在一場演講中，有人問當時的執行長托比・寇斯葛洛夫(Toby Cosgrove)：「你們會教導醫護人員要有同理心嗎？」
會這樣問，是因為這位發問者的親人有心臟疾病，原本想去克里夫蘭就診，卻因為感受不到醫護人員的同理心，最後選擇了其他醫院。
這件事讓寇斯葛洛夫很在意。因為即使醫術全國頂尖，那也是「自己的技術和名聲很棒」；但對病患來說，專業技術真的是他們要的全部嗎？或許他要的價值不只是好的醫術，還想要被關心、被了解、被照顧。
於是托比把醫療的主體從醫生移回病患身上，做出了四項改革。下面每一項，我都接著對照 Scrum／敏捷的精神，再用 AI coding 時代的角度反思一次。
以疾病或病人為主，而非以科別分類
你可能遇過：去醫院看病，如果不是你掛的那一科負責，就要轉去別科，或者等別科的資料過來，搞得你等很久，還擔心這些醫師根本沒坐在一起討論過——這樣得出的結果真的對嗎？
為了解決這個現象，托比廢除了內外科的分界，改以「疾病或病人」為主，建立一個個跨科的「institute（醫療中心）」，讓外科、內科醫師與其他人員一起攜手治療同一個病患。這樣病情才能被綜合考量，不會只看單一面向；不同科別的醫師也能相互交流、學到更多。
對照 Scrum
Scrum Team 正是這種精神。它不強調職稱，大家團結合作，一方面貢獻自己所長，一方面學習其他角色的技能，整體戰力才會更強。Feature team 的用意也跟「以病人為中心」一樣——團隊本身就有能力把事情處理完，不必再依賴別的團隊來幫忙。
AI coding 時代反思
傳統上我們用科別（前端、後端、測試、維運）切團隊。AI coding 工具讓單一工程師能跨層產出程式碼，表面上科別的牆變矮了。但新的穀倉跑出來了——它出現在「產生程式碼的人」和「驗證程式碼的人」之間。
產出變便宜，驗證卻變貴：程式碼審查平台 CodeRabbit 在 2025 年 12 月的報告指出，AI 共同撰寫的 PR 大約多出 1.7 倍的問題[10]；GitClear 分析 2.11 億行變更，發現兩週內就被改掉的 code churn 從 2020 年的 3.1% 升到 2024 年的 5.7%，與 AI 採用率上升同步[11]。換句話說，AI 一天生出的程式碼量已經超過人能審查的速度，如果團隊還停在「我寫完丟給你審」的科別式分工，驗證就會塞車（verification bottleneck）。
這時候 feature team 的精神更關鍵：同一群人要同時握有產生與驗證的能力，讓 spec、實作、測試、上線在同一個團隊裡閉環，而不是把 AI 的產出丟過牆給下一個科別。
小組合作模式
一般醫院的運作，就像電視上演的：有位主治大夫、或者一位像「醫龍」那樣的人物出現，告訴大家要做什麼，然後所有人照表操課。
但碰到急診、意外頻傳的場面——例如戰爭、恐怖攻擊——情況往往超過任何單一醫師能掌控的範圍。這時候，那位很強的醫生反而變成瓶頸。加上科技進步、各種污染與傳染源層出不窮，再加上過度細分的專業技術，連單科醫生都不容易掌握全部狀況。
這裡要先解釋一下後面會一直用到的「越戰模式」，因為這個說法台灣比較少聽到。它指的是越戰時期戰地醫療發展出來的一套運作方式。傳統醫院的搶救是金字塔式的：一位資深主刀醫師站在頂端發號施令，其他人照指令動作。但戰場上傷患一次大量湧入、傷勢千奇百怪，狀況遠超過任何一位醫師能獨自判斷，這時候那位最強的人反而卡住整條線。
於是軍醫改了做法：讓資深外科醫師退下指揮的位置，把判斷權交還給團隊裡的其他醫師與護理人員，大家依照事前共同演練過的流程各自處置、邊做邊一起討論。撐住整個搶救的，是平時練出來的默契和彼此的信任，而不是等一個人下令。書中提到，這個改變讓急救復甦時間整整縮短一半，從 122 分鐘降到 56 分鐘。後來在 2013 年的波士頓馬拉松爆炸案，醫院面對大量傷患時也是靠同一套「團隊分散決策」的模式，在混亂中高效救回了許多人。
所以兩種模式的差別很清楚：醫龍模式強調指揮和控制，容易把團隊成員當笨蛋，一切聽我指揮、不要想太多；越戰模式強調的是應變和合作，背後靠的是信任和使命的連結——相信每個成員，相信其他人為了多救一個人，連犧牲自己都在所不惜。托比認為，戰時這套有效的做法，平時也該能用：由不同背景的人才組成醫療小組，一起討論、一起治療病人。克里夫蘭也就用這個方式重新拆解組織。
對照 Scrum
看到這裡，應該很容易聯想到 Scrum 團隊要 self-organizing、不要 command and control——兩者講的是同一件事。
AI coding 時代反思
這裡很容易直覺地把醫龍對應到「團隊裡最會用 AI、什麼 prompt 都他來下的那個人」，但現實剛好相反。AI 工具的採用是擴散式、由下而上的：JetBrains 2026 年 1 月的調查顯示，90% 的開發者在工作中固定使用至少一種 AI 工具，七成的人同時用 2 到 4 種[9]。常見的路徑是個別工程師自己裝、自己報帳，等公司採購注意到，它已經長進日常工作流，連「一種工具給全公司用」的模式都在被放棄。所以瓶頸並不集中在某個英雄身上，而是每個人都在自己的位置上獨立產出，整隊加起來的量遠超過大家能一起審查的速度。
醫龍模式在這裡真正的對應，是把驗證也想成可以集中化——找一個資深的人把所有 AI 產出審完。這條路會死，因為一個腦袋扛不住全隊的洪流，他只會變成新的瓶頸，把全團隊的認知負荷壓在他一個人身上。撐得住的還是越戰模式那一套：把「這段 AI 寫的能不能信」的判斷分散到團隊，用結對或群審一起看，讓資深的人從「自己審完一切」轉成「定義驗證標準、帶大家一起審」。信任和共同責任要接住的，是分散的過度產出，而不是某個指揮官的卡關。
固定薪水機制
醫生大多採績效給薪，看的是業績。問題是，如果想賺更多，就會壓縮花在每個病人身上的時間——這樣的醫療你會想要嗎？所以克里夫蘭改採固定薪水制，一開始就談定薪資，讓醫生不會為了多看幾個病人而犧牲醫療品質。
對照敏捷
導入敏捷時，我們也在談績效評估方式要改變，要鼓勵大家往對的方向走，而不是用個人獎勵把大家逼向局部最佳化。坦白說這仍是個大難題，目前沒有漂亮的結論（延伸閱讀見文末 [3]、[4]）。
AI coding 時代反思
業績制讓醫生想多看病人而犧牲品質；AI coding 時代有個一模一樣的陷阱。如果你用程式碼行數、PR 數、commit 數來衡量工程師，AI 會讓這些數字輕鬆灌水，但灌出來的多半是還沒被驗證的「驗證債」。
這不是憑感覺：Faros AI 根據 1,255 個團隊、超過一萬名開發者的遙測資料發現，AI 工具確實拉高了個人產出，但這些收益沒有轉化成公司層級的生產力，反而與每位開發者多出 9% 的 bug 相關[12]（這是工具廠商的遙測數據，引用時要標明）。Google 的 DORA 2025 報告也指出，個人吞吐量上升 21% 到 55%，但若缺乏扎實的工程基礎，組織層級的交付穩定性反而下降[13]。
更值得放進投影片的是 METR 那場隨機對照試驗：找來資深的開源開發者，用 AI 的那組實際上慢了 19%，但他們自己以為快了 20%[14]。個人指標漂亮、感覺很快，系統品質卻在背後慢慢崩——這就是局部最佳化，只是 AI 把它放大了。衡量的對象要從「個人生出多少程式碼」(output) 移回「交付給用戶的成果」(outcome)，不然 AI 只會幫你把錯的指標衝得更快。
同理用戶
「改善用戶體驗」這句話大家都會講，但托比不是只是嘴上說說。他任命了體驗長(CXO) 專職處理，要求所有員工參加同理心訓練課程，還辦了同理心研討會，到 2019 年已經是第十屆——說到做到[5][6]。他們最有名的那支同理心影片，連 IDEO 都專文推薦[7]。
對照 Scrum
以用戶為主，是所有有效團隊的共同起點；但在 AI 時代，這一點從「口號」變成了真正的防線。
AI coding 時代反思
先講清楚這段是倡議，不是現況描述——目前業界多數人是 ad hoc 地下 prompt，很少先把規格講清楚再讓 AI 動手。但這正是缺口所在。AI 讓我們很快就能做出「看起來對」的功能，Stack Overflow 2025 調查就有 66% 的開發者抱怨 AI 的產出「幾乎對，但又不太對」，對輸出的信任度從 2024 年的四成掉到 2025 年的 29%[15]。快不等於做對東西，把錯的東西做得更快，傷害只會更大。
同理用戶在 AI 時代最該補上的著力點，就是在讓 AI 寫之前先把「用戶到底要什麼」講清楚。這正是 Specification by Example／ATDD 在做的事——用具體例子跟用戶（或 PO）對齊需求，讓那個例子同時變成 AI 的規格，也變成後面驗證的依據。把同理心前置到需求釐清，AI 才不會高速地幫你做出沒人要的東西。這不是現在大家都這樣做，而是在這個時間點最值得補起來的一塊。
整體反思：AI 沒有消滅穀倉，它把牆搬了位置
從克里夫蘭的案例可以看到，有效團隊所具備的精神，不管在哪個領域都差不多：
- 自組織
- 有共同信念
- 互信
- 跨職能
- 以用戶為主
要落實這些理念，組織結構和文化必須配合，得從價值觀開始改變，讓大家知道為何而戰；接著用組織切割（跨職能的自組織小團隊）來鞏固這些精神和意志，變革才能真正落地生根。[8]
把這套放到 AI coding 時代再看一次，會發現一件事：AI 並沒有消滅穀倉，它只是把穀倉的牆從「角色之間」搬到了「產生與驗證之間」。產出便宜了，驗證變貴了；瓶頸從「誰來寫」變成「誰來確認這能信」。克里夫蘭那四招——以病人（用戶）為中心、團隊應變勝過英雄、把指標對準成果而非業績、把同理心前置——拿來對付這道新的牆，剛剛好。
所以結論跟原本一樣，只是換了個對象。導入 AI coding 工具，如果只是發 license、教大家怎麼下 prompt，卻沒去調整團隊怎麼切、怎麼一起審查 AI 的產出、用什麼指標衡量、怎麼跟用戶對齊需求，那 AI 只會讓你更快累積一堆還沒人驗證的程式碼。先把結構和文化調好，工具才接得住。
參考資料
AI 時代的數據多為二手彙整與工具廠商數據，已標明各筆來源的性質（問卷／廠商遙測／獨立研究）。正式投影片或文章發布前，建議回到各機構的原始報告再確認一次數字與年份。
原文相關出處
- 克里夫蘭醫學中心（維基百科）。zh.wikipedia.org
- 醫生薪資結構與看診時間的關係（The News Lens 關鍵評論網）。thenewslens.com/article/40113
- 怎麼有效衡量敏捷團隊績效？（微信公眾號）。mp.weixin.qq.com
- 績效考核——敏捷轉型的鴻溝（Thoughtworks Insights）。insights.thoughtworkers.org
- Patient Experience: Empathy & Innovation Summit（Cleveland Clinic）。my.clevelandclinic.org
- Cleveland Clinic Patient Experience Summit, May 2017（YouTube 介紹影片）。youtube.com/watch?v=rDYSZ8hdgo4
- A Lesson in Empathy（IDEO Design Thinking Blog，推薦克里夫蘭同理心影片）。designthinking.ideo.com
- Leading Agility Inside-Out（Pete Behrens，SlideShare）。slideshare.net/petebehrens
AI 時代數據與研究
- JetBrains，AI Pulse / State of Developer Ecosystem（2026 年 1 月）：90% 開發者工作中使用 AI 工具、多工具併用比例。問卷調查
- CodeRabbit（2025 年 12 月報告）：AI 共同撰寫的 PR 約多出 1.7 倍問題。程式碼審查工具廠商數據
- GitClear：code churn 由 3.1%（2020）升至 5.7%（2024），分析 2.11 億行變更。第三方分析
- Faros AI：1,255 團隊、逾一萬名開發者遙測；個人產出上升但未轉化為公司層級生產力，與每位開發者多 9% bug 相關。工具廠商遙測
- Google DORA 2025 報告：個人吞吐量 +21%～55%，缺乏工程基礎時組織交付穩定性下降。產業研究報告
- METR，隨機對照試驗（arXiv，2025）：資深開源開發者用 AI 慢 19%、自評快 20%。獨立非營利機構 RCT
- Stack Overflow 2025 Developer Survey：66% 反映 AI 產出「幾乎對但不太對」、信任度由 40%（2024）降至 29%（2025）。問卷調查
發表迴響