Uber五个月企业AI转型（给中国企业的7个启示）#

韭5 个月前，Uber 的一个工程师自己建了个仓库，往里放了 2 个 Claude 技能。没有立项，没有审批，没有人知道。

5 个月后，这个仓库变成了 Uber 全公司 500+ 技能的生态系统，覆盖了从代码审查到生产监控的整个开发生命周期。

这是怎么发生的？

> 本文基于 Anthropic 官方直播，Uber AI Foundations 团队负责人 Adam Hooda 的访谈整理。原始对话约 50 分钟，

本文做了大量结构化提炼。

一、背景：谁在说话，为什么值得听#

Adam Hooda，Uber AI Foundations & DevX 团队负责人。

早年是 Twitter 的第 8 号 iOS 工程师（在 Twitter 做过照片和视频发推功能）。现在的核心职责：把 Uber 的整个软件开发流程转向 Agentic Engineering。

访谈人是 Anthropic Claude Code 团队的 Dax。

为什么这场对话值得中国企业关注？因为 Uber 不是一个在 PPT 上谈 AI 转型的公司。他们有 200+ 个微服务、数千名工程师、全球级的复杂度

而他们在不到一年时间里，把 Claude Skills 从 2 个做到了 500+，并且这个过程几乎完全是自下而上发生的。

这不是一个"试点项目"的故事，是一个真实的企业级 AI 工程转型的一手数据。

二、增长时间线：从 2 个技能到 500+#

这不是一个自上而下推动的项目。

2024 年 10 月：

Uber 开发者平台团队的一个 Claude 重度用户，

自己创建了公司第一个技能市场（Marketplace）。

里面只有 2 个技能：

CI 日志分类和修复
代码审查

没有战略规划，没有管理层推动。纯粹是一个工程师的个人实验。

2024 年底：增长到约 20 个技能。缓慢、自然的增长。

2025 年 1 月：拐点。Adam 本人开始深度使用 Claude Code，体验到了技能系统的威力。与此同时，同样的顿悟在 Uber 工程团队中集体发生——用 Adam 的话说，"像多米诺骨牌一样"。

现在（2025 年 3 月）：

黄金市场（Golden Marketplace）：200+ 个经过筛选的技能
加上各团队和个人的市场：总数超过 500
仅采访前一周就新增了 20 个

值得注意的增长模式：10 月到 12 月，3 个月长到 20 个。

1 月到 3 月，3 个月从 20 爆发到 500+。

前一个阶段是种子期，后一个阶段是网络效应。

触发点是工程师的第一次"顿悟体验"

当他们真正用技能完成了一件以前做不到的事，就会开始主动创造新技能。

三、架构设计：双层市场体系#

500 个技能听起来很多。但如果质量参差不齐——重复的、冲突的、过时的技能混在一起——反而会破坏体验。Uber 的解法是一个双层结构。

1⃣第一层：黄金市场（Golden Marketplace）

开箱即用：工程师启动 Claude Code 时自动加载，不需要手动配置市场或插件
严格准入：每个技能提交后经过代码审查、CI/CD 流程、LLM-as-Judge 自动评估（系统根据预期输入输出进行测试，只有通过足够的评估标准才能进入）
覆盖 SDLC 全环节：从需求研究、代码实现、测试验证到生产监控
每个技能有明确的 Owner、文档、性能保证
目标规模：约 100 个核心技能（不是越多越好）

2⃣第二层：个人和团队市场

工程师可以在个人仓库中快速实验
通过 URL 分享技能，小范围验证想法
不受黄金市场的严格标准约束
验证有效的技能可以逐步"晋升"到黄金市场

Adam 原话："最好的技能往往来自整个工程团队的某个人在深夜的发现，而不是中心化团队的决策。"

设计哲学：核心体验严格把控 + 边缘创新自由生长。

不是二选一，是两层并行。

这个平衡策略既保证了默认体验的质量，又不会扼杀自下而上的创新。

四、杀手级技能：哪些真正改变了工作方式#

1⃣代码审查家族

不是一个"快速审查"按钮，而是一整个技能族群：

