大多数公司的数据分片按用户ID或哈希值切，Uber的做法是把「城市」当成基础原语。资深工程师 Uday Kiran Medisetty 分享的内部实践显示，数据分片和部署都以城市为单位推进，而不是抽象成统一的区域或集群。

这个选择背后是业务逻辑的直接映射。城市是Uber运营的最小完整单元，定价、合规、调度都围绕它展开。把工程原语对齐业务原语，分片和部署的边界天然清晰，不需要额外发明一套中间抽象层。

模型无关的AI网关

Uber构建了一个模型无关的AI网关。核心目的是避免供应商锁定——不让业务代码绑死在某一家的模型接口上。网关层做统一抽象，底层换模型时上层无感知。

这个思路在AI基础设施里越来越常见。模型迭代速度太快，今天选定的供应商可能半年后就不是最优解。把调用层抽象出来，切换成本从重写业务代码降到改配置。

AI生成代码带来的指标转向

AI Agent 正在产生大量 PR，Uber把评估指标从「速度」转向了「分类」。不再只看合并了多少、多快合并，而是按功能、维护等类别拆分，去评估这些代码的真实业务价值。

速度指标在AI辅助编程时代会失真。Agent 可以快速产出大量可合并的PR，但合并快不等于价值高。分类之后才能看清：多少是真正推进功能的，多少只是维护性改动。

这套组合拳的逻辑是一致的：无论是数据分片、模型调用还是代码评估，Uber都在把抽象层对齐到真实业务单元，而不是追求技术上的统一优雅。