从零搭建AI驱动的自动化开发脚手架

🚀 从零搭建AI驱动的自动化开发脚手架：我的架构设计思想与实践

本文目的：分享一套可落地的架构设计思想，帮助你搭建切合自己业务系统的自动化开发脚手架。重要的不是技术栈，而是架构思想！

---

一、为什么需要自动化开发脚手架？

传统开发的痛点

1. 产品经理写需求文档 → 开发人工阅读理解
2. 设计师出UI稿 → 开发人工切图还原
3. 后端写接口文档 → 前端人工对接联调
4. QA写测试用例 → 开发人工执行修复
5. 部署上线 → 人工操作CI/CD

核心问题：

• ⏰ 重复劳动：每次迭代都要重复相同的流程
• 🐛 人为错误：理解偏差、遗漏细节、手误bug
• 📦 知识孤岛：经验难以沉淀，新人上手慢
• 🔄 协作成本：前后端联调、测试反馈循环往复

自动化开发的效果

指标	传统开发	自动化开发	提升
需求到上线时间	3-5天	4-8小时	70%↓
编码时间占比	40%	10%（AI生成）	75%↓
测试时间占比	30%	5%（自动化）	83%↓
Bug密度	中等	低（自动校验）	显著改善
知识沉淀	分散在代码中	结构化文档	可复用

---

二、核心架构思想

2.1 架构三要素

这套脚手架的核心是三个层次的抽象：

graph TD
    A[主Agent<br/>流程编排者] --> B[子Agent层<br/>功能专家]
    B --> C[能力层<br/>Skills/Rules/MCP]
    
    A1[需求分析] --> A
    A2[任务调度] --> A
    A3[结果验收] --> A
    
    B1[前端代码生成Agent] --> B
    B2[后端代码生成Agent] --> B
    B3[自动化测试Agent] --> B
    B4[部署发布Agent] --> B
    
    C1[Skills: 具体实现] --> C
    C2[Rules: 执行规则] --> C
    C3[MCP: 工具集成] --> C

关键洞察

类比：智能餐厅后厨

• 主厨（主Agent）：负责统筹全局，"先备菜、再炒菜、最后摆盘"，面向过程
• 专职厨师（子Agent）：切菜工、炒菜工、摆盘师，各司其职，面向对象
• 操作手册（Rules）：告诉厨师"番茄要切多大块"、"炒几分钟"
• 厨具设备（Skills）：切菜刀、炒锅、摆盘工具的具体实现
• 智能设备（MCP）：自动洗碗机、智能温控炉

核心原则：主Agent不需要知道"如何切菜"，子Agent不需要知道"什么时候切菜"，各司其职，关注点分离！

2.2 三大设计原则

原则1：主Agent面向过程，子Agent面向对象

主Agent的职责：流程编排

// 主Agent伪代码：只关心流程，不关心实现细节
async function requirementDevelopmentProcess() {
  // 阶段一：文档准备
  await prepareDocuments();
  
  // 阶段二：并行开发（前后端独立）
  await Promise.all([
    frontendAgent.generateCode(),  // 前端Agent负责前端
    backendAgent.generateCode()    // 后端Agent负责后端
  ]);
  
  // 阶段三：编译检查
  await waitForBuild();
  
  // 阶段四：测试与修复循环
  while (hasErrors()) {
    await runTests();
    await fixErrors();
  }
  
  // 阶段五：部署上线
  await deploy();
}

子Agent的职责：功能实现

// 前端代码生成Agent：只关心如何生成前端代码
class FrontendCodeAgent {
  async generateCode() {
    // 读取需求文档
    const requirement = await readRequirement();
    
    // 读取UI设计稿
    const uiDesign = await readFigma();

    // 读取企业知识库
    const knowledgeBase = await readKnowledgeBase();
    ...
    // 生成Vue/React代码
    const code = this.generateFrontendCode(requirement, uiDesign, knowledgeBase);
    
    // 写入文件
    await writeCode(code);
  }
}

为什么这样设计？

维度	好处
解耦合	主Agent不关心"如何写前端代码"，前端Agent不关心"什么时候测试"
可替换	前端Agent可以从Vue换成React，不影响主流程
可扩展	新增"移动端Agent"，只需在并行开发中加入一行代码

原则2：构建闭环自修复的Agent Loop

传统开发：线性流程，遇到问题就卡住

