企业官网建设流程全解析

最近两天，AI 圈又炸出一个新方向：Runway 发布了所谓“首个界面世界模型”。标题党一点说，是“UI 自己长出来，代码被干掉了”；翻译成开发者听得懂的话，就是生成式 UI不再是简单的布局猜测，而是让模型理解“界面是一个可以交互的世界”，并直接生成可用的前端界面。

很多朋友看到这类新闻的第一反应是：又一个 PPT 产品？还是真的能跑？前端开发是不是要凉了？我是不是该转行了？

先说结论：短期内，它不会干掉前端工程师，但它会重新定义前端工程师的日常。这篇文章不打算吹捧任何一家公司，而是想从一个实际开发者的角度，把“界面世界模型”这个概念拆开揉碎，看看它到底解决了什么问题，背后是什么技术逻辑，以及我们这些写代码的人，该怎么面对“UI 自己长出来”这件事。

文章会从概念、技术机制、开发者的应对策略，到可落地的复现思路和排查方案一路展开。即使你现在不打算立刻上手，也能通过这篇文章建立一套判断框架，避免下次看到类似产品时只会“哇塞”。

1. 这件事真正改变的是什么：不是写代码，而是“从哪来”

我们先把注意力从“代码被干掉”这种刺激说法上移开，回到一个更根本的问题：UI 的源头在哪里？

过去十年，UI 开发的主线逻辑几乎没有变过：设计师出 Figma 图纸，前端工程师按图切图、写布局、调样式、对接口、处理状态。标准流程是“人先把界面想清楚，再让人告诉机器怎么做”。

这个流程的核心瓶颈不是打字速度，而是“翻译损耗”。设计稿里一个按钮的圆角、阴影、间距，到了代码里要变成一个又一个 CSS 属性；产品经理口中的“用户下单后要能看到订单状态流转”，到了代码里要变成状态机、路由、组件树和接口调用。每一层翻译都可能失真，每一次改动都可能要重新同步。

Runway 提出的“界面世界模型”，方向是把“翻译损耗”抹掉：你不再用手一条一条写命令，而是用自然语言描述“我要一个什么样子的界面，能做什么操作”，模型直接生成整个可交互的界面。

用一句话概括：它改变了 UI 的“原材料”。过去原材料是代码，现在原材料变成了意图和描述。

这件事对开发者的影响是结构性的。过去我们说“你会写代码”，其实是“你能把设计意图转译成机器能执行的指令”。当模型能直接完成转译时，前端工程师的核心竞争力就必须从“转译能力”转向“判断和校验能力”。

1.1 一个容易混淆的概念：它不是“AI 帮你生成一个网页”

很多朋友会把“界面世界模型”理解为“AI 写了一个网页”，然后用它和 Cursor、Copilot 之类的代码生成工具对比。这个类比是不准确的，或者说层次不对。

代码生成工具（比如 Cursor）做的事情是：你和 AI 共享一套代码库，你给它一个任务描述，它在现有工程上下文里生成或修改代码。它本质上还是“代码导向”的工具，最终输出物是源代码，运行在构建系统上。

而从 Runway 展示的方向来看，“界面世界模型”更接近“运行时生成”：模型本身就像一个小的“世界模拟器”，它理解界面上的每一个元素（按钮、输入框、列表、弹窗）在交互中会如何变化。它不是先写了 HTML/CSS/JS 再让你跑，而是直接从需求生成“一个可运行的界面状态”。

这就像 RPG 游戏里的场景生成：过去我们是用地图编辑器逐块搭建，而“世界模型”是模型自己知道“山洞里应该有怪物、宝箱和出口”，然后基于这个理解动态生成场景。

当然，在技术落地层面，它最终还是会输出代码或中间表示，以便接入现有工程。但从产品理念上，两者已经分道扬镳。

2. 界面世界模型：从“生成布局”到“理解交互”

要理解 Runway 这次发布的“界面世界模型”到底强在哪里，我们需要先回顾一下“文本生成 UI”这个赛道的前两代产品。

第一代可以叫“布局生成器”。你输入“帮我做一个登录页”，模型输出一张静态的 UI 设计图，或者一段 HTML。它只是把常见的登录页元素（输入框、按钮、忘记密码链接）拼在一起，并没有真正理解“用户点击按钮之后会发生什么”。

