结论

For FDE 和高效 POC，我怎样选择默认技术栈？

• 前端按场景选择：
  • PC 工作台、复杂 SPA 和 PC 客户端：
    • React + Vite + Ant Design + Ant Design Pro 等
  • 复杂的移动 Web 和 H5：
    • Vue + Vite + Vant
  • 移动客户端：
    • React Native，继续复用 React 经验
  • 小程序跨端：
    • Taro，继续复用 React 经验
• 静态官网和内容站：
  • PC：
    • Astro + Vite，默认只用 HTML、CSS 和 JavaScript
  • H5 或公众号：
    • Astro + Vite，默认只用 HTML、CSS 和 JavaScript
• PC 工作台、中后台和复杂 SPA：React + Vite + Ant Design。
  • 浏览器交互是主体，直接控制路由、状态、权限、图表和地图更合适。
  • 完全自定义时直接使用 Vite
    • 其他 Modern.js（Rspack）、Umi、Next.js 等前端元框架，反而会限制住手脚。
    • React 页面与服务端确实需要一体化时，再使用 Next.js
      • 同理，没必要为了渲染性能（SSR、服务端组件等）而徒增复杂度
• 后端：优先 FastAPI
  • Node.js 生态我太熟了，但主动放弃
  • 因为：
    • 岗位样本中，Python 在 Agent 开发中命中 80%，FDE 为 57%，Harness 为 52.9%

技术选型只服务一个目标：缩短从真实问题到可运行产品和 新岗位的距离

最小产品形态优先、ROI 最高优先

• 每次先选择最小产品形态，选择最成熟的、自己最熟的
  • 能用 Web，不先做 App；
  • 能用 H5，不先做原生；
  • 能用 CLI 验证，不先做完整界面；
  • 没有真实需求，不提前加入数据库、队列、向量库和 Agent 框架。
  • 移动 Web 先 H5；需要小程序入口时使用 Taro，需要原生 App 能力时使用 React Native
  • 桌面端先 Web；确实需要系统能力时再使用 Tauri 或 Electron
  • CLI 根据实际情况选择 TypeScript 或 Python

每种场景的最佳选择

For me：下面每种场景都是我自己最熟且生态最好的，对于我来说是最平衡的选择。

Web 场景

内容官网不要预装前端框架和组件库

PC 端选择 Astro 后，默认不加 React 和 Ant Design；H5 选择 Astro 后，默认不加 Vue 和 Vant。普通的菜单、轮播、表单、弹层和地图都可以用 HTML、CSS、JavaScript 与对应 Web SDK 完成。React 和 Vue 本质上也是在组织 JavaScript；只有当状态、组件复用和长期维护的成本已经被真实需求证明时，才引入框架。

① PC 内容官网：Astro + Vite

• 默认生成 HTML 和 CSS；
• Content Collections 在构建时校验内容，适合通过 Git 和 Codex 维护官网。
• 轮播、表单和地图等局部交互先用原生 JavaScript 和对应 Web SDK，CSS 和 PostCSS 继续走 Vite。
• 页面开始依赖统一路由、登录态、全局状态和大量可复用业务组件时，问题已经从“内容官网”变成“应用”，应该独立使用 Vite + React + Ant Design，而不是继续往 Astro 里堆 React Islands 和 Ant Design。

案例：公司官网

• PC / 和 H5 /m 继续作为两套独立静态应用维护。
  • PC 使用 Astro + Vite，交互默认用原生 JavaScript，非必要不要 React + Antd。
  • H5 /m 也使用 Astro + Vite，不预装 Vue 和 Vant。
• FastAPI 提供 /api 并托管静态产物，生产环境不运行 Node.js

② 移动官网、营销页和公众号 H5：Astro + Vite

• 内容优先的移动官网和 H5 默认使用 Astro + Vite，交互先用原生 JavaScript。
• 表单、弹层、轮播和展开收起不是引入 Vue 和 Vant 的充分理由。
• 只有当它实际变成以管理、长表单、列表状态和复杂交互为主的 H5 应用时，才切换到后文的 Vue + Vite + Vant。

