每日突破性工具推薦｜Astral ty 0.0.93

Astral ty 0.0.93：以細粒度增量分析重新設計 Python 型別檢查

推薦類型：Fallback。ty 並非本日首次發布的新工具；本次選擇 2026-10-28 的 0.0.93，原因是診斷基準線（Diagnostic Baseline）讓既有大型程式庫能漸進導入型別檢查，並結合其增量分析架構與編輯器支援。版本日期以官方 Release 為準。

1. 工具定位與適用情境

ty 是 Astral 以 Rust 開發的 Python 靜態型別檢查器與 Language Server，與同公司的 Ruff（Lint／Formatter）及 uv（套件管理）分工不同。它在不執行程式碼的情況下分析 Python 型別，提供命令列檢查、編輯器診斷、跳轉、補全與重構輔助。

適合 Python API、後端服務、資料處理及持續演進的大型程式庫；尤其適合希望在 CI 導入型別檢查，卻無法一次修完歷史錯誤的團隊。

2. 近期突破：診斷基準線

0.0.93（2026-10-28）加入預覽中的 Diagnostic Baseline。可先記錄既有診斷，再讓後續檢查聚焦於新出現的問題：

# pyproject.toml
[tool.ty]
baseline = "ty-baseline.json"

uvx ty check --update-baseline
uvx ty check

官方說明：符合基準線的診斷會從 CLI 輸出中過濾，並在 Language Server 中以提示呈現。這並非修復舊錯誤，也不能替代品質門檻；基準線格式仍可能調整。版本同時修正迴圈真值判斷可能造成的 panic、遞迴 union 取反可能造成的卡住，並改善 Django 抽象模型主鍵、ParamSpec 與覆寫檢查。

0.0.92（2026-10-26）加入 SARIF 格式輸出，可用於支援 SARIF 的程式碼掃描與 CI 呈現；也改善 Django 模型欄位推論。這些是相鄰版本的已公開變更，不應誤記為 0.0.93 才新增。

3. 核心架構與運作方式

ty 的設計核心是細粒度增量分析：依賴圖追蹤程式碼定義與使用關係；編輯單一檔案時，盡量只重算受影響的分析結果，而不是重新分析整個專案。CLI 的 ty check --watch 會監控檔案並重查受影響項目，Language Server 也採用相同的低延遲分析方向。

型別系統支援交集型別（intersection types）與型別縮窄，並依型別資訊推斷不可達分支。這有助於表達複雜 Python 控制流程，但其型別推論與其他檢查器可能產生不同診斷，應以實際專案比對。

整合流程通常是：尋找 Python 環境及第三方依賴 → 解析原始碼與型別資訊 → 增量推論 → 套用診斷規則及 baseline → 透過 CLI、SARIF 或 LSP 回報。這是架構層次的整理，不代表每個內部步驟都有固定公開 API。

4. 主要優勢

• 快速回饋：Rust 實作與細粒度增量更新，有利於大型專案的編輯器互動；實際速度依專案與硬體而異，不應套用未經驗證的倍數。
• 漸進導入：baseline 可把歷史問題與新增問題分開處理。
• 完整開發體驗：支援 VS Code、PyCharm 及標準 LSP；具備診斷、跳轉、參照查找、補全與提示。
• Python 生態整合：能搭配 uv 管理環境、Ruff 做格式與 Lint，形成職責清晰的工具鏈。
• CI 友善：CLI 檢查、watch 模式及 SARIF 輸出可整合不同品質流程。

5. 與同類工具比較

6. 缺點、風險與限制

1. 0.0.x 仍屬快速演進階段；規則、診斷、設定與 baseline 格式可能變動。
2. 動態 Python、反射、複雜 metaclass 或缺乏型別註記的第三方套件，可能造成誤報或推論限制。
3. 導入既有專案時，診斷數量及與 mypy／Pyright 的差異需先量測；不宜直接替換既有 CI 門檻。
4. baseline 若長期不清理，可能讓歷史型別債務永久留存；應定期縮減基準線。
5. 型別檢查無法取代單元測試、整合測試、執行時驗證或安全掃描。

7. 適合與不適合的使用者

適合：大型 Python Monorepo、重視 IDE 回饋的開發團隊、想把新型別錯誤納入 CI 但已有技術債的專案，以及正在採用 uv + Ruff 的開發流程。

不適合直接全面替換：深度依賴特定 mypy 外掛的程式庫、需完全固定診斷行為的受監管環境、尚未完成相容性測試的關鍵生產 CI。

8. 建議導入流程

uv add --dev ty
uv run ty check
uv run ty check --watch

先在獨立 CI Job 執行，觀察診斷差異；如歷史錯誤過多，可評估啟用 0.0.93 預覽 baseline。將 baseline 納入版本控制前，應檢查內容並規劃逐步減少舊錯誤；等結果穩定後再設為阻擋合併的必要檢查。

9. 結論

ty 值得關注的不是單一效能數字，而是將 Python 型別分析、編輯器服務與漸進式品質治理整合為低延遲工作流程。0.0.93 的 Diagnostic Baseline 讓有技術債的既有專案更容易開始導入，但仍屬預覽功能。建議先與既有檢查器並行評估，再決定是否遷移。

官方資料

• ty 0.0.93 Release（另開分頁）
• ty Releases（含 0.0.92）（另開分頁）
• Type checking（另開分頁）
• Language server（另開分頁）
• Type system（另開分頁）
• Editor integration（另開分頁）
• Installation（另開分頁）