开发 → 测试 → 发现bug → 人工修复 → 再测试 → 再修复...（无限循环）

自动化开发：闭环自修复

┌─────────────────────────────────────────────────────────────┐
│                    闭环自修复流程                              │
└─────────────────────────────────────────────────────────────┘

阶段1: 文档准备
   │
   ↓
阶段2: 并行开发
   │
   ↓
阶段3: 编译检查 ────┐
   │               │
   ├─ 失败 ──→ 错误修复 ──┐
   │                      │
   ↓ 通过                 │ 重试循环
阶段4: 自动化测试 ────────┘
   │
   ├─ 失败 ──→ 错误修复 ──┐
   │                      │
   ↓ 通过                 │ 重试循环
阶段5: 部署上线  ←────────┘
   │
   ↓
✅ 完成

流程状态表：

当前阶段	检查结果	下一动作	说明
编译检查	❌ 失败	错误修复	语法错误、类型错误等
编译检查	✅ 通过	自动化测试	进入测试阶段
自动化测试	❌ 失败	错误修复	功能异常、接口错误等
自动化测试	✅ 通过	部署上线	所有测试用例通过
错误修复	修复完成	编译检查	返回阶段3重新检查

关键技术：

• 脚本化检查：通过编译脚本判断"前后端是否完成开发"
• 结构化错误：错误报告区分"前端错误"和"后端错误"
• 循环退出条件：当错误报告为空时，自动退出循环

原则3：通用框架 + 业务适配

不要试图做万能工具！

通用框架层：主Agent编排逻辑（可复用）
  ↓
业务适配层：
  ├── 前端代码生成Agent（根据你的技术栈：Vue/React/Angular）
  ├── 后端代码生成Agent（根据你的语言：Go/Java/Node.js）
  └── 自动化测试Agent（根据你的测试工具：Chrome DevTools/Puppeteer）

示例：

团队	前端Agent	后端Agent	测试Agent
团队A	Vue + Element Plus	Spring Boot	Playwright
团队B	React + Ant Design	Express.js	Puppeteer
团队C	Vue3 + Element Plus	Django	Cypress

---

三、如何搭建：核心的文件结构与示例

3.1 整体文件结构

your-project/
├── .codebuddy/                    # AI开发配置目录（核心）
│   ├── agents/                    # 子Agent配置
│   │   ├── frontend-code-gen.md   # 前端代码生成Agent
│   │   ├── backend-code-gen.md    # 后端代码生成Agent
│   │   └── test-agent.md          # 自动化测试Agent
│   │
│   ├── skills/                    # Skills：具体实现
│   │   ├── requirement-development/      # 需求开发 主Agent调用
│   │   │   ├── skill.md
│   │   │   └── scripts/
│   │   ├── interface-protocol-fetch/    # 接口协议获取
│   │   │   ├── skill.md
│   │   │   └── scripts/
│   │   ├── frontend-compiler/           # 前端编译检查
│   │   │   ├── skill.md
│   │   │   └── scripts/
│   │   │       └── compile-check.js
│   │   ├── auto-test-and-fix/           # 自动测试及纠错
│   │   │   ├── skill.md
│   │   │   └── scripts/
│   │   │       ├── run-test.js
│   │   │       └── fix-error.js
│   │   └── deploy/                      # 部署发布
│   │       └── skill.md
│   │
│   ├── rules/                     # Rules：执行规则
│   │   ├── development-guidelines.md     # 开发指导原则
│   │   ├── coding-standards.md           # 编码规范
│   │   ├── api-contract.md               # 接口契约
│   │   └── test-standards.md             # 测试标准
│   │
│   └── config/                    # 配置文件
│       ├── project-config.json     # 项目配置
│       └── mcp-servers.json        # MCP服务配置
│
├── docs/                          # 文档目录
│   ├── requirements/              # 需求文档
│   │   └── feature-xxx.md
│   ├── api/                       # 接口文档
│   │   ├── api-spec.md
│   │   └── field-check.json       # 接口字段校验
│   └── test-cases/                # 测试用例
│       └── test-case-xxx.md
│
├── .process/                      # 运行时状态（自动生成）
│   ├── frontend-errors.txt        # 前端错误报告
│   ├── backend-errors.txt         # 后端错误报告
│   └── test-result.md             # 测试结果
│
├── frontend/                      # 前端项目（你的代码）
│   └── src/
├── backend/                       # 后端项目（你的代码）
│   └── src/
│
└── MCP/                           # MCP服务（可选）
    ├── chrome-devtools-mcp/       # Chrome自动化测试
    └── figma-mcp/                 # Figma设计导入