第二代可以叫“组件生成器”。比如一些低代码平台的 AI 助手，它能根据需求生成组件树和样式代码，会写 React 组件，会调用 Mock 数据。但它的边界非常明显：一旦遇到复杂状态流转、多角色权限、动态数据联动，模型就开始“胡编”。因为它生成的是静态结构，而不是“可交互的逻辑”。

Runway 提出的“界面世界模型”，我认为它真正的增量在于：它试图让模型学习“界面变化”的规律。

这句话怎么理解？我们看看一个界面背后到底有什么规律：

• 按钮有点击态、悬停态、禁用态；
• 表单有校验态、提交中、提交成功/失败；
• 列表有加载中、空数据、有数据、加载失败；
• 弹窗有打开、关闭、遮罩点击、动画播放中；
• 多选框选中后，关联的提交按钮才会可点。

这些规律，在过去是靠前端工程师一行一行代码“声明”出来的。状态多的时候，组件复杂度指数级上升。而一个真正能“理解界面世界”的模型，应该不需要你告诉它“表单校验失败要显示红字提示”，它应该从大量界面数据中自己学到这个交互规律。

这是一个非常关键的技术方向：它不是在学“代码怎么写”，而是在学“界面如何运作”。

2.1 为什么叫“世界模型”

“世界模型”这个词来自强化学习和机器人领域，指的是模型对环境的内部模拟能力：不是对当前这一刻的感知，而是对“如果我做一个动作，环境会如何响应”的预测能力。

把这个概念搬到 UI 上，就意味着模型不仅仅生成当前界面，而是能预测“用户下一步操作后，界面会变成什么样”。这就是“交互能力”的来源。

从技术形态上看，它可能结合了多模态大模型、时序建模和界面结构理解。输入是多模态的一段自然语言描述和产品需求，输出是“界面状态 + 状态转移规则”。前端拿到这些信息后，再渲染成具体组件和代码。

当然，要严谨地说：到目前为止，公开材料里关于 Runway 这个“界面世界模型”的技术实现细节仍然非常有限。我们看到的更多是产品演示和方向性介绍。但这并不妨碍我们理解它背后的技术趋势，也不妨碍我们提前做技术准备。

2.2 它和传统 UI 开发的核心区别

用一个表格来对比，会更清晰：

看完这张表你应该能感觉到，这不是简单的“效率提升”，这是“分层逻辑”在改变。传统 UI 开发是“人写代码、代码控制界面状态”；新范式是“人写意图、模型理解界面状态”。

所以真正受冲击的不是“会写 CSS 的人”，而是“只写代码、不理解业务意图的人”。

3. 从“手写 UI”到“定义 UI”：开发者的角色要变了

这时候，很多前端朋友已经开始焦虑：那我以后算什么？算验收员？算测试员？

我觉得更准确的描述是：你会变成“界面体验定义者”。

当模型能自动生成 UI 时，谁能定义“什么是好的 UI”？谁能判断“这个交互是否符合业务逻辑”？谁能告诉模型“这里缺了一个空状态提示”？谁能设计“什么情况下按钮应该禁用”的规则边界？

答案是：懂业务、懂设计原则、懂用户心理、懂工程约束的人。

这不是在安慰前端同行。我举一个现实的例子：如果你让 Chat-GPT 写一个“商品列表页”，它会很轻松写出一个漂亮的网格布局，每个商品有图片、标题、价格。但你把它放到真实电商系统里，它大概率不会自动处理“库存为 0 的商品置灰”“过期活动标签自动隐藏”“不同用户角色看到不同价格”这些业务规则。

而这些业务规则，恰恰是“界面世界模型”最需要人去定义的部分。模型知道“界面一般长什么样”，但它不知道“你的业务为什么长成这样”。

所以未来前端开发者最需要练的，不是“手写 flex 布局”，而是：

1. 拆解交互状态的能力：一个页面上到底有多少种状态？状态之间如何流转？
2. 定义生成约束的能力：哪些地方可以自由发挥，哪些地方必须严格遵循品牌规范和业务规则？
3. 验证和回归的能力：模型生成的界面，如何验证它对不同输入的响应是正确的？
4. 与 AI 协作的能力：怎么用自然语言清晰描述界面需求？怎么迭代式地优化生成结果？

