AI ENGINEERING · AGENT WORKFLOW

全栈Agent
协同开发

Full-stack Agent Collaboration
基于 CodeBuddy 实践 · Powered by CodeBuddy
AI 全栈工程师 · AI Full-stack Engineer Agent 规约编程 · Agent Spec Programming 工作流可移植 · Portable Workflow 按角色分模型 · Cost-aware Model Routing
分享人:产研四组-梁宗诚 | 日期:2026-09 | Codebuddy · TAPD
Chapter 01

前后端 · 协同开发

Front-end & Back-end · Multi-Agent Collaboration
传统模式 · TRADITIONAL 👥

传统开发模式

Conventional Division of Labor

  • 前端代码由 前端工程师 开发
  • 后端代码由 后端工程师 开发
  • 或前后端统一由 全栈工程师 开发
// 依赖岗位分工与协作成本
新构想 · NEW VISION 🤖

AI 全栈工程师

AI Full-stack Engineer

  • 一个人使用 Codebuddy
  • 采用 Agent 规约编程 方式开发好前后端
  • 多 Agent 分工协作,各司其职
// 一人团队,规约驱动,Agent 协同

谁适合转型为 AI 全栈工程师

🧑‍💻

全栈工程师

前后端都熟悉,天然适合,直接放大产能。

天然适合 · Natural Fit
✓ 最平滑的转型路径
⚙️

后端强 · 前端一般

后端技术扎实,前端短板交由 Agent 补齐。

后端强 / 前端一般
✓ Agent 补足前端能力
🎨

前端强 · 后端一般

前端功底深厚,后端逻辑交给 Agent 实现。

前端强 / 后端一般
✓ Agent 补足后端能力

另一种模式 · 纯前端 + 纯后端组合

Pair Collaboration · Front-end + Back-end
🎨

纯前端工程师

Front-end Engineer

  • · 专注页面、交互与体验
  • · 由 Agent 辅助组件与样式开发
⚙️

纯后端工程师

Back-end Engineer

  • · 专注接口、逻辑与数据
  • · 由 Agent 辅助接口与 SQL 开发

两端各司其职 —— 保留专业分工,Agent 打通前后端边界。

目录结构示意 Project Layout

一个工作区内同时挂载前后端工程,AI 可直接读取前后端代码作为上下文, 从而理解跨端调用关系、统一修改与联调。

workspace/
├── .codebuddy/                # 规约资产(rules / skills / agents)
├── saas-xproject-frontend/    # 前端工程(Vue 或 React)
└── saas-xproject-backend/     # 后端工程(Java/SpringBoot)
Chapter 02

前端落地 · MCP + Ardot 原型驱动

Front-end · Ardot Prototype via MCP

通过 MCP 连接 Ardot 原型设计,将原型数据作为上下文, 自动生成 Vue 3 + Element Plus 前端页面,打通「设计 → 页面」的最后一公里。

工作流 Workflow

拉取原型数据

Ardot MCP 获取结构/坐标/样式/交互

坐标转布局

坐标推导父子关系、排列方向

确认输出目录

static/{模块}/{文件名}.html

生成前端页面

Vue 3 + Element Plus 单文件

两种输入途径 Two Input Paths

  • 途径一(优先):Ardot MCP 拉取精确设计数据
  • 途径二(降级):用户直接提供原型截图
  • MCP 不可用时自动降级为截图识别

MCP 上下文驱动 Context-driven

  • · 页面结构、组件树、坐标、样式属性
  • · 交互定义 + 自动截图交叉校验
  • · 生成后附功能清单,可审计可复核

Ardot 原型 → 前端实现 From Prototype to Front-end

以「日志管理」页面为例:左侧为 Ardot 原型设计,右侧为 MCP 驱动生成的前端页面(Vue 3 + Element Plus)。

① Ardot 原型 · Ardot Prototype
截图预览
② 实现效果 · Front-end Implementation
截图预览
Chapter 03

项目管理 · TAPD 统一收口

TAPD Unified Management

需求、缺陷、迭代、发布评审与组织过程资产统一在 TAPD 沉淀,让全流程可追溯、可审计。

