Faceflow 的设计初衷：为什么我们选择用“资源”来构建页面

在介绍 Faceflow 之前，我们常常会先澄清一件事：

Faceflow 并不是一个“把页面画出来”的工具。

它更像是一个帮助你创建和管理资源的系统，而页面，只是这些资源在某个时间点上的一种组合结果。

这一点，几乎决定了 Faceflow 和大多数可视化建站工具的根本差异。

从“页面优先”，到“资源优先”

在传统的建站或页面编辑工具中，页面通常是一切的起点。

你创建一个页面，在页面里添加模块、复制内容、调整布局。久而久之，每一个页面都变成了一个独立的个体，结构相似，却彼此割裂。

一旦需要修改某个通用内容、统一样式，或者调整数据结构，维护成本就会迅速上升。

Faceflow 的设计初衷，正是从这个问题出发：

如果页面只是“结果”，那真正应该被认真对待的，是什么？

我们的答案是：资源。

像搭积木一样构建页面

在 Faceflow 中，你并不是直接“画页面”，而是先创建可以被反复使用的资源。

这些资源包括：

• Variable：可复用的数据变量和内容片段，可以承载文本、结构，甚至是 PHP、HTML、CSS、JavaScript 代码
• Component：基于 Tailwind CSS 的组件模块，用于封装 UI 和功能逻辑，支持自定义字段和前端代码
• Layout：页面的结构骨架，用来定义整体布局以及全站通用的内容，例如头部、底部或 Cookie 声明
• Form：可视化创建的表单与验证规则，用于收集和管理用户数据

页面本身，并不是一个孤立的编辑对象，而是这些资源在特定路由和数据条件下的组合。

换句话说，页面是拼出来的，而不是堆出来的。

如果我不懂技术，也能用好 Faceflow 吗？

这是一个我们经常被问到的问题。

答案是肯定的，而且两种情况都会成立。

如果你并不熟悉前端或后端技术，也不需要从零开始理解所有细节。你可以通过官方的应用市场，直接获取已经构建好的资源：组件、布局、表单，甚至是完整的应用结构。

这些资源可以被直接导入和使用，你只需要根据自己的需求进行组合和调整，就可以完成页面和功能的搭建。

而如果你具备技术背景，那么 Faceflow 会呈现出完全不同的一面。

你可以自由编写和扩展变量、组件和布局，把可视化当作结构管理工具，而不是能力的边界。在这种情况下，Faceflow 不再是“简化工具”，而会逐渐变成你的主场。

我们并不要求所有人以同一种方式使用它。Faceflow 更像是一块足够开放的空间，让不同阶段、不同背景的用户，都能找到适合自己的进入方式。

页面只是组合，数据才是核心

Faceflow 中的 Page，并不是一个简单的“静态页面”。

它直接绑定到底层的数据对象，并与系统的多语言机制、自定义字段和数据结构保持一致。

这意味着：

• 页面可以天然支持多语言
• 内容和结构是分离的
• 同一套资源可以服务于不同页面形态

当业务发生变化时，你并不是在“改页面”，而是在调整资源的组合方式。

为什么要做到这么细？

Faceflow 的颗粒度，看起来可能比大多数可视化工具更细。

这是一个刻意的选择。

因为我们并不假设用户的需求是稳定的，也不假设一个项目只会停留在“展示页面”的阶段。

在真实场景中，很多项目：

• 一开始是内容页面
• 后来加入了表单和交互
• 再后来变成了完整的 Web 应用

如果工具的结构从一开始就是“页面驱动”的，那么在复杂度上升时，系统就会变得越来越难以维护。

Faceflow 选择从资源层开始，是为了让这种演进变得自然。

可视化，并不意味着失去控制

在 Faceflow 中，“可视化”并不等同于“封闭”。

每一种资源类型，都允许你直接使用 HTML、CSS、JavaScript，甚至是后端逻辑代码。

可视化的存在，是为了降低重复劳动，而不是限制表达方式。

你可以从简单的组合开始，也可以在需要的时候，深入到底层进行完全定制。

Faceflow 想解决的，从来不是“页面怎么画”

我们并不是想让页面创建这件事变得更花哨。

Faceflow 真正关注的是：

• 资源是否可以被复用
• 结构是否可以长期维护
• 系统是否能随着需求一起成长

当页面不再是唯一的中心，而只是资源的一种组合结果时，很多复杂问题，反而会变得简单。

这正是 Faceflow 的设计初衷。