AI 零代码应用生成项目 - 架构与设计面试题

一、架构与设计

1. 介绍 AI 零代码应用生成项目的后端整体架构，有哪些核心模块，它们之间是如何交互的？

整体架构概述

AI 零代码应用生成项目采用分层架构设计，主要包含以下核心模块：

核心模块

1. 控制层（Controller Layer）

   • AppController: 应用管理接口
   • WorkflowSseController: 工作流SSE流式输出接口
   • CodePreviewController: 代码预览接口
   • ChatHistoryController: 聊天历史管理
   • UserController: 用户管理

2. 服务层（Service Layer）

   • AiCodeGeneratorFacade: AI代码生成门面服务，统一入口
   • AiCodeGeneratorService: AI代码生成核心服务
   • AiCodeGenTypeRoutingService: 智能路由服务，自动选择生成类型
   • AppService: 应用业务服务
   • UserService: 用户业务服务

3. AI核心层（AI Core Layer）

   • AiCodeGeneratorServiceFactory: AI服务工厂，管理不同类型的生成器
   • ToolManager: 工具管理器，管理AI可调用的工具
   • 工具集合：FileWriteTool、FileReadTool、FileModifyTool等

4. 工作流引擎层（Workflow Engine Layer）

   • CodeGenWorkflow: 基础工作流
   • CodeGenConcurrentWorkflow: 并发工作流
   • CodeGenSubgraphWorkflow: 子图工作流
   • 节点集合：CodeGeneratorNode、ImageCollectorNode、QualityCheckNode等

5. 代码处理层（Code Processing Layer）

   • CodeParserExecutor: 代码解析执行器
   • CodeFileSaverExecutor: 代码保存执行器
   • StreamHandlerExecutor: 流处理执行器

6. 数据访问层（Data Access Layer）

   • AppMapper: 应用数据访问
   • UserMapper: 用户数据访问
   • ChatHistoryMapper: 聊天历史数据访问

模块交互流程

用户请求 → Controller → AiCodeGeneratorFacade → AiCodeGeneratorService → LangChain4j/LangGraph4j → 
AI模型 → 工具调用 → 代码生成 → 解析保存 → 返回结果

2. 项目支持多种 AI 代码生成模式，从架构层面是如何设计和隔离不同模式的生成逻辑的？

生成模式类型

项目支持三种主要生成模式：

• HTML: 单文件HTML应用生成
• MULTI_FILE: 多文件项目生成
• VUE_PROJECT: Vue项目生成（支持工具调用）

架构设计原则

1. 策略模式（Strategy Pattern）

   • 使用CodeGenTypeEnum枚举定义生成类型
   • AiCodeGeneratorFacade作为统一入口，根据类型路由到不同处理逻辑

2. 工厂模式（Factory Pattern）

   • AiCodeGeneratorServiceFactory根据应用ID和生成类型创建对应的服务实例
   • 支持不同模型配置和工具集合

3. 模板方法模式（Template Method Pattern）

   • 统一的流式处理框架：processCodeStream和processTokenStream
   • 不同类型使用相同的处理模板，但具体实现不同

隔离机制

// 在AiCodeGeneratorFacade中的类型路由
return switch (codeGenTypeEnum) {
    case HTML -> {
        Flux<String> codeStream = aiCodeGeneratorService.generateHtmlCodeStream(userMessage);
        yield processCodeStream(codeStream, CodeGenTypeEnum.HTML, appId, control);
    }
    case MULTI_FILE -> {
        Flux<String> codeStream = aiCodeGeneratorService.generateMultiFileCodeStream(userMessage);
        yield processCodeStream(codeStream, CodeGenTypeEnum.MULTI_FILE, appId, control);
    }
    case VUE_PROJECT -> {
        TokenStream codeTokenStream = aiCodeGeneratorService.generateVueProjectCodeStream(appId, userMessage);
        yield processTokenStream(codeTokenStream, appId, control);
    }
};

3. 描述一下 AI 代码生成工作流的核心节点，以及它们之间的数据流转？

核心节点

1. ImageCollectorNode: 图片收集节点

   • 功能：根据需求收集相关图片资源
   • 输入：用户原始需求
   • 输出：图片资源列表