统一收口清单 Unified Management Scope

需求 Story 缺陷 Bug 迭代 Iteration 发布评审 Release Review
需求、缺陷、迭代、发布评审统一在 TAPD 沉淀,让全流程可追溯、可审计。

组织过程资产 · Wiki 管理 Assets in TAPD Wiki

数据库设计文档与接口文档统一沉淀在 TAPD Wiki,作为组织过程资产集中管理、持续更新。

数据库设计文档 DB Design

数据表结构、字段说明、索引与约束,随版本演进持续维护。

接口文档 API Doc

REST 接口清单、入参出参、错误码,前后端联调的统一依据。

Chapter 04

规约资产的 可移植性

Spec Assets Portability

Rules(编码规范)与 Skill(多 Agent:agent-team-multiple / 单 Agent:agent-team-single) 沉淀为可复用的「规约资产」,复制即可迁移到新项目,不依赖特定个人。

如何移植 How to Port

三步完成移植:复制 rules、skills → 复制 agents → 跑小需求迭代优化。

复制 rules、skills

编码规范 + 多/单 Agent Skill(工作流、模板)复制到目标项目

复制 agents

多 Agent 的角色定义(pm、developer 等)复制到 .codebuddy/agents/

跑小需求迭代优化

先跑几个小需求,逐步优化样板使其更适配目标项目

Skill 通用样板结构 Skill Asset Structure

Skill 复制到目标项目的 .codebuddy/skills/ 下,Agent 角色定义放在 .codebuddy/agents/ 根目录下,即可复用,内部结构如下。

单 Agent · agent-team-single

单角色串行,轻量简洁

.codebuddy/skills/
└── agent-team-single/
    ├── SKILL.md
    └── templates/          # 4 个产物模板
        ├── plan.md.template
        ├── task.md.template
        ├── checklist.md.template
        └── self-test-report.md.template

多 Agent · agent-team-multiple

7 角色协同,覆盖全链路

.codebuddy/
├── agents/                      # 7 个角色定义(根目录)
│   ├── pm.md
│   ├── requirement-analyst.md
│   ├── solution-architect.md
│   ├── developer.md
│   ├── code-reviewer.md
│   ├── qa-tester.md
│   ├── gate-reviewer.md
│   └── README.md              # 模型矩阵
└── skills/
    └── agent-team-multiple/
        ├── SKILL.md
        └── templates/          # 7 个产物模板
            ├── requirement-analysis.md.template
            ├── plan.md.template
            ├── task.md.template
            ├── checklist.md.template
            ├── code-review.md.template
            ├── gate-review.md.template
            └── self-test-report.md.template

输出归档 · 可审计 Output Archiving & Auditability

Agent 协同开发的每个阶段产物统一归档到任务池,一需求一目录, 需求分析、方案、任务、审查、门禁、自测、SQL 全链路留痕,可随时回溯审计。

# 过程资产沉淀,一需求一目录
.codebuddy/Agent协同/任务池/需求/
└── {yyyMMdd}-{序号}/
    ├── spec-kit/
    │   ├── requirement-analysis.md   # 需求分析
    │   ├── plan.md / task.md          # 方案 / 任务
    │   ├── checklist.md               # 自测清单
    │   ├── code-review.md             # 代码审查
    │   ├── gate-review.md             # 发布门禁
    │   └── *.sql                    # 数据库变更(唯一归档)
    └── {需求ID}.md               # 自测报告
Chapter 05

单Agent vs 多Agent 优缺点

Single-Agent vs Multi-Agent
对比维度 单 Agent · Single-Agent 多 Agent · Multi-Agent
上下文隔离 所有内容挤在一个上下文,易污染、易超限 角色独立上下文,各加载所需,更聚焦
职责分离 分析/设计/开发/审查集于一身,易顾此失彼 职责单一,专人专事,边界清晰
可追溯性 过程不落文件,难以回溯问题 各角色产物独立文件,可定位到具体阶段
成本 Token 消耗低,成本可控 Token 消耗约为单 Agent 的 1.5x~2.5x
协调复杂度 无协调开销,流程简单 需编排与门禁,交接链有维护成本

