第 03 章

用 AI 交付一个完整 SaaS：从规划、界面、后端到自动排错

以一个健身教练平台为例，走一遍可复用的全栈交付流程：先访谈式规划，再用参考图做界面，然后逐个功能实现并自测；后端用 Neon，实时聊天与视频用 Stream 的 agent skills，错误监控与自动修复交给 Sentry。

Shipping a Full-Stack SaaS with AI: Planning, UI, Backend, and Self-Healing

A reusable end-to-end workflow, demonstrated on a personal-training platform: interview-style planning, UI built from visual references, one feature at a time with manual checks; Neon for the backend, Stream agent skills for chat and video, and Sentry for monitoring and automated fixes.

首发于 2026.10.30中 / EN

技术教程ai-codingsaasfull-stackdeploymentdebugging

篇内目录

这一篇在讲什么

用 AI 做一个漂亮的静态网站已经不难，难的是把它变成一个真正的应用：登录、支付、数据库、实时更新、视频通话、消息系统，还要让这些部分彼此配合。

演示项目是一个健身教练平台：用户可以找教练、购买训练计划、看视频课、聊天、预约一对一课程；教练有自己的后台，管理客户、上传课程、查看收入。平台抽取佣金。

技术选型是作者的示范，不是通用推荐：

部分	工具	用途
框架	Next.js	全栈应用
后端	Neon	Postgres、认证、存储、函数、实时
实时聊天与视频	Stream	消息、回复、话题、输入状态、一对一视频
媒体	ImageKit	视频上传、图片优化、自适应码率播放器
支付	Stripe	一次性购买与平台抽成
可观测性	Sentry	错误监控、会话回放、AI 自动排查
托管	Cloudways Velocity	部署与自动重新部署

作者反复强调：这套课真正重要的不是这个应用，而是流程。先规划、再做界面、然后一个功能一个功能实现，每完成一个就人工检查、让 AI 复核、提交，再进入下一个。

时间轴

时间	内容
0:00	项目预览与工作流总览
3:02	环境：Node.js、VS Code、选 AI 工具，跑通一个最小 Next.js 项目
12:00	部署到 Cloudways Velocity，接 GitHub 实现自动部署
24:32	规划：用 plan mode 让 AI 采访你，产出 PLAN.md
41:37	界面：用 Pinterest 参考图 + 假数据搭完整 UI
54:12	后端：Neon 认证、数据库、实时更新
1:17:43	Stream agent skills：聊天与视频通话
1:33:48	Sentry：错误监控、会话回放与自动修复
1:58:41	ImageKit：图片优化与视频播放器
2:07:32	收尾：Stripe 留作练习，提交并部署

工作流：一个闭环

作者把它画成一个循环，值得先记住整体形状：

规划：说清楚要做什么、有哪些页面、用户流程、技术栈。不知道自己在建什么，AI 只能靠猜。
界面：根据规划做 UI，给 AI 参考图，而不是让它自由发挥。
逐个功能实现：一次只做一个功能。
人工自检：自己点一遍，确认功能真的能用。
AI 复核代码：让 AI 检查实现是否有问题。
修复 → 提交：功能完成就保存进度；没完成就重复上面几步。
还有功能就回到第 3 步，没有了就结束。

这个循环里，第 4 步和第 5 步的顺序很关键：先自己确认功能对不对，再让 AI 看代码。否则 AI 可能在错误的目标上做优化。

第 1 步：环境与部署

先把最小项目跑起来

安装 Node.js 和 VS Code 后，新建空文件夹拖进编辑器。AI 工具可以用 Claude Code、Codex、Cursor 等，命令各不相同，但流程一致。作者建议至少订阅 20 美元档，理由是用量足够跟完整套流程。

先用一句最简单的话验证工具链是通的：

build me a nextjs project, keep it simple, a habit tracker application

这个习惯记录器不是最终项目，只是为了确认「AI 能建项目、能跑起来」。

npm run dev

打开本地地址，新增一条习惯、刷新页面确认数据还在，工具链就验证完了。

尽早部署，并接上自动部署

作者在写任何业务代码之前就先部署，这一步的价值常被低估：从第一天起就有一个真实可访问的地址，后面每加一个功能都能立刻在线上看到。