我在后面会展开讲这些能力对应的具体实践。这里先记住一个判断：能被明确写出来的 UI 规则，正在变成 AI 的默认能力；不能被明确写出来的业务判断，才是你的护城河。

4. 环境准备与上手路径：没有官方 SDK，先用这些思路跑通

很多读者会问：那我怎么体验 Runway 的“界面世界模型”？现在能下载吗？

从目前公开的信息看，Runway 的这次发布更偏向技术前瞻和产品方向展示，还没有像传统产品那样开放完整的 SDK 文档和开发者工具。所以如果你今天就想“拿来即用”，大概率是跑不通的。

但我们就什么都做不了吗？不是。我们可以把“界面世界模型”背后的核心能力拆出来，用现有工具链模仿它的工作流，提前积累经验。这里我给一个务实的建议：

• 想要体验“自然语言描述直接生成 UI”？可以先用 v0、Figma AI、甚至 Cursor 配合 Claude/GPT 做简化版；
• 想要体验“让模型理解交互状态”？可以用 Playwright 写 UI 自动化用例，把“某个状态下界面应该长什么样”用代码描述出来；
• 想要体验“AI 生成组件 + 人工校对交互逻辑”？可以尝试用 Claude/GPT 生成 React 组件，然后用 Storybook 做交互冒烟测试。

这样的“降级复现”，能让你在官方正式 API 开放之前，就先建立对这个新范式的体感。

以下是环境准备层面的建议，这部分你只要跟着做，就能搭起一套“文本生成 UI + 自动化验证”的最小实验环境。

4.1 环境准备清单

我建议的操作系统是 macOS 或 Linux，Windows 用户建议使用 WSL2。JavaScript 运行时需要 Node.js 18 或更新版本，包管理器用 npm 或 pnpm 都可以，Python 环境建议 3.10 以上，因为很多 UI 生成的工具链会用到 Python 脚本。

我不在这里写死版本号，因为这类轮子更新速度太快，以官方 docs 为准才是正确姿势。核心原则是：能跑通官方 example 的版本，就是最适合你的版本。

项目初始化我建议采用 Vite + React + TypeScript 的组合，组件库可以用 shadcn/ui 或 Ant Design，它们的组件语义化程度高，AI 生成代码时更容易猜对意图。

# 创建一个 React + TS 项目 npm create vite@latest ui-world-demo -- --template react-ts # 进入项目并安装依赖 cd ui-world-demo npm install

4.2 让 AI 直接生成一个复杂表单组件

我先演示一个最贴近“界面世界模型”的玩法：让 AI 直接生成一个“多步骤注册表单”。这个表单包含三页信息填写、校验规则、进度条、异步提交按钮状态。

把它拆成 Prompt，写得越具体，生成结果越接近“真实可交互的界面”：

请生成一个 React 多步骤注册表单组件。 要求： 1. 一共三步：账号信息（用户名、邮箱、密码）、个人资料（姓名、手机号、行业）、完成页。 2. 每一步都有前端校验，校验失败时在输入框下方显示红色错误提示。 3. 顶部有一个进度条，当前步骤高亮显示。 4. 只有校验通过后才能点击“下一步”按钮。 5. 第三步提交按钮点击后变为 loading 状态，2 秒后模拟提交成功。 6. 组件文件用 TypeScript 编写，只用函数组件和 hooks。

这里真正关键的是第 2、4、5 条。这三条涉及“界面状态”的变化，而不是单纯的“布局”。

4.3 人机协作：用代码约束 AI 的生成边界

AI 生成代码通常“看起来很美”，但一跑就报错。我的经验是：不要让它一次性生成一个大组件，而是先定好接口类型，让它在类型约束下填充实现。

先定义“世界模型”的规则层，也就是组件 props 的边界：

// 文件路径：src/types/registerForm.types.ts export interface RegisterFormData { username: string; email: string; password: string; name: string; phone: string; industry: string; } export interface RegisterFormErrors { username?: string; email?: string; password?: string; name?: string; phone?: string; industry?: string; } export interface StepProps { data: Partial<RegisterFormData>; errors: RegisterFormErrors; onChange: (field: keyof RegisterFormData, value: string) => void; onNext?: () => void; onPrev?: () => void; }