为什么要分层？因为不是每个 PR 都需要同等强度的审查。日常小改动走快速通道，核心业务逻辑变更走深度审查——工程师根据变更的重要性自己选择。

2⃣验证技能（Verification）

Adam 说这是他当前最关注的方向，尤其针对移动端开发：

同时启动多个模拟器
在不同配置下（浅色/深色模式、不同语言、不同设备尺寸）自动编排测试
核心问题：Claude 帮你实现了一个功能，你怎么知道它真的能跑？

这个问题对所有使用 AI 辅助编码的团队都是共通的。代码生成容易，验证代码正确性难。Uber 的思路是把验证本身也交给技能系统来自动化。

3⃣性能优化技能

由 Uber 工程师 Ankit 和 Uday 创建。

他们有多年优化 Go 和 Java 服务的深厚经验，把这些部落知识编码成了技能。

关键设计原则——确定性输出：

> "我们尝试了 5 个优化，3 个成功，2 个不适用。"

而不是模糊的"我优化了你的代码"。

为什么确定性输出这么重要？

两个原因：

第一，让没有同等专业知识的工程师也能信任和使用这个技能的结果；

第二，让效果可验证，后续改进有了基准线。

4⃣隐形技能

Adam 认为最好的Skill是你不知道它在运行的Skill。

有工程师来找他说："我需要在本地启动服务进行测试，

Claude 就自己搞定了。"后来才发现后台有一个"启动服务"技能在运行。

这种无感体验是技能设计的理想状态——用户不需要知道后台有什么在帮忙，Agent 自己判断需要什么、自动调用、自动完成。

五、元技能：制作技能的技能#

1⃣ Skill Workshop——内部培训的核心工具

Uber 教工程师学习技能的方式很聪明：

不直接教技能的 Markdown 格式和语法
让工程师先正常工作——实现功能、调试问题、完成日常任务
运行 Skill Workshop，它分析你刚才的对话会话，自动提议可以从中提取的技能

效果：工程师突然意识到——自己每天的工作流程、解决问题的方法、积累的经验，都可以被提炼成可复用的技能。这是一个强烈的顿悟时刻。技能不再是需要额外学习的抽象概念，而是自己工作方式的自然延伸。

而且技能有自我修复能力。你创建了一个技能，它工作了一段时间，然后因为环境变化不再工作——Claude 可以自动重写和修复它。当工程师看到这种"技能自愈"的能力时，信任度会快速建立。

2⃣大规模技能发现实验

Adam 和工程师 Israel 做了两个有趣的实验：

实验一：让 Claude Agent 团队研究整个 Uber 工程 Wiki，找出所有多步骤流程，提议转化为技能。

实验二：让 Agent 对所有 Uber 内部 CLI 工具运行 --help，提议将它们包装成技能。

关键发现：如果只是基础 CLI 包装（把命令行变成技能调用），价值不大。

但如果Skill能修改或增强CLI 的功能：

比如组合多个命令、添加智能参数选择、增加错误处理，就有了显著的额外价值。

这个发现帮助团队建立了一个清晰的判断标准：

什么值得做成技能，什么不值得。

六、从定制 Agent 到通用 Agent + Skills#

Adam 在 AI 领域工作多年，他描述了一个清晰的范式转变：

> 前年（2024）：所有人都在谈论构建定制 Agent。

典型流程是花几周时间用 Agent SDK 开发一个专门的 Agent，让它以特定方式运作，执行特定任务。

> 去年（2025）：通用 Agent 框架（Claude）+ Skills = 任意专业化。

不需要为每个需求建一个 Agent。

Adam 用《黑客帝国》类比：Neo 被上传功夫程序后说"我知道功夫"——加载技能包就是这种感觉。

实际案例：

Adam 本人是 iOS 开发者出身，

但通过数据科学技能包，他可以立即构建任何主题的数据仪表板，Claude 帮他像数据科学家一样提出深入的分析问题。

他不需要花几个月学习数据科学，只需要加载正确的技能包。

这意味着：

数据科学家 + 工程技能包写出更健壮的查询和数据管道
工程师 + 数据科学技能包快速验证假设、创建实验、构建可视化
非技术人员 + 基础开发技能包可以完成文档网站搭建，不需要了解 Git 命令