做法是：在 GitHub 新建仓库并推送代码（可以直接让 AI 执行你粘贴的 git 命令），然后在 Cloudways Velocity 里连接 GitHub、选中仓库、点部署。平台会自动识别这是 Next.js 项目，一两分钟就能得到一个临时域名。

更关键的是自动部署：平台监听仓库的新 commit，任何一次推送都会触发重新部署。于是日常开发变成：

给项目加一个明暗主题切换，然后提交并推送到我的仓库。

AI 改代码、提交、推送；平台自动重新部署；线上地址几分钟后就更新了。你不需要进任何控制台。

第 2 步：规划——让 AI 采访你

新手最常见的错误，是打开编辑器就说「我要做 X，请帮我做」。作者说，从第一天起不可能想到所有细节，但有一个办法可以让细节自己浮现：plan mode + 一个「采访我」的提示词。

提示词的核心是告诉 AI：

你的任务是对我即将描述的项目做访谈。就每一个细节、每一个决策向我提问，不要自己猜功能。

作者举的例子很具体：涉及支付时，AI 会问用 Stripe 还是一次性付款、要不要订阅、月费定 20 还是 50。这样一轮下来，可能产生 20–30 个问题。

描述项目时，把技术栈也一起说清楚：

我想用 Next.js 做一个全栈健身教练平台。
用户可以找教练、购买训练计划、看视频课、和教练聊天、预约一对一课程。
教练有自己的后台，管理客户、查看训练计划和收入。
技术栈：Neon 做 Postgres、认证和实时；Stripe 做支付；
Stream 做带 reaction、回复、话题的聊天和一对一视频；
Sentry 做错误监控和自动调试；
Cloudways 做托管与部署；ImageKit 做图片视频上传、优化和播放器。
界面要现代、有质感。

回答问题时的取舍

拿到问题后，作者提醒了一个很容易被忽略的细节：不要无脑全选「推荐选项」。教程里为了节省时间可以全选默认，但在真正要变现的项目里，有些问题的不同选项会显著改变产品形态和成本，必须逐条读。

回答完会生成一份计划，界面会展示出来。此时同样要通读，不满意就改成你的版本，再接受。

最后把计划落成文件：

把这份计划保存到 PLAN.md 文件里。

PLAN.md 与 AGENTS.md 的分工

PLAN.md：这个项目要做什么、架构决策、技术栈、假设。
AGENTS.md：给 AI 的项目规则，类似 README 但对象是 AI 而不是人。里面可以写「必须用这个技术栈、绝不用那个」「每次改动都提交 commit」等。

AGENTS.md 的特殊之处是：即使你不主动引用它，它也会一直加载进上下文。所以它适合放那些「每次都必须遵守」的约束。

第 3 步：界面——用参考，而不是凭空生成

直接说「给我做一个好看的 UI」，得到的通常是随机风格。作者的做法固定为三步：

新建 design/ 文件夹；
去 Pinterest 搜 website design，再叠加领域词（如 fitness website design），挑一张真正喜欢的截图存进去；
把图片附给 AI，并说明这是灵感来源。

指令大致是：

分析 PLAN.md，然后为整个应用搭建完整的 UI 设计。
现在用假数据，不要接认证、数据库或支付，只做界面和硬编码数据。
界面风格参考我附上的这张图。

这里有两个值得学的细节：

先做完整 UI，后接真实数据。 界面阶段只用假数据，可以快速看到整体效果；等界面定稿，再把假数据换成真数据。作者在后面的后端章节正是这样做的。
背景图这类素材单独生成。 把参考图截图发给 GPT 或 Gemini，要求「生成这张背景图，不要文字和 logo」；也可以用 Higgsfield 这类付费工具并通过 MCP 直接在编辑器里出图，省去来回切换。

生成的界面里，有些交互是假的（比如预约时段点不动），这是故意的。把「哪里不对」截图给 AI，它会继续改，直到满意为止。

第 4 步：后端——Neon

界面完成后，开始把假数据换成真数据。Neon 提供 Postgres、认证、存储、函数、AI Gateway 和实时功能。

关键技巧不是「让 AI 写代码」，而是让 AI 告诉你它需要什么：

这是我从 Neon 拿到的接入文档。先读 PLAN.md，然后实现认证，
并在数据库里创建一些真实数据。
如果需要在 Neon 控制台做什么，给我一份待办清单，我来做。
如果需要某些值，直接告诉我，我去取。

