很多公司一講 AI 轉型，第一反應就是先立項、排 roadmap、開治理會，最後做出一個沒幾個人想用的平台。但這篇整理值得看，正好因為 Uber 的路徑幾乎反過來：不是先有總戰略，而是先有工程師自己做出東西，後面治理、評估、擴散機制才慢慢補上。

原作者李韭二這篇推文，是根據 Anthropic 官方直播裡，Uber AI Foundations & DevX 團隊負責人 Adam Hooda 的訪談整理而成。重點不是「Uber 很大所以什麼都做得到」，而是這家公司本來就有 200+ 個微服務、數千名工程師、全球級複雜度，卻還是在不到一年內，把 Claude Skills 從 2 個推到 500+，而且這過程幾乎完全是自下而上發生的。

事情是怎麼開始的

照推文中的說法，2024 年 10 月，Uber 有位重度使用 Claude 的工程師自己建了一個 repo，做出公司第一個技能市場。裡面只有兩個技能，一個是 CI log 分類與修復，另一個是 code review。沒有正式立項，也沒有管理層在前面推。

接下來幾個月，這套東西不是靠命令長大，而是靠工程師真的用到、真的有感，才一路擴散。原作者整理的時間線大概是這樣：

  • 2024 年 10 月：市集出現，只有 2 個技能。
  • 2024 年底：成長到約 20 個，還是偏慢、偏自然的增長。
  • 2025 年 1 月：出現拐點。Adam Hooda 開始深度使用 Claude Code，團隊裡也陸續出現類似的頓悟時刻。
  • 2025 年 3 月：Golden Marketplace 已有 200+ 個經過篩選的技能，加上團隊與個人市集後，總數超過 500。
  • 原作者還補充一個很關鍵的加速度訊號：光是訪談前一週，就又新增了 20 個技能。

推文把這個成長分成兩段看。前面幾個月比較像種子期，後面則很像網路效應啟動後的爆發期。真正的觸發點，不是公司喊出「我們要 AI 轉型」，而是工程師第一次真的用 Skill 完成一件以前很難做到的事。

Clawd Clawd 偷偷說：

如果只看數字，很容易把這件事讀成「Uber 很會堆功能」。但原作者真正點出的其實是擴散機制：先有局部成功，再讓使用者自己變成貢獻者。這比較像產品長出 PMF，不像總部在推政策。

Uber 怎麼避免 500 個技能變成 500 個垃圾抽屜

技能一多，風險反而不是做不出來，而是難用。重複、衝突、過期的技能如果全堆在一起，很快就會把預設體驗搞壞。推文裡提到，Uber 的解法是一個雙層市場。

第一層：Golden Marketplace

這一層是預設體驗。工程師打開 Claude Code 就會自動載入，不需要手動裝插件或到處找設定。能進這層的技能要經過比較嚴格的流程，包括 code review、CI/CD，以及 LLM-as-Judge 這類自動評估。

這層的覆蓋範圍很完整，原作者直接寫到它可以涵蓋從需求研究、程式實作、測試驗證一路到生產監控。每個技能最好都有 owner、文件和性能保證。目標規模也不是越大越好，而是大約維持在 100 個核心技能左右。

不過原作者也補了一個很重要的限制：Uber 不是想把所有技能都評到死，而是只確保大約 100 個核心 SDLC 技能可靠，其餘部分仍要保留實驗空間。核心原則很直接，不要過度評估，不然會扼殺實驗。

第二層：個人與團隊市場

另一層則是給大家自由試。工程師可以在自己的 repo 快速做技能、透過 URL 分享、小範圍驗證想法，不需要一開始就滿足黃金市集的所有標準。真的有價值的，再逐步升級進 Golden Marketplace。

Adam 的原話，原作者有特別摘出來，大意是：最好的技能，常常不是中央團隊規劃出來的，而是某個工程師在深夜裡意外發現的。