2. PromptEnhancerNode: 提示词增强节点

   • 功能：优化和增强用户输入的提示词
   • 输入：原始提示词 + 图片资源
   • 输出：增强后的提示词

3. RouterNode: 路由节点

   • 功能：智能判断代码生成类型
   • 输入：增强提示词
   • 输出：生成类型（HTML/MULTI_FILE/VUE_PROJECT）

4. CodeGeneratorNode: 代码生成节点

   • 功能：根据类型生成对应代码
   • 输入：增强提示词 + 生成类型
   • 输出：生成的代码

5. CodeQualityCheckNode: 代码质检节点

   • 功能：检查生成代码的质量和完整性
   • 输入：生成的代码
   • 输出：质检结果

6. ProjectBuilderNode: 项目构建节点

   • 功能：构建可运行的项目（仅Vue项目）
   • 输入：代码文件
   • 输出：构建结果

数据流转

WorkflowContext: {
  originalPrompt: String,
  enhancedPrompt: String,
  generationType: CodeGenTypeEnum,
  imageResources: List<ImageResource>,
  generatedCode: String,
  qualityResult: QualityResult,
  buildResult: BuildResult
}

流转路径：

START → ImageCollector → PromptEnhancer → Router → CodeGenerator → 
QualityCheck → [质检通过] → ProjectBuilder → END
           ↑ [质检失败] ←─────────────┘

4. AI 零代码应用生成项目后期为什么引入 LangGraph4j 来构建 AI 工作流？和之前的方式相比，解决了什么问题？

引入LangGraph4j的原因

之前的问题：

1. 线性处理限制: 原有的流式处理只能按顺序执行，无法并发处理
2. 复杂逻辑难以管理: 条件分支和循环逻辑散落在代码各处
3. 状态管理困难: 工作流状态传递复杂，容易出错
4. 扩展性差: 添加新节点需要修改大量代码
5. 错误处理不统一: 各个环节的错误处理机制不一致

LangGraph4j的优势：

1. 图形化工作流

   // 清晰的图形化定义
   .addNode("image_collector", ImageCollectorNode.create())
   .addNode("prompt_enhancer", PromptEnhancerNode.create())
   .addEdge("image_collector", "prompt_enhancer")
   .addConditionalEdges("code_quality_check", this::routeAfterQualityCheck)
   

2. 并发执行能力

   // 并发图片收集
   .addEdge("image_plan", "content_image_collector")
   .addEdge("image_plan", "illustration_collector")
   .addEdge("image_plan", "diagram_collector")
   .addEdge("image_plan", "logo_collector")
   

3. 状态管理

   • 统一的WorkflowContext状态管理
   • 自动状态传递和更新
   • 状态版本控制和回滚

4. 条件路由

   private String routeAfterQualityCheck(MessagesState<String> state) {
       QualityResult qualityResult = context.getQualityResult();
       if (!qualityResult.getIsValid()) {
           return "fail";  // 重新生成
       }
       return "build";     // 继续构建
   }
   

5. 错误恢复机制

   • 自动重试机制
   • 优雅降级处理
   • 详细的错误追踪

5. AI 零代码应用生成项目中，微服务架构中主要有哪些模块？介绍每个模块的作用？

注意：当前项目采用单体架构，但可以按业务域划分为以下逻辑模块：

核心业务模块

1. 用户管理模块

   • 组件：UserController、UserService、UserMapper
   • 功能：用户注册、登录、权限管理
   • 数据：用户基本信息、角色权限

2. 应用管理模块

   • 组件：AppController、AppService、AppMapper
   • 功能：应用创建、编辑、部署、删除
   • 数据：应用元数据、配置信息

3. AI代码生成模块

   • 组件：AiCodeGeneratorFacade、AiCodeGeneratorService
   • 功能：智能代码生成、类型路由、流式输出
   • 依赖：LangChain4j、各种AI模型

4. 工作流引擎模块

   • 组件：CodeGenWorkflow、各种Node节点
   • 功能：复杂工作流编排、并发执行、状态管理
   • 依赖：LangGraph4j