这个「给我待办清单」的模式贯穿全篇。第一次用某个控制台时，你不知道该复制哪个值、该点哪里；与其自己摸索，不如让 AI 列出它需要的东西，你照着做。

实践中的几个点：

数据库连接串、认证 URL 等放进 .env.local，注意去掉复制时带的引号。
认证用的是 Better Auth；上线前要把生产域名加进可信域名列表。
改环境变量之后必须重新部署，否则线上仍然是旧值。
遇到不确定的事（比如「开发环境要不要加 localhost」），直接截图问 AI，而不是猜。

验证方式很实在：用 Google 登录一次，再用邮箱注册一次，去 Neon 的认证面板能看到新用户，就说明链路真的通了。

实时功能要用两个账号验证

预约功能做完后，作者开了第二个浏览器、登录另一个账号，两边并排放在一起：一边预约某个时段，另一边不刷新就应该看到该时段被禁用。

第一次没成功。处理方式不是读日志，而是截图 + 描述 + 要求：

这是我每次预约时会看到的结果（附图）。
请修复它，并确保所有人都能实时收到更新。

修好后重新验证，实时更新生效。这是全篇最值得记住的排错方式之一：截图比文字描述准确得多。

第 5 步：实时通信——Stream 的 agent skills

聊天和视频通话如果从零搭，代价极高（信令、媒体服务器、扩展性）。Stream 提供现成的 SDK，而它的 agent skills 解决的是另一个问题：让 AI 知道怎么正确使用这套 SDK。

做法是：安装 Stream CLI，登录，在项目里初始化：

npm install -g @stream-io/stream-cli
stream login
stream init

初始化时会选择组织与应用，然后询问「为哪个工具安装 skills」。选你用的工具（Claude Code、Cursor、Codex 等），它就会把一整套文档作为 skill 写进项目。之后在编辑器里输入 stream 就能查询这些文档，例如「如何在 Node.js 里生成用户 token」。

为什么这很重要？ 没有 skills，AI 只能凭训练数据里的旧版 SDK 猜 API；有了 skills，它读的是当前版本的官方文档。

集成指令要写清边界：

把 Stream 的聊天和视频集成到我现有的 Next.js 应用里。
保留现有的认证后端和 UI 设计。
加入带频道、reaction、回复和话题的实时消息，以及带摄像头和麦克风控制的视频通话。
使用服务端安全生成 token，并遵循最新的官方 SDK 文档。

测试时逐项确认：摄像头开关、麦克风开关、加入通话、reaction、录屏、共享屏幕、结束通话。

聊天界面第一版很乱——按钮被遮住、话题打不开。作者同样用截图 + 一句「UI 彻底坏了，请修好，你可以用浏览器自己测，直到看起来正常」解决，并且提前连好了 Chrome MCP，让 AI 能自己打开页面验证。结果一次提示就修好了。

随后验证聊天功能：发消息、加 reaction、开话题、同时发到主聊天、附件、GIF 命令、编辑、删除、引用。确认无误后提交。

一次真实的部署失败

提交后线上部署失败。原因很清楚：Stream 的 API key 和 secret 只加在了本地，没有加到托管平台的环境变量里。加上、保存、重新部署，成功。

这类失败很典型：本地能跑 ≠ 线上能跑，环境变量是最常见的差异来源。

第 6 步：可观测性——Sentry 与自动修复

用户不会在出错时给你发邮件，他们会直接关掉页面、再也不回来。Sentry 的作用是当那个「瞭望塔」：捕获错误、记录会话、给出上下文。

作者列出的能力里，对本篇最重要的是三个：

错误监控：出错时间、影响范围、调用栈、请求与用户上下文。
会话回放：出错时录屏，能直接看到用户点了什么、在哪一步崩掉。
AI 自动排查（Seir）：读代码找根因，生成修复，并开一个 pull request 等你合并。

安装方式已经变成「让 agent 来做」：在 Sentry 控制台复制给 agent 的安装命令，在终端执行，再把生成的提示词贴给 AI。期间需要通过 MCP 完成 OAuth 授权——作者第一次也没成功，重新执行 /mcp、再授权一次就好了。

手动流程：分析 → 计划 → 修复 → PR

先故意制造一个错误，触发后进入 issue：

点击分析，Seir 给出根因与复现步骤；
让它制定计划；
让它写修复代码；
生成 pull request；
你 review 并合并。

