一次 AI 应用技术实战，聊聊「前端即服务」的低成本落地姿势

一、起因：一个「顺手」的需求

前阵子家里要给宝宝做一个成长记录台：每天睡觉、吃饭、喝奶的打卡，每个月该加什么辅食、买什么玩具，再带上身高体重头围的生长曲线。

需求不难，但有个隐藏要求：手机能看、家里人能一起用、数据不能丢。

按习惯，这玩意儿要么做个小程序，要么下个现成 App。但「全家的、私有的、还要按我的想法长」——现成 App 都满足不了，自研又嫌重。

于是我换了个思路：让 AI 直接给我生成一个网页，托管出去，再用一个免费数据库做共享存储。

二、传统做法的代价

如果按常规全栈流程走一遍：

• 买一台云服务器（或容器实例）
• 起一个后端服务，设计数据表、写增删改查接口
• 配 HTTPS、域名、跨域
• 做一套最简登录（否则谁都能改数据）
• 前端再调这些接口

一个「顺手」的需求，硬生生变成了半个后端项目。对个人、对小团队，投入产出比太低，往往做到一半就搁置了。

核心矛盾是：我们想要的只是一个「能跑、能共享、不丢数据」的页面，却被迫养一整套后端基础设施。

三、换条路：单文件 H5 + 免费托管 + 免费数据库

解法其实很朴素——把「页面」和「数据」彻底解耦，各自找最便宜的载体：

• 页面：让 AI 生成一个单文件 HTML（CSS、JS、图标全部内联，零外部依赖）。这种文件丢到任意静态托管都能跑，不依赖任何框架。
• 数据：用 Supabase 免费版。它本质是「Postgres + 自动生成的 REST API」，前端用浏览器原生的 fetch 就能直接读写，不需要自己写一行后端。
• 托管：用现成的 H5 沙箱（比如各类 AI 编程工具的部署能力），一键拿到公网链接，手机打开即是一个网页应用。

这套组合拳的特点很突出：没有服务器要养，没有后端要写，没有证书要配。链接是平台给的，数据库是免费的。

四、实战：以「宝宝成长记录台」为例

下面把关键步骤拆开，所有代码均可复现。

1）让 AI 产出单文件工作台

把需求描述清楚，AI 会生成一个 index.html。我的案例里包含三个模块：

• 今日作息打卡（喝奶量、辅食、睡眠，支持自定义备注）
• 月龄成长指南（6–24 月逐月的辅食、玩具、启蒙活动）
• 生长记录（填身高体重头围，手写 SVG 画出 WHO 50% 曲线）

第一个关键决策：数据先用浏览器 localStorage 持久化。这样不联网也能用，刷新、关闭都不丢，先让功能跑起来。

2）部署到 H5 沙箱，拿到公网链接

把 index.html 部署出去，得到类似 https://xxx.sh3.agentos-app.net 的链接。手机浏览器打开后「添加到主屏幕」，就是一个没有地址栏、全屏打开的「类 App」体验。

到这里，「能看、不丢（本机）」已经满足。但有个问题：数据存在各自的浏览器里，家人打开看到的是不同的内容。

3）开通 Supabase 免费项目

去 supabase.com 注册一个免费项目，进 SQL 编辑器建一张极简的表：

create table app_state (
  id text primary key,
  payload jsonb not null,
  updated_at timestamptz default now()
);

alter table app_state enable row level security;
create policy "public all" on app_state
  for all to anon using (true) with check (true);

这张表只干一件事：存一份「应用全部状态的快照」。payload 是 JSON，把你所有的业务数据（打卡、记录、设置）打包塞进去即可。

建好后你会拿到两样东西：

• Project URL：形如 https://xxxx.supabase.co
• anon public key：公开密钥，设计上就可以放在前端

注：示例里把表设为「匿名可读写」，适合家人/小团队共享。如果要对外公开，请务必加访问口令或收紧 RLS 策略（见第六节）。

4）把云端同步接进 H5（纯 fetch，零库）

同步逻辑其实非常短，核心就是「本地先写、云端异步镜像」：

// 推送：本地改动 → 云端（合并写入，last-write-wins）
function push(){
  fetch(URL + '/rest/v1/app_state', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'apikey': KEY,
      'Authorization': 'Bearer ' + KEY,
      'Prefer': 'resolution=merge-duplicates'
    },
    body: JSON.stringify({
      id: 'main',
      payload: collect(),                 // 收集所有本地状态
      updated_at: new Date().toISOString()
    })
  });
}

// 拉取：云端 → 本地（带时间戳冲突处理）
function pull(){
  fetch(URL + '/rest/v1/app_state?id=eq.main&select=*', {
    headers: { 'apikey': KEY, 'Authorization': 'Bearer ' + KEY }
  })
  .then(r => r.json())
  .then(rows => {
    if (rows[0] && new Date(rows[0].updated_at) > lastPush) {
      apply(rows[0].payload);             // 远程更新 → 覆盖本地
    }
  });
}

同步策略只有一句话：本地先写（秒回、离线可用），云端异步镜像；多端拉取时比较 updated_at，后写的赢。简单、最终一致，对个人和小团队完全够用。

整个过程没有引入任何外部 SDK——Supabase 的 REST 接口用原生 fetch 直接调，依然是单文件零依赖。

5）多端验证

不同设备打开同一个链接，任意一处打卡，几十秒内其他设备自动刷新出同样的数据。最关键的是：数据存在 Supabase，不再依赖托管沙箱，沙箱回收也不丢。

五、为什么这套能跑通

• 零依赖单文件：所有逻辑内联，不引 CDN、不引框架，规避了「库 404 → 功能全废」这个经典坑。
• 免费额度对个人绰绰有余：Supabase 免费层提供 500MB 数据库、每月 5 万次 API 请求，个人小应用的数据量基本触不到上限。
• 前端即服务：Supabase 把「数据库 + API + 鉴权」打包成现成能力，前端把它当成「云存储」来用，后端职责被极大消解。

六、边界与注意事项（别踩坑）

1. 匿名读写 = 拿到链接即可读写。适合家人、小团队共享；若要公开，务必加访问口令，或把 RLS 策略改成「凭 token 才能写」。
2. 冲突是「后写赢」。同一份数据多人同时改，后保存的会覆盖先保存的。强协作场景需要自己做字段级合并。
3. 托管沙箱可能被回收。页面本身托管在沙箱，闲置一段时间后链接可能失效；但数据在 Supabase 不受影响，重新部署即可恢复。
4. 养成备份习惯。再稳的云也建议定期导出一份 JSON 兜底，防止项目被误删或密钥轮换。

七、适合拿它做什么

• 个人效率工具：记账、习惯打卡、倒计时、待办
• 家庭共享小应用：成长记录、购物清单、共同日程
• 活动 / 聚会临时页：打卡、投票、留言墙
• 产品 MVP 快速验证：先用网页跑通核心闭环，再决定是否投入后端

八、小结：AI 应用技术的落地点

这次实践最让我感慨的是——AI 不再只是「问答」，而是能端到端交付一个可用产品的「全栈搭档」：从需求拆解、生成单文件、部署上线，到接上数据库，全程在对话里完成。

对做 AI 应用技术分享的朋友，这类「零成本、可复现」的小实战最有价值：读者照着能自己做出来，而不是只看个热闹。

把重活交给 AI 和免费基础设施，把创造力留给真正重要的事——这大概就是当下最舒服的开发姿势了。

---