5. 代码处理模块

   • 组件：CodeParser、CodeFileSaver、VueProjectBuilder
   • 功能：代码解析、文件保存、项目构建
   • 输出：可运行的项目文件

支撑服务模块

6. 聊天历史模块

   • 组件：ChatHistoryController、ChatHistoryService
   • 功能：对话记录、历史查询
   • 存储：Redis + MySQL

7. 文件管理模块

   • 组件：CosManager、StaticResourceController
   • 功能：文件上传、下载、预览
   • 存储：腾讯云COS

8. 监控模块

   • 组件：AiModelMetricsCollector、MonitorContext
   • 功能：性能监控、指标收集
   • 输出：Prometheus指标

微服务拆分建议

如果要拆分为微服务，建议按以下方式：

• 用户服务: 用户管理、认证授权
• 应用服务: 应用CRUD、元数据管理
• AI服务: 代码生成、模型调用
• 工作流服务: 复杂流程编排
• 文件服务: 文件存储、CDN
• 网关服务: 路由、限流、认证

6. 描述 AI 零代码应用生成项目前端的核心业务流程，以及如何实现？

核心业务流程

1. 应用创建流程

// 用户输入 → 创建应用 → 验证状态 → 跳转聊天
const createApp = async () => {
  // 1. 验证用户输入
  if (!userPrompt.value.trim()) return;
  
  // 2. 调用后端创建应用
  const res = await addApp({ initPrompt: userPrompt.value.trim() });
  
  // 3. 重试验证应用状态 
  const maxRetries = 5;
  for (let i = 0; i < maxRetries; i++) {
    const checkRes = await getAppVoById({ id: appId });
    if (checkRes.data.code === 0) {
      // 4. 跳转到聊天页面
      await router.push(`/app/chat/${appId}`);
      break;
    }
  }
}

2. 实时代码生成流程

// SSE连接 → 流式接收 → 实时渲染
const connectSSE = () => {
  const eventSource = new EventSource(`/api/workflow/sse/${appId}`);
  
  eventSource.onmessage = (event) => {
    const message = JSON.parse(event.data);
    // 根据消息类型处理
    switch (message.type) {
      case 'AI_RESPONSE':
        appendToChat(message.content);
        break;
      case 'TOOL_REQUEST':
        showToolExecution(message.tool);
        break;
      case 'TOOL_EXECUTED':
        updateToolResult(message.result);
        break;
    }
  };
};

技术实现

1. 前端技术栈

• 框架: Vue 3 + TypeScript
• 状态管理: Pinia
• 路由: Vue Router 4
• UI组件: Ant Design Vue
• 构建工具: Vite
• 代码高亮: highlight.js
• Markdown渲染: markdown-it

2. 关键实现

// 状态管理
const useLoginUserStore = defineStore('loginUser', {
  state: () => ({ loginUser: {} as API.LoginUserVO }),
  actions: {
    async fetchLoginUser() {
      const res = await getLoginUser();
      this.loginUser = res.data.data || {};
    }
  }
});

// API自动生成
// 使用openapi2ts自动生成TypeScript接口
"openapi2ts": "openapi2ts"

3. 响应式设计

/* 网格布局 */
.app-grid {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(320px, 1fr));
  gap: 24px;
}

/* 响应式断点 */
@media (max-width: 768px) {
  .app-grid { grid-template-columns: 1fr; }
}

7. 将项目从单体架构改造为微服务架构，有哪些优势？又存在哪些问题？

优势

1. 技术优势

• 独立部署: 每个服务可独立发布，降低部署风险
• 技术栈自由: 不同服务可选择最适合的技术栈
• 弹性扩展: 根据负载独立扩缩容
• 故障隔离: 单个服务故障不影响整体系统

2. 业务优势

• 团队自治: 不同团队负责不同服务，提高开发效率
• 业务边界清晰: 服务按业务域划分，职责明确
• 快速迭代: 小团队快速响应业务需求

3. 运维优势

• 监控细粒度: 每个服务独立监控
• 资源优化: 根据服务特点优化资源配置
• 容灾能力: 分布式部署提高可用性

存在的问题

