> 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/2026-nian/w13-mei-tuan-q4-cai-bao-yu-wei-shen-me-ai-shi-dai-xu-yao-yi-ge-tong-yi-gao-xiao-de-gong-ju-lian.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 持续运行。