Ras Mic · 30:18 · 发布 2026-07-02 · 1.6万次观看(截至抓取) · 观看原视频
主旨
以自己的 AI agent 产品 Pluto 为例,拆解一套用 AI 构建应用时的完整系统设计:客户端/服务器/数据库分层、抽象层选择、monorepo 组织方式、service 拆分标准、鉴权与支付选型。
核心论点
- 工程没有完美方案,只有关于 scalability(可扩展)、reliability(可靠)、performance(性能)、cost(成本)四项的权衡取舍。(→ 详解1)
- 云抽象层一层层收窄了系统设计的复杂度,今天的 BaaS 工具已经把 AWS 级别的脏活累活包起来。(→ 详解2)
- Monorepo 把多个客户端和统一后端放进同一代码库,是让 coding agent 具备全局上下文、跨界面协同开发的关键前提。(→ 详解3)
- 客户端永远不能直接读写数据库,一切必须经服务器中转,否则密钥必泄露。(→ 详解4)
- 像 Convex 这类”后端即数据库”的 BaaS,能免费拿到 durable workflow、队列、并行任务等原本要自己造轮子的能力。(→ 详解5)
- 把功能拆成独立 service 没有死公式,判断标准是这块代码是否自成一体、职责单一、能独立演进。(→ 详解6)
- 鉴权与支付工具要按业务模式选,不是默认套 Stripe:企业级 OAuth 用 WorkOS,信用点计费用 Autumn。(→ 详解7)
知识点详解
1. 系统设计的本质:工程四要素权衡 01:54
系统设计的标准定义是”规划软件系统的架构、组件、模块、接口与数据流以满足特定需求”的过程。作者强调,AI 时代之前需要人工决定存储方案、负载均衡、告警服务、CI/CD 管线,而现在很多工具已经把这些抽象掉了。
但无论工具怎么变,工程的本质没变:没有完美系统,每个技术栈、每个工具、每个数据提供商都有取舍。作者给出四个要考虑的维度:scalability(流量涨了能否只靠加资源应对)、reliability(服务商是否稳定不宕机)、performance(应用是否够快)、cost(是否负担得起)。这四项互相牵制,任何架构决策本质上都是在这四者间做交换。
2. 抽象层的演化:从自建机房到 Vercel/Convex/Supabase 04:41
早期公司要自建服务器机房,雇 IT 与运维人员自行扩容,流量猜错就要么硬件不够被冲垮、要么闲置浪费钱。AWS、GCP、Azure、Cloudflare 的出现是第一层抽象层:把物理机器与底层运维隐藏起来,开发者只管部署。
后来又出现第二层抽象:Vercel、Convex、Supabase、Neon 等公司又把 AWS/GCP/Azure 包了一层,进一步简化开发者体验。作者直言 Azure、GCP 用起来很痛苦,“agent 体验”也差;而 Vercel + Convex 这类工具则让开发者和 AI agent 都用得顺手。
这解释了为什么作者现在几乎不直接碰 AWS/GCP/Azure:前端部署用 Vercel,后端用 Convex,需要 Postgres 就用 PlanetScale。每往上一层抽象,系统设计要操心的底层细节就少一层,把精力留给业务逻辑。
3. Monorepo:让 agent 看到全代码库 11:00
Pluto 有四个客户端:web app、desktop app、mobile app、内部 admin 站点。如果每个客户端各建一个仓库,人和 AI agent 都要在多个割裂的上下文之间来回切换,尤其对不太会写代码的人几乎是灾难。
作者的解法是几乎每次启动新项目都从一个 Monorepo 开始:一个仓库里装 web、mobile、desktop 客户端,以及统一的后端和各种独立 service,可以共享同一套 UI 组件库。因为部署用 Vercel,他配套用 Turbo Repo 管理这套 monorepo。
Monorepo 真正的价值在 AI 时代被放大:当使用 Fable 5 等 agent 编码时,agent 能一次性访问整个代码库,理解 web/desktop/mobile 客户端如何共同调用同一个后端,不必靠人工在多个仓库间搬运上下文。
4. 客户端-服务器-数据库分离铁律 13:51
后端(服务器)要做三件事:从数据库读数据、往数据库写数据、调用外部服务(如天气 API),且要保证这些操作不失败、不慢。作者反复强调一条铁律:客户端绝不能直接读写数据库。
正确的链路是:客户端调服务器,服务器调数据库,数据库把结果返回服务器,服务器再返回客户端。这也是作者不太喜欢 Supabase 默认用法的原因——很多人图省事让前端直连数据库、靠 RLS(行级安全) 兜底,但只要打开浏览器 Network 面板就能看到暴露的 API key,是个”愚人的游戏”。
Supabase 其实提供了服务器端 SDK 可以规避这个问题,但作者观察到大多数人并没有这么用。这条铁律不针对具体工具,而是任何后端架构都该守住的边界。
5. 用 Convex 统一后端与数据库 15:24
过去要么自建 Node.js 后端 + Postgres 数据库并让两者通信,要么把这套部署在 AWS 上再接一个 RDS 实例。作者用 Convex 把服务器和数据库合二为一:一个基础设施里同时提供读写数据与调用外部服务的能力,并且一切实时同步。这三种操作 Convex 里分别叫 queries(读)、mutations(写)、actions(调外部服务)。
Convex 的另一个价值是内置了 Durable Process(持久化工作流):一个持续运行、即便用户关闭页面刷新也不会中断的流程。构建 AI agent 时这一点是刚需——如果没有 durable workflow,用户中途离开会导致对话流程中断。Convex 直接提供 workflow 组件,复制粘贴文档就能让 agent 帮你接上。
同理,如果要做排队(比如抢票网站的流量削峰)或并行任务调度(workpool),原本需要自己接 AWS SQS 之类的服务,Convex 都内置了对应组件。作者认为这类 BaaS 的核心价值在于”everything is code”——数据库、后端逻辑全部是代码,这意味着 AI agent 可以直接帮你写、帮你改。
6. 服务拆分原则:何时把功能独立成 service 20:06
一个 service 是”自成一体、可复用、为其他部分或外部客户端完成特定任务的软件功能块”。Pluto 里有两个独立 service:iMessage 集成和 inference/payments(推理与计费)。iMessage 代码几乎不牵扯其余代码库,独立出来互不干扰;inference/payments 则是因为随着 Convex 后端逐渐变大,且未来可能有专人专职维护这块,值得提前拆开。
作者坦言这个判断更多是经验和直觉(“vibes”),而非某种严格公式:一块功能如果触及面单一、不太牵连全局,就适合独立成 service。inference/payments 用的技术栈是 Effect TS + Postgres(经 PlanetScale 托管),选 Effect 的原因一是 AI 写 Effect 代码写得好,二是需要非常扎实的错误处理——支付和推理环节出错必须能被清楚捕获和处理。
这套 service 依然放在同一个 monorepo 里,保证 agent 始终能看到全局代码结构,只是内部按职责边界切开成不同的可独立演进单元。
7. 鉴权与支付选型 + 落地权衡 24:29
支付上有 Stripe、Polar、Autumn 三个选项。作者没有直接用最常见的 Stripe,而是选了 Autumn,因为 Pluto 是信用点(credit)计费模式而非纯订阅——用户充值、消费额度、部分功能免费、部分需要充值,这套复杂计费逻辑 Autumn 处理得更顺手。经验法则很简单:纯订阅用 Stripe,涉及信用点等复杂计费用 Autumn。
鉴权上 Pluto 用 WorkOS,因为它面向企业级客户(目标客户是 15-60 人规模的中小企业),能满足 SOC 2 等合规要求,且 agent 也很擅长对接它。这与 Pluto 定位”面向团队而非纯个人 agent 用户”的产品策略一致。
回到整体权衡,作者坦承目前最大的舍弃是成本:还没想清楚商业模式,Daytona 沙盒用的是中大型规格以保证每个 agent 都快,Vercel 账单从 $20/月套餐一路花到超过 $100。他的态度是先把体验做扎实、把”应用不会崩”放在第一位,成本优化留到后面再说——这本身也是一种权衡选择,而非无意间超支。
可执行步骤
- 设计新系统前先列出 scalability / reliability / performance / cost 四项,写清楚愿意在哪几项让步。
- 多客户端项目(web+mobile+desktop)起步就用单一 monorepo,让 coding agent 能一次看到全部客户端与后端代码。
- 审查现有代码:检查是否存在客户端直连数据库的路径,发现即改为经服务器中转。
- 后端选型前先问”这个能力平台是否已内置”(durable workflow / 队列 / 并行任务),避免重复造轮子。
- 拆分 service 前先判断这块功能是否自成一体、职责单一,而非套用某个固定公式。
- 计费模式先想清楚是纯订阅还是按量/信用点计费,再挑对应工具。
- 上线前接入错误监控与日志(工具不限),保证出问题时能第一时间定位原因。
关联
- 进阶:Skill 按需加载 vs agents.md 每轮注入 是同频道链路第一集(harness 上下文管理),先读它再读本片的系统架构层。
- 冲突/更新:用AI构建精美UI的设计工作流 是同频道续作,把本片一笔带过的 UI 层展开成 token 系统 + Claude Design 工作流,两片串联才是完整链路。
- 印证:代码库关系图谱(见 给编码agent一张代码库地图codebase-memory-MCP)要解决的是”agent 如何看到跨文件/跨 repo 的依赖关系”;本片的 monorepo 是同一问题更朴素的解法——物理上把所有代码放进 agent 能一次读到的同一仓库,而非事后建索引图谱;两者思路不同但目标一致:让 agent 具备足够的代码库上下文。
术语
- OAuth(开放授权协议,企业级鉴权常用标准)
- Effect TS(强调类型安全与错误处理的 TypeScript 框架)
- WorkOS(面向企业客户的鉴权/SSO 服务)
- Autumn(基于信用点/额度的计费组件,内置 Convex 集成)
- Daytona(为 AI agent 提供沙盒与算力的托管服务,附带带浏览器的虚拟机)
- Turbo Repo(Vercel 出品的 monorepo 构建与任务编排工具)
- PlanetScale(托管 Postgres/MySQL 兼容数据库的服务)
立场与利益
视频中段插入了对 Greptile(代码审查工具)的明确赞助推广,附带专属链接与折扣码,已从笔记中剥离。视频主体是作者拆解自己产品 Pluto 的系统设计,本身也是为 Pluto 及其所在 agency Hey Fabrica 做曝光和背书,选型建议(如 Convex、Autumn、WorkOS)带有个人偏好色彩,不代表行业唯一最优解。
价值定位
适合已经理解基本系统设计概念、正在用 AI agent 编码构建多客户端应用的开发者,提供一套具体可参照的技术栈与拆分判断(monorepo、BaaS 选型、service 边界、鉴权支付选型),偏实操层面的”一个人怎么想”的案例分享,而非系统性工程理论;对完全不懂开发的纯 vibe coder 或已经有一套成熟架构方法论的资深工程师,增量价值有限。
自检问题
- 为什么客户端不能直接读写数据库? 答案:会暴露 API key,必须经服务器中转,数据库只对服务器可见。13:51
- Monorepo 对使用 AI agent 开发多客户端应用有什么核心好处? 答案:agent 能一次性访问 web/mobile/desktop/backend 全部代码,不必在多个割裂仓库间来回切换上下文。11:00
- Convex 这类 BaaS 如何替代自建的 durable workflow 和队列? 答案:Convex 内置 workflow 组件保证断线续跑,内置 workpool 组件支持并行任务调度,不必自己接 AWS SQS 之类的服务重新实现。15:24
- 判断一块功能是否该拆成独立 service 的标准是什么? 答案:是否自成一体、职责单一、不太牵连全局代码库,更多依赖经验直觉而非严格公式。20:06
- 视频作者选支付工具的依据是什么? 答案:纯订阅制用 Stripe,涉及信用点等复杂计费逻辑用 Autumn。24:29
💬 热门评论 top-12 主 + 8 回(抓取 2026-07-07)
[2] @simbabuilds9338:兄弟，你几年前关于Cursor的一个视频鼓励我继续学习，现在我管理着有50多个WAU的医疗应用 👍 33 ↪ @rasmic(UP):传奇😊 👍 8 ↪ @CarlosGarcia-lm8em:我也在2024年中左右看他搭建工作流，然后就被吸引住了..现在我有了一个自己用vibe coding做的酷炫RSS阅读器，还有自己的AI智能体在我的博客上发帖 :) 👍 2 ↪ @tonyporj:WAU是什么？ 👍 2 ↪ @Elricky124:我需要一份工作！ 👍 1 [7] @tominho7:开始学AI是因为我不想学软件工程来构建产品，现在我却在这里记笔记学习如何设计更好的系统😭，生活不断提醒我没有捷径 👍 10 ↪ @rasmic(UP):😂没有捷径 [10] @IliaTalksAI:非常感谢你完整讲解了这次构建的技术栈！这太有帮助了！ 👍 1 ——其他 8 条:感谢/夸赞([1]@ThisisUzii、[3]@specter0o0、[5]@AbuBakr1、[6]@talvinramnah1051、[8]@CodeWithClinton、[9]@user-ve4ti5ml2y、[11]@ranakaleem9012、[12]@JacquesSchaeken);1 条 spam 已略
英文原文
[1] @ThisisUzii:Bro those terminal notifications were tripping me out 😂 Kept thinking my agents were done working lol 👍 30
↪ @rasmic(UP):my bad lol, tried editing them out 👍 3
↪ @BallRank28:Same thought my cursor 😂 👍 1
↪ @learning_the_hard_way:Me too. I had to rewind to see if it was from the video or my computer. 😂 👍 1
[2] @simbabuilds9338:Bro one of your videos from a couple years ago about Cursor encouraged me to keep learning and now I am managing health care apps with 50+ WAUs 👍 33
↪ @rasmic(UP):Legend 😊 👍 8
↪ @CarlosGarcia-lm8em:I also watched him around mid 2024 building a workflow and got hooked.. Now I have a cool RSS reader I vibe coded and my own AI agent posting on my blog. :) 👍 2
↪ @tonyporj:what is WAUs? 👍 2
↪ @Elricky124:I need a job! 👍 1
[3] @specter0o0:criminally underrated channel 👍 4
[4] @lethaldose2000:I love this. You at Max Boss level. I can't wait to access this service. Let me know when it's available. 👍 1
[5] @AbuBakr1:What modern advert looks like 😅 👍 5
[6] @talvinramnah1051:bro 10/10 video, sending this to the non-technical staff in my team 👍 3
[7] @tominho7:Started learning about AI because I didn’t want to learn about software engineering to build products Now I’m over here taking notes about how to design better systems 😭 Life keeps reminding me shortcuts don’t exist 👍 10
↪ @rasmic(UP):😂 no shortcuts
[8] @CodeWithClinton:Mic is a gem, thank you Jesus Boy! 👍 1
[9] @user-ve4ti5ml2y:Finally, some real videos 👍 4
[10] @IliaTalksAI:Thank you so much for walking through your whole tech stack for this build! This is so helpful! 👍 1
[11] @ranakaleem9012:generally i don't comment on the youtube videos but your video force me to do this. amazing video 👍 1
[12] @JacquesSchaeken:Bro you cook every time. You explain everything so intuitively 🤝 👍 3