前端以前能做什么？

回顾前端的发展历程，最早的前端更多只是负责编写简单的 HTML 页面，供后端模板调用。后来，随着页面复杂度提升，前端逐渐变成了大家口中的“切图仔”，主要职责是将设计稿还原成可交互的网页。

再往后，前端才真正发展为一个独立且专业的开发岗位。Vue、React、Angular 等主流框架的出现，大幅提升了前端开发效率，也让前端工程化逐渐成熟。

随着浏览器能力不断增强，前端能做的事情也越来越多。例如：

• 使用 Three.js、WebGL 实现 3D 可视化；
• 使用 WebAssembly 提升浏览器端的计算性能；
• 使用 TensorFlow.js 在前端侧尝试机器学习能力；
• 借助 PWA、Service Worker 等技术提升 Web 应用体验。

可以说，前端早已不只是“写页面”，而是逐渐演变成了连接用户体验、工程架构和跨端能力的重要岗位。

现在前端能做什么？

现在的前端，已经突破了传统网页开发的边界。

在跨端开发方面，前端开发者可以使用 UniApp、React Native、Expo、Flutter 等方案开发移动端应用。我曾经尝试过 UniApp 的 UTS，但它在兼容性方面仍有不足，尤其是在 iOS 端，很多能力本质上仍然依赖 WebView。之后也使用过 Expo，不过部分插件的实现并不够优雅，实际开发体验仍有提升空间。

如果更关注跨平台一致性和运行流畅度，Flutter 是一个值得投入的方向。它基于 Dart 语言，拥有自己的渲染引擎，跨平台表现稳定，也是我目前主要使用的移动端开发方案。

在后端开发方面，前端开发者也有了更多选择。过去如果想转向后端，常见路线是学习 Java，或者直接使用 Node.js。现在，Bun、Hono 等新工具和框架也逐渐受到关注。如果追求更好的性能和工程稳定性，也可以选择 Go 搭配 Gin 框架。

我目前主要使用 Rust 进行后端开发。Rust 拥有优秀的性能和内存安全能力，适合对稳定性和并发性能有要求的项目。不过，Rust 的学习曲线相对较陡，对开发者的工程能力也有一定要求。

此外，现代前端开发者还需要具备一定的架构意识。例如：

• Docker 容器化部署；
• CI/CD 自动化流程；
• Nginx 服务配置；
• SQL 数据库设计与查询；
• 服务端接口设计；
• 项目目录组织与模块拆分。

如果完全不了解这些内容，在面对中大型项目时，就很难做到独立维护，也难以从全局视角把控项目的长期演进。

未来前端的发展方向会是什么？

我个人比较看好 PWA，也就是 Progressive Web App，中文通常称为“渐进式 Web 应用”。

PWA 的目标是让 Web 应用具备接近原生应用的体验，例如离线访问、桌面安装、推送通知、缓存策略等能力。但从现实情况来看，PWA 这些年一直处于“不温不火”的状态，并没有真正成为主流移动端应用形态。

这让我想到 NFC 的发展过程。NFC，全称 Near Field Communication，也就是近场通信技术。它出现了很多年，但在部分场景中并没有像预期那样全面普及，甚至在很多使用场景里被二维码替代。

PWA 未来是否会迎来新的发展机会，目前还很难下定论。它的技术方向是有价值的，但最终能否成为主流，还取决于浏览器厂商、操作系统平台、应用分发方式以及用户习惯等多个因素。

不过可以确定的是，未来前端的发展一定不会只停留在“页面开发”层面，而会更加关注以下几个方向：

• 多端统一开发；
• 更强的工程化能力；
• 更好的性能优化能力；
• 与 AI 工具深度协作；
• 前后端一体化开发；
• 跨平台应用交付能力。

我如何看待 AI？

现在市面上已经有很多 AI 工具，例如 GPT-5.5、Gemini 3.1 Pro、GLM 5.1、Claude Code 等。

从我的使用体验来看，不同 AI 工具在不同任务上各有优势。例如：

• Gemini 3.1 Pro 更适合编写 HTML、CSS 这类偏视觉和结构化的代码；
• GPT-5.5 在 JavaScript、Rust、Dart 等代码生成和逻辑推理方面表现较好；
• Claude Code 在代码理解和项目分析方面有优势，但价格较高，响应速度也相对较慢，所以我使用得较少。

AI 的价值并不只是“帮我们写代码”，更重要的是它可以帮助开发者快速理解项目结构、生成初始方案、补全重复逻辑、优化代码组织方式，并在一定程度上降低试错成本。

对个人开发者来说，AI 可以显著提高开发效率。对团队来说，AI 也能帮助降低沟通成本，让新成员更快理解项目上下文。

当前 AI 还存在哪些问题？

虽然 AI 已经非常强大，但它目前仍然存在一些明显问题。