│
└── Agent.md                       # 整个项目的核心信息 确保多轮次对话，核心逻辑不丢失

3.2 关键文件示例

主Agent配置示例：requirement-development/skill.md

# 主Agent：需求开发流程

## 角色
你是一个流程编排者，负责从需求导入到代码上线的整个流程。

## 职责
1. 调用文档准备Agent，生成细化的需求文档、接口文档、测试用例
2. 并行调度前端代码生成Agent和后端代码生成Agent
3. 执行编译检查，等待前后端开发完成
4. 调用自动化测试Agent，执行测试用例
5. 如果发现错误，调用错误修复Agent
6. 循环执行测试-修复，直到所有测试通过
7. 调用部署Agent，完成上线

## 工作流程
1. 调用 `requirement-refinement` skill
2. 并行调用 `frontend-code-gen` 和 `backend-code-gen` agents
3. 执行 `frontend-compiler` skill
4. 循环执行 `auto-test-and-fix` skill，直到错误为空
5. 执行 `deploy` skill

## 规则
- 每个阶段必须有明确的输入和输出
- 错误修复最多重试10次
- 所有操作必须记录日志

前端代码生成Agent示例：frontend-code-gen.md

# 前端代码生成Agent

## 角色
你是一个前端开发专家，负责根据需求文档和接口文档生成前端代码。

## 输入
- 需求文档：`docs/requirements/feature-xxx.md`
- 接口文档：`docs/api/api-spec.md`
- UI设计稿：Figma链接（可选）

## 输出
- 前端页面代码：`frontend/src/views/xxx/`
- API接口文件：`frontend/src/api/xxx.js`
- 路由配置：更新 `frontend/src/router/index.js`

## 技术栈
根据你的团队实际情况定义，例如：
- 框架：Vue / React / Angular
- UI组件库：Ant Design / Element / Material-UI
- HTTP库：Axios / Fetch
- 样式方案：Less / Sass / Styled-components

## 编码规范
遵循团队定义的编码规范文档。

## 工作流程
1. 读取需求文档，理解业务逻辑
2. 读取接口文档，获取API定义
3. 根据UI设计稿（如有），生成页面布局
4. 生成页面组件代码
5. 生成API接口调用代码
6. 注册路由
7. 生成Mock数据（如果后端未就绪）

Skill配置示例：auto-test-and-fix/skill.md

# 自动测试及纠错Skill

## 功能
执行自动化测试用例，如果发现错误，自动修复。

## 输入
- 测试用例：`docs/test-cases/test-case-xxx.md`
- 前端服务地址：http://localhost:8080
- Chrome调试端口：9222

## 输出
- 测试报告：`.process/test-result.md`
- 错误报告：`.process/frontend-errors.txt` 或 `.process/backend-errors.txt`
- 测试快照：`.process/snapshots/`

## 工作流程
1. 启动Chrome调试模式
2. 打开测试页面
3. 读取测试用例
4. 逐个执行测试步骤：
   - 点击元素
   - 填写表单
   - 验证结果
   - 截图留证
5. 收集错误信息
6. 如果有错误：
   - 分析错误类型（前端错误/后端错误）
   - 调用修复逻辑
   - 重新测试

## 依赖
- Chrome DevTools MCP
- 测试用例生成Skill

Rules示例：rules/coding-standards.md

# 编码规范

## 命名规范
- 文件命名：kebab-case，如 `user-list.vue`
- 组件命名：PascalCase，如 `UserList`
- 变量命名：camelCase，如 `userName`
- 常量命名：UPPER_SNAKE_CASE，如 `API_BASE_URL`

## 代码风格
- 缩进：2空格 或 4空格（根据团队习惯）
- 分号：使用或不使用（保持一致）
- 引号：统一使用单引号或双引号
- 换行：每个逻辑块之间空一行

## 注释规范
- 函数必须添加注释说明
- 复杂逻辑必须添加注释说明
- 注释应清晰描述意图

## 组件使用规范
- 优先使用项目内的通用组件
- 遵循团队的组件复用原则