技能包在打破专业领域之间的壁垒。

以前说"T 型人才"更多是一种培养理想，

现在通过技能包，它变成了一个可以即时实现的现实。

七、特征流水线：一个工程师的疯狂实验#

Uber 工程师 Ashutosh Bhatia 独立创建了数百个技能。

他最引人注目的作品是一个特征装配线系统，

用Skill编排实现端到端的功能开发：

最精妙的部分是他的调试哲学：

> "如果出现问题，我不会手动修复那行代码。我会回到系统层面，改进规划技能或测试技能，防止这类缺陷再次出现。"

这是一种元层面的思考方式：不是修复症状，是改进生成代码的系统本身。

短期看可能更费时，但长期能持续提升整条流水线的质量。

Adam 坦言这还是"非常实验性"的工作，但他看到了初步成效。这代表一种可能性：工程师的角色从写代码，变成设计和优化生成代码的系统。

八、SDLC 的折叠：技能链如何覆盖全生命周期#

Adam 提到了一个重要的架构观察：

技能不只是单点工具，它们可以被链式组合，覆盖整个软件开发生命周期。

一个功能从想法到上线的完整链条：

这意味着 Claude 可以编排整个 SDLC。工程师不再在不同工具之间切换，而是在一个统一的 Agent 环境中完成所有工作。

Adam 强调："这不是说 Claude 在自动运行 Uber。

人类仍然对输入和输出负责。但 Claude 成为了一个强大的协调者。"

九、Skill评估：怎么知道Skill好不好#

Adam 坦言这还很早期。但 Uber 已经在构建一个多维度评估框架：

核心原则：不要过度评估，会扼杀实验。

目标是确保核心的约 100 个 SDLC 关键技能可靠，其余的让它自由生长。

好技能的硬标准——确定性输出：Skill应该明确报告做了什么、成功了什么、失败了什么。"

尝试了 5 个优化，3 个成功，2 个不适用"——这种输出才是企业级可信赖的。

十、未来方向：三个前沿#

1⃣ 团队记忆系统

Uber 工程师 Matos 和实习生 Alex 正在构建一个团队级记忆系统：

将有价值的对话会话存储到图数据库
提供"召回"技能，通过 Graph RAG拉取之前已经发现的上下文
目标场景：新工程师入职时可以立即访问团队积累的解决方案和架构决策；跨团队协作时可以快速了解其他团队已经解决的问题

待解决的难题：

记忆层次（什么该忘？什么进入工作记忆/短期/长期？）、

衰减函数（多久的记忆开始失效？）、

隐私权限（谁能访问什么记忆？）、

相关性判断（如何确保召回的记忆有用，而不是噪音？）。

2⃣自进化技能

愿景：收集所有Skill的遥测数据和实际使用数据，在 CI/CD 构建时或定期运行的任务中，系统自动分析数据，提议改进甚至直接升级技能。

Skill不再是静态的指令集，而是从使用中持续学习、进化的活体。

3⃣技能继承模型

一个基础Skill，用户可以进一步专业化，同时继承基础版的所有能力。

核心逻辑集中维护，个性化调整在本地进行。

这在标准化和个性化之间找到了平衡。

十一、Claude 作为个人延伸#

Adam 也分享他自己的个人使用方式

我们值得单独说，因为它展示了企业管理者如何深度使用 AI 工具：

在 Claude 中添加了个人档案 MD 文件：写作风格、个人信息、工作背景
问 Claude"我是谁"，它能准确回答：你是 Adam，在 Uber 领导 AI Foundations 团队，这是你的合作对象、主要项目和工作风格
创建了 "Agentic EM"（代理工程管理）市场：不再手动问工程师要状态更新，用 Claude 拉取散落在各处的已有信息，生成符合自己风格的报告
同时运行多个 Claude 实例——一个做研究，一个构建内部工具
开发环境配置、Shell 设置、调试——所有以前"没时间处理"的事情，现在全部交给 Claude

Adam 说："我从未在职业生涯中感到如此有创造力。

我实际上工作时间比以往更多，因为能做的事情太多了。

我需要有意识地踩刹车暂停，否则会被创意淹没。"