③ PC 工作台和复杂 SPA：React + Vite + Ant Design 6.0 + Ant Design Pro 6.0

• 适合权限、表格、图表、地图、Excel、拖拽和复杂客户端状态，Ant Design、ECharts、Zustand、Wujie 等按需进入。
• 之前大量的复杂内部业务和外部 SaaS 已经证明了这一点，毋庸置疑！
• Umi 暂时不纳入范围。蚂蚁体验中心已经拆分，生态延续性大概率不如 Vite。
  • 复杂业务随时可能接入小众类库，Vite 更灵活。

PC 复杂 SPA 不考虑 Vue；复杂移动 Web 和 H5 应用使用 Vue。内容官网两端都优先使用 Astro。
当下这个时间点，Vite 生态应该是构建工具里最好的。

案例：公司对内对外数据产品及其作业产品

• 使用 React + Vite + Ant Design + ECharts + 高德地图等。
• 产品复杂度已经特别高，还通过 wujie 微前端嵌入子应用。

开源的及其复杂单页系统，大多是 React 生态，之前做低代码平台，感触很深

④ 复杂 H5：Vue + Vite + Vant

• 移动 Web 中的管理、表单、列表和复杂交互也统一使用 Vue + Vite + Vant，不再为了保持 React 主线选择 Ant Design Mobile，原因如下：
  • UI 生态
    • 当前真正需要比较的是 Vant 和 Ant Design Mobile。
    • 截至 2026-08-02，两者都仍在维护，但 Vant 的近期提交与正式发版节奏更稳定，Ant Design Mobile 的正式版本发布明显变慢。
  • 构建生态
    • Vite 对移动 Web 构建更友好；之前做移动端项目时，我曾因兼容问题只能降级到 Umi 3
  • 再考虑蚂蚁体验中心近期拆分，以及我本身熟悉 Vue，复杂移动 Web 统一选择 Vue + Vite + Vant

后端场景

• FastAPI 作为默认后端
  • 适合独立 API，以及 Agent、RAG、数据和评测相关服务
• FastAPI 与静态前端分开：
  • 前端继续静态构建
  • 根工程使用 pnpm workspace 统一编排多个应用，Python 依赖继续由 uv 管理

备注：
1、选择 Python 不是因为 Node.js 做不了，而是为了在完成交付时形成 FDE 和 Agent 岗位需要的 Python 证据。
2、如果性能真是瓶颈，那么可以用其他的后端语言，Node.js、Go、甚至 Java 都是可选项。同样，这也肯定也是未来的事情。

Agent 或 Harness 场景

• 根据实际情况选择 JavaScript 生态（Node.js、Bun 等）或者 Python。

性能真是瓶颈，那可以考虑 Rust，当然，这是未来的事情。

PC 客户端

• 默认先做 Web；确实需要安装包、本地文件、托盘、快捷键等系统能力时，再做 PC 客户端。
• 选择 React + Tauri 或 Electron 。
  • 继续复用 React 和 Web UI。
  • 明显依赖 Node.js、Electron 插件或现有 Electron 代码时，使用用 Electron。
  • 对包体积有要求，使用 Tauri

以后有真实桌面产品需求时，再做具体选择，目前这里只是建议的候选路线
Electron 个人有实践经验

移动客户端

• React Native
  • 延续 React 和 TypeScript 主线
  • React Native 我也是搞过的
• 深度平台能力或性能成为真实瓶颈后，再考虑 Swift / Kotlin / Flutter

未来真有移动端场景，也需要考虑鸿蒙系统。

小程序

• Taro + React + TypeScript
  • Taro 可以延续 React 心智
• uni-app 不考虑
  • uni-app 的 HBuilder，各种 QQ 微信群，你体验一下？
  • 真给我留下了深刻印象

Taro 之前我也是搞过的，能支持微信、支付宝、飞书等等的小程序
除非一定要做鸿蒙 APP，uni-app 才考虑

关于脚手架

• 各类产品的大方向和技术选择已经明确，遇到真实项目时，直接让 AI 按需生成即可。
• 每个项目从真实需求中长出来，提前设计脚手架反而会增加约束和维护
• 最后，我认为脚手架已经不是一个真需求了。