然后你再把这份类型定义交给 AI，告诉它“按照这个接口实现组件”。这样它就很难自由发挥、偏离业务约束。这一步很关键，它模拟的就是未来“人定义规则、AI 生成实现”的协作范式。

5. 核心流程拆解：从自然语言到可验证的 UI

了解了“人机协作”的基本姿势后，我们展开讲讲，从自然语言需求到最终可验证 UI 的完整流程，应该怎么拆。

如果你把“界面世界模型”当作一个黑盒，它的输入是需求描述，输出是交互界面。但我们自己要跑通这条链路，至少需要四个环节。

5.1 需求描述：把“模糊想法”拆成“可验证的状态”

这是最容易被忽略的一步。很多人给 AI 的描述是“做一个登录页”，这太模糊了。登录页有太多种写法：有验证码的吗？有第三方登录吗？密码错误提示是 Toast 还是行内错误？登录按钮 loading 时有防重复提交吗？

我的建议是，在写 Prompt 之前，先用五分钟画一张“状态表”：

这张表就是未来“界面世界模型”最需要人类提供的“规则燃料”。它比单纯几张设计图更有价值，因为设计图只表达“静止状态”，而状态表表达的是“界面如何根据现实变化”。

5.2 生成实现：让 AI 在约束下产出组件

把 5.1 的状态表，加上 4.3 的类型定义，一起交给 AI。让它先画一个组件树，再逐层实现。

这里我们用一个实际例子演示。假设让 AI 生成一个登录组件，你可以把状态表写进 Prompt：

请根据以下状态表，生成一个 React 登录组件。 状态表： - 初始状态：两个输入框（用户名/密码）和一个登录按钮，按钮可点。 - 校验失败：点击登录时如果字段为空，对应输入框下方出现红色提示。 - 提交中：字段合法时点击按钮，按钮进入 loading 状态，并禁用重复点击。 - 登录失败：模拟接口返回错误码 401，表单上方显示红底白字的错误条。 - 登录成功：2 秒后跳转到 /dashboard，并用 console.log 打印用户信息。 组件规格： - 使用 TypeScript，React 函数组件 + hooks。 - 不要使用 UI 组件库，全部用原生元素并加上内联样式。

这样生成出来的组件，已经不只是“布局正确”，而是“行为可预期”。你可以把它当成一个高保真原型，后续再逐步替换成真实样式和接口。

5.3 自动化验证：让“界面状态”可回归

AI 生成的 UI，最大的问题不是第一眼不好看，而是改了几轮之后，你无法确定它是否还能正确处理边界情况。这时候就需要引入 UI 自动化测试。

用 Playwright 写三个核心用例，覆盖“校验失败”“提交中”“登录成功”三种状态：

// 文件路径：tests/login.spec.ts import { test, expect } from '@playwright/test'; test.describe('Login Form State Test', () => { test.beforeEach(async ({ page }) => { await page.goto('http://localhost:5173/login'); }); test('点击登录但字段为空时，显示校验错误', async ({ page }) => { await page.getByRole('button', { name: '登录' }).click(); await expect(page.locator('text=请输入用户名')).toBeVisible(); await expect(page.locator('text=请输入密码')).toBeVisible(); }); test('输入合法信息后点击登录，按钮进入 loading 且不可重复点击', async ({ page }) => { await page.getByPlaceholder('用户名').fill('admin'); await page.getByPlaceholder('密码').fill('123456'); await page.getByRole('button', { name: '登录' }).click(); await expect(page.getByRole('button', { name: '登录' })).toBeDisabled(); }); test('模拟登录成功后跳转到 /dashboard', async ({ page }) => { await page.getByPlaceholder('用户名').fill('admin'); await page.getByPlaceholder('密码').fill('123456'); await page.getByRole('button', { name: '登录' }).click(); await page.waitForURL('**/dashboard'); }); });

这三个用例，其实就是把上面“状态表”里的规则，用代码固化下来。未来不管 UI 是人写的还是 AI 生成的，只要这些用例还在绿，交互逻辑就不会跑偏。

5.4 人机校验：接受还是返工

