前言
2026年初，一款名叫"死了么"的App在AppStore付费榜狂销。
这不仅是一个关于产品创意的故事，还是一个关于技术如何重塑创业门槛的故事。
曾经，一个看似简单的App需要庞大的技术团队：后端框架、数据库部署、系统认证、定时任务、邮件推送、基础设施运维......整个过程耗时冗长、成本高昂。而如今，一切都发生了变化。
使用AI编程工具能快速生成前端代码，用"无服务器应用后端" Supabase 处理所有后端工作，开发者不需要自己搭建服务器，也无需担心系统维护。从前端到后端、从数据到模型，全链路轻量敏捷。
本文通过30分钟复刻"死了么"APP，深度分析在AI编程时代如何使用正确的技术栈实现应用的极速开发。
一、一个8元APP为何在AppStore狂销？
2026 年第一款全网爆火的 App「死了么」，是一款标价8元的付费产品，已经连续几天占据苹果 AppStore 付费榜第一。
这款 App 的功能极其简单，输入你的名字和紧急联系人邮箱，然后每天签到。如果没签到，则会自动发送邮件警报给紧急联系人。 这么简单的功能却精准戳中了独居者面临的生活难题也切切实实反映了只要戳中用户痛点，再简单的APP也有它独特的价值。同时体现出，在AI时代，只要有想法，就可以迅速落地实现。
虽然这个App的功能看似简单，开发者也声称开发成本仅几千元。但麻雀虽小，五脏俱全，前端仅有的签到功能背后，却包含了用户管理、邮件推送、定时任务能力。当前流行的AI编码可以迅速且完整地实现前端能力，但涉及到包含后端能力时就会有一定挑战，但是这一短板并非不能克服，通过Rules、Skills和正确的技术选型，则可以迅速完成全栈落地。
二、从想法到上线：用最佳技术选型实现AI全栈编程
下面我们就以复刻整个「死了么」为例，使用AI编码时代的最佳技术选型迅速实现落地。
使用Qoder 30分钟完全复刻版（包含后端）
看下面的视频，左边我们使用模拟器模拟了真机效果，右边是Supabase后端dashboard，可以看到刚开始后端并没有数据，当我们通过左边APP完成签到后，数据写入到了后端的users和check_ins表里。
当完成签到后，签到数据会存储在后端，在重复打开APP时，会从后端获取签到数据，如果已经完成签到，则直接显示签到成功。如果2天没签到则触发邮件发送任务。
三、开发工具选型
欲善其事，先利其器。选择合适的开发工具可以加速整体开发效率，正所谓最热门的编程语言是英语，其次是中文，AI编码已然是当前提升开发效率的不二选择。当下主流的IDE主要是Cursor、Qoder 等，它们还能够很好地支持自定义的 Rules 和 Skills，让AI能够更加高效且准确地编码。并且通过Skills，可以让AI自我总结经验，避免编码过程重复踩坑。这里我们以Qoder作为编码工具，它不但可以编码，还可以使用Bmad-METHOD方法对需求进行梳理和拆解，比如我们可以基于它对「死了么」APP进行功能分析和模块拆解梳理，让AI开发编码流程更清晰。
3.1 BMAD-Method：从"先写再救火"到"先规划再迭代"的 Agent 开发范式
如果直接让 AI 进入编码阶段，往往只能快速做出一个小型 demo；但当项目需要持续迭代和演进时，维护成本会迅速上升，开发也会变得越来越困难。我们可以借助 Mmad Method：先让 AI 对需求进行整体评审，再完成规划与架构设计，随后拆解功能模块，最后按步骤逐步实现。
这种方式的优势在于：既能让 AI 在具体开发时聚焦于清晰、可执行的小任务，又能保持全局视角，持续掌控项目方向与进度，从而降低随着代码量增长而带来的错误率。
例如，AI 可能在完成 A 功能后，开发 B 功能时无意中改动了 A 的依赖，导致 A 失效，最终让系统整体不可用；而当上下文变长后，AI 反而更难准确定位并修复问题。通过"先规划、再拆解、后实现"的流程，可以显著减少这类连锁问题的发生。
3.2 Agent Skills: 用"渐进式披露"把上下文用在刀刃上
Agent Skills 对 AI Coding 的最大价值，在于通过渐进式披露机制系统性缓解"上下文不够用"的工程问题：智能体启动时只加载每个技能的少量元数据（通常约百 token 级），从而在安装大量技能的情况下仍保持极低的初始上下文占用；当某个任务真正需要某项能力时，才按需加载该技能的完整指令与示例，把 token 精准投入到当前要做的事上，避免像传统 MCP 那样在连接时一次性灌入大量工具 Schema 造成"开局上下文爆炸"。更进一步，复杂能力还可以通过脚本与引用资源延展出几乎无限的知识容量，并把解析、转换、计算等高风险步骤交给代码确定性执行，减少 LLM 的幻觉与不稳定输出。最终效果是：对话更轻、决策更准、上下文更干净，AI 在持续迭代编码时更不容易遗忘关键约束或误改既有逻辑，整体交付质量与迭代效率都会显著提升。
同时关于AI Coding的上下文工程等其他内容已然有很多研究，这里不再赘述，本文主要聚焦于如何通过更友好的技术选型，提升AI编码的执行率。
四、技术选型
4.1 功能拆解：麻雀虽小，五脏俱全
这款APP看起来只有一个签到按钮，但背后涉及的技术模块其实不少。这是一款面向日常自检/报平安场景的轻量应用，通过每日签到帮助用户建立持续的状态确认机制，并在缺席时触发提醒，降低"无人察觉"的风险。其底层技术拆解后主要涉及到以下前后端模块。
4.1.1 前端功能模块
| 功能 | 用户操作 | 技术要求 |
|---|---|---|
| 信息录入 | 输入姓名和邮箱 | 表单验证、输入框组件 |
| 每日签到 | 点击签到按钮 | 按钮交互、状态管理 |
| 状态展示 | 显示"今日已签到" | UI状态切换、本地缓存 |
| 成功反馈 | 签到成功动画 | 动画效果、用户体验 |
4.1.2 后端功能模块
| 功能 | 业务需求 | 技术要求 |
|---|---|---|
| 用户管理 | 记录用户信息 | 数据库、用户表 |
| 身份识别 | 区分不同用户 | 认证系统、Session管理 |
| 签到记录 | 存储每日签到 | 数据库、防重复机制 |
| 数据隔离 | 用户只能看自己的数据 | 权限控制、安全策略 |
| 定时检测 | 自动检查哪些用户未签到 | 定时任务、业务逻辑 |
| 邮件通知 | 发送提醒邮件 | 邮件服务、消息推送 |
4.2 整体技术架构
基于前面的功能分析与模块拆解，接下来进入 APP 能力的正式落地实现。在 AI 编程时代，AI 已经能够快速生成前端代码，高效完成界面搭建与交互实现；但真正的挑战往往出现在后端：数据库与数据管理、用户认证与权限控制、定时任务、邮件服务等模块缺一不可，而技术选型一旦过多、过重，不仅会显著拉长开发周期，也会在 MVP 阶段分散团队最宝贵的时间与注意力。
因此，我们采用一套更适合 AI 协作、低运维、可快速迭代的技术方案：前端使用 SwiftUI，后端核心能力交给托管的阿里云 AnalyticDB Supabase（下文简称ADB Supabase） 云服务承载。应用通过 HTTPS 跨域直连 Supabase，直接调用认证、数据库、边缘函数等能力，无需自建后端服务，更无需投入服务器部署、扩缩容与日常运维，从而把精力集中在客户端体验与核心业务逻辑上。
4.2.1 前端选型：SwiftUI
从"AI 亲和度"来看，TypeScript + React + Vite 等 Web 技术栈确实更接近当下主流模型的训练语料与生态，适合快速构建 Web 应用或 AI Native 产品。但本项目的目标是复刻 iOS 生态的 APP，因此选择 SwiftUI 更符合平台一致性与用户体验预期。同时 SwiftUI 具备声明式 UI、组件化结构清晰等特点，也非常利于 AI 生成与维护代码。
4.2.2 后端选型：Supabase------AI 编程时代的理想后端
Supabase 的优势不只是"开箱即用"，更在于它天然适配 AI 的工作方式：
- 声明式与数据库优先：把复杂度放到 AI 更擅长的地方
相比编写大量后端业务代码，AI 更擅长产出 SQL 与声明式配置：表结构、索引、约束、防重复机制、RLS（行级安全）策略等都可以通过 SQL 清晰表达。将关键规则下沉到数据库层，前端逻辑会更简单、更可控，也更不易在迭代中被改坏。
- 丰富 SDK + 自动化 API：减少手写接口与架构负担
Supabase 提供多语言 SDK，并以统一的.insert()、.select()等方式调用数据与认证能力，开发者无需手写 RESTful 接口，也不必先搭一套完整后端框架。对 AI 而言，这意味着更少的上下文、更标准的调用路径、更高的实现准确度。
- 基于云托管的ADB Supabase，实现「死了么」所有功能，都不需要开发者额外再部署后端
依托 Supabase 托管服务，「死了么」APP的核心后端能力无需额外部署：数据库、认证、权限控制与对外 HTTPS 访问能力一并提供。开发者可以把注意力锁定在客户端与业务闭环上，显著节省开发与运维成本，加快迭代速度。
五、详细功能实现拆解
5.1 匿名认证：无感身份识别（不做"用户体系"，也能完成绑定）
"死了么 "APP不提供显式的注册/登录入口，但仍需要做到"数据归属到具体用户"。我们采用 匿名认证（Anonymous Auth）+ 设备唯一标识 的方式实现无感绑定：
- 实现思路：客户端首次启动时触发匿名登录，Supabase Auth 生成一个唯一的
user_id；客户端将该身份与本机的设备标识建立关联，后续签到、查询都在该user_id下进行。 - 效果：用户不需要注册、不需要记密码，即可完成身份识别与数据隔离（配合 RLS）。
- 已知限制：用户更换设备后会被视为"新用户"（因为设备标识变化）。
可演进方向：如果希望"多端同一用户"，可以直接升级为 Supabase Auth 的标准登录体系。ADB Supabase 提供本土化可用的认证能力（如微信/支付宝 OAuth、邮箱等），可以在不改变整体架构的前提下强化登录与账号合并能力。
5.2 Edge Functions：把服务端业务逻辑交给云端（AI 友好、低运维）
本项目中两类关键能力并不适合放在客户端完成："定时检测未签到用户"和"发送邮件通知（或其它通知渠道）"
因此我们使用 ADB Supabase Edge Functions 承载服务端逻辑。Edge Functions 是运行在 Supabase 云端的 Serverless 函数：
- 运行时：Deno
- 语言：原生 TypeScript
- 能力：可作为 HTTP 接口暴露，也可被 Cron Job 定时触发
为什么Edge Functions对AI编程友好？
| 维度 | 传统自建后端 | ADB Supabase Edge Functions | 对 AI 的直接收益 |
|---|---|---|---|
| 开发语言/环境 | Node/框架/依赖与环境配置 | 直接写 TypeScript（Deno） | AI 更擅长 TS，减少环境坑 |
| 部署 | 服务器、Docker、网关、证书 | 一条命令发布到云端 | AI 不用"指导你运维" |
| API 暴露 | 手写路由/网关配置 | 自动生成 HTTP 端点 | AI 只需按 URL 调用 |
| 定时任务 | 额外 Cron 服务/任务系统 | 内置 Cron Jobs 触发 | AI 只配置 Cron 表达式 |
| 权限与密钥 | 自己设计鉴权与密钥管理 | 使用 service_role key（服务端专用） |
机密留在云端，客户端更安全 |
这里我们实现了两个Edge Function：check-missed-check-ins和send-notification-email。
Edge Function 1: check-missed-check-ins
目标：每天扫描所有用户，找出"连续 2 天未签到"的用户，并触发通知流程。
这一类"全量扫描 + 规则判断 + 批量触发"的逻辑放在客户端几乎不可行；放在 Supabase Edge Functions 则天然适配。
业务流程
Edge Function 2: send-notification-email
目标：接收用户信息与紧急联系人邮箱，发送提醒邮件。
邮件内容示例：
主题：一条重要通知
我是{username},我已经连续很多天没有活动了，快来检测一下我的身体状态。可扩展性：目前实现的是邮件通知；但基于 ADB Supabase Edge Functions，同一套模式可以平滑扩展到 微信、钉钉、短信等渠道。并且因为第三方渠道的密钥配置保存在云端环境变量/密钥体系中，不会泄露到客户端，安全性更高。
5.3 Cron Jobs - 定时任务调度
实现的功能模块：每天自动检测
在Supabase Dashboard中创建Cron Job：
| 配置项 | 值 | 说明 |
|---|---|---|
| 任务名称 | check-missed-check-ins | 描述性名称 |
| Cron表达式 | 0 1 * * * |
UTC时间凌晨1点 = 北京9点 |
| 触发方式 | HTTP POST | 调用Edge Function |
| URL | /functions/v1/check-missed-check-ins |
函数端点 |
| 认证 | Service Role Key | 绕过RLS |
六、总结与思考
虽然「死了么」APP的场景并不是特别复杂，但是也向我们展示了完整的AI编码技术选型的最佳实践。AI编码前端的能力远远强于后端，一方面，模型需要提高对后端的编码能力，另一方面，通过减少后端编码，依托于ADB Supase等BaaS服务，让前端直接变成全栈，也不失为一种围魏救赵的解法。尤其是在AI时代，各种想法加速落地MVP，尽可能让研发聚焦业务本身逻辑，反而显得更加重要。
6.1 AI编程时代的技术选型原则
通过这个项目，我们沉淀了几条在 AI 辅助开发 / Vibe Coding 场景下更"稳"的技术选型原则------核心目标是：让 AI 更容易写对、写稳、并且更好维护。
| 原则 | 说明 | 示例 |
|---|---|---|
| 原则1：优先选择声明式技术栈 | AI 更擅长处理声明式代码 | - ✅ SwiftUI的声明式UI > UIKit的命令式UI ✅ SQL的声明式查询 > ORM的命令式操作✅ RLS的声明式策略 > 中间件的命令式鉴权 |
| 原则2：选择文档友好的技术 | AI 依赖高质量文档生成代码 | - ✅ Supabase官方文档完善✅ SwiftUI有大量示例代码✅ TypeScript类型系统帮助AI理解 |
| 原则3：选择自动化程度高的服务 | 减少 AI 需要处理的配置细节 | - ✅ Supabase自动生成API✅ 匿名认证自动管理Session✅ RLS自动应用权限规则 |
| 原则4：选择类型安全的语言 | 类型系统减少 AI 生成错误 | - ✅ Swift和TypeScript都是类型安全语言✅ 编译时发现错误，而非运行时✅ IDE自动提示，AI生成更准确 |
6.2 Supabase 的核心价值
Supabase 在 AI 编程时代展现出独特价值，核心体现在两点：让后端更"轻"，让交付更"快"。
1. 降低后端复杂度：把长链路工程收敛为少量声明式要素
在传统自建后端中，AI 需要处理的环节非常多，而且每一层都伴随着大量样板代码与隐性约定：
erlang
框架选择 → 路由设计 → 控制器 → 服务层 →
数据访问层 → ORM配置 → 数据库连接 →
认证中间件 → 权限中间件 → 错误处理 →
日志系统 → 部署配置 → 负载均衡 → ...链路越长，越容易在迭代中产生回归与耦合问题，也会显著消耗上下文与调试成本。而 Supabase 将后端能力高度收敛，开发者与 AI 往往只需要聚焦在三件事上：
| 组件 | 描述 |
|---|---|
| SQL Schema | 定义数据库的数据模型，包括表结构、索引、约束等 |
| RLS 策略 | 在数据库层实施行级安全策略，控制用户对数据的访问权限与隔离规则 |
| Edge Functions | 按需使用的后端服务代码，处理定时任务、通知、复杂业务逻辑 |
2. 摆脱后端运维：用托管能力换取更快的启动与迭代
相比自建后端，BaaS 的优势在于"快速启动、持续省心"。ADB Supabase 提供托管数据库、认证、权限控制与对外 API 能力，项目从 0 到可用的启动成本更低；上线后也无需投入精力在服务器部署、扩缩容、证书、网关与日常运维上。
对移动 App 尤其关键：开发者可以把注意力集中在客户端体验与核心业务闭环，通过 HTTPS 直连云端能力完成数据读写与权限控制，而不是被后端基础设施牵制开发节奏。
欢迎钉钉搜索群号："101930027031"，加入钉群获取完整源码资料。
了解更多关于ADB Supabase ：help.aliyun.com/zh/analytic...