> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh-hant/2026/w13-meituans-q4-earnings-and-why-the-ai-era-needs-a-unified-efficient-toolchain.md).

# W13-美團 Q4 財報與為什麼 AI 時代需要一個統一高效的工具鏈

去年每個 Q 都會讀財報，結合公眾號的內容寫一個回顧。今年這個工作也可以自動化了，通過 Cowork 的 Schedule 完成。如今 AI 可以獨立完成信息抓取、分析、整理、輸出到學城，完成質量比我自己做高得多。以後每個 Q 動態補充我認為好的信源，手動觸發 Schedule，保持分析架構的穩定。

我分析財報有一個重要的目的，是想搞清楚怎麼去客觀地研究一家公司，美團是我現階段最值得研究的公司。最近半年有一個感受，在一家公司裡研究這家公司，可能會燈下黑。在公司裡，受到的影響不止於市場，有自己的立場，有局部的噪聲，有從局部線性外推到整體的傾向。自以為在公司裡就可以很瞭解公司，可以掌握很多內部信息，事實上，很多關鍵信息反而是從外部先獲得。比如 LongCat，從 LongCat 在 Coding 中的表現來看，以前很輕易地做了否定。但我是認同模型專業化的演化趨勢的，我在沒有仔細瞭解過 LongCat 的情況下就做出判斷，這就不是一種好的研究習慣。我想諸如此類的問題也是區別投行分析師和民間股評人的核心差異。

***

### 為什麼 AI 時代需要一個統一高效的工具鏈？

上週兩個事情讓我覺得應該認真思考一下這個問題。

一個是尤雨溪在 D2 繼續推廣用 Rust 重寫的一體化前端工具鏈。核心觀點是寫代碼不是瓶頸了，AI 需要不斷檢查驗證自己的代碼，如果你不能給 AI 提供一個乾淨高效的工具鏈，那麼未來會阻礙你生產力的大幅提升。

另一個是 [OpenAI 宣佈將收購 Astral](https://openai.com/index/openai-to-acquire-astral/)，把 Python 的一套工具鏈併入 Codex。這次收購在某種程度上看起來與 [Anthropic 收購 Bun](https://www.anthropic.com/news/anthropic-acquires-bun-as-claude-code-reaches-usd1b-milestone) 類似。Astral 是 uv（Python 包管理器）、Ruff（代碼檢查器）和 ty（類型檢查器）的開發商。

無獨有偶，Jeff Dean 在剛結束的 GTC 裡也提到一個觀點。當前的工具大多是為人類設計的。人類的交互速度以秒計，因此 C 編譯器的啟動時間、API 的響應延遲在過去並不致命。但當智能體的運行速度比人快 50 倍時，這些毫秒級的延遲就會產生主導影響。根據阿姆達爾定律（Amdahl's Law），系統的整體加速比受限於那部分不可加速的部分。如果模型推理只需 100 毫秒，但工具鏈的初始化和調用需要 2 秒，那麼模型性能的提升對端到端效率的貢獻將微乎其微。

類似的邏輯，也能解釋為什麼 Anthropic 要收購 Bun。關鍵不在 Bun 更快，而在它是一整套可控的執行環境。傳統工具（如 Bash）是為人類設計的，通過文本輸出傳遞信息，但 AI 需要的是結構化、低噪音、可解析的反饋。如果工具層本身就為 Agent 設計，那麼上下文對齊和錯誤修復的成本會顯著下降。

我現在會把這些事統一理解為 Harness Engineering。Harness Engineering 的本質就是能設計出更好的 Harness，在有限上下文和工具能力下，讓一群 Agent 和少量人組成可控、可驗證、可擴展的工程系統。

AI 可以快速生成代碼，但無法一次寫對。真實過程是反覆調用工具：裝依賴、編譯、lint、類型檢查、跑測試、執行程序。如果這套鏈路慢、碎、不可預測，那麼大部分時間都會消耗在等待和不確定性上。

所以 AI-ready 的工程可以考慮有沒有一套乾淨、快速、統一的工具鏈，能夠支撐 Agent 持續運行。