读狼叔 2025 年总结有感：AI 时代的架构变局与长期主义这篇文章鸽了很久，直到最近完整读完狼叔（i5ting）的《2

这篇文章鸽了很久，直到最近完整读完狼叔（i5ting）的《2025 总结》，才觉得有必要系统性地写下一些自己的思考。

原文链接如下：

狼叔 2025 总结

狼叔是前端领域非常资深的架构师，他的年度总结往往并不是简单复盘，而是提前暴露未来 1–2 年工程形态变化的信号。下面我按他的几个关键观点逐条展开，也结合我自己的实践经验和理解聊一聊。

1. 构建工具的终局：Webpack → Rsbuild

观点：把 Webpack 升级为 Rsbuild，最复杂的项目也能取得 10x 左右的性能提升。渐进式升级，未来上不上 Rolldown 问题不大。

这一点我深有同感。早在 2022 年，我就在项目中尝试使用 Vite。对于中小项目来说，Vite 带来的启动速度和热更新体验确实非常好，但一旦项目规模变大，现实就会变得复杂。

在企业级项目中，从 Webpack 迁移到 Vite 往往面临两个问题：

迁移成本高：企业必须做有 ROI 的事情，如果贸然进行大规模重构，很容易影响交付节奏。
Dev / Prod 不一致：Vite 开发阶段基于原生 ESM，生产阶段基于 Rollup（即便现在在往 Rolldown 方向统一），在复杂项目中仍可能踩到一些边界问题，比如 CSS 优先级、Polyfill 行为差异等。

因此我非常认同狼叔选择 Rsbuild 的判断。

Rsbuild 基于 Rust 重写的 Rspack，但同时对 Webpack 的 loaders 和 plugins 有非常好的兼容性。这意味着不用推倒重来，就能直接享受到数量级的性能提升。这对大型、历史包袱较重的项目来说，是非常务实的选择。

我自己也在项目中较早尝试过 Rsbuild，并在 2024 年写过一篇完整的迁移复盘：从 VueCLI 迁移到 Rsbuild。整体体验就是：配置几乎不怎么动，但构建性能肉眼可见地提升。至于 Rolldown，在 Rsbuild 已经解决核心痛点的前提下，是否追新反而没那么重要了。

观点：升级 Node 16 → 24，用 Cursor 搞定 C / C++，增强团队信心。反感 Vibe Coding，认为编程的专业化与平民化将长期共存。

在 Bun 和 Deno 的压力下，Node.js 这两年的更新速度明显加快了。比如原生支持 TypeScript 运行、.env 文件加载、Watch 模式等，这些都是对开发者非常友好的改进。紧跟 LTS 版本，本身就是一种低成本的收益。

关于 AI，我自己也是 Cursor 的深度用户。在 AI 的辅助下，我明显感觉到自己的技术边界被拉宽了——以前不太敢碰的 C++、Rust 相关代码，现在至少敢去看、敢去改、敢去验证。这一点和狼叔提到的“用 AI 写 C++ 给团队上一课”非常有共鸣。

至于 Vibe Coding（凭感觉编程），我个人的态度也比较接近狼叔：小项目里我也会“一把梭”，甚至报错修复都依赖 AI；但在真正的工程场景中，是否具备审视、Review 和纠偏 AI 输出的能力，依然是专业性的体现。

我并不认为 AI 会完全替代程序员，短期内也没看到真正颠覆性的创新，但从长期来看，AI 会不断放大个人的能力边界。未来程序员的角色可能会变得更模糊，对工具的理解和使用能力，反而会成为重要的衡量标准之一。

观点：基于页面级别的 Bundless 改造，发布从分钟级降到秒级，无需 Web Server，为 AI Agent 提供基础设施。

这是整篇总结中我个人最喜欢、也最看好的一个创新点。

AI Agent 构建项目的速度非常快，但传统的发布流程却异常缓慢：

CI 推送
→ npm install
→ npm run build
→ Docker 镜像构建
→ 镜像推送
→ K8s 调度与健康检查

这一整套流程跑下来，动辄 10 分钟以上。如果 AI 需要反复修改和验证，这样的反馈速度是完全无法接受的。

结合狼叔的描述，我推测核心思路是：利用 ESM 实现页面级别的“原子化发布”。

可能的实现方式是：

用户访问时的流程可能是：

用户访问
→ CDN 返回 HTML 空壳
→ 动态读取路由表
→ 按需加载页面模块

整个系统完全由静态文件组成，不需要 Node.js 服务，也不需要 Nginx、Docker 或 K8s。发布的本质变成了“上传文件”，这正是能够做到秒级反馈的关键。

观点：基于 AST 和 AI Search 的自动验收，比生成 E2E 更可靠。

E2E 测试的问题大家都很熟悉：慢、不稳定、维护成本高，而且让 AI 写 E2E 测试也很容易陷入“描述过多、细节脆弱”的问题，需求稍微一变就要全部重来。

如果结合 AST（抽象语法树） 和 AI，思路就完全不同了。

AST 提供的是一种数学意义上的确定性：代码被编译成 AST 之后，它的结构是稳定且不会“说谎”的。通过 AST，我们可以非常明确地知道某段逻辑是否存在、是否被执行。

一个可能的流程是：

例如：让 AI 检查“登录逻辑是否校验了用户是否勾选隐私协议”，AST 负责提供确定的逻辑结构，AI 负责判断语义是否符合需求。

相比 E2E 测试验证 UI 表象，AST + AI 更接近对业务本质的验证，也更适合构建 AI Code Agent 的自动闭环。

观点：基于 Moonbit 实现 React SSR，性能提升约 2x；看好 Bun 作为工具链。

Moonbit（月兔）是一门面向 WebAssembly（Wasm） 的编程语言。狼叔提到用它重写 React SSR 并获得 2x 的性能提升，本质上是把计算密集型逻辑从 JavaScript 中剥离，交给 Wasm 来完成。

这背后反映的是一个趋势： 前端正在主动下沉到更高性能的技术栈中，而不是局限在 JavaScript 本身。

至于 Bun，虽然社区对稳定性仍有一些争议，但它将包管理、打包、测试等工具整合在一起，用作工具链确实非常方便。对 AI 来说，开箱即用的工具链体验会变得越来越重要。我个人也会持续关注 Moonbit 和 Bun 的发展。

对我来说，狼叔提到的点很多，但真正触动我的，主要集中在下面三点：