8.0
热点
AI SCORE
编程提效2026-09-22 02:38
AI 生成 React UI 的真实问题：从第二页开始组件漂移
dev.to · AI#React#AI编程#工程实践
Editor brief · 编辑速览
AI 生成的首屏 UI 看似不错，但进入多页面后出现重复组件、间距值不一致、设计系统被破坏等问题，根源在于绿色项目无既有约束。
AI 生成 UI 在第一屏看起来相当可信。
要一个 SaaS dashboard，通常几分钟内就能得到一个还不错的东西：侧边栏、卡片、表格、表单、按钮。
但一旦你继续往下走，麻烦就来了。
到了第二或第三页，项目里已经有了值得复用的组件，而这时 AI 编程 agent 往往开始自创替代方案。
已经有一个 Button，却又冒出来一个。
已经有一个 Card，但新页面得到了一个略有不同的实现。
项目用了 spacing token，但 18px 的值突然出现在某个组件里。
过了几个页面，又出现了一个新的 modal 实现。
没有什么明显是坏的。应用仍然能跑，UI 看起来也可能完全没问题。
但代码库正在慢慢变成同一个 UI 系统的多个略有不同的版本。
在空项目中，AI UI 生成器的工作要容易得多。
没有现成的组件库需要理解，没有 design token 需要遵守，没有已建立的变体，也没有之前的设计决策需要顾及。
真实的 React 产品是不同的。
它可能已经有了可复用的 React 组件、props、变体、UI kit、语义 design token、主题、无障碍行为，以及随着时间积累的项目约定。
现在让 Claude Code、Codex 或其他 AI 编程 agent 来生成：
困难的部分不是为账单页面生成 JSX。
困难的部分是知道已经存在什么，以及如何将新页面融入其中。
如果项目已经有合适的 Button，就用它。
如果差不多但需要另一种变体，就扩展它。
如果已经有 Dialog，就用 Dialog 而不是在本地再建一个 modal。
如果语义 token 已经存在，就不要在旁边硬编码一个替代品。
写代码实际上不是问题。
理解代码所属的系统才是。
很多事情可以手工管理。
我写过很多这样的 prompt：
Check the existing components first. Reuse the current UI kit. Don't create duplicate components. Use semantic design tokens. Extend existing variants where possible.
但这样做了一段时间后，我意识到我在 prompt 里花了大量时间来维护设计系统。
我本来应该思考产品本身。
但我实际上在决定 agent 是否被允许创建另一个组件、它是否检查了当前的变体、以及它是否即将硬编码一个已经作为 token 存在的东西。
手工工作并没有消失。
它只是转移到了 prompt 里。
实际上，我的 prompt 应该专注于产品：构建 dashboard、添加 Projects、改进 Project Details、创建 onboarding、或者用视觉参考重新设计 Settings。
我不应该在每次停下来时还要决定 agent 是否需要复用组件、添加变体或扩展 token 系统。
这些应该发生在产品工作之下。
粗略的规则很简单：
reuse → extend → create → validate
如果已经存在，就复用它。
如果差不多，就扩展它。
只有当产品真正引入新的可复用模式时才创建新东西。
重要的一点是，我不想在每个 prompt 里手动强制执行这些规则。
新产品也有另一个版本的问题。
你可以在设计实际应用之前构建一个完整的设计系统，但你还不知道产品需要的所有模式。
或者你可以先生成二十个屏幕，然后再清理一切。
然后你就要决定五个相似的按钮中哪个应该成为真正的 Button、哪些 spacing 值应该变成 token、哪些重复模式应该归入 UI kit。
至少对我来说，更好的流程是让系统从产品中生长出来。
Dashboard 引入第一批可复用组件。
Projects 复用它们。
Project Details 需要另一个 Badge 状态，所以现有组件发生变化。
Settings 引入了新的重复模式，所以那个变成了可复用的。
Billing 需要另一个语义状态，所以 token 系统扩展。
经过几个页面后，你得到的不是一堆互不相关的 AI 生成屏幕。
你有一个 React 产品，其组件系统与产品共同演进。
我绝对想要可复用组件、可预测的变体和一致的 design token。
但这些是基础设施。
当我做产品时，我宁愿把时间花在决定用户看到什么、流程如何运作、需要哪些页面、以及产品如何表现。
设计系统应该支持那项工作。
它不应该成为每次 AI 生成页面时我都必须微观管理的第二个产品。
即使 AI 设计工具生成了一个很棒的界面，如果结果仍然是 canvas 或 mockup，我仍然需要把它转换成实际的 React 应用。
工作流程仍然大致是：
idea → design → mockup → handoff → React implementation → component cleanup → design system cleanup → business logic
AI 可以让这条管道更快，但它仍然是管道。
我更想这样工作：
describe the product → design directly in React → components, variants, tokens, and UI kit evolve with it → continue building the product
到了那时，就没有单独的"现在把设计转成 React"阶段了。
你已经在 React 实现中工作了。
这可能是我最在意的部分。
如果生产应用已经运行在 React 组件上，我真的不想让同一个 UI 系统在别处还有另一个表示。
真正的 Button 已经在代码库里了。
它的变体在那里。
真正的 design token 在那里。
真实的交互状态在那里。
产品使用的组件库在那里。
所以对我来说，让 AI 设计工作流直接在该系统上操作更有意义。
代码是唯一的真相来源。
这就是导致我构建 Varelyo 的问题。
我是它的开发者，所以这显然不是对这个工具的独立评测。它来自于我自己想要的工作流程。
我并不是要构建另一个比 Claude Code 或 Codex 更好地写 React 的模型。
那些工具写代码已经很强了。
我想要的是围绕它们的一个不同层：一个让我保持专注于产品的工具。
模型仍然写代码。
Varelyo 工具给了它产品上下文、现有 UI 系统的结构，以及组件、变体、token 和 UI kit 如何复用和扩展的规则。
所以不用再写：
Check the existing components. Don't create another Button. Use semantic tokens. Extend existing variants. Keep the UI kit consistent.
我应该能够写：
其余的属于 agent 周围的系统。
这并不意味着 agent 从不创建新东西。它意味着新东西应该被有意地创建，作为产品组件系统的一部分，而不是作为最新页面内的一次性 JSX。
在现有 React 代码库中，目标是理解并扩展已有的东西。
在新产品中，相同的系统可以逐渐出现。
Build a project management product with Dashboard, Projects, Task Details, Team, and Settings. Use this reference as the visual direction.
然后我可以逐页工作。
组件在产品真正需要时才出现。
变体随着新情况出现而改变。
Design token 在视觉语言变得更清晰时被引入。
每个新页面都有一些真实的东西可以构建。
我不需要在开始前完全定义设计系统，也不需要在之后从二十个生成的屏幕中反向工程出一个。
对我来说，React 的 AI 设计工具应该产出不仅仅是截图或互不关联的 JSX。
我想要实际属于一个连贯系统的 React 产品代码：
reusable React components consistent props and variants shared design tokens an evolving UI kit pages that build on the same component library
然后正常的开发继续。
APIs, state management, permissions, data fetching, business logic.
不应该有一个单独的阶段，让团队必须把 AI 设计转换成真正的 React 应用。
他们应该已经在其中工作了。
AI 已经可以做出一个看起来不错的 dashboard。
这部分已经不那么有趣了。
我不断回到的问题是：
第十页之后项目是什么样子？
Agent 是否仍在使用现有的 React 组件库？
它是在扩展组件而不是悄悄复制它们吗？
Design token 仍然一致吗？
UI kit 是否随产品演进了？
以及我是否能够继续思考产品本身，而不是监督它下面的设计系统？
这正是我试图用 Varelyo 解决的问题。
如果你在 Claude Code、Codex 或其他 AI 编程工具中遇到过同样的问题，我很想知道你是如何处理的。
你也可以看看 Varelyo 来了解这个方法的实际运作。