AI 生成桌面端 React 应用实战：评审与上线前工程化避坑指南

很多 AI 生成的产品页面，第一眼看起来已经不错了，但我最近拿一个 AI 生成的产品页跑评审，点进详情就露馅：有的条目打不开，表单提交后也没提示。

这次我用 Paico 生成了一套 React 应用，前后十几分钟。左侧导航、列表、详情面板都齐了，点列表也能切换内容。我不注重某个页面好不好看，只是把它作为一份可继续开发的应用原型时，重点看看哪些部分已经成形，有哪些是需要前端和产品一起处理的。

一、我们要的 UI 到底是什么属性

如果交付物只有静态图，开发还得自己猜交互。我更想要能跑起来的 React 页面，哪怕粗糙，至少能把主流程点一遍。

这次生成的是一款艺术内容浏览应用，主导航、内容列表、详情面板和个人操作区都已经搭起来。桌面端空间比较宽，应用采用多栏布局，一边保留导航和列表，中间展示主要内容，另一边放详细信息。浏览时不用频繁跳转，能一边看内容一边查资料。

单独生成一张 UI 图，与生成一个能演示点击的应用，它们的差别主要是：

• 不同模块之间能不能顺利切换；
• 点击列表项后，详情是否显示对应内容；
• 收藏、标记等操作有没有反馈；
• 搜索、筛选和空状态考虑进去了没；
• 生成结果能不能继续交给前端修改。

这套应用能走通首页→列表→详情→收藏→个人页，拿来开评审会够用，但账户、权限、服务端存储都还没接。

二、AI生成桌面端 UI 做得怎么样

先来看这个应用的布局，AI 没有把所有信息塞进一个页面，它是按用户浏览时的注意力分配空间。导航一直留在侧边，列表方便切换内容，主要区域突出图片和文字，详情面板承接补充资料与操作按钮。这样的结构适合内容量较大的桌面应用，用户可以左边换条目，右边详情跟着变，不用反复进出详情页。

视觉层级也比较明确：图片是第一眼看到的内容，标题和关键信息紧跟其后，次要说明放在更靠后的位置。按钮基本跟着操作对象走，收藏、标记、查看大图不需要去全局导航里找。

不过，桌面端页面做得完整，也容易掩盖内容本身的问题。图片有没有对应标题，数量是否一致，日期和状态匹配等都要单独校对。尤其是内容展示类应用，错误的图片或过期信息会直接影响用户判断。AI 排版很快，但资料错得也隐蔽。比如同一幅画，列表里写 1890，详情里写 1889，它不会自己发现。

三、看交互不能只检查按钮能点

评审这类应用时，我会打开一个条目，收藏、再回收藏夹看它在不在。这样很容易发现页面截图里看不到的问题。比如多栏界面切换了左侧内容后，中间展示区和右侧详情区是否一起更新？收藏一项内容后，收藏夹里是否能找到它？筛选条件变化后，结果数量和列表内容是否对应？这些都是同一份数据在不同位置的表现。

本次 AI 生成的应用里提供了浏览、筛选、收藏、计划等交互入口，也准备了空状态和表单。这种能帮团队比较早地讨论完整流程，不用等开发写完才发现少了哪个状态。

入口有了，规则还没定。比如表单填错会怎样，内容被删后详情页显示什么，日期过期后按钮还能不能点，这些开发前得写清楚。原型阶段可以先演示主要路径，交付开发时就要把这些状态逐一补进需求。

四、AI 生成 React 代码要看哪些地方

页面预览是能说明交互效果，但不能单凭预览，来判断源码是否适合长期维护。拿到生成的 React 工程后，我会先看三个位置：页面组织、数据来源和状态更新。

1. 页面组织：不同模块是否拆成清楚的组件？列表项、详情面板、按钮、弹窗等重复区域有没有复用？如果整个应用都挤在一个大组件里，第一版能跑，后面改一个交互就容易牵动其他页面。
2. 数据来源：同一件内容出现在列表、详情和收藏夹中，最好通过稳定的 id 关联，而不是在几个组件里分别写一份标题和图片。数据分散时，页面看起来都对，修改一处资料后却可能出现不同版本。
3. 状态更新：以收藏为例，按钮状态和收藏夹应读取同一份收藏数据。概念上可以写成这样：

const [favoriteIds, setFavoriteIds] = useState<string[]>([]);

function toggleFavorite(id: string) {
  setFavoriteIds((current) =>
    current.includes(id)
      ? current.filter((itemId) => itemId !== id)
      : [...current, id]
  );
}

这个只是说明检查思路，不是本次 AI 生成工程的源码。真正接入项目时，还要决定收藏数据保存在哪里、失败时怎样回退、不同设备之间是否同步。而且路由也要看，浏览器地址能否对应具体模块或内容，刷新后能不能回到当前页面，会影响分享、返回和后续接入权限控制。预览里能完成页面切换，尚不足以证明这些工程细节已经处理妥当。

五、从可演示到可上线，中间还差什么

这次的生成结果比较适合做交互原型：界面完整、主要入口齐全，设计、产品和开发可以围着同一份应用讨论。它也能给前端提供一个起点，这样能省掉重新组织基础结构的时间。

现在大家的工作流节奏很快，很多独立开发者就用这样的 AI 工具迅速生成应用后，让 AI 继续处理代码达到上线准备。但在正式上线之前，我觉得至少还有几类工作要做：

• 内容数据要核对，图片、标题、描述、数量、时间和状态应来自可信的数据源，并且在不同页面保持一致。
• 用户数据要保存，收藏、偏好和个人计划如果只存在 React 内存里，刷新后就会消失；即使保存到浏览器本地，也要想清楚换设备和清理缓存后的处理方式。
• 操作结果要与服务端对齐，创建、修改、删除等动作不能只改前端画面，还要处理请求中、失败、重复提交和权限不足。

最后工程验证我会先缩窗口，看三栏会不会挤坏；再断网看图片失败有没有占位；最后才补主流程测试。桌面端应用不一定要按手机页面的方式设计，但窗口尺寸变化仍然是实际使用的一部分。

总结

当需求还比较模糊，但团队急着确认产品结构的时候，可以先用这类 AI 生成一套能点击的应用。导航该怎么分、详情放在哪里、一次操作之后用户去哪里，先让 AI 生成这样的应用雏形，比靠想象讨论更有效率。而且评审也可以用到，问题会更早暴露，修改成本也比较低。前端准备开发时，它可以提供页面与组件的初稿，但需要先检查代码结构和数据关系，再决定保留哪些部分。

就这次的桌面端应用而言，AI 已经能把一个内容型产品做成可浏览、可操作的 React 原型。先拿它开评审会，确认导航和详情位置，定下来后前端接手，把假数据换接口，再补登录和持久化。