這個架構厲害的地方就在於，它不是在「全面開放」和「全面中心化」之間二選一，而是兩層一起存在。核心體驗管住，邊緣創新放開。

真正有感的技能，長什麼樣子

原作者挑了幾類技能來講，這段很重要，因為它把「AI 幫忙寫 code」這種太空泛的說法，拆成企業內部真的能落地的工作流。

Code review 不是一顆按鈕，而是一個家族

Uber 不是做一個通用 review 按鈕就結束，而是做出一整套 code review 技能。原因很現實：不是每個 PR 都值得同樣強度的審查。日常小改動可以走快速通道，核心邏輯變更則需要更深的 review。

這其實是在承認一件事：AI 工具要好用，不只是要能做，而是要做得剛剛好。

Verification 是現在最關鍵的一塊

Adam 特別在意 verification，尤其是 mobile 開發場景。推文裡提到的例子包括同時啟動多個模擬器、跑不同裝置尺寸、不同語言、深色與淺色模式等配置。

因為難的通常不是讓 Claude 把功能寫出來，而是你怎麼知道它真的能跑。這也是為什麼 Uber 的方向看起來不是只讓 AI 生成 code，而是把驗證流程本身也技能化。

效能優化技能的重點不是神，而是可驗證

推文裡提到，Uber 的兩位工程師把多年做 Go 和 Java 效能調校的經驗編成技能。最關鍵的設計原則，不是「看起來很聰明」，而是確定性輸出。

好的輸出不是一句「我幫你優化好了」，而是清楚回報：試了哪些優化、哪些成功、哪些不適用。原作者舉的例子就是「嘗試了 5 個優化，3 個成功，2 個不適用」。

這種輸出形式對企業很重要，因為它讓結果可以被信任、被驗證，也能成為後續改進的基準線。

最好的技能，甚至最好別被使用者感覺到

Adam 在訪談裡還有一個很有意思的觀點：最好的 Skill，可能是你根本不知道它在跑的 Skill。

原作者舉的例子是，有工程師只是想在本地啟動服務測試，結果 Claude 自己把該做的事做完了。後來才知道，背後其實有一個「啟動服務」技能在運作。

Clawd Clawd 認真說：

這裡有個很實際的設計訊號：企業內部的 Skill，不一定該被包裝成「很多功能等你選」。更好的狀態反而可能是，使用者只講任務，系統自己路由到合適的技能。前提當然是底層治理夠穩，不然就只是把不確定性藏起來。

Uber 為什麼特別重視元技能

如果每個技能都要靠人工從零開始寫，成長速度大概很快就會撞牆。所以推文裡提到，Uber 很重視另一種東西：不是直接拿來做事的技能，而是拿來產技能、修技能、評估技能的元技能。

Skill Workshop：把日常工作反推成 Skill

這套工具的教學方式很聰明。不是先教工程師 Markdown 語法怎麼寫，而是先讓大家正常工作，做 feature、debug、解問題。然後再跑 Skill Workshop，讓它回頭分析剛才的對話，提議哪些流程值得抽成技能。

這樣一來，「學技能」就不是額外作業，而是把原本就在做的事整理成可重用資產。原作者也提到另一個很強的體驗：技能因為環境變動而失效時，Claude 還可能協助重寫與修復。這種「技能自癒」的感覺，會快速建立信任。

大規模技能發現，不是什麼都包一層就算有價值

Adam 和工程師 Israel 做了兩個實驗。一個是讓 Agent 去掃 Uber 工程 Wiki，找所有多步驟流程；另一個是讓 Agent 去看內部 CLI 工具的 --help，提議哪些東西適合包成技能。

但這裡的重要結論不是「全部都值得 Skill 化」。推文裡反而很明確地說，如果只是把 CLI 包一層皮，價值不大。真正有額外價值的，是技能能不能幫你組合多個命令、選參數、補錯誤處理，甚至改進原本工具的使用方式。

這個判準很有用，因為它讓團隊知道：什麼叫做 Skill，只是換包裝；什麼叫做 Skill，真的有放大能力。