自动化测试通过，并不代表界面能上线。你还需要从这几条标准去人工复核：文案是否清晰？操作路径是否顺畅？加载状态是否遮挡了关键信息？错误提示是否覆盖了所有分支？

如果发现需要返工，不要直接说“重新生成一个”，这样会让 AI 推翻之前的正确部分。更高效的方式是带着上下文提修改需求，例如“保持现在的结构，把登录失败的错误提示从顶部 Banner 移到密码输入框下方”。

这其实是未来前端工程师的核心日常：你不再“面向代码编程”，而是“面向描述编程”——描述越精确，返工越少。

6. 完整示例与代码实现：跑通一个最小可交互界面

这一节，我们直接动手实现一个“AI 生成的 + 自动化验证的”最小可交互界面，完整跑通上面说的流程。

6.1 项目结构与依赖

项目结构尽量保持简单，我们只需要几个文件：

ui-world-demo/ ├── src/ │ ├── components/ │ │ └── LoginForm.tsx │ ├── types/ │ │ └── login.types.ts │ ├── pages/ │ │ └── LoginPage.tsx │ └── App.tsx ├── tests/ │ └── login.spec.ts ├── package.json └── playwright.config.ts

安装依赖时，我们除了基础框架外，还要额外安装 Playwright 测试库：

npm install @playwright/test npx playwright install chromium

6.2 类型定义：先定契约，再让 AI 填充实现

这一步非常推荐，它能极大避免 AI 生成过程中出现的类型不一致问题。我们先定义登录场景的类型：

// 文件路径：src/types/login.types.ts export type LoginStatus = 'idle' | 'submitting' | 'success' | 'error'; export interface LoginFormData { username: string; password: string; } export interface LoginFormErrors { username?: string; password?: string; } export interface LoginFormProps { initialValues?: Partial<LoginFormData>; onSubmit: (data: LoginFormData) => Promise<{ success: boolean; message?: string }>; }

这里设计的onSubmit是一个返回 Promise 的函数，这样组件内部只关心“界面状态”，不需要关心接口怎么调用。这个边界设计，正是“界面世界模型”和业务逻辑解耦的关键。

6.3 AI 生成的登录组件：注意这里的关键逻辑

下面是我的一个参照实现。你可以把它当作文档，也可以把它喂给 AI 作为示例：

// 文件路径：src/components/LoginForm.tsx import { useState } from 'react'; import type { LoginFormData, LoginFormErrors, LoginFormProps, LoginStatus, } from '../types/login.types'; export const LoginForm = ({ initialValues, onSubmit }: LoginFormProps) => { const [formData, setFormData] = useState<LoginFormData>({ username: initialValues?.username || '', password: initialValues?.password || '', }); const [errors, setErrors] = useState<LoginFormErrors>({}); const [status, setStatus] = useState<LoginStatus>('idle'); const [serverMessage, setServerMessage] = useState(''); const validate = (): boolean => { const nextErrors: LoginFormErrors = {}; if (!formData.username.trim()) { nextErrors.username = '请输入用户名'; } if (!formData.password.trim()) { nextErrors.password = '请输入密码'; } if (!formData.password || formData.password.length < 6) { nextErrors.password = '密码至少 6 位'; } setErrors(nextErrors); return Object.keys(nextErrors).length === 0; }; const handleChange = (field: keyof LoginFormData, value: string) => { setFormData((prev) => ({ ...prev, [field]: value })); if (errors[field]) { setErrors((prev) => ({ ...prev, [field]: undefined })); } }; const handleSubmit = async () => { if (status === 'submitting') return; if (!validate()) return; setStatus('submitting'); setServerMessage(''); const result = await onSubmit(formData); if (result.success) { setStatus('success'); window.location.href = '/dashboard'; } else { setStatus('error'); setServerMessage(result.message || '登录失败，请稍后重试'); } }; return ( <div style={{ maxWidth: 400, margin: '0 auto', padding: 24 }}> <h2>登录</h2> {serverMessage && ( <div style={{ background: '#ffecec', color: '#b91c1c', padding: '8px 12px', borderRadius: 6, marginBottom: 16, }} > {serverMessage} </div> )} <div style={{ marginBottom: 16 }}> <label>用户名</label> <input type="text" placeholder="用户名" value={formData.username} onChange={(e) => handleChange('username', e.target.value)} style={{ width: '100%', padding: '8px 12px', borderRadius: 6, border: errors.username ? '1px solid #ef4444' : '1px solid #d1d5db', }} /> {errors.username && ( <div style={{ color: '#ef4444', fontSize: 13, marginTop: 4 }}>{errors.username}</div> )} </div> <div style={{ marginBottom: 16 }}> <label>密码</label> <input type="password" placeholder="密码" value={formData.password} onChange={(e) => handleChange('password', e.target.value)} style={{ width: '100%', padding: '8px 12px', borderRadius: 6, border: errors.password ? '1px solid #ef4444' : '1px solid #d1d5db', }} /> {errors.password && ( <div style={{ color: '#ef4444', fontSize: 13, marginTop: 4 }}>{errors.password}</div> )} </div> <button onClick={handleSubmit} disabled={status === 'submitting'} style={{ width: '100%', padding: '10px 0', borderRadius: 6, background: status === 'submitting' ? '#93c5fd' : '#2563eb', color: '#fff', border: 'none', cursor: status === 'submitting' ? 'not-allowed' : 'pointer', }} > {status === 'submitting' ? '登录中...' : '登录'} </button> </div> ); };

