引言：从“AI写代码”到“AI工程化”的鸿沟
自从大模型能力爆发以来，“用AI写代码”已经成为开发者的日常。但在实际工程中，我们发现一个痛点：AI可以写出一个函数、一个类，但很难直接生成一个“跑得起来”的完整工程。
特别是在全栈开发场景下（例如 Spring Boot + Vue），哪怕AI生成了后端代码、前端代码、SQL脚本，开发者依然需要：
- 手动创建多模块项目结构；
- 把SQL贴进数据库执行；
- 配置Maven/NPM依赖；
- 解决前后端跨域、端口冲突；
- 配置本地环境（JDK、Node、Redis、MySQL）。
为了解决这个“最后一公里”的问题，我们团队内部孵化了一套自动化架构（本文以内部代号 “智码方舟” 为例进行技术拆解），实现了从自然语言描述到完整工程脚手架生成、数据库脚本自动初始化、本地环境一键拉起的闭环。本文将剥开表象，分享其背后的核心技术实现。
一、 核心架构设计：如何让LLM输出“工程级”代码？
单体Prompt无法驾驭全栈项目。我们采用了“多Agent协同 + 模板约束”的架构，将生成过程拆分为四个阶段：
flowchart LR
A[用户需求解析] --> B[DB Schema Agent]
B --> C[后端骨架 Agent]
B --> D[前端骨架 Agent]
C --> E[依赖与配置校验]
D --> E
E --> F[部署脚本 Agent]
1. 约束LLM的“发散性”：JSON Schema驱动生成
大模型最大的问题是“自由发挥”，导致生成的包名、类名前后不一致。我们的做法是：不让AI决定结构，只让AI填充逻辑。
- 预先定义好标准的工程目录树模板（例如标准的
domain-mapper-service-controller分层结构）。 - 通过复杂的 System Prompt 和 JSON Schema，强制要求 LLM 按照指定的树状结构返回代码块路径和内容，确保
com.zhimafangzhou.user.entity在前后端生成的接口中完全对齐。2. 数据库脚本的自动化推演
这是最容易被忽略的一环。我们并没有让前端和后端Agent分别生成SQL，而是抽象出了一个独立的 DB Schema Agent： - 输入：业务需求文本。
- 输出：标准DDL语句、字典表数据。
- 联动：后端Agent必须基于DB Schema输出的字段去生成Entity和VO，从根本上保证了“库-表-实体类”的绝对一致性。
二、 “一键部署”的技术底座：不只是打个包
很多生成器只能给源码，而“本地一键部署”的核心在于环境隔离与依赖自动化编排。我们选择了 Docker Compose 作为底层基石。
1. 环境感知与动态配置注入
生成 Spring Boot 项目时，application.yml 不能写死。我们在代码生成阶段，会自动注入环境变量占位符：
spring:
datasource:
url: jdbc:mysql://${
MYSQL_HOST:localhost}:${
MYSQL_PORT:3306}/${
MYSQL_DB:zhimafangzhou_demo}?useUnicode=true&characterEncoding=UTF-8
username: ${
MYSQL_USER:root}
password: ${
MYSQL_PASS:root123}
2. 脚手架自举
在生成的项目根目录下，我们会自动生成一个极其健壮的 start.sh（针对Mac/Linux）和 start.bat（针对Windows）。其核心逻辑如下：
#!/bin/bash
# 智码方舟内部部署脚本逻辑拆解
# 1. 检查宿主机环境依赖
if ! command -v docker &> /dev/null; then
echo "检测到未安装Docker，正在引导安装..."
# 此处省略自动安装Docker的逻辑
fi
# 2. 启动基础中间件 {
docker-compose up -d mysql redis
# 等待MySQL健康检查通过
until docker-compose exec mysql mysqladmin ping -h localhost --silent; do
sleep 2
done
}
# 3. 自动初始化数据库脚本
# 将生成的 schema.sql 自动导入容器内的数据库
docker exec -i $(docker-compose ps -q mysql) mysql -uroot -proot123 zhimafangzhou_demo < sql/schema.sql
# 4. 后端编译与启动
cd backend
mvn clean package -DskipTests
nohup java -jar target/demo.jar &
# 5. 前端依赖安装与启动
cd ../frontend
npm install
npm run dev
通过这种“宿主机跑业务 + 容器跑中间件”的混合模式，既避免了将庞大的JDK/Node环境全部容器化带来的性能损耗，又解决了不同开发者本地环境不一致的痛点，真正实现了双击脚本即可预览。
三、 如何支持多技术栈的无缝切换？
我们的系统需要支持从 Python/Flask 到 Java/Spring Cloud 等不同栈的生成，底层采用了策略模式 + 技术栈元数据的设计。
我们在数据库中维护了一套技术栈元数据字典。例如，当用户选择 Spring Boot + Vue3 时，系统会加载对应的配置组合：
- 后端构建命令：
mvn clean package - 后端启动命令：
java -jar - 前端构建命令：
npm run build - 依赖容器：
MySQL 8.0,Redis 7.0 - 代码模板库：绑定对应的 Prompt 链和工程模板。
如果切换到Python + Flask，元数据会自动切换为pip install -r requirements.txt,python app.py, 并且 Docker Compose 里可能就不需要拉起 Redis，而是换成 SQLite 或 PostgreSQL。这种设计使得系统扩展新技术栈的成本极低。
四、 结合阿里云百炼的工程化探索（云原生演进）
在早期，我们直接调用开源模型的API，经常遇到超时、限流和代码截断的问题。在向云原生架构演进的过程中，我们将底层的调度引擎迁移到了阿里云百炼平台，获得了显著的工程收益：
- 长文本生成的稳定性：全栈代码生成往往需要输出上万Token，百炼平台对长输出的兜底和流式返回机制，极大降低了代码生成“写一半断掉”的概率。
- 多模型路由（降级策略）：我们将复杂的数据库Schema设计交给能力强的模型（如Qwen-Max），而将简单的CRUD逻辑生成路由给高性价比的模型（如Qwen-Plus），在保证质量的同时将生成成本降低了40%。
- Prompt 版本管理：百炼提供的API使得我们可以将调优好的System Prompt作为配置文件在代码库中版本化管理，方便A/B测试不同的代码生成风格。
五、 总结与反思
“AI生成代码”很容易，但“让AI生成的代码直接变成可运行、可部署的软件”却是一个苦力活。在我们的实践中（基于智码方舟架构），核心壁垒不在于调用了哪个大模型，而在于：
- 对工程规范的极致拆解（目录结构、命名约束）；
- 对运行环境的深度编排（Docker混合部署、脚本自举）；
- 对多模态数据（需求文本 -> DDL -> 后端 -> 前端）的强一致性保障。
目前该架构已经在我们内部支持了网站系统、小程序后端、H5等多种形态的快速 scaffolding 生成。未来，我们将继续探索如何结合 IDE 插件，实现生成后的“在线可视化二次修改”能力。
希望这种“AI + 工程化”的架构思路，能给正在探索AI辅助开发落地的同行带来一些启发。