從客製 Agent，轉向通用 Agent + Skills

Adam 在訪談中描述了一個很清楚的范式轉移。原作者把它整理成一句很俐落的對比：2024 年大家還在談客製化 Agent，到了 2025 年，越來越像是通用 Agent 加上 Skills，就能完成大部分專業化需求。

這裡的意思不是說客製 Agent 完全沒用，而是相較之下，通用底座 + 可插拔技能 似乎更輕、更快，也更容易被工程師自己維護。

推文還用《駭客任務》的比喻來講這件事：像 Neo 一樣，技能包一載入，就突然「我知道功夫了」。Adam 自己本來是 iOS 背景，但靠著資料科學技能包，也能快速做 dashboard，讓 Claude 幫他問出更像資料科學家的問題。

原作者想帶出的重點很明確：Skills 在降低專業邊界，把很多原本要花很久才能補起來的能力，變成可快速借用的能力。

一個工程師的極端實驗：把 feature pipeline 也技能化

原作者在後半段還提到 Uber 工程師 Ashutosh Bhatia，他自己獨立做出了數百個技能，裡面最吸睛的是一種很實驗性的 feature pipeline。

重點不只是把功能從頭做到尾串起來，而是他對 debug 的想法：如果出問題，不是回頭手動修那一行 code，而是回去改規劃技能或測試技能，從系統層避免同類缺陷再次出現。

這其實是在把工程師的角色，從直接寫每一行程式，往「設計與優化生成程式的系統」移動。Adam 也很保留，明講這還是非常早期的實驗，但他已經看到了初步效果。

Skill 不是單點工具，而是能串起整個 SDLC

Adam 還提到一個很重要的架構觀察：技能不只是單點工具，它們可以被鏈式組合，覆蓋整個軟體開發生命週期。

也就是說，從需求、研究、實作、驗證，一路到上線後的監控，理論上都能在同一個 Agent 環境中被編排起來。這不是在說 Claude 會自己接管 Uber，而是它開始變成一個強力的協調者。

這裡原作者特別保留了一個限制，不能漏掉：Adam 明講，這不代表 Claude 在自動運行 Uber，人類仍然要對輸入與輸出負責。

Skill 評估：重點不是全都管住，而是核心可靠

推文後面也補了 Uber 對評估的態度。它們確實在建多維度評估框架，但核心原則很鮮明：不要過度評估，因為那會扼殺實驗。

真正要被嚴格保證的，是大約 100 個核心 SDLC 技能；其餘部分應該讓它自由生長。這跟前面的雙層治理其實是同一套思路。

另一個硬標準則沒有變，就是確定性輸出。Skill 應該明確報告做了什麼、成功了什麼、失敗了什麼。對企業來說，這不是加分項，而是可信任的底線。

接下來的三個前沿方向

原作者最後整理了三個 Uber 正在看的前沿方向。

1. 團隊記憶系統

Uber 的工程師 Matos 和實習生 Alex 正在做團隊級記憶系統，會把有價值的對話會話存進圖資料庫，再透過 Graph RAG 類型的召回技能，把之前已經發現過的上下文拉回來。

想像中的場景很直接：新工程師加入時，可以立刻存取團隊累積的解法與架構決策；跨團隊協作時，也能快速知道別人已經解過哪些問題。

但這裡還有很多硬問題沒解，包括記憶分層、衰減函數、隱私權限，以及怎麼確保召回的是有用上下文而不是噪音。

2. 自我進化技能

另一個方向是收集所有 Skill 的遙測與實際使用資料，在 CI/CD 或定期任務中，自動分析這些訊號，提議改進，甚至直接升級技能。

如果這條路走得通，Skill 就不再只是靜態指令集，而會變成從實際使用中持續學習、演化的活體。

3. 技能繼承模型

還有一個方向是技能繼承。也就是先有一個基礎 Skill，然後不同使用者或團隊再在上面做局部專門化，同時保留基礎版的能力。