一个容易踩的坑：Seir 读的是 GitHub 上的代码，不是你本地的文件。所以修复前必须先把代码推上去，并且要在 Sentry 里配置好 GitHub 集成与仓库映射。

自动流程：错误达到阈值就自己修

配置好代码映射后，同一个错误触发超过一定次数（演示中约 10 次），Seir 会自动开始分析、修复并起草 PR。作者让 AI 故意把错误触发 15 次以上，然后去 GitHub 看，已经有现成的 PR；合并即可，整个过程人只需要 review。

合并后让本地同步：

我刚刚合并了一个 pull request，请拉取最新代码。

日志与追踪

生产环境不要用 console.log。Sentry 的 structured logs 可以打标签、可查询、存在云端，并且和 trace、error、replay 关联。用户量小的时候感觉不到价值，但到几百、几千用户时，它就是排查问题的唯一入口。

第 7 步：媒体——ImageKit

ImageKit 负责图片和视频的上传、存储、变换与分发。

URL 即变换：在图片 URL 里加参数就能裁剪、缩放、旋转、叠加，一次上传可以得到头像、页头、卡片三种尺寸。
自动优化：自动压缩并输出 WebP/AVIF 等现代格式。
视频播放器：支持自适应码率（按网速切清晰度）、字幕、章节和预览缩略图；课程视频可以设为私有，只有购买者能看。

集成同样靠一句「需要什么环境变量告诉我」：

把 ImageKit 接入这个应用，覆盖 PLAN.md 里的第三、四阶段。
功能包括……（列出）
告诉我你需要哪些环境变量，以及哪些要加到 Cloudways。

ImageKit 文档每页都有「Copy for LLM」按钮，可以把整页说明直接贴给 AI，省去手工整理。

贯穿全程的几条方法

先规划再动手。 访谈式提示词把「AI 猜功能」变成「你回答问题」，这是整篇投入产出比最高的一步。
给参考，而不是给形容词。 「现代、有质感」几乎没有信息量；一张截图能立刻对齐审美。
一次一个功能，做完就验证、就提交。 每个功能都走「实现 → 人工自检 → AI 复核 → 修复 → 提交」。
让 AI 告诉你要什么。 控制台里该点哪里、该复制哪个值，直接问，让它给待办清单。
截图是最高效的 bug 报告。 报错界面、错位按钮、失败状态，截图加一句要求，通常比描述有效。
本地能跑不等于线上能跑。 环境变量、域名白名单、重新部署，是最常见的三类差异。
尽早引入可观测性。 有真实用户之后，看不见的错误比看得见的错误更贵。

理解检验

1. 为什么作者建议「先人工自检，再让 AI 复核代码」，而不是反过来？

参考答案：AI 复核的是代码实现层面的问题（结构、边界、潜在 bug），前提是「这段代码在做正确的事」。如果功能本身就不符合预期，先让 AI 看代码，它可能在一个错误的目标上优化，浪费一轮修改。先人工确认功能行为正确，再把「如何实现得更稳」交给 AI，两次检查各管一层，顺序不能颠倒。

2. plan mode 的「采访式」提示词解决了什么问题？为什么它比直接描述需求更有效？

参考答案：直接描述需求时，没被说到的细节会由 AI 自行猜测，最终成品常与预期不符。「采访我」把 AI 从执行者变成提问者，就支付方式、订阅价格、教练入驻方式等逐个决策向你确认，把隐含假设显式化。一次可能产生 20–30 个问题，覆盖的正是你原本没想到的部分。作者同时提醒：不能无脑选推荐项，重要项目要逐条读，因为不同选项会改变产品形态与成本。

3. 为什么界面阶段要先只用假数据，等界面定稿后再接真实数据？

参考答案：界面阶段的目标是快速看到整体效果、验证布局与交互，假数据能立刻铺满所有页面，不受后端进度影响。如果一开始就接真实数据和认证，任何一个后端问题都会阻塞界面迭代，反馈变慢。等界面定稿后再接真实数据，替换的是数据来源而不是重做界面，改动范围可控。作者在后端章节正是按这个顺序做的。

4. Seir 自动修复前，为什么必须先配置 GitHub 集成与代码映射？

参考答案：Seir 读的是 GitHub 仓库里的代码，不是你本地工作区的文件。没有 GitHub 集成，它拿不到源码；没有代码映射（project → repo → 分支），它不知道该去哪个仓库找对应文件。两者缺一，分析就会失败或改错地方。另外，修复前要先把本地改动推送到 GitHub，否则它基于旧代码生成 PR。

