组件和规则都有了，AI 为什么还是拼不好页面？

一位设计师同学找到我时，已经准备了 Figma 组件、组件规则和前端提供的工程包，也尝试建立一套让 AI 从需求走到页面生成的流程。

但真正开始生成页面后，结果依然不稳定：有的组件能够被调用，有的会被绕开；单个页面看起来完成了，组合起来却不理想。明明组件和规则都有了，AI 为什么还是拼不好页面？

01｜同学的问题

AI 已经可以在 Figma 或前端工程中查找组件，却不真正理解组件适合什么场景。它有时会调用错误，有时会重新手写，最后让页面结构和设计系统逐渐脱节。

组件说明和场景规则并不少，但文件彼此分散。AI 的上下文有限，不可能每次把所有资料完整读完，也不知道应该先读哪一份。

同学并不熟悉前端代码，也不敢直接修改公司的代码仓库。她能够发现页面效果有问题，却很难判断问题究竟来自组件、页面规则还是整个生成流程。

MD 文档可以告诉 AI 一个组件是什么、怎样使用，但它并不是可以直接执行的组件。缺少明确映射时，AI 即使读过规则，也可能继续手写页面或引用错误的工程组件。

按钮、表格和弹窗分别怎么用，属于组件层面的规则；列表页、详情页应该如何组织，属于页面层面的规则。只有底层组件，没有页面模板，AI 仍然不知道怎样把它们组合起来。

问题不在于 AI 没有读到组件，而在于它缺少一条从需求、页面模板、组件检索到工程实现的完整路径。现有资料需要先被组织起来，才能成为 AI 可以稳定使用的系统。

我们没有继续增加零散规则，而是先把 Figma 组件、MD 文档、前端工程和已有生成流程放在一起检查，看清楚已经有什么、彼此如何连接，以及还缺少什么。

组件需要一个可检索的目录，文档也需要清楚的入口；设计组件、使用规则和前端组件之间要建立映射。页面层面再补充常用模板与固定壳层，让 AI 知道应该怎样组合。

新的流程不要求 AI 一次读完全部资料，而是先理解需求，再检索页面模板和组件目录，按场景读取具体规则，调用真实工程组件，最后检查是否遵守约束。

如果所有地方都被限制为固定组件，页面会更加统一，但也可能失去必要的灵活性；如果完全允许 AI 自由生成，又容易让布局和交互失控。需要明确哪些内容必须复用，哪些允许组合和调整。

团队已经有自己的 Figma 设计系统、前端工程和组件库。这次要解决的是怎样让 AI 正确理解和使用它们，而不是为了 AI 更换整套技术方案。

过去页面生成错了，就继续补一条规则或修改一个组件。经过这次梳理，同学开始看到目录、映射、页面模板和执行流程之间的关系。

设计师不必先掌握所有前端知识。可以先让 Codex 盘点现有项目、提出缺失项，再逐步确认和补充，而不是直接进入公司的代码仓库盲目修改。

咨询后形成的 Execution Protocol，解决了 Codex 先读什么、后读什么、什么情况下继续查资料的问题。同样的方法也可以继续用于其他业务页面和设计系统项目。

AI 时代的设计系统，不只是整理好组件，也不只是多写几份规则文档。它还需要让 AI 知道去哪里查、什么时候读、怎样组合，以及最终应该调用哪一个真实的工程组件。

设计师不一定要先成为前端工程师，但需要开始把自己的设计资产，整理成一套 AI 能够检索、理解、执行和验证的系统。