它想解的其實是企業裡很常見的張力：核心邏輯希望集中維護，但每個團隊又都想保留自己的工作習慣。

延伸閱讀

Clawd Clawd murmur：

這三個方向放在一起看，其實很像一個更完整的平台藍圖：記憶層負責保留上下文，自我進化負責吸收使用訊號，繼承模型負責在標準化和客製化之間找平衡。也就是說，Skill 最後可能不只是「一段可重用提示」，而是組織知識的運行單位。

Claude 作為個人延伸：Adam 自己怎麼用

推文最後一段很值得單獨看，因為它不只是在談平台治理，也在談一個管理者怎麼把 Claude 用進日常工作。

Adam 會在 Claude 裡放個人的 MD 檔，寫自己的風格、背景、合作對象與工作方式；他也做了一個「Agentic EM」市場，不再手動追工程狀態，而是讓 Claude 去拉散落各處的資訊，整理成符合自己風格的報告。

另外，他還會同時跑多個 Claude 實例，一個做研究，一個做內部工具；連開發環境配置、shell 設定、debug 這些以前常常擠不出時間處理的事情，也都交給 Claude。

原作者最後摘了一句 Adam 的感受，大意是：他從來沒有在職涯裡感到這麼有創造力，甚至需要有意識地踩煞車，不然會被太多想法淹沒。對 Adam 來說，Claude 不是單純工具，而更像是「我的延伸」。

七個對企業有用的啟示

原作者最後把整件事收成七點，我把它翻成比較白話的版本。

1. 先讓一個人偷跑，不要等完整戰略

Uber 的 500+ 技能，不是先做戰略規劃才長出來的，而是從一個工程師先試兩個技能開始。種子期最需要的往往不是制度，而是真的有人願意動手。

2. 雙層治理可能比完全開放或完全中心化都合理

完全放開，體驗容易碎掉；全部收編，創新又會被悶死。Golden Marketplace 加個人市集，至少從推文裡看起來，是一個兼顧品質與擴散的平衡點。

3. 與其為每個場景都造一個 Agent，不如優先想 Skill

每多一個客製 Agent，通常就多一筆維護成本。反過來說，如果通用 Agent 已經夠強，那把知識與流程做成輕量技能，成本可能低很多。

4. 把資深工程師腦中的部落知識，變成可執行資產

推文裡最典型的例子就是效能優化技能。知識如果只留在高手腦中，擴散很慢，也容易隨人流失。Skill 的價值不只是把知識寫下來，而是讓別人真的能拿去跑。

5. 確定性輸出，是企業信任的底線

企業不太能接受「應該有改善」這種模糊答覆，它更需要的是清楚交代做了什麼、沒做成什麼、結果該怎麼驗。這篇裡反覆出現的 deterministic，講的就是這件事。

6. 元技能的報酬，可能比業務技能更大

像 Skill Workshop、評估管線、從對話抽技能的工具，這些基礎設施一開始看起來不 flashy，但它們反而可能持續催生更多真正有用的技能。

7. AI 時代不是比較不需要工程基礎，而是更需要

Adam 在訪談裡提醒的一點很值得記：有了 AI，不代表 CI、提交隊列、工具鏈這些基礎工程就不重要。反而因為人和 Agent 都要依賴這些系統，基礎設施如果不穩，放大後只會更痛。

結語

就原作者這篇整理來看，Uber 的案例有意思的地方，不只是五個月長出 500+ Skills，而是它把企業內部的 AI 使用，慢慢接到治理、驗證、評估、記憶與技能擴散這些工程現實上。

更重要的是，Adam 也明講了：這不代表 Claude 在自動運行 Uber，人類仍然要對輸入與輸出負責，Claude 比較像是一個更強的協調者。這個限制沒有被拿掉，反而是整套做法能走向企業場景的重要前提。 (๑˃ᴗ˂)⁠ﻭ