5. 部署失败最常见的原因是什么？这篇里给出了哪两个具体例子？

参考答案：最常见的是本地与线上环境不一致，尤其是环境变量。例子一：Stream 的 API key 与 secret 只写进了本地环境，托管平台没有，部署直接失败；补上并重新部署后成功。例子二：改完环境变量后必须触发一次新的部署，否则线上仍用旧值。除此之外，认证服务要求把生产域名加入可信域名列表，也是上线时才暴露的一类差异。

6. Stream 的 agent skills 解决的是什么问题？没有它会怎样？

参考答案：它把当前版本的官方 SDK 文档打包成 AI 可读的 skill 写进项目，让 agent 在写 Stream 代码时依据最新文档，而不是训练数据里的旧 API。没有它，AI 容易用过时或臆造的接口，出现「代码看起来合理但跑不通」的情况；有了它，可以直接问「如何在 Node.js 生成用户 token」并获得当前版本的答案，集成提示词里也就能要求「遵循最新官方 SDK 文档」。

与前后内容的关系

这一篇是「用 AI 交付完整应用」的实战版：它把规划、界面、后端、实时通信、可观测性、媒体服务串成一条流水线，重点在于每一步的验证方式和交给 AI 的输入形式（计划文件、参考图、待办清单、截图）。

同书的另外两篇提供对照：一篇讲通用的五步流程与三条不能省的原则（Git、让 AI 自测、人工验证），可以看作本篇的方法论提炼；另一篇从零做到能收款的 SaaS，覆盖部署、数据库、支付与安全扫描。合起来看，可以把「流程骨架」「实战细节」「工具选择」分开理解，换项目时只替换其中一层。

What this walkthrough is about

Building a pretty static site with AI is easy. Turning that site into a real application is not: you need authentication, payments, a database, realtime updates, video calling, messaging — and all of those pieces have to work together.

The demo project is a personal training and coaching platform. Users discover trainers, buy workout programs, watch video lessons, chat with trainers, and book one-on-one sessions. Trainers get a dashboard to manage clients, upload lessons, and track earnings; the platform takes a commission.

The stack is the author's example, not a universal recommendation:

Layer	Tool	Role
Framework	Next.js	Full-stack app
Backend	Neon	Postgres, auth, storage, functions, realtime
Chat & video	Stream	Messaging, replies, threads, typing indicators, 1:1 calls
Media	ImageKit	Video upload, image optimization, adaptive player
Payments	Stripe	One-time purchases and platform commission
Observability	Sentry	Error tracking, session replay, AI debugging
Hosting	Cloudways Velocity	Deployment and auto-redeploy

The author stresses repeatedly: the application is not the point — the workflow is. Plan first, then design the UI, then implement one feature at a time, checking manually and having AI review each one before committing and moving on.

Timeline

Time	Topic
0:00	Project preview and workflow overview
3:02	Environment: Node.js, VS Code, choosing an AI tool, bootstrapping a small Next.js app
12:00	Deploy to Cloudways Velocity; connect GitHub for auto-deploy
24:32	Planning: plan mode where the AI interviews you; produce PLAN.md
41:37	UI: build the full interface from a Pinterest reference with fake data
54:12	Backend: Neon auth, database, realtime
1:17:43	Stream agent skills: chat and video calls
1:33:48	Sentry: monitoring, session replay, automated fixing
1:58:41	ImageKit: image optimization and the video player
2:07:32	Wrap-up: Stripe left as an exercise; commit and deploy

The workflow is a loop

Remember the shape before the details:

Plan — what you are building, which pages, user flows, stack. If you do not know, the AI guesses.
Design the UI — from a visual reference, not from thin air.
Implement one feature.
Check it manually — click through it yourself.
Have the AI review the code.
Fix, then commit — save progress when the feature is done; otherwise repeat.
More features? Back to step 3. None left? Done.

The order of steps 4 and 5 matters: confirm the feature behaves correctly before asking AI to review the code. Otherwise it may optimise toward the wrong target.

Step 1: Environment and deployment

Get the smallest possible app running

After installing Node.js and VS Code, create an empty folder and drag it into the editor. Any agent works (Claude Code, Codex, Cursor); the commands differ, the workflow does not. The author suggests at least the $20/month tier, which is enough to follow along.

