为什么你的 AI 应用构建器先给你看假数据（以及为什么这么做才对）

你向你的 AI 应用构建器描述了一个应用。一分钟后，你就看着一个能用的界面 —— 页面、按钮、一张用户表，里面是些叫”Alex Rivera""Priya Shah”之类的名字、一些没什么道理的价格、一个你压根没要的”专业版套餐”。什么都没保存。你刷新一下，数据还在。你添加一个新用户，它就消失了。

它看起来像一场马上就要露馅的魔术。其实不是。那是这次构建里好的那部分。你屏幕上的那些模拟数据是刻意为之的第一步，也正是接下来出现的数据库，将真正契合你想要的那个应用的原因。

“先用假数据”到底是什么意思

当一个 AI 应用构建器接过你的需求时，它不会直奔数据库而去。一个好的构建器会先写出那些屏幕，用看上去像那么回事的占位数据把它们填满，然后 —— 而且只有到那时 —— 才去设计一个与之匹配的数据库。

那些占位数据不是装饰。它是一份合约。一旦你的应用说”每个订单都有一个客户名、三个明细项、一个总额和一个状态”，接下来被搭出来的那个数据库，就必须分毫不差地拥有那些东西，并且是分毫不差的那些形状。是屏幕决定数据长什么样，而不是反过来。

这跟一个人类开发者通常的起手方式是反着来的。一个传统开发者会先设计数据库，再针对它去搭屏幕。AI 构建器把这个顺序倒了过来，而大多数人没察觉 —— 他们只看到那些假用户，然后认定构建器是在糊弄人。

为什么这个顺序配上 AI 反而更好用

我们试过同时去搭数据库和屏幕。行不通。下面是个为什么的简短版本。

当两个 AI 智能体在看不到彼此产出的情况下，各自去做应用的不同部分时，它们会做出互不兼容的猜测。界面智能体认定用户有一个”name”字段。数据库智能体认定用户有一个”fullName”字段。两个看上去都对。凑到一起，什么都不对。于是请来第三个智能体去打补丁、弥合这个错位。它也照样在猜。现在外头有了三个猜测在乱跑，而你预览到的那个应用，是这三者拼出来的某种科学怪人。

修法几乎让人有点不好意思：先做一件事，再做另一件。界面被搭出来。它把自己需要的数据写成一份单独的文件，里面是假用户、假订单、以及任何你这应用所关乎的假东西。数据库智能体读那份文件，然后一个字段对一个字段地去匹配。没有猜测。没有讨价还价。没有错位。

这就是为什么你的 AI 应用构建器能在一分钟内给你看一个看上去已经完工的应用。它没有把这次构建糊弄过去。它已经完成了这次构建的四分之一 —— 那个决定了其他一切的部分 —— 而数据库是接下来十秒钟的活儿，不是接下来十个小时的活儿。

假数据在屏幕上时，该看些什么

这正是大多数人一带而过的时刻。他们看到占位数据，就开始要求改颜色。但占位数据是一个正在向你提出的问题。读懂它。

下面是几个该留意的例子：

• **用词不对。**你想要的应用追踪的是”发货（shipments）“。占位数据把它们叫成了”订单（orders）“。告诉构建器。如果你现在让它溜过去，那么每一个屏幕、每一个数据库字段、每一份报表都会用错那个词 —— 而日后重命名，在任何工具里都不是一键就能搞定的事，无论营销话术怎么吹。
• **缺字段。**那张假发票有总额、有日期。你还需要一个采购订单号。趁现在屏幕上只有五张模拟发票时把它加上，好过等数据库搭好、灌进真实客户数据之后再加。
• **形状不对。**模拟数据显示”1 个客户，1 个地址”。可你真实的客户有多个地址。构建器没法从你的需求里推断出这一点。现在就告诉它，趁改动形状还分文不花的时候。
• **冒出来的意外实体。**构建器自作主张地发明了一个你没要的”团队”概念，因为它假定这是个多用户应用。也许你确实想要。也许你不想。无论哪种，都要在数据库围着它搭起来之前定好。

一条好用的规则：如果你的应用里有一个名词，在屏幕上的占位数据里没有被体现出来，那构建器就还不知道它的存在。在你对第一个预览点下”保存”之前，把它提出来。

为什么这个顺序对接下来发生的事很重要

一旦占位数据对了，搭数据库就是机械活了。构建器读你的假数据，生成一个与之匹配的结构，写出那些屏幕本来就在试图调用的查询，最后再把那些占位的导入换成真实的。原本展示假用户的同一批屏幕，现在展示的是你实际放进去的任何东西。

你通常能实时看到这个切换发生。一个原本因为在读一个本地文件而瞬间加载完的页面，现在多了半秒的加载状态 —— 那是这个屏幕第一次在跟一个真实的数据库说话。大多数人会漏掉这一刻，没意识到这个应用刚刚跨过了从”演示品”到”能存真实数据的东西”的那条线。

这一切之所以能成立，是因为下游的所有东西 —— 数据库设计、各种查询、加载状态、空状态 —— 都是由你在占位阶段于屏幕上看到的东西所决定的。如果你当时签字认可了三列，你拿到的就是三列。如果你签字认可了一个取值为”草稿”和”已发送”的”状态”字段，那数据库就恰好接受这些。中间不存在第二道转译步骤，让某个设计师向开发者的交接把事情搞砸。

一个你可以做的小测试

下次你做点什么的时候，试试这个：当占位数据出现时，在要求任何别的东西之前，先改一样关于它的东西。重命名一个字段。加一列。把”用户”换成”成员”。然后看看数据库被搭出来时会发生什么。

你会看到那个改动出现在所有地方 —— 出现在数据库设计里、出现在查询里、出现在应用完工时构建器灌进去的种子数据里。占位阶段的一个词，涟漪般传遍了整个应用。这就是你在这个阶段所握有的杠杆，也是”先用假数据”并非偷工减料把戏的原因。它正是这个应用真正被决定下来的地方。

如果你想钻得更深，我们上一篇关于一个 AI 做出来的应用里面究竟有什么的文章，带你逐一走过那些你乍一看看不到的其他运转部件。规律是一样的：大部分杠杆，都藏在那些看上去无关紧要的部分里。