一句話：Google 於 2026-10-06 官宣以 Meta 開源的 Pyrefly 取代自研 14 年的 Pytype，增量重建延遲最高降 98%。本文拆解那個 98% 的真實語義、bytecode 架構的致命傷、遷移工程細節，以及它與 Astral ty 的雙雄格局。
用了一個自己養了 14 年的工具，某天公開宣布：換掉，改用競爭對手家的開源品。Google 在 2026 年 10 月 6 日做了這件事。官方工程部落格那句公告寫得平靜，背後卻是 Python 工具治理邏輯的整頁翻新。
這不是小調整。Google 的 monorepo 裡有數十萬個 Python 檔案，型別檢查是每次程式碼變更的必經關卡。換掉它，等於替全公司的 Python 開發迴圈換心臟。
先說結論：那個 98% 不是你想的那樣
多數轉述文會告訴你「快了 98%」。這句話省略了三個關鍵前提。
第一，98% 是「最高值（up to）」，不是平均值。第二，它量的是 incremental rebuild 延遲，也就是工程師改完程式碼後，等型別檢查跑完的那段時間。第三，也是最常被省略的：它只有在 warm daemon（暖常駐行程）的前提下成立。活躍編輯週期中，daemon 記住了之前的分析狀態，增量才快得起來。
冷快取是另一組數字：乾淨建置（clean build）的關鍵路徑上，型別檢查佔比降了 90% 到 99%，這是 cold-cache 基準套件的口徑。第三組是基礎建設成本：Python 型別檢查的每日峰值算力佔用降超過 80%，每天省下數千個 machine cores。
三組數字三個口徑，混在一起講就是幻覺（出處：Google 開源部落格）。
落到單一目標更有感。官方對比圖（暖 Bazel 快取）裡，小型 configuration 函式庫：Pytype 2.7 秒，Pyrefly 1.7 秒，差距不大。大型機器學習模型：Pytype 246.7 秒，約 4.1 分鐘；Pyrefly 4.5 秒。分鐘級變秒級，這才是「98%」的實體。
Pytype 為什麼被放棄：架構級的疲倦
Pytype 不是失敗品。2012 年開始開發，跟 Guido 與 mypy 團隊協作催生了 typeshed，也就是今天 Python 型別 stub 生態的公共地基。它是型別檢查的先驅，GitHub 上有 5,000 顆以上的星星。
問題出在架構假設過期了。Pytype 分析的是編譯後的 bytecode，不是原始碼 AST。bytecode 跨 Python 版本不穩定，而這幾年 Python 的型別語法（typing PEP）快速演化，每個新版本都要追著 bytecode 改，維護負擔越滾越大。官方 README 的終止聲明寫得直白：Python 3.12 是 Pytype 支援的最後一個版本。
換句話說，不是 Pytype 做錯了什麼，是它立足的地基（bytecode）跟語言的演化方向（快速迭代的型別語法）脫節了。
Pyrefly 是什麼：Meta 為 Instagram 造的引擎
Pyrefly 是 Meta 開源（MIT 授權）的 Python 型別檢查器與 IDE 語言服務，Rust 寫的。動機很單純：Instagram 的程式碼庫超過 2,000 萬行，整個 monorepo 約 150 萬個 Python 檔，舊工具 Pyre（2017 年起，OCaml 實作）跟不上，Meta 決定打掉重練。
它的時間線值得細看，因為這解釋了 Google 為什麼敢選一個「別人家的工具」：
2025 年 4 月首度公開；5 月 15 日 alpha 官宣，吞吐 1.8M lines/sec；9 月 15 日 IDE 擴充上線，從 Pyright 切換過來的開發者 hover 等待時間減 98%；11 月 17 日進入 beta，typing 規格符合度（conformance）從 alpha 時的 39% 衝上 70% 以上；2026 年 5 月 12 日發布 v1.0，PyTorch 全量型檢快了 34%，採用方包括 NumPy、Pandas 與 JAX；然後是 10 月 6 日，Google 官宣採用。
那條 conformance 迭代曲線（39%、70%+、約 97%）是 Google 引用的數字，也是「這個工具在快速成熟」的最硬證據。順帶一提，97% 和 98% 是兩回事：97% 是官方 typing conformance test suite 的規格符合度，98% 是延遲降幅。淺層文章最愛把這兩個數字攪在一起。
一段程式碼看懂語義差異
Pyrefly 不是 Pytype 的加速版，它連檢查規則都更嚴格。官方文給的例子是 unsound unions：
def process_id(x: int) -> None: ...
def get_id() -> int | None: ...
val = get_id()
process_id(val) # Pytype 放行，Pyrefly 拒絕Pytype 的老邏輯：union 裡只要有一型相容就放行。Pyrefly 強制 sound union checking：None 可能流進來，直接報錯，並建議補一個 is not None 檢查。
這個差異就是遷移摩擦的縮影。更嚴格的檢查器會在新舊交接期製造一波「新錯誤」，怎麼處理這波錯誤，正是下一節的工程細節。
遷移工程：五步路線與兩個陷阱
官方遷移文件給的路線，精簡成五步：
- 舊 checker 並存安裝 pyrefly
pyrefly init轉換既有 mypy 或 Pyright 設定pyrefly check驗證，舊設定原地保留，雙工具並行- 收斂行為差異造成的新錯誤：行內
# pyrefly: ignore，或用 baseline file 記錄既有錯誤、CI 只報新增 - 收斂後移除舊工具
第一個陷阱藏在第二步。pyrefly init 轉設定時，未識別的設定會靜默跳過、不給警告。這是官方文件自己承認的坑，人工核對映射不可省。
第二個陷阱是語義摩擦集中爆發，unsound unions 只是典型。超大 codebase 的解法是 baseline 模式：先把存量錯誤凍結在檔案裡，CI 只管新增，讓遷移先動起來，再慢慢還債。
至於 Google 自己的遷移時程，沒有公開，只有 10 月 6 日的發布日。官方文只提到 rollout 期間 Meta 團隊對 upstream issue 的快速回應。這是本次事件資訊的邊界，寫到這裡為止，不腦補。
ty 對比：同一條賽道的另一匹馬
講 Pyrefly 不能漏掉 Astral 的 ty，就是做 uv 和 Ruff 的那家。2025 年 12 月 16 日 beta 官宣，同樣是 Rust 實作，官方口徑：CLI 無快取情境下，持續比 mypy 和 Pyright 快 10 到 60 倍。
真實專案的對比數字（Astral 引 home-assistant，M4 無快取）：ty 2.19 秒、Pyrefly 5.32 秒、Pyright 19.62 秒、mypy 45.66 秒。
但編輯器增量場景是另一個世界。ty 官方宣稱：PyTorch repo 編輯後增量更新 4.7ms，比 Pyrefly 的 2.38 秒快 500 倍。Pyrefly 官方自述：同為 PyTorch 加 M4 的環境，v1.0 編輯後 diagnostics 更新 19ms，比 beta 快 125 倍。
兩邊都是自家宣稱，測試環境相同，數字卻差到以倍數難以對照，差距主要來自增量架構與快取策略的設計選擇。誰快？老實說：看工作流。cold check 的數字 ty 漂亮，暖 daemon 的日常編輯迴圈則是 Pyrefly 在 Google 被大規模驗證的場景。數據並列，判斷留給你。
生態裡還有其他玩家：mypy 2.0 宣稱大型專案 cold check 最高 5 倍提速，Pyright 仍是 VSCode 預設的語言服務。四強格局已成，這篇文章先把鏡頭留在 Pyrefly 身上。
這件事真正的意義：型別檢查器的用戶變了
Google 官方文裡最有訊息量的不是數字，是 JAX Tech Lead Peter Hawkins 的引言：「自從切換後，再也沒等過 Pytype action。對 agentic coding 是雙重利好，型別檢查比跑測試還快。」
AI coding agent 的一天要跑幾十次型別檢查。工具速度從「人的耐心問題」，變成「agent 的吞吐瓶頸」。這是型別檢查器第一次因為非人類用戶，而成為基礎建設採購決策的主角。
Google 選擇不續養自研、改用對手的開源品，本質上是承認一件事：維護一個追著語言演化的檢查器，需要的工程火力已經超過單一公司的邊際效益。Meta 主力開發、Google 驗證、Microsoft 合作把 Pyrefly 接進 Pylance，社群合力才是 2026 年的工具治理答案。
自研是負債，開源是公共財。當語言每半年改一次規則，連 Google 都選擇讓社群替它扛維護成本。
工具的競爭，不再是誰的功能多，是誰的社群大。
參考來源
- Google Open Source Blog 的採用公告（2026-10-06）：https://opensource.googleblog.com/2026/10/adopting-pyrefly-as-the-python-type-checker-at-google.html
- Pytype 的 GitHub README：https://github.com/google/pytype
- Meta 工程部落格的 Pyrefly alpha 官宣（2025-05-15）：https://engineering.fb.com/2025/05/15/developer-tools/introducing-pyrefly-a-new-type-checker-and-ide-experience-for-python
- Pyrefly 官網的 v1.0 公告（2026-05-12）：https://pyrefly.org/blog/v1.0
- Pyrefly 官方的遷移文件：https://pyrefly.org/en/docs/migrating-to-pyrefly
- Astral 的 ty beta 公告（2025-12-16）：https://astral.sh/blog/ty
- InfoQ 的 Google 採用報導（2026-10-18）：https://www.infoq.com/news/2026/10/google-pyrefly-python
- Pyrefly beta 公告（2025-11-17）：https://pyrefly.org/blog/pyrefly-beta
相關文章
從零開始！用 ChatGPT 玩轉 SciPy 積分與繪圖實戰指南
用 ChatGPT 直接體驗 SciPy 積分與 Matplotlib 繪圖，不需本地安裝！本文從零開始，帶你一步步操作數值積分、函數視覺化，快速掌握 Python 科學計算的基本流程，適合新手與進階開發者。
用 Firecrawl 自動爬取網站，打造最乾淨的 GPT 訓練資料
還在手動整理網頁內容給 ChatGPT？Firecrawl 幫你自動爬取網站、轉成乾淨的 Markdown 或 JSON，讓你快速建立知識庫、訓練 LLM，省時又高效。本文已更新至 Firecrawl v2.5（2026 年 10 月）。
使用 Google Colab 理解線性代數中的 A=CR 分解：Gilbert Strang 講座解析
A=CR分解是線性代數中的第一個基本分解方法，它表示任何矩陣A都可以被分解為兩個特殊矩陣的乘積：一個包含獨立列的矩陣C和一個包含獨立行的矩陣R。
不用帶電腦也能 Coding？我的手機 AI Agent 工作流（Tailscale ＋ Termius ＋ tmux 實戰）
開發者的工作場所，常常被綁在一張桌子上。本文記錄我如何用 Tailscale 把手機和 AWS EC2 開發機放進同一個私有網路、用 Termius 在手機上維持 SSH 終端、用 tmux 讓 AI agent 在斷線後繼續工作，把自然語言變成 commit。從架構設計、安全模型、踩過的地雷，到非同步委派的工作模式與成本，完整拆解「手機叫 AI 寫程式」這件事。
用 ChatGPT + NumPy 互動模擬蒙特卡羅：一鍵估算 π 值與圖形化教學
本文教你如何使用 ChatGPT 的 Python 執行器，搭配 NumPy 與 Matplotlib，互動式實作蒙特卡羅模擬，估算 π 值並視覺化模擬過程，適合數據分析、教學演示與 AI 工具愛好者。
NumPy：Python 數據科學中的強大工具
NumPy（Numerical Python）作為 Python 中最受歡迎的數值計算庫，為數據科學家和工程師提供了處理大型數據集的強大工具。與 Python 原生列表相比，NumPy 提供了顯著的性能提升和更便捷的數據操作方式。本文將深入探討 NumPy 的優勢，並通過實例展示其在數據處理中的應用。