1. 复杂性增加

# 服务数量激增
services:
  - user-service
  - app-service  
  - ai-service
  - workflow-service
  - file-service
  - gateway-service
  - config-service
  - registry-service

2. 分布式问题

• 网络延迟: 服务间调用增加网络开销
• 数据一致性: 分布式事务处理复杂
• 服务发现: 需要注册中心管理服务
• 配置管理: 配置分散难以统一管理

3. 运维成本

• 部署复杂: 需要容器化、编排工具
• 监控告警: 需要分布式链路追踪
• 日志聚合: 需要统一日志收集分析
• 测试困难: 集成测试环境搭建复杂

4. 开发成本

• 接口定义: 需要严格的API契约
• 版本兼容: 服务升级需考虑向后兼容
• 调试困难: 跨服务问题定位复杂
• 重复代码: 公共逻辑可能重复实现

8. 拆分微服务时有哪些核心原则？请结合你的项目说明。

核心原则

1. 单一职责原则（Single Responsibility Principle）

// 每个服务只负责一个业务域
UserService: 只处理用户相关业务
AppService: 只处理应用管理业务
AiService: 只处理AI代码生成业务

2. 业务边界清晰（Domain-Driven Design）

用户域: 用户注册、登录、权限管理
应用域: 应用创建、编辑、部署
AI域: 代码生成、模型调用、工具管理
工作流域: 流程编排、状态管理

3. 数据独立性

-- 每个服务拥有独立的数据库
user_db: users, roles, permissions
app_db: apps, app_configs
ai_db: generation_logs, model_configs
workflow_db: workflow_instances, node_states

4. 接口稳定性

// 使用版本化API
@RestController
@RequestMapping("/api/v1/users")
public class UserController {
    // 保持接口向后兼容
}

项目拆分实践

1. 按业务能力拆分

ai-code-mother项目拆分建议:

1. 用户服务 (user-service)
   - 功能: 用户管理、认证授权
   - 数据: users, roles, permissions
   - 依赖: Redis(session), MySQL

2. 应用服务 (app-service)  
   - 功能: 应用CRUD、元数据管理
   - 数据: apps, app_configs
   - 依赖: MySQL, COS(文件存储)

3. AI服务 (ai-service)
   - 功能: 代码生成、模型调用
   - 数据: generation_logs, model_metrics
   - 依赖: LangChain4j, 各种AI模型

4. 工作流服务 (workflow-service)
   - 功能: 复杂流程编排
   - 数据: workflow_instances, execution_logs  
   - 依赖: LangGraph4j, Redis

5. 文件服务 (file-service)
   - 功能: 文件上传、下载、预览
   - 数据: file_metadata
   - 依赖: COS, CDN

2. 服务间通信设计

// 同步调用 - 使用OpenFeign
@FeignClient("app-service")
public interface AppServiceClient {
    @GetMapping("/api/v1/apps/{id}")
    AppVO getApp(@PathVariable Long id);
}

// 异步通信 - 使用消息队列
@EventListener
public void handleAppCreated(AppCreatedEvent event) {
    // 异步处理应用创建后的初始化工作
}

3. 数据一致性保证

// 使用Saga模式处理分布式事务
@SagaOrchestrationStart
public void createAppWithAI(CreateAppRequest request) {
    // 1. 创建应用
    choreography.step("createApp")
        .invokeParticipant(AppService.class)
        .withCompensation(AppService.class, "deleteApp");
    
    // 2. 初始化AI配置  
    choreography.step("initAI")
        .invokeParticipant(AiService.class)
        .withCompensation(AiService.class, "cleanupAI");
}

4. 监控和治理

# 服务治理配置
spring:
  cloud:
    gateway:
      routes:
        - id: user-service
          uri: lb://user-service
          predicates:
            - Path=/api/v1/users/**
          filters:
            - name: RateLimiter
              args:
                redis-rate-limiter.replenishRate: 10

总结：
微服务拆分需要综合考虑业务复杂度、团队规模、技术能力等因素。对于AI零代码生成项目，建议采用渐进式拆分策略，先从边界清晰的模块开始，逐步演进到完整的微服务架构。