首先是上下文长度限制。很多复杂项目并不是只看一个文件就能理解的，而是需要结合目录结构、业务流程、接口设计、数据库模型、历史需求等多个信息源。如果 AI 无法完整理解上下文，就容易给出片面的建议。

其次是幻觉问题。AI 有时会生成看似合理、但实际上并不存在或不正确的内容。例如虚构 API、错误理解业务逻辑、误用框架特性等。

如果未来 AI 能够真正解决上下文理解和幻觉问题，那么程序员岗位确实可能受到很大冲击。但就目前来看，AI 更适合作为开发者的协作工具，而不是完全替代开发者。

现阶段比较合理的模式是：

人类负责需求判断、架构取舍、业务理解和最终决策；AI 负责提升执行效率、辅助生成代码、补充方案和加速迭代。

也就是说，程序员的核心竞争力会从“单纯写代码”，逐渐转向“提出正确问题、设计合理架构、判断 AI 输出质量，并把项目真正落地”。

推荐技术架构方案：适配多端协同开发

结合我自己的开发经验，如果是个人项目、中小型项目，或者需要同时覆盖 Web 和 App 的项目，我比较推荐采用一套统一的多端协同开发架构。

这套架构的核心目标是：

• 需求管理清晰；
• 多端项目结构统一；
• 技术选型稳定；
• 后期维护成本可控；
• AI 能够快速理解项目结构；
• 个人开发者也能高效推进项目。

一、需求与原型管理

在正式开发之前，建议先做好 PRD 和原型设计。这样可以减少需求混乱，也能让设计、开发和测试保持同一套认知。

1. PRD 管理

可以使用飞书文档或 Notion 编写 PRD 文档，统一管理需求内容。

PRD 中建议包含：

• 需求背景；
• 功能说明；
• 页面流程；
• 交互逻辑；
• 异常场景；
• 权限规则；
• 接口需求；
• 原型链接；
• 相关截图或备注。

这样做的好处是，开发时可以直接根据文档拆分任务，也方便后续复盘和维护。

2. 原型设计

原型工具可以选择 Figma 或 Axure RP。

如果更重视跨平台协作和设计规范管理，Figma 会更合适；如果更重视复杂交互说明，Axure RP 也仍然有价值。

原型设计的重点不是追求视觉多精美，而是要明确：

• 页面结构；
• 按钮状态；
• 跳转逻辑；
• 表单校验；
• 空状态；
• 加载状态；
• 异常状态。

这些内容越清楚，开发阶段的沟通成本就越低。

二、各端技术选型

1. Web 端技术选型

Web 端建议采用 Vue 3 + Vite + TypeScript 的组合。

推荐方案：

• 核心框架：Vue 3；
• 构建工具：Vite；
• 开发语言：TypeScript；
• 状态管理：Pinia；
• 路由管理：Vue Router；
• 样式方案：Tailwind CSS。

Vue 3 的 Composition API 更适合组织复杂逻辑，Vite 的开发体验也比传统 Webpack 项目更加流畅。Tailwind CSS 则可以减少大量重复样式代码，适合快速搭建统一风格的页面。

2. App 端技术选型

App 端建议采用 Flutter。

推荐方案：

• 核心框架：Flutter；
• 开发语言：Dart；
• 状态管理与路由：GetX；
• 屏幕适配：flutter_screenutil。

Flutter 的优势在于跨平台一致性强，渲染性能较好，一套代码可以同时适配 iOS 和 Android。对于个人开发者或小团队来说，可以有效减少重复开发成本。

当然，如果项目对原生能力依赖特别重，也需要结合具体业务判断是否使用原生开发。

3. 后端技术选型

后端推荐 Rust + Axum。

推荐方案：

• 核心语言：Rust；
• Web 框架：Axum；
• 异步运行时：Tokio；
• 数据库访问：SQLx 或 SeaORM；
• 接口规范：RESTful API 或 GraphQL。

Rust 的优势是性能高、内存安全、并发能力强，适合构建稳定可靠的后端服务。Axum 则是 Rust 生态中比较轻量且现代化的 Web 框架，适合快速开发接口服务。

如果觉得 Rust 学习成本过高，也可以选择 Go + Gin。Go 的语法更简单，开发效率较高，也非常适合构建中小型后端服务。

4. 数据库技术选型

数据库可以根据项目规模灵活选择。

轻量场景

如果是个人项目、小型工具、本地应用或低并发服务，可以选择 SQLite。

它的优点是：

• 无需单独部署；
• 文件型数据库；
• 使用成本低；
• 适合快速开发和本地存储。

扩展场景

如果是中型项目，或者后期可能出现高并发、复杂查询、多用户协作等需求，建议选择 PostgreSQL。

它的优点是：

• 开源稳定；
• 支持复杂查询；
• 扩展能力强；
• 生态成熟；
• 与 Rust、Go 等后端技术栈兼容良好。

三、使用 pnpm 管理多端项目