Validate the toolchain with the simplest possible request:

build me a nextjs project, keep it simple, a habit tracker application

The habit tracker is not the real project — it only proves the agent can create and run an app.

npm run dev

Add a habit, reload, confirm the data persists. Toolchain verified.

Deploy early, and wire up auto-deploy

The author deploys before writing any business code. The value is easy to underestimate: from day one there is a real, reachable URL, and every later feature can be seen in production immediately.

Create a GitHub repository and push (you can hand the agent the git commands to run). In Cloudways Velocity, connect GitHub, pick the repository, and deploy. The platform detects Next.js automatically; a temporary domain appears within a minute or two.

The important part is auto-deploy: the platform watches the repository and redeploys on every new commit. Day-to-day work becomes:

Add a light/dark mode switch to this project, then commit and push to my repo.

The agent edits, commits, pushes; the platform redeploys; the live URL is updated a few minutes later. No dashboard visit required.

Step 2: Planning — let the AI interview you

The most common beginner mistake is opening the editor and saying "I want to build X, please build it." You cannot think of every detail on day one, but there is a way to surface them: plan mode plus an interview prompt.

The prompt's core instruction:

Your job is to interview me about the project I am about to describe. Ask about every detail and every decision; do not guess features.

The example is concrete: when payments come up, the AI asks whether to use Stripe, whether it is one-time or subscription, and whether the monthly price should be $20 or$ 50. A single pass can produce 20–30 questions.

Describe the stack along with the product:

I want to build a full-stack personal training and coaching platform with Next.js.
Users discover trainers, buy workout programs, watch video lessons,
chat with trainers, and book one-on-one sessions.
Trainers get a dashboard to manage clients and see programs and earnings.
Stack: Neon for Postgres, auth and realtime; Stripe for payments;
Stream for chat with reactions, replies and threads plus 1:1 video;
Sentry for error tracking and automated debugging;
Cloudways for hosting; ImageKit for image/video upload, optimization and player.
The UI should look modern and premium.

Answer the questions with judgment

One easily missed detail: do not blindly accept every "recommended" option. In a tutorial it is fine to save time, but in a project you intend to monetize, different answers change the product's shape and cost. Read each question.

When the plan appears, read it end to end, reject it with your edits if something is wrong, then accept.

Finally, persist it:

Save this plan to a file called PLAN.md.

How PLAN.md and AGENTS.md differ

PLAN.md — what this project is: architecture decisions, stack, assumptions.
AGENTS.md — rules for the AI, like a README whose audience is the agent: "always use this stack, never that one", "commit after every change".

AGENTS.md is special because it is loaded into context even when you do not reference it. That makes it the right home for constraints that must always hold.

Step 3: UI — references, not adjectives

Asking for "a really nice UI" produces something generic. The author's routine has three fixed steps:

Create a design/ folder.
Search Pinterest for website design, narrowed by domain (fitness website design), and save a screenshot you actually like.
Attach the image and say it is the inspiration.

The instruction is roughly:

Analyze PLAN.md and build the entire UI for the application.
Use fake data for now; do not integrate auth, database or payments yet,
just the UI with hardcoded data.
Get inspired by the image I attached.

Two details worth copying:

Full UI first, real data later. Fake data lets you see the whole product immediately; once the UI is settled, swap the data source. That is exactly what the backend section does.
Generate assets separately. Screenshot the reference, send it to GPT or Gemini, and ask for "this background image without text or logos"; or use a tool such as Higgsfield through MCP so images are generated without leaving the editor.

Some interactions in the generated UI are fake (booking a slot does nothing). That is intentional. Screenshot what is wrong, describe it, and let the agent iterate until it is right.

Step 4: Backend — Neon

With the UI in place, replace fake data with real data. Neon provides Postgres, auth, storage, functions, an AI gateway, and realtime.

The key move is not "have the AI write code" but have the AI tell you what it needs:

Here is the integration documentation I got from Neon. Read PLAN.md first,
then implement authentication and create some real data in the database.
If I need to do anything in the Neon dashboard, give me a to-do list.
If you need any values, tell me and I will fetch them.

That "give me a to-do list" pattern recurs throughout. The first time you use a console you do not know which value to copy or which button to press; asking the agent to enumerate its requirements beats guessing.

Practical points:

Put the database URL, auth URL and similar values in .env.local; strip the quotes you get when copying.
Authentication runs on Better Auth; before going live, add the production domain to the trusted domains list.
Changing environment variables requires a new deployment, or production keeps the old values.
When unsure (for example, "do I need to allow localhost in development?"), screenshot and ask instead of guessing.

Verification is concrete: sign in with Google once, register with email once, then check the Neon auth panel — new users appearing there proves the chain works.

Test realtime with two accounts

After booking is implemented, open a second browser, sign in as another user, and put the windows side by side: book a slot in one; the other should disable that slot without reloading.

The first attempt failed. The fix was not log reading but screenshot + description + requirement:

This is what I get every time I try to book a session (image attached).
Please fix it and make sure everyone receives the update in realtime.

After the fix, the realtime update worked. This is one of the most useful debugging habits in the whole video: a screenshot carries far more signal than a paragraph.

Step 5: Realtime chat and video — Stream agent skills

Building chat and video from scratch is expensive — signalling, media servers, scaling. Stream provides the SDKs. Its agent skills solve a different problem: teaching the AI how to use those SDKs correctly.

Install the CLI, log in, and initialise:

npm install -g @stream-io/stream-cli
stream login
stream init

Initialisation asks for the organisation and app, then which tool to install skills for (Claude Code, Cursor, Codex). The skill pack documents the current SDK inside your project. You can then type stream in the editor and ask things like "how do I generate a user token in Node.js".

Why it matters: without the skills, the AI guesses at APIs from its training data, which may be outdated. With them, it reads the current official documentation.

The integration prompt should state boundaries:

Integrate Stream chat and video into my existing Next.js application.
Preserve our current authentication backend and UI design.
Add realtime messaging with channels, reactions, replies and threads,
plus video calls with camera and microphone controls.
Use secure server-side token generation and follow the latest official SDK docs.

Then verify each capability: camera on/off, microphone on/off, join, reactions, recording, screen sharing, ending the call.

The chat UI was broken at first — buttons hidden, threads unreachable. Again: screenshot plus "the UI is completely broken, fix it; you can use the browser to test until it looks right." With the Chrome MCP connected, the agent could open the page itself, and one prompt fixed it.

Then exercise the chat: send messages, react, open a thread, send to the main chat as well, attach files, use the GIF command, edit, delete, quote. Commit when it holds up.

A real deployment failure

The deploy after committing failed. The cause was plain: the Stream API key and secret existed only locally, not in the hosting platform's environment variables. Add them, save, redeploy — success.

This failure is typical. Local working does not imply production working; environment variables are the most common gap.

Step 6: Observability — Sentry and automated fixes

Users do not email you when something breaks. They close the tab and do not come back. Sentry is the watchtower: it captures the error, records the session, and supplies context.

Three capabilities matter here:

Error monitoring — when, how often, the stack trace, request and user context.
Session replay — a screen recording around the error, so you can see what the user clicked before it broke.
AI debugging (Seir) — reads the code, finds the root cause, proposes a fix, and opens a pull request for review.

Setup is now "let the agent do it": copy the agent setup command from the Sentry console, run it in the terminal, paste the generated prompt into your coding agent. OAuth happens through MCP — the author's first attempt failed, and re-running /mcp and authenticating again fixed it.

Manual path: analyse → plan → fix → PR

Trigger a deliberate error, open the issue, and:

Start the analysis; Seir reports the root cause and reproduction steps.
Ask it to make a plan.
Ask it to write the fix.
Generate a pull request.
Review and merge.

One trap: Seir reads code from GitHub, not from your local disk. Push before asking for a fix, and configure the GitHub integration and repository mapping.

Automated path: threshold-triggered fixes

With code mappings configured, an error that fires more than a threshold (about ten times in the demo) causes Seir to analyse, fix, and draft a PR automatically. The author had the agent fire an error 15+ times, then found ready-made PRs on GitHub; merging is the only human step.

Then sync locally:

I just merged a pull request. Please pull the latest changes into my codebase.

Logs and traces

Do not ship console.log to production. Sentry's structured logs are tagged, queryable, stored in the cloud, and linked to traces, errors, and replays. With a handful of users it feels unnecessary; with hundreds or thousands it is the only way to find out what happened.

Step 7: Media — ImageKit

ImageKit handles upload, storage, transformation, and delivery for images and video.