这里最值得注意的，不是样式，而是两处“状态保护”：

1. if (status === 'submitting') return;这行代码防止重复提交，这是真实项目里非常容易出现 bug 的地方；
2. 输入框边框颜色根据错误信息动态变化，把“错误状态”视觉化，这是 UI 自动化测试很难覆盖但用户感知最强的一层。

6.4 页面接入：用 Mock 模拟接口

为了让组件能跑起来，我们还需要一个页面文件，把真实的接口调用用 Mock 替代：

// 文件路径：src/pages/LoginPage.tsx import { LoginForm } from '../components/LoginForm'; import type { LoginFormData } from '../types/login.types'; const mockLoginRequest = (data: LoginFormData) => { return new Promise<{ success: boolean; message?: string }>((resolve) => { setTimeout(() => { if (data.username === 'admin' && data.password === '123456') { resolve({ success: true }); } else { resolve({ success: false, message: '用户名或密码错误' }); } }, 2000); }); }; export const LoginPage = () => { return ( <div> <LoginForm onSubmit={async (data) => { const result = await mockLoginRequest(data); return result; }} /> </div> ); };

然后把App.tsx改造成直接渲染 LoginPage：

// 文件路径：src/App.tsx import { LoginPage } from './pages/LoginPage'; function App() { return <LoginPage />; } export default App;

启动项目：

npm run dev

浏览器访问http://localhost:5173/login，就能看到完整的登录界面。

7. 运行结果与效果验证

代码跑起来只是一半，另一半是验证行为是否符合预期。

7.1 手动验证路径

按下面的路径走一遍，每一步都要确认界面反馈正确：

1. 不输入任何内容，直接点击“登录”，确认用户名和密码下方出现红色错误提示；
2. 输入用户名admin，密码123，点击登录，确认密码下方提示“密码至少 6 位”；
3. 输入正确账号密码，点击登录，确认按钮变成“登录中...”且不可点击；
4. 等待 2 秒，确认页面跳转到/dashboard；
5. 改输入错误密码，确认顶部出现“用户名或密码错误”的红底错误条。

如果你的界面在这几步中都表现正确，说明组件逻辑完整。

7.2 自动化验证路径

运行 Playwright 测试：

npx playwright test tests/login.spec.ts

预期结果是 3 个测试全部通过。如果某个用例失败，先看标准的失败排查路径：

这里要特别提醒一个点：如果你发现 Playwright 运行时无法定位元素，大概率不是代码写错，而是你的页面渲染位置不对，比如window.location.href = '/dashboard'这一行在测试环境里会导致页面刷新，测试上下文被重置。更稳妥的做法是把跳转逻辑通过 props 传入，测试时用vi.fn()mock 掉，源码里不直接操作window.location。

8. 常见问题与排查思路

上面我们只是跑通了登录页这个简单场景。当你真的开始把“界面世界模型”的思路用到复杂项目中时，大概率会遇到下面这几类问题，我提前列成表格，方便你遇到时直接对照。

