---
schemaVersion: 1
slug: gp-122-20260321-li9292-uber-500-ai-skills
ticketId: GP-122
lang: zh-tw
title: Uber 五個月長出 500+ AI Skills：企業轉型不是先寫計畫，而是先有人偷跑
summary: 這篇推文整理了 Uber AI Foundations 團隊負責人 Adam Hooda 的訪談，講的是 Claude Skills 怎麼在公司內部從 2 個自然長成 500+。重點不只是數量，而是 Uber 看起來是怎麼靠雙層治理、確定性輸出與元技能，把 AI 輔助開發慢慢推進到企業級規模。
originalDate: 2026-03-20
translatedDate: 2026-03-21
source: "@li9292 on X"
sourceUrl: https://x.com/li9292/status/2034919020668031453
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/gp-122-20260321-li9292-uber-500-ai-skills
status: published
replacementTicketId: null
replacementUrl: null
---

# Uber 五個月長出 500+ AI Skills：企業轉型不是先寫計畫，而是先有人偷跑

> **來源:** [@li9292 on X](https://x.com/li9292/status/2034919020668031453)

很多公司一講 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](https://gu-log.vercel.app/glossary#claude-code)，團隊裡也陸續出現類似的頓悟時刻。
- 2025 年 3 月：Golden Marketplace 已有 200+ 個經過篩選的技能，加上團隊與個人市集後，總數超過 500。
- 原作者還補充一個很關鍵的加速度訊號：光是訪談前一週，就又新增了 20 個技能。

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

> **Mogu 偷偷說：**
>
> 如果只看數字，很容易把這件事讀成「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 自己把該做的事做完了。後來才知道，背後其實有一個「啟動服務」技能在運作。

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

## Uber 為什麼特別重視元技能

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

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

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

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

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

Adam 和工程師 Israel 做了兩個實驗。一個是讓 [Agent](https://gu-log.vercel.app/glossary#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，然後不同使用者或團隊再在上面做局部專門化，同時保留基礎版的能力。

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

## 延伸閱讀

- [MP-176: AI 把寫 code 變快了，怎麼有人反而說工程師注定變窮？](https://gu-log.vercel.app/posts/mp-176-20260316-daniel-mac8-swe-not-screwed/)
- [MP-155: AI 革命會看起來像經濟衰退？從女性主義經濟學看 AI 時代的 GDP 盲點](https://gu-log.vercel.app/posts/mp-155-20260312-semianalysis-ai-ai-gdp/)
- [MP-1: swyx：你以為 AI agent 只是 LLM + tools？太天真了](https://gu-log.vercel.app/posts/mp-1-20260203-swyx-agent-definition/)

> **Mogu 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 比較像是一個更強的協調者。這個限制沒有被拿掉，反而是整套做法能走向企業場景的重要前提。 (๑˃ᴗ˂)ﻭ