为了让 Web、App、后端项目保持统一管理，可以使用 pnpm workspace 将多个项目聚合在同一个仓库中。

这样做的核心好处是：

• 项目结构清晰；
• 依赖管理统一；
• 启动脚本集中；
• 方便 AI 理解项目结构；
• 方便后续扩展更多子项目；
• 适合个人和小团队协同开发。

1. 初始化项目结构

可以创建如下目录：

multi-end-project/
├── web/
├── app/
├── backend/
├── package.json
└── pnpm-workspace.yaml

在根目录执行：

pnpm init

然后创建 pnpm-workspace.yaml：

packages:
  - "web"
  - "app"
  - "backend"
  - "packages/*"

其中：

• web 用于存放 Vue 3 项目；
• app 用于存放 Flutter 项目；
• backend 用于存放 Rust 后端项目；
• packages/* 可以用于存放公共工具、类型定义、SDK 等共享模块。

2. 创建 Web 项目

进入 web 目录，执行：

pnpm create vite . --template vue-ts

然后根据需要安装依赖：

pnpm install
pnpm add pinia vue-router
pnpm add -D tailwindcss postcss autoprefixer

3. 创建 App 项目

进入 app 目录，执行：

flutter create .

Flutter 的依赖仍然由 pubspec.yaml 管理，不需要强行交给 pnpm。pnpm 在这里主要承担统一目录和脚本调度的作用。

4. 创建后端项目

进入 backend 目录，执行：

cargo init

然后添加 Axum、Tokio 等依赖：

cargo add axum tokio

后端依赖由 Cargo 管理，同样不需要 pnpm 直接管理。

5. 配置统一脚本

根目录的 package.json 可以配置一些常用脚本：

{
  "scripts": {
    "dev:web": "pnpm --dir web dev",
    "dev:app": "cd app && flutter run",
    "dev:backend": "cd backend && cargo run",
    "dev:all": "concurrently \"pnpm dev:web\" \"pnpm dev:backend\"",
    "build:web": "pnpm --dir web build",
    "build:backend": "cd backend && cargo build --release"
  },
  "devDependencies": {
    "concurrently": "^9.0.0"
  }
}

然后安装 concurrently：

pnpm add -D concurrently

这样就可以通过一个入口统一启动多个项目。

四、推荐项目结构

最终项目结构可以整理成这样：

multi-end-project/
├── web/                    # Vue 3 Web 项目
│   ├── src/
│   ├── package.json
│   └── vite.config.ts
│
├── app/                    # Flutter App 项目
│   ├── lib/
│   ├── pubspec.yaml
│   └── android/
│
├── backend/                # Rust 后端项目
│   ├── src/
│   ├── Cargo.toml
│   └── migrations/
│
├── packages/               # 公共模块
│   ├── shared-types/
│   └── api-client/
│
├── docs/                   # 文档目录
│   ├── prd/
│   ├── api/
│   └── architecture/
│
├── package.json
├── pnpm-workspace.yaml
└── README.md

其中，docs 目录非常重要。建议将 PRD、接口文档、架构说明、部署说明都放进去。这样不仅方便我们进行维护，也方便 AI 快速理解项目上下文。

这种架构的优势

采用这种方式，最大的好处是可以让项目结构更加清晰，也能让 AI 更快的理解整个项目。

尤其是在 AI 辅助开发越来越普遍的情况下，项目组织方式会直接影响 AI 的工作效率。如果项目结构混乱、文档缺失、命名不统一，那么 AI 很容易给出错误建议。相反，如果项目目录清晰、文档完整、模块边界明确，AI 就能更准确地理解需求并生成可用代码。

总结来看，这套架构的优势包括：

• Web、App、后端统一管理；
• 不强行统一技术栈，而是尊重各端最佳实践；
• 适合个人开发者和中小型团队；
• 后期可扩展性较好；
• 方便接入 AI 辅助开发；
• 有利于沉淀长期可维护的工程结构。

总结

未来前端不会消失，但前端的能力边界一定会继续扩大。

过去的前端主要关注页面实现，现在的前端需要关注工程化、跨端开发、后端接口、部署流程和用户体验。未来的前端，则更需要具备 AI 协作能力、架构判断能力和产品落地能力。

AI 会改变开发方式，但不会立刻取代所有开发者。真正有价值的开发者，不只是会写代码，而是能够理解需求、设计系统、判断技术方案，并借助 AI 更高效地完成项目。

因此，对前端开发者来说，未来比较重要的方向不是盲目追逐所有新技术，而是建立一套稳定的技术体系：

• Web 端掌握 Vue 3 / React 等主流框架；
• App 端理解 Flutter 或 React Native；
• 后端掌握一门稳定语言，例如 Rust、Go 或 Node.js；
• 熟悉数据库、部署、CI/CD 等基础设施；
• 学会利用 AI 提升开发效率；
• 保持清晰的项目结构和文档习惯。

这样，无论未来技术如何变化，都能保持足够的适应能力。