谷歌已经把它最庞大的 Python 代码库，交给了一个来自 Meta 的工具。在内部包含数十万个文件的 monorepo 里，Google 正式采用开源的 Pyrefly 作为 Python 类型检查器，替换掉自家维护了十余年的 Pytype。据谷歌披露，这次替换让工程师和 AI 编码智能体的编辑-重建循环最高快了 98%，并把类型检查在干净构建关键路径上的占比压缩了 90% 到 99%。
Pytype 是谷歌内部开发的类型检查器，十余年来一直是这一领域的先行者，还曾与开源社区合作创建 typeshed。问题出在实现路径上：Pytype 分析的是编译后的字节码，而不是源码 AST。随着 Python 类型系统快速演进，字节码在不同 Python 版本间并不稳定，跟上新 PEP 的维护成本越来越高，它也越发难以提供现代开发循环需要的快速反馈。谷歌此前已宣布，Python 3.12 是 Pytype 最后一个支持的版本，随后开始寻找现代开源替代品。
Pyrefly 在三方面胜出。性能上，它用 Rust 编写，为高吞吐和惰性、并行求值而设计，在谷歌内部多个项目的基准中比 Pytype 快一个数量级，并能在大规模依赖图上平稳扩展。类型规范符合度上，它在官方类型一致性测试套件上的得分约为 97%，并持续跟进新的 Python 版本和类型 PEP。更重要的是，它在 Pytype 历史上较为宽松的地方提供了严格类型安全：Pytype 允许把 int | None 或 int | str 这类联合类型的值传给只接受 int 的函数，只要联合中有一个类型兼容即可；Pyrefly 则强制进行可靠的联合类型检查。源码里 process_id(val) 这种写法，Pytype 接受，Pyrefly 直接报错。
诊断信息也是 Pyrefly 的卖点。它提供 Rust 风格的编译器诊断，把出错的代码片段连同内联标注一起展示，直接指向类型不匹配的根因，有时还会给出修复建议。上面那个例子会得到「Argument int | None is not assignable to parameter x with type int」，附箭头指向具体行列，并提示「声明的类型不允许 None，考虑用 is not None 检查收窄类型」。
落到基础设施层面，数字更能说明问题。在开发者编辑-重建的工作流中（守护进程处于热状态），Pyrefly 让延迟最多降低 98%，大型机器学习目标的类型检查时间从分钟级降到秒级。在主要库和模型的冷缓存基准中，它把类型检查在构建关键路径上的占比降低 90% 到 99%，消除了一个长期存在的瓶颈。谷歌表示，Pyrefly 让 Python 类型检查每天的峰值算力占用下降超过 80%，相当于每天省下数千个机器核。
谷歌工程师的反馈集中在「不用再等」和「报错清楚」两点。JAX 技术负责人 Peter Hawkins 说，项目切换后他就没再等过 Pytype 动作完成，这对智能体编码是双重利好，「类型检查现在比跑测试还快」。负责 Gemini 大规模预训练的 Yotam Doron 喜欢 Pyrefly 指出问题所在的清晰报错。GDM Science 的 Tom Ward 则认为，投资 Python 工具链对研究速度回报巨大，Pyrefly 让实验迭代保持快速，并用可操作的错误及早抓住细微 bug。
对谷歌来说，这次迁移还有一层姿态上的意义：它承认「团结在共享的开源开发者工具之上」有价值，并对 Pyrefly 团队在推出过程中快速响应上游问题表示感谢。
对中国 Python 开发者而言，值得注意的不是谷歌换了一个工具，而是类型检查器正在被整体重写一遍。用 Rust 重做 Python 工具链已经形成一条清晰路线------Ruff 重写了 lint，uv 重写了包管理，Astral 的 ty 也在推进类型检查------Pyrefly 又被 Meta 开源、被谷歌采用，说明这条路线在大厂的真实代码库里已经跑通。Pyrefly 已在 GitHub 开源，任何团队都可以拿自己的项目试一试。