uv在GitHub杀到43%份额，LLM却还在教用户用pip

Stack Overflow 2025开发者调查显示，74.2%的受访者对uv持"赞赏"态度——这个数字让它成为当年最受推崇的技术标签。但同一时期，GitHub上前10万个星标最高的仓库中，uv的实际使用率只有10%。

差距从何而来？一个工具可以同时被"喜欢"和"不用"。这篇数据复盘会解释为什么uv在开发者口碑和真实落地之间隔着一层窗户纸，以及谁还在拖后腿。

2024年2月登场：uv的闪电战

uv由Astral公司推出，主打速度营销。但让作者从Poetry迁移过来的，其实是Python版本管理和虚拟环境的隐形减负——把支持的Python版本写进pyproject.toml，README里再也不用啰嗦venv怎么配。

社区反馈印证了这个痛点。问题是：好感度能换算成装机量吗？

检测方法很直接：仓库里有uv.lock文件算用uv，有requirements.txt算用pip。前10万星标仓库的筛选引入了强烈的遗留偏见——老项目不会凭空迁移工具链。所以作者把镜头对准2025年新建仓库，这是uv完整可用的第一个日历年。

数据立刻变样：uv出现在32%的Python仓库里， popularity达到requirements.txt的43%。2026年第一季度，新建仓库中uv占比30%，相对popularity微升至44%。样本量245个仓库，其中13个"脚踩两条船"同时用了uv和pip。

2026年目前星标最高的Python仓库karpathy/autoresearch，用的就是uv。

考虑到开发者通常维护多个仓库，uv的真实装机基数大概率高于30%这个数字。

VC背景和OpenAI收购：偏见有没有成真

第一反应往往是情绪性的：是不是因为uv拿了风投钱？是不是OpenAI收购Astral之后大家膈应了？

实际数据不支持这个叙事。VC背景没拦住uv在2025年反超Poetry；OpenAI交易之后，作者也没观察到增速放缓的迹象。工具链迁移的惯性比道德洁癖更强大。

真正有趣的是那70%没用uv的仓库在干什么。作者抽查了2026年top仓库里仍在用requirements.txt的案例，发现几种用法：零依赖安装、给agent装技能、测试专用（其他依赖用uv管）、benchmark子项目、在agent内部运行、以及最传统的——普通Python项目依赖声明。

最后一种算是主动选择，前面几种看起来像是……没人在管。

LLM才是隐形的产品经理

作者做了个实验：问ChatGPT、Gemini、Claude怎么装Python包，三家齐刷刷推荐pip。

训练数据里沉淀了十年的pip install -r requirements.txt和pip install {package}，不是新工具一两年能刷掉的。LLM的推荐权重本质上是对历史语料的投票统计，而uv太年轻了。

这就形成了一个荒诞局面：人类开发者一边在Stack Overflow给uv打高分，一边让AI助手给自己项目写requirements.txt。代码仓库成了人机协作的化石层，底层是LLM的惯性，表层是开发者的真实偏好。

那些"脚踩两条船"的仓库——同时有uv.lock和requirements.txt——可能就是过渡态的证据：人已经切了uv，但CI脚本或者自动生成代码还在吐pip配置。

给不同角色的三条建议

作者按身份分了应对策略。普通开发者：直接上uv，你的队友大概率已经装了，只是没声张。工具链作者：检测一下环境，有uv就优先用，没有再fallback到pip，别让用户手动选。LLM产品经理：训练数据该更新了，你们的产品建议正在和用户的真实工具链脱节。

最后一条指向一个更深层的问题。当AI成为代码的主要生产者，它的"知识截止日期"就变成了整个生态的拖速带。uv不是输在功能，是输在还没被写进足够多的训练语料里。

karpathy/autoresearch用uv这件事本身，可能比它的星标数字更有信号意义——顶级独立开发者正在用脚投票，而这个选择还没被LLM大规模镜像。

你的新项目，README里写的是pip install还是uv sync？