拖拽很方便，但为什么用户总是卡在“最后一行代码”？

一、开篇：一个困扰我很久的问题

在做零代码平台的这几年，我听到最多的一句话是：

“界面拖好了，但业务逻辑怎么配？”

用户可以用鼠标拖出一个漂亮的表单，但一遇到“如果订单金额大于1000且用户等级为VIP，则走特殊审批流”这种逻辑，就不得不找开发人员帮忙写脚本。

组件库越做越大，但用户反而更迷茫——“这么多组件，我该用哪个组合？”

模板库存了300多个模板，但用户还是要从头改起，因为“没有一个是完全匹配我的业务”。

这就是零代码平台的“最后一公里”之痛：可视化解决了80%的通用需求，但剩下的20%长尾逻辑，成了用户永远迈不过去的坎。

直到我开始思考一件事：能不能把AI塞进平台的每一层？

但在引入AI之前，我得先回答一个更基础的问题：组件到底该怎么分层？

二、组件分层：被忽视的架构基石

2.1 两种视角的冲突
在组件设计上，我遇到了一个经典矛盾：

开发视角：需要区分“内部组件”和“业务组件”。内部组件可以互相调用，业务组件只暴露给用户。

业务视角：用户只关心“这个组件能不能用”，不关心它是基础组件还是复合组件。

这个矛盾不解决，AI来了也无从下手——AI需要理解组件的层次和关系，才能做智能推荐和生成。

2.2 四层组件划分策略
经过几次重构，我最终确定了这样的分层：

// 1. 基础组件层 (Primitives) - 内部使用
export const BaseButton = defineComponent({
  name: 'BaseButton',
  // 包含所有技术细节，业务不可见
});

// 2. 复合组件层 (Composites) - 内部使用  
export const FormInput = defineComponent({
  name: 'FormInput',
  components: { BaseButton, BaseInput },
  // 组合基础组件，添加逻辑
});

// 3. 业务组件层 (Business) - 业务可见
export const UserProfileCard = defineComponent({
  name: 'UserProfileCard',
  components: { FormInput, Avatar },
  // 业务语义明确的组件
});

// 4. 模板层 (Templates) - 业务可见
export const DashboardLayout = defineComponent({
  name: 'DashboardLayout',
  // 完整的页面区块
});

2.3 调用约束：让架构可维护
光分层还不够，还得定规矩。我设计了这样的调用约束：

// 1. 原子组件：只依赖基础库，不调用任何组件
// ✅ 允许：import { axios } from 'axios'
// ❌ 禁止：import { BaseButton } from './BaseButton'

// 2. 组合组件：可调用原子组件 + 其他组合组件
// ✅ 允许：import { BaseButton, BaseInput } from '../primitives'
// ✅ 允许：import { AnotherComposite } from './AnotherComposite'
// ❌ 禁止：import { UserProfileCard } from '../../business'

// 3. 业务组件：可调用组合组件 + 原子组件
// ✅ 允许：import { FormInput } from '../../internal/composites'
// ✅ 允许：import { BaseButton } from '../../internal/primitives'
// ❌ 禁止：import { DashboardLayout } from '../../templates'

// 4. 场景模板：可调用业务组件 + 组合组件 + 原子组件
// ✅ 允许：import { UserProfileCard } from '../../business'
// ✅ 允许：import { FormInput } from '../../internal/composites'

这个约束的核心思想是：依赖方向必须从上到下，不能逆向或跨层调用。

三、组件可见性控制：让该看的看到，不该看的隐藏

3.1 目录结构

src/components/
├── internal/           # 内部组件
│   ├── primitives/    # 基础组件
│   │   ├── BaseButton/
│   │   ├── BaseInput/
│   │   └── index.ts
│   └── composites/    # 复合组件
│       ├── FormInput/
│       ├── ModalPanel/
│       └── index.ts
├── business/          # 业务组件
│   ├── UserProfileCard/
│   ├── DashboardLayout/
│   └── index.ts
├── templates/         # 页面模板
└── index.ts          # 主入口

3.2 注册与导出控制

// components/internal/index.ts - 内部组件
export const internalComponents = {
  BaseButton,
  FormInput,
  // ... 其他内部组件
};

// components/business/index.ts - 业务可见
export const businessComponents = {
  UserProfileCard,
  DashboardLayout,
  // ... 业务组件
};

// 主入口文件
export const ComponentLibrary = {
  // 业务可见组件
  ...businessComponents,
  
  // 内部组件通过别名提供高级用法
  advanced: {
    FormInput,
    BaseModal
  }
};

3.3 元数据驱动配置
为了让AI能理解组件，我加了一层元数据：

// component-meta.ts
export const componentMetadata = {
  UserProfileCard: {
    category: '业务组件',
    displayName: '用户信息卡片',
    description: '用于展示用户基本信息',
    allowedChildren: ['Avatar', 'ActionButton'],
    props: {
      title: { type: 'string', label: '标题' },
      size: { 
        type: 'select', 
        label: '尺寸',
        options: ['small', 'medium', 'large'],
        default: 'medium'
      }
    }
  },
  
  // 内部组件标记为隐藏
  BaseButton: {
    internal: true,
    category: '基础组件'
  }
};

四、用户视角：简单到不需要思考

做了这么多约束和控制，最终目的是让业务用户的使用体验足够简单：

<template>
  <!-- 业务人员只能看到这些 -->
  <UserProfileCard title="用户信息" />
  <DashboardLayout />
  
  <!-- 无法访问内部组件 -->
  <!-- <BaseButton> 不会出现在组件面板中 -->
</template>

<script setup>
// 自动导入业务组件
import { UserProfileCard, DashboardLayout } from '@your-library/components';
</script>

五、为AI铺路：四层架构如何让AI发挥作用

现在回到最初的问题：这个四层架构，跟AI有什么关系？

关系大了。每一层都为AI留下了明确的“介入点”：

换句话说：没有这个四层架构，AI来了也看不懂你的组件；有了这个架构，AI就知道该从哪里下手。

六、小结与预告

这篇文章我们聊了：

为什么组件分层是零代码平台的基石

四层架构的具体设计（原子/复合/业务/模板）

调用约束和可见性控制

元数据如何为AI铺路

下一篇预告：《零代码+AI实战手记（二）：原子层破局——让AI写Groovy脚本》

下一篇我们会深入实战：如何用DeepSeek在普通PC上部署一个能写Groovy的AI模型，以及50条数据微调就能见效的秘诀。
如需沟通:lita2lz