用 AI 做的应用里到底有什么：一份给非开发者的导览

你打了一段描述，点了运行，二十分钟后就有了一个能用的应用。很棒。可现在你点开了”查看文件”，正盯着一棵看起来像是用另一种语言写出来的文件夹树发愣。package.json 是什么？为什么 node_modules 里有四十个东西？“schema”是什么意思，你为什么会有一个？

这篇文章是一次导览。不是教程 —— 是导览。读完之后，你不会知道怎么亲手去写这些文件里的任何一个，但下次有什么东西看起来不对劲时，你会知道该指向应用的哪个角落。

我会从头到尾用三个贯穿全文的例子，好让那些抽象的部件有点具体的东西可以挂靠：

• Maya，一位市场主管，给她的团队做了一个推荐排行榜。
• Jordan，一位瑜伽老师，做了一个课程预约网站。
• Sam，经营一家面包店，做了一个”预订明天的羊角面包”页面。

他们三个都用了 AI 应用构建器。在客户眼里，这三个应用看起来完全不一样。但在引擎盖下面，它们的结构出奇地相似。

前端：你的客户真正看到的东西

前端是在别人浏览器里加载出来的一切。按钮、布局、字体、动画、表单在你提交后自己清空的方式。只要你能看见它，它就是前端。

对 Maya 来说，前端是一个带排名、姓名和推荐数的排行榜。对 Jordan 来说，是一个带”预约”按钮的课程日历。对 Sam 来说，是一个糕点清单，每一项旁边都有小小的加号和减号按钮。

在项目里，前端通常待在一个叫 app/、pages/ 或 src/ 之类的文件夹里。你会看到一些以 .tsx 或 .jsx 结尾的文件。每一个大致就是”一个界面”或”一个界面的一部分”。排行榜的一行是一个文件。页头是另一个文件。把这一切串起来的那个页面，是第三个文件。

当你让 AI 构建器”把按钮做得更圆一点”或”把排行榜挪到右边”时，变的就是这一部分。

后端：负责思考的那部分

后端是没人看得见、但人人都离不开的那部分。它是运行在别的地方的代码 —— 在服务器上，而不是在客户的浏览器里 —— 它在那些不该单独信任客户浏览器去做的事情需要发生时，挺身而出。

为什么浏览器不能把一切都包了？因为浏览器是客户的机器，你不能信任它。如果 Maya 的排行榜纯粹在浏览器里更新推荐数，那任何人都能右键给自己加上 9000 个推荐。所以后端是规则待的地方：“这个人可以做这个，但不能做那个”、“真的把这个保存到数据库”、“把这封邮件发出去”。

后端通常待在一个叫 api/、server/ 或 app/api/ 的文件夹里。那里的文件通常都很短。每一个处理一个具体的请求：“创建一个预约”、“列出今天的羊角面包”、“加一个推荐”。

当你的应用里某件事看起来成功了、但结果却没留住 —— 你点了提交、看到了确认、可第二天数据没了 —— 几乎总是后端出了 bug。

数据库：你应用的记忆

把你应用的记忆想象成一排文件柜。每个柜子正面都贴着一个标签。一个写着”users（用户）“。一个写着”bookings（预约）“。一个写着”croissant_orders（羊角面包订单）“。每个柜子里，每一个抽屉是一行。每个抽屉都有同一套格子：一个名字、一个邮箱、一个 created_at（创建时间）、一个 status（状态）。

那个结构 —— “存在哪些柜子，每一行有哪些格子” —— 就叫 schema（结构定义）。它是整个项目里最重要的文件，尽管它大概也是看起来最无聊的那个。找一个叫 schema.ts、schema.prisma 的文件，或者在某个叫 db/ 或 migrations/ 的文件夹里找点东西。打开它。你会看到一个清单，正好映照出你的应用到底记住了关于这个世界的什么。

Jordan 的 schema 有一张 classes 表、一张 bookings 表和一张 users 表。Sam 的有 products、orders 和 order_items。Maya 的有 members 和 referrals。schema 的形状就是产品的形状，这也正是为什么以后改它，比改按钮长什么样要难得多。