## API调用规范
- 所有API定义统一管理
- 统一使用项目的请求方法
- 明确请求成功/失败的判断标准

3.3 五个关键阶段的实现

阶段一：文档准备

目的：将需求文档转化为结构化的、可执行的输入

输入：

• 📄 需求文档（Markdown格式）
• 🎨 UI设计稿（Figma链接）
• 📡 接口协议（从API管理平台获取）

输出：

• ✅ 细化需求文档（包含交互细节、字段说明）
• ✅ 接口字段校验JSON（用于自动校验请求响应）
• ✅ 自动化测试用例（每个功能点的测试步骤）

关键技巧：

不要让AI"猜测"需求细节！通过结构化的文档准备，确保代码生成有据可依。

阶段二：并行开发

实现方式：

// 主Agent调度逻辑
async function parallelDevelopment() {
  // 前后端独立开发，互不阻塞
  const frontendPromise = frontendAgent.generateCode();
  const backendPromise = backendAgent.generateCode();
  
  await Promise.all([frontendPromise, backendPromise]);
  
  // 等待编译完成
  await waitForBuild();
}

为什么并行？

• ⚡ 效率提升：前后端同时开发，节省50%时间
• 🔗 解耦合：前端不需要等后端接口文档
• 📦 Mock支持：前端使用Mock数据开发，后端独立测试

阶段三：编译检查

实现脚本：frontend-compiler/scripts/compile-check.js

const { exec } = require('child_process');
const fs = require('fs');

async function checkCompilation() {
  return new Promise((resolve, reject) => {
    // 执行前端编译
    exec('cd frontend && npm run build', (error, stdout, stderr) => {
      if (error) {
        // 记录编译错误
        fs.writeFileSync('.process/frontend-errors.txt', stderr);
        reject(new Error('编译失败'));
      } else {
        // 清空错误文件
        fs.writeFileSync('.process/frontend-errors.txt', '');
        resolve('编译成功');
      }
    });
  });
}

module.exports = { checkCompilation };

阶段四：自动化测试 + 错误自修复

测试执行：

// 测试Agent伪代码
async function automatedTesting() {
  // 1. 启动Chrome调试模式
  await launchChromeDebug();
  
  // 2. 打开待测页面
  await navigateTo('http://localhost:8080/test-page');
  
  // 3. 读取测试用例
  const testCases = readTestCases();
  
  // 4. 逐个执行测试
  for (const testCase of testCases) {
    await executeTestCase(testCase);
    await takeSnapshot(); // 截图留证
  }
  
  // 5. 生成测试报告
  await generateReport();
}

错误修复循环：

// 闭环自修复逻辑
let maxRetries = 10;
let retryCount = 0;

while (retryCount < maxRetries) {
  const errors = await runTestsAndGetErrors();
  
  if (errors.length === 0) {
    console.log('✅ 所有测试通过！');
    break;
  }
  
  console.log(`🔄 发现 ${errors.length} 个错误，开始修复...`);
  await fixErrors(errors);
  
  retryCount++;
}

错误分类：

错误报告结构：
├── 前端错误
│   ├── 编译错误（类型错误、语法错误）
│   └── 运行错误（控制台报错、界面异常）
└── 后端错误
    ├── 接口404（路由未注册）
    ├── 参数校验失败（字段缺失或类型错误）
    └── 业务逻辑错误（状态码非200）

阶段五：自动化部署

部署流程：
1. 前端构建 → 生成dist包
2. 后端构建 → 生成可执行文件
3. 推送镜像 → Docker镜像仓库
4. 更新服务 → Kubernetes滚动更新
5. 健康检查 → 验证服务可用性

---

四、实战经验与最佳实践

4.1 适用场景

✅ 适合自动化的场景

• 📋 CRUD页面：增删改查的标准页面
• 📊 数据展示：表格、图表、筛选
• 📝 表单处理：新增、编辑、校验
• 🔄 标准化流程：固定的业务流程

⚠️ 不适合自动化的场景

• 🎨 创意性UI：高度定制化的交互设计
• 🧮 复杂算法：需要深度思考的核心逻辑
• 🔐 安全敏感：支付、加密等关键模块
• 🚀 性能优化：需要精细调优的场景

4.2 踩过的坑

坑1：过度依赖AI

问题：AI生成的代码有bug，盲目信任导致问题

解决：

