我的技术栈：如何为新的 AE（Agentic Engineering）项目选型

这篇文章会聊聊我现在怎么给一个新的 AE（Agentic Engineering）项目选技术栈。 不是“最标准答案”，而是我自己反复试下来最顺手、最能快速落地的一套方法。

标记说明：⭐ = 我当前的主力 / 默认选择

1) 先问自己：我要做的 Product 到底是什么？

• 你要的是 纯 Web App？
• 还是 Mobile + Web？
• 甚至只是一个 Command Line 工具等等？

2) 大部分情况下，你都需要一个 Web App

• 你需要放 Privacy Policy / Terms 等基础页面,这些事在app store前必须做的事情
• 你需要让用户可以通过链接分享（比如在微信里先分享网址给还没下载 App 的人）
• 你需要一个公开入口来搜索和品牌展示

在 Web 这一层，我现在的默认组合是：

• ⭐ Next.js（前端框架）
• ⭐ Supabase（数据库 + Authentication）

这套组合的优点是：上手快、文档好、社区成熟，做 MVP 的速度非常高。 用vite + 原生react应该也不错

3) Mobile：Flutter 还是原生 SwiftUI / Kotlin？

这是最常问的问题之一。 是个比较难选的问题

适合优先 Flutter 的情况

如果你的核心目标是：

• 更快上线
• 一套代码覆盖双平台
• 信息传达和功能闭环比“极致动效/原生细节”更重要 （社区之类的）

那我会优先选 ⭐ Flutter。 它通常能显著节约开发时间，特别适合社交类、工具类、内容类应用。

适合原生的情况

如果你对这些点要求非常高：

• 丝滑且高度定制的系统级动效
• 深度依赖系统原生能力（例如某些原生 photo picker 行为）
• 第一时间吃到 Apple 最新 UI/交互特性（例如新的 liquid glass 视觉体系）和人工智能

那就考虑 SwiftUI / Kotlin 原生开发。

一句话总结： 重速度和双端覆盖，先 Flutter；重系统原生体验，走原生。

4) 当项目是 Mobile + Web：我会加一层统一后端 API

当我同时有 Mobile + Web 时，我一般会在 ⭐ AWS Lightsail 上放一个 Python Server，做统一 API 层：

• Python Server ↔ Supabase
• Mobile / Web ↔ Python Server

也就是说： 我通常不会让 Mobile 和 Web 直接连 Supabase 数据库。

这样做的好处是：

• 业务逻辑集中管理
• 权限和风控策略更一致
• 客户端更“薄”，后续调整数据库结构时影响更可控

5) 文件和图片存储：当前还在 Supabase

目前文件/图片存储我还是放在 ⭐ Supabase Storage。

原因很简单：

• 和现有 Supabase 体系集成顺手
• 前期开发体验好
• 对小团队和早期项目来说，维护成本低

我在尝试用cloudflare来做这部分的功能

6) 长期方向：可能逐步迁移到 AWS 全家桶

长期来看，我大概率会把 Supabase 逐步替换成 AWS 方案。（或者cloudflare）

一个现实考量是可用性与区域风险： 最近有印度地区的事件会影响 Supabase，但同样规模地 block AWS 的概率更低，因为用AWS的太多了。

另外，工具最后都会卷向“性价比最高”的方案。 以前很多人觉得 AWS 难用；但在 AI 时代，这个缺点被明显削弱了：

• 配置不会可以让 AI 手把手教
• 你学会一次后，后面可以复用很久

所以在“长期稳定性 + 成本 + 可扩展性”的维度上，AWS 依然是非常强的终局候选。

上次更新

• 2026-03-02