应用场景 When to Use Which

单、多模式应根据情景灵活选用 —— 只有按需匹配,才能同时达到高效率低成本的效果。

轻量 · 单 Agent

单 Agent 场景

Single-Agent · Lightweight

  • 小型需求、常规缺陷
  • 涉及代码文件 5 个以内
  • 不涉及对接其他业务系统
  • 不涉及数据库变更
重量级 · 多 Agent

多 Agent 场景

Multi-Agent · Heavyweight

  • 中、大型需求,复杂缺陷
  • 涉及代码文件 超过 5 个
  • 涉及对接其他业务系统
  • 涉及数据库建表、数据迁移

7 角色交接链 Handoff Chain

PM主调度
requirement-analyst需求分析
solution-architect方案设计
developer编码实现
code-reviewer代码审查
qa-tester自测验证
gate-reviewer发布门禁

7 角色岗位职责 Roles & Responsibilities

角色中文名岗位职责
pm项目管理 / 主调度流程编排、TAPD 状态流转、门禁裁决,统筹全局节奏
requirement-analyst需求分析师需求分析,澄清歧义,输出疑点清单
solution-architect解决方案架构师技术方案设计、任务拆分、数据库变更脚本
developer开发工程师按任务清单编码实现,勾选任务进度
code-reviewer代码审查员代码审查,分级门禁(阻断级/建议级)
qa-tester测试工程师自测验证,逐项核对并输出自测报告
gate-reviewer发布门禁评审员发布门禁,核对产物完整性

模型成本矩阵 Cost-aware Model Routing

不同 Agent 角色绑定不同模型 —— 轻量编排用轻量模型,编码用强编码模型,推理用强推理模型,从而节省成本。

Agent 角色绑定模型定位
pmhy4轻量编排(流程调度、状态流转,低延迟低成本)
developerglm-5.3强编码模型(编码为核心职责)
requirement-analystdeepseek-v4-pro强推理(需求分析、疑点清单)
solution-architectdeepseek-v4-pro强推理(技术方案、任务拆分、SQL)
code-reviewerhy4代码审查、分级门禁(检查型任务,无需深度生成)
qa-testerdeepseek-v4-pro强推理(自测验证、自测报告)
gate-reviewerdeepseek-v4-pro强推理(发布门禁、产物完整性)
Case Study

实证案例 · 后端真实落地

Real-world Validation · Back-end

基于本项目后端(Java/SpringBoot + PostgreSQL,案件纠纷管理)真实跑通的多 Agent 协同工作流。

7 角色职责与产物 Roles & Artifacts

角色职责产物
pm流程编排、状态流转、门禁裁决无(调度)
requirement-analyst需求分析、疑点清单requirement-analysis.md
solution-architect技术方案、任务拆分、SQLplan.md / task.md / checklist.md / *.sql
developer编码实现代码 + task.md 勾选
code-reviewer代码审查code-review.md
qa-tester自测验证{需求ID}.md 自测报告
gate-reviewer发布门禁gate-review.md

阻断级 · Blocker

必须修复才能进入下一阶段,回退 developer。

  • · 代码逻辑错误
  • · 安全漏洞
  • · SQL 缺失/错误
  • · 核心功能未实现
  • · 产物缺失 / 编码规范严重违规

建议级 · Suggestion

记录在产物中,不阻断,可后续优化。

  • · 性能优化点
  • · 命名可读性
  • · 非关键注释缺失

8 阶段工作流 8-Stage Workflow

拉取需求

PM 拉取 TAPD 需求

需求分析

requirement-analyst 产出疑点清单

方案设计

solution-architect 产出方案/SQL

方案确认与开发

developer 按 task 编码

代码审查

code-reviewer 分级门禁

自测验证

qa-tester 逐项验证

发布门禁

gate-reviewer 产物完整性

修复缺陷

回退修复并复测

一人团队,Agent 协同

关键词: AI全栈工程师,TAPD,多Agent分工协作

如何推广 · Seed Spirit

基于种子精神,把方案封装成一颗种子,通过播撒种子的方式, 在四面八方生根发芽,最终开花结果