• ✅ 引入接口字段校验（自动发现数据格式错误）
• ✅ 编译检查脚本（提前发现语法错误）
• ✅ 人工Code Review（关键模块）

坑2：测试用例维护成本高

问题：需求变更后，测试用例也需要更新

解决：

• ✅ 测试用例从需求文档自动生成
• ✅ 采用"示例驱动"测试（记录正确操作序列）

坑3：错误修复陷入死循环

问题：AI反复修复同一个错误

解决：

• ✅ 设置最大重试次数
• ✅ 错误去重（相同的错误只修复一次）
• ✅ 人工介入机制

4.3 最佳实践

实践1：文档结构化

核心心法：不要让AI做"选择题"，要让AI做"填空题"

• ❌ 错误："帮我生成一个用户管理页面"
• ✅ 正确："根据需求文档生成用户管理页面，使用团队标准表格组件，接口路径是/api/users"

关键：通过文档结构化，约束AI的生成空间

实践2：渐进式自动化

第一阶段：手动开发 + AI辅助（代码补全）
  ↓
第二阶段：文档准备自动化（需求细化、接口文档生成）
  ↓
第三阶段：代码生成自动化（前端、后端）
  ↓
第四阶段：测试自动化（测试用例生成、自动执行）
  ↓
第五阶段：全流程自动化（开发→测试→部署）

实践3：保留人工检查环节

关键节点：

• 需求评审：人工确认需求理解正确
• 架构设计：人工确认技术方案合理
• 关键模块：人工Code Review
• 上线前检查：人工验收测试结果

---

五、快速开始：搭建你的第一个脚手架

步骤1：创建基础目录结构

mkdir -p .codebuddy/{agents,skills,rules,config}
mkdir -p docs/{requirements,api,test-cases}
mkdir -p .process

步骤2：定义主Agent

创建 .codebuddy/requirement-development/skill.md，参考前面的示例。

步骤3：定义你的第一个子Agent

根据你的技术栈，创建 .codebuddy/agents/frontend-code-gen.md：

# 前端代码生成Agent

## 技术栈
- 框架：[你的框架：Vue/React/Angular]
- UI组件库：[你的组件库：Ant Design/Element/其他]
- HTTP库：[你的选择：Axios/Fetch]

## 输入
- 需求文档
- 接口文档

## 输出
- 页面代码
- API接口文件
- 路由配置

步骤4：创建第一个Skill

创建 .codebuddy/skills/frontend-compiler/skill.md：

# 前端编译检查Skill

## 功能
执行前端编译，检查是否有语法错误。

## 脚本
scripts/compile-check.js

创建 .codebuddy/skills/frontend-compiler/scripts/compile-check.js，参考前面的示例。

步骤5：定义Rules

创建 .codebuddy/rules/coding-standards.md，根据你的团队规范编写。

步骤6：测试你的脚手架

1. 准备一个简单的需求文档
2. 调用主Agent
3. 观察流程执行
4. 根据结果调整配置

---

六、核心价值总结

这套脚手架的真正价值不在于"AI写代码"，而在于：

1. 知识资产化

传统模式：
需求文档 → 开发人员大脑 → 代码 → 人员离职 → 知识流失

自动化模式：
需求文档 → 结构化知识库 → AI执行 → 可复用的资产

2. 标准化流程

• 🎯 编码规范：Rules强制执行
• 🔍 接口契约：自动校验字段类型
• ✅ 测试覆盖：100%功能点测试

3. 持续改进

每次开发都是对系统的优化：

第一次：手动配置 → 第二次：自动生成配置 → 第三次：智能推荐配置

---

📝 写在最后

这套系统的核心思想可以总结为一句话：

把重复的工作交给机器，把创造性的工作留给人

重要的不是用了什么技术栈，而是这套架构设计思想：

• 🎯 面向过程的主Agent + 面向对象的子Agent
• 🔄 闭环自修复的Agent Loop
• 📦 知识资产化的文档驱动开发

希望这篇文章能帮助你搭建切合自己业务系统的开发脚手架。如果你在实践过程中遇到问题，欢迎交流讨论！

---

互动话题：

🤔 你的团队正在使用什么技术栈？你打算如何搭建自己的自动化开发脚手架？

💬 欢迎在评论区分享你的想法，我会一一回复！

---

📌 声明：本文分享的是架构设计思想和通用实现方案。具体实现时需要根据团队技术栈和业务特点进行调整。