Transformation in the URL — resize, crop, rotate, overlay by changing URL parameters; one upload serves an avatar, a header, and a card.
Automatic optimization — compression and modern formats such as WebP and AVIF.
Video player — adaptive bitrate, subtitles, chapters, preview thumbnails; lesson videos can stay private so only buyers can watch.

The integration prompt follows the same pattern:

Add ImageKit to this application, covering phases three and four in PLAN.md.
Features: ...(list)
Tell me which environment variables you need and which ones to add to Cloudways.

Every ImageKit documentation page has a "Copy for LLM" button, which hands the whole page to the agent without manual rewriting.

Methods that carry across the whole build

Plan before building. The interview prompt turns "AI guesses features" into "you answer questions" — the highest-leverage step in the video.
Give references, not adjectives. "Modern and premium" carries almost no information; one screenshot aligns taste instantly.
One feature at a time, verified and committed. Implement → check manually → AI review → fix → commit.
Let the AI tell you what it needs. Which console button to press, which value to copy — ask for a to-do list.
Screenshots are the most efficient bug reports. An error screen, a misplaced button, a failed state — image plus requirement beats prose.
Local ≠ production. Environment variables, domain allow-lists, and redeploys are the three usual suspects.
Add observability early. Once real users exist, invisible errors cost more than visible ones.

Check your understanding

1. Why does the author check a feature manually before asking the AI to review the code, rather than the other way round?

Reference answer: An AI review covers the implementation layer — structure, edge cases, latent bugs — and assumes the code is doing the right thing. If the feature does not behave as intended, reviewing first may optimise toward the wrong target and waste a round. Confirming behaviour manually and then asking for a code review checks two different layers; reversing the order blurs them.

2. What problem does the interview-style plan-mode prompt solve, and why is it better than describing the requirements directly?

Reference answer: When you describe requirements directly, every unstated detail is filled in by the AI's guesses, which is how finished products drift from expectations. The interview prompt turns the AI into a questioner: it confirms decisions one by one — payment method, subscription price, how trainers onboard — making implicit assumptions explicit. A pass can generate 20–30 questions covering exactly what you had not thought about. The author also warns against blindly taking every recommended answer, since some choices change the product's shape and cost.

3. Why build the UI with fake data first and connect real data only after the design is settled?

Reference answer: The UI phase aims to validate layout and interaction quickly. Fake data fills every page immediately, independent of backend progress; wiring real data and auth first means any backend problem blocks UI iteration. Once the design is final, replacing the data source does not require rebuilding the interface, so the change stays contained. The backend section follows exactly this order.

4. Why must the GitHub integration and code mappings be configured before Seir can fix anything?

Reference answer: Seir reads source code from the GitHub repository, not from your local working copy. Without the integration it has no code; without mappings (project → repo → branch) it does not know where to look. If either is missing, analysis fails or changes the wrong place. Also, push local changes first, otherwise the fix is generated against stale code.

5. What is the most common cause of deployment failure, and which two examples does the walkthrough give?

Reference answer: Environment drift between local and production, most often environment variables. Example one: the Stream API key and secret existed only locally, so the deploy failed until they were added to the host and redeployed. Example two: after changing environment variables you must trigger a new deployment, or production keeps the old values. A related case is the auth provider requiring the production domain to be added to its trusted list — another difference that only appears on launch.

6. What do Stream's agent skills actually solve? What happens without them?

Reference answer: They package the current official SDK documentation as AI-readable skills inside the project, so the agent writes Stream code against the current API instead of outdated training data. Without them, the AI tends to use stale or invented interfaces — code that looks plausible but fails at runtime. With them you can ask "how do I generate a user token in Node.js" and get an answer for the current version, and the integration prompt can legitimately require following the latest official docs.

How it connects

This is the hands-on version of shipping a full application with AI: planning, UI, backend, realtime, observability, and media stitched into one pipeline. What matters most is each step's verification method and the form of the input you give the agent — a plan file, a reference image, a to-do list, a screenshot.

The other notes in this book provide contrast. One distils a general five-step workflow and three non-negotiables (version control, letting the AI self-test, and manual acceptance); another builds a monetisable SaaS from scratch, covering deployment, database, payments, and security scanning. Read together, they separate the workflow skeleton, the practical detail, and the tool choices, so you can swap one layer when the project changes.

来源

视频How Senior Developers Use AI to Build SaaS - Full WorkflowCodesistency · 2026-10-30