一个好用的小窍门：如果你能用大白话描述你的应用记住了什么，你通常就能描述出它的 schema。“我记住每个客户的名字和邮箱。对每个客户，我记住他们下过的订单。对每个订单，我记住是哪些糕点、每种几个。“那句话，几乎就是逐字逐句的 schema。

Auth：门口的保安

“Auth” 是两个词揉到一起的：authentication（认证，你是谁？）和 authorization（授权，你被允许做什么？）。这两件事通常由一个叫 auth/ 的文件夹里的一小撮文件来处理，或者由一个你可能眼熟的服务来处理：Clerk、Auth0、Supabase Auth、NextAuth。

这两个问题是不一样的。认证回答的是：“这真的是 Maya 吗？” —— 通常靠一个密码、一个 Google 登录，或者一封发到她邮箱的魔法链接。授权回答的是：“Maya 被允许删除别人的推荐吗？” —— 而对大多数刚做出来第一周的 AI 应用来说，诚实的答案是”我们忘了去检查”。

这是最常被悄悄搞坏的那部分。登录界面能用，所以感觉很安全。但后端并不总是在检查：那个登录进来的人，是不是他正试图读取数据的那个人。如果你的应用有任何”我的数据 vs 你的数据”的概念，就明确地对 AI 构建器说：“确保用户只能看到和编辑他们自己的数据。” 你会惊讶于，这一句话有多频繁地揭出一个缺失的检查。

集成：那些不是你做的、却照样在用的东西

正是在这里，大多数非开发者低估了实际正在发生的事情。给 Sam 发”你的羊角面包好了”邮件的那个东西不是代码 —— 它是一个 SendGrid 或 Resend 上的账号。处理 Jordan 课程付款的那个东西不是代码 —— 它是 Stripe。托管 Maya 排行榜上那些照片的那个东西不是代码 —— 它是一个像 S3 或 Cloudinary 那样的存储服务。

每个集成都出现在两个地方。后端有一小段代码说”嘿，Stripe，刷这张卡”。还有一个密钥 —— 一长串机密的字符串 —— 存在某个安全的地方（通常是一个叫 .env 的文件，谁都不该把它提交上去），它向 Stripe 证明：这个请求来自 Sam 的面包店，而不是某个陌生人。

如果你哪天纳闷为什么你的应用突然不发邮件了、或者不收款了，原因几乎总是其中之一：一个过期的密钥、一个用满了的额度，或者集成方政策的一次变更。不是代码坏了，是握手坏了。

部署：它是怎么上到互联网的

最后一块，是把你硬盘上那个文件夹，变成客户能通过一个网址访问到的东西的那部分。这通常意味着三件小事在协同工作：

• 主机：一个像 Vercel、Netlify、Fly 或 Render 这样的服务，它运行你的后端、托管你的前端。
• 域名：一个像 mayas-leaderboard.com 这样、指向你主机的名字。
• 构建：那份把你乱糟糟的源文件，变成真正运行起来的那个更精简、更快版本的”配方”。

当一件事在本地能用、却在生产环境坏掉时，麻烦通常就在这里。一个在你笔记本上设了、却没在主机上设的密钥。一个在开发环境装了、却没在生产环境装的库。一个存在于你浏览器里、却不存在于线上站点的数据库。

那个能回本的五分钟习惯

你不需要读你项目里的每一个文件。你不需要知道它们大多数是干嘛的。但你应该每周一次，做一个五分钟的巡视：把上面那几个文件夹挨个打开，然后用大白话问 AI 构建器，有什么变了。

Maya 每周五下午都这么做。她打字问：“这周 schema 里有什么变了，为什么？“以及：“这个应用里有没有任何我没要过的新集成？“答案几乎总是让人安心的。而那少数几次不安心的时候，她在问题还小的时候就抓住了它们。

这就是搞懂这些部件的全部意义。不是为了变成开发者，只是为了能问出更好的问题。

接下来去哪儿

如果这趟导览帮到了你，有两篇后续值得你花时间。那种”看起来没事”的 bug 讲的是当这些部件之一被悄悄搞坏时该怎么办，而能演示 vs 能上线 讲的是怎么判断你的应用何时从第一个阶段走到了第二个阶段。同一张地图，不同的用法。