他把 Claude 描述为"我的延伸"

不仅仅是一个通用工具，

而是了解他的风格、优先级和工作上下文的个人化助手。

十二、对中国企业的启示#

Uber 的这场 AI 工程转型，对中国的企业——特别是有一定研发规模、正在考虑或已经在使用 AI 辅助开发的 To B 用户——有直接的参考价值。

1⃣启示 1：不要等战略，从 1 个人的实验开始

Uber 的 500 个技能不是规划出来的，是从 1 个工程师的 2 个技能长出来的。

中国企业最常见的陷阱是"先规划、再立项、再招人、再试点"。

Uber 的经验说明：**先让最活跃的工程师自己玩起来。

种子期不需要管理层的许可，不需要预算，

只需要一个有热情的人和一个仓库。

2⃣启示 2：双层治理是正确的架构

完全开放 = 技能质量崩溃，用户体验碎片化。

完全中心化 = 创新窒息，工程师没有参与感。

Uber 的黄金市场 + 个人市场双层结构，精确解决了这个矛盾。

如果你在公司内推动 AI 工具的规模化落地，

这个治理模型值得直接照搬：

中心团队维护核心Skill库（严格质量标准），同时允许各团队和个人自由实验（低门槛、快迭代）。

3⃣启示 3：Skill> 定制 Agent

中国企业 AI 落地的主流思路是"为每个业务场景建一个 Agent"。

Uber 的经验是：这条路走不通——开发成本高、维护成本更高、每个 Agent 都是一个独立的技术债务。

新范式是：通用 Agent + 技能包。

一个 Claude（或任何足够好的基座模型）加上领域技能，就能覆盖绝大多数场景。

技能是轻量级的 Markdown 文件，创建成本低，迭代速度快，可以由业务工程师自己维护。

4⃣启示 4：把部落知识编码成技能

所有企业都有这个问题：最有价值的知识在少数资深工程师的脑子里。

他们离职，知识就消失了。代码注释和文档永远跟不上现实。

Uber 的性能优化技能是一个完美案例——两个资深工程师把多年的 Go/Java 调优经验编码成了一个技能，现在任何工程师都能使用。技能是部落知识最好的容器，因为它不只是记录知识，而是把知识变成了可执行的行动。

5⃣启示 5：确定性输出是企业级信任的基础

"我优化了你的代码"

这种输出在个人使用中可以接受，在企业环境中不行。

企业需要的是：

"尝试了 5 个优化，3 个成功，2 个不适用，这是每个优化的具体变更和理由。"

设计企业级Skill时，永远追求可验证的确定性输出。这不只是技术要求，是建立组织信任的前提。

6⃣启示 6：优先投资元Skill

制作技能的技能（Skill Workshop）、评估技能的技能（LLM-as-Judge 管线）、从会话中提取技能的工具——这些"元层"能力会带来指数级回报。

原因很简单：1 个元技能可以催生 100 个业务技能。如果你的资源有限，先把元基础设施建好，让技能的生产和评估都自动化。

7⃣启示 7：工程师角色的重新定义

Adam 说得很直接：

AI 时代，那些对人类重要的基础工程实践：

提交队列、CI 系统、各种工具链变得更加重要而不是更不重要。

因为现在不只是人类依赖这些系统，Agent 也依赖它们。

对中国企业的含义：不要因为有了 AI 就忽视工程基础设施。

相反，应该投入更多资源加固它们，因为质量门控现在不仅约束人，也约束 Agent。

最好的工程师的新角色不是写更多代码，而是设计和优化生成代码的系统。

你的公司在用 AI 辅助开发吗？踩过什么坑？我很想听听不同规模团队的真实经验。#

*数据来源：Anthropic 官方直播，2025 年 3 月。访谈人 Dax（Anthropic Claude Code 团队）与 Adam Hooda（Uber AI Foundations & DevX 团队负责人）。

Thread#

各位尊重的读者，#

https://x.com/li9292/status/2035018424859205938

李韭二编辑部给您致以最郑重的、最真诚的道歉和更正：时间是 2025 年 10 月到 2026 年 3 月这五个月原文中的2024年10月到2025年3月是错误的