这些不是“未来问题”，而是你今天就可能在 AI 辅助编程中遇到的问题。它们的共性只有一个：AI 擅长生成“局部正确”，但很不会全局管理状态。状态管理能力，是人在未来 AI 协作中为数不多依然有极高价值的能力。

9. 最佳实践与工程建议

下面这五条建议，不是空泛的口号，都是我结合现有技术实践和趋势判断提炼出来的，值得认真对待。

9.1 把 UI 行为建模成“状态集合”

不要再用“页面”作为组织单位来思考 UI，改成用“状态”来组织。一个登录页不是一张图，而是初始态、校验失败态、提交中态、成功态、失败态这五个状态的集合。

当你能把一个界面拆成状态集合，你就等于给了 AI 一份非常精确的“界面世界说明书”。AI 再也不需要“猜”你想要什么了。

9.2 用类型定义约束 AI 的产出

AI 生成代码自由度很高，但工程需要的是确定性。在让 AI 动手之前，先把接口类型、props 边界、数据结构定义好。类型就是你和 AI 之间的“契约”，有了契约，AI 的产出才可预期。

这也是界面世界模型未来要解决的技术难点：模型生成的界面，如何保证它符合现有系统的类型约束和数据流规范。

9.3 把核心交互写成自动化测试

我见过太多团队用 AI 写了 UI，靠肉眼检查没问题就上线，结果一个隐藏 bug 能炸一晚上。程序员的底线是：人工可以偷懒，自动化测试不能。

不需要覆盖所有 UI 细节，但核心的交互状态流转（校验、提交、错误、成功、跳转）必须有自动化用例。这些用例将来就是你的“界面世界回归基线”。

9.4 保留人工校验，但要换一种方式

以后前端工程师不用逐行检查代码了，但需要校验“AI 生成的结果是否满足交互目标”。我推荐一个实践：每次让 AI 生成界面后，跑一遍 Playwright 用例，再人工过一遍五种用户场景，确认状态切换自然、文案易懂、边界不空白。

这个工作流，短期来看和现在差别不大，长期看会越来越高效。

9.5 建立自己的“Prompt 资产库”

不要让每个开发者各自和 AI 对话。一个好的团队，会沉淀一套符合自身业务规范的 Prompt 模板：状态表模板、类型定义模板、组件生成模板、测试生成模板、重构指令模板。

这些模板，将来就是团队的“数字化界面规范”。

10. 怎么看待 Runway 的“界面世界模型”这件事

写到这里，我们可以回到最初的那个判断了。

Runway 发布“界面世界模型”，从产品角度是一次大胆的方向性探索。它如果真的做成了，意味着 UI 开发的“原材料”从代码变成了意图，从“写状态”变成了“描述状态”。这对行业的影响，不亚于当年从 jQuery 时代进入 React 组件化时代。

但它目前的呈现，距离“替代开发者日常生产”还有不小的距离。真实项目里，对接接口、多租户权限、复杂业务规则、无障碍、国际化、性能优化、埋点上报，哪一个都不是单纯“生成一个漂亮界面”能解决的。

对普通开发者来说，最需要抓住的是这几点：

1. 你的核心价值将越来越向“业务理解、状态建模、质量验证”集中；
2. 你需要从现在开始锻炼“自然语言描述界面需求”的能力；
3. 你要学会把 UI 设计从“静态视觉”转向“状态化描述”；
4. 自动化测试不再只是质量保障手段，而是未来和 AI 协作时最可靠的回退保障。

与其焦虑“代码被干掉”，不如把这个趋势看作一次洗牌：重复性的切图和简单页面搭建会慢慢变廉价，但对界面行为的深刻理解、对复杂业务规则的建模能力，会越来越值钱。

如果你已经有几年前端经验，我建议你把目光从“怎么写一个好看的按钮”上移开，开始研究“怎么定义一套可被 AI 理解的状态描述体系”。这是下一阶段绕不开的基本功。

如果你还在学习阶段，我更建议你从今天开始练习这样一件事：拿到任何网页，先别急着打开 DevTools 看代码，而是先试着用一两句话，把这个页面的状态流转描述清楚。这个练习看起来简单，但它会让你比同龄人更早进入“界面世界模型”的思考方式。

下一次我再聊这个话题时，希望我们都能带着自己的项目实践回来，而不是停留在“转发新闻”的层面。