---
title: 淘天营销中后台生码工作流最佳实践
source_url: https://mp.weixin.qq.com/s/VjTyHFr17l_bObG6x8-Mmw
publish_date: 2026-04-27
tags: [wechat, article, agent]
review_value: 7
review_confidence: 7
review_recommendation: neutral
sha256: ab26f76a9622df3ad2950c979aec3a43eac1d65f99d9977d8a966c90e03aed46
---
# 淘天营销中后台生码工作流最佳实践
> source: https://mp.weixin.qq.com/s/VjTyHFr17l_bObG6x8-Mmw
> author: 营销前台技术团队，大淘宝技术
> date: 2026-04-27
> tags: #AI生码 #工作流 #云端托管 #跨仓库 #turborepo #功能树 #D2C #Agent #淘天
## 核心摘要
本文系统总结了营销中后台在财年初推进AI生码提效的最佳实践升级路径：
- **统一收敛至云端托管生码**（基于AoneSuper），解决本地研发环境不一致、AK管理难、执行易中断等问题
- **构建跨仓库工作区**（git submodule + turborepo）支持多仓协同
- **打造可编排场景化工作流**，覆盖需求理解→编码→构建发布全链路
- **差异化优化策略**：迁移/重构（高确定性）采用架构说明文档+领域Skill固化规则；日常迭代（低确定性）引入功能树实现精准查表式知识供给
- **核心方法论**：给恰好够用的精确知识、确定性逻辑交工程、知识建正向循环
---
## 一、生码提效路径的重新梳理
### 现状与痛点
营销中后台面向业务研发有两条提效路径：
| 路径 | 适用场景 | 工具 |
|------|----------|------|
| 云端Alex平台 | 简单需求，可一站式托管 | Alex平台 |
| 本地Cursor/CodeAgent CLI | 复杂需求，需人工干预 | Cursor / CodeAgent CLI |
**两个痛点**：
1. 两条路径天然增加业务开发的评估判断成本
2. AI辅助只覆盖编码研发节点，完整需求交付生命周期还需大量人力做流程串联
### 收敛决策：统一至云端托管生码
**为什么不选本地**：
- 环境配置难以统一，问题排查协作成本高
- 生态用工的 AK 管理困难（明文存储、分发轮换回收缺乏管控）
- 执行易中断（电脑息屏/网络断开导致任务中断）
**借力集团已有AI基建**：
选择 AoneSuper 而非自建的原因：S1 自建 LangGraph 多 Agent 架构，基建维护成本高；CodeAgent CLI 社区生态迅速成熟（Skills、MCP、SubAgent 等原生能力），自建边际收益递减。
### 云端一体化研发流程
| 模式 | 适用场景 |
|------|----------|
| 云端生码 | 绝大多数场景，可云端执行全流程 |
| 本地IDE直连沙箱 | 少数复杂场景，需强人工干预，具备原生开发体验 |
---
## 二、跨仓库研发工作区方案
### 设计背景
营销中后台日常需求中有大量跨仓库研发场景，可归纳为两类：
1. **项目重构/迁移**：仓库A需要参考仓库B的部分功能实现
2. **项目间相互依赖**：前端业务仓库 ← 业务组件仓库 ← 基础组件仓库，多层协同
### 方案设计
**聚合需求相关的仓库**：创建"空文件夹"聚合需求相关的所有仓库，实现跨仓库代码感知
**引入 git submodule**：
- 外层"文件夹"作为独立git空间，具备git托管能力（存放Agent消费的配置项Skills/MCP/SubAgent等，以及中间产物）
- 内层业务仓库通过软链接聚合
- 需求交付过程中，仅面向需求工作区进行研发，对子仓库的修改会提交到对应子仓库git空间
**消除副作用**：通过脚本自动化执行submodule操作（仓库初始化、代码拉取/提交等）
### 研发调试优化
对于项目间相互依赖的跨仓库研发场景，借助 **turborepo** 工具进行优化，实现：
- 一键启动所有需求子仓库的服务
- 自动配置子仓库间的依赖link
**turborepo 配置示例**：
```json
{
  "workspaces": ["projects/*"],
  "scripts": {
    "build": "turbo run build",
    "lint": "turbo run lint",
    "test": "turbo run test",
    "start:workspace": "turbo run start:workspace"
  },
  "devDependencies": { "turbo": "latest" }
}
```
```json
{
  "$schema": "https://turbo.build/schema.json",
  "globalDependencies": [".env", "tsconfig.json"],
  "daemon": true,
  "concurrency": 3,
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["build/**", "dist/**", ".next/**", "!.next/cache/**"],
      "cache": true
    },
    "start:workspace": {
      "dependsOn": ["^build"],
      "cache": false,
      "persistent": true
    }
  }
}
```
完整工作区结构（不限制云端/本地使用，当作正常monorepo仓库即可，projects目录通过git submodule聚合需求相关子仓库）
---
## 三、可编排的场景化工作流
### 设计背景
S1阶段AI辅助以编码研发节点为核心，但完整需求交付链路远不止编码。S2核心目标是将AI辅助从编码节点扩展到需求交付全链路，通过可编排的工作流将前置准备、编码研发、后置构建部署串联为一体。
整体设计以 **CodeAgent CLI 的 Command 机制**作为工作流节点推进方式，每次触发时将文件内容作为Prompt注入当前对话，天然支持在Prompt中声明调用MCP工具和Skills。
### 工作流整体架构
**工作流构成**：
- 固定节点 - 需求准备（入口）：选择需求仓库（支持多仓库配置）、选择需求场景、输入需求描述
- 动态节点（1~N个，由场景定义）：每个节点绑定独立的Command，Prompt中可声明调用MCP（aone-km读取需求文档、d2c还原等）和Skills（领域Skill按需加载）
- 固定节点 - 构建部署（出口）：自动梳理仓库间依赖关系→按依赖顺序执行构建→依序完成所有仓库发布
### 落地工作流示例
- ToB｜需求迭代｜商家营销工具
- ToC｜需求迭代｜POP弹窗
- ToB｜技术重构｜营销资金设置端迁移
- ToB｜技术重构｜商家营销工具N合一迁移
---
## 四、两化研发任务的差异化生码优化策略
### 高确定性任务：迁移/重构
**特点**：任务确定性高，迁移规范可前置梳理，执行路径可完全固化
**核心挑战**：
- 规则传递失真：迁移规范散落在设计文档、口头约定和历史代码中，Agent接收碎片化、歧义多的描述
- 执行验证缺失：跨越大量文件，人工逐一review成本极高
**解决思路**：
1. **将规则前置固化**：架构说明文档
   - 新旧架构对照：明确旧写法对应新写法，不留歧义空间
   - 禁止行为清单：强制规则形式写入（如"禁止在组件层写业务逻辑"）
   - 接口映射规则：预定义字段映射关系，Agent按映射表转换
2. **将验证系统化**：每个关键迁移点都有明确的检查项
3. **领域知识编码**：Skill作为按需手册
   - 表单开发Skill（ProForm）：基于ProForm+useForm的表单开发范式
   - 表格开发Skill（ProTable）：基于ProTable+useTable的表格开发范式
4. **工作流节点化**：
   - 了解旧架构：编码启动前加载旧架构仓库
   - 计划制定阶段：规格撰写→歧义澄清→迁移计划生成→任务拆解→跨文档一致性分析
   - 编码实现阶段：严格按计划逐文件生成
   - 验证收尾阶段：表单迁移逐字段生成测试用例；通用重构生成验收检查清单
**落地效果**：
- 赠品重构场景：功能点完成率 71.43%，TC通过率 66.7%，效率提升 58.13%
- 营销资金设置端迁移：21个页面迁移，时间降低 62.73%
---
### 低确定性任务：日常迭代
**特点**：任务确定性低，需求由产品随业务发展决定，无法提前穷举
**初期方案暴露的系统性缺陷**：
- 信息过载：单次生码注入过多上下文知识，关键信息被稀释
- 知识来源多元、优先级不明确：架构规范、大而全Skills、CodeBase检索结果同时注入，Agent无法判断以谁为准
- 链路过长、衰减严重：需求输入→理解架构规范→加载Skills→搜索代码→推导方案→生码，6+步链路
**核心问题**：给Agent的是通用、抽象的知识，但生码需要的是具体、精确的信息
**解决思路**：
- **知识预编译**：把通用架构知识转化为功能点粒度的精确信息
- **获取动静分离**：静态指引（功能树召回）+ 动态按需查询组件API
### 功能树（核心载体）
将每个业务应用的所有功能点预先整理成树状结构，每个叶节点绑定四类资产：
```
└─ 优惠券
   ├─ 首页
   │  ├─ 首页_面包屑
   │  ├─ Banner
   │  │  └─ 推荐设置入口
   │  ├─ Tab切换
   │  │  └─ Tab拓展区（批量创建、存储版数量查看）
   │  ├─ 券管理列表（筛选表单、单元格展示、列表操作）
   │  ├─ 查看活动数据
   │  └─ 创建页入口列表
```
**四类绑定资产**：
1. **关联代码**：文件路径 + 文件概要
2. **关联接口**（可选）：接口描述、路径、请求方法、出入参定义
3. **关联设计稿**（可选）：设计稿ID（D2C）+ 截图
4. **关联Skill**（可选）：原子化Skill（如新增表单项规范）
生码前，通过MCP将需求点与功能树节点匹配，"理解架构→搜索代码→推导方案"的推理链路压缩为一次**查表操作**。
### 研发指引分层
| 分层 | 触发条件 | 作用 |
|------|----------|------|
| 功能点层 | 匹配到功能树已有节点 | 获得高度精确的指引，提上限 |
| 应用层 | 全新功能/未覆盖场景 | 通用规范兜底，保下限 |
### 按需获取（动态）
包装统一的营销中后台资产查询MCP，Agent只需按需调用，即可动态获取精确上下文（组件Props等），避免Skills内部路由逻辑干扰Agent核心创作。
**最佳实践**：确定性逻辑交还工程，不确定性决策留给Agent——"合适的角色做合适的事"
### D2C 还原效果优化
**结构分析驱动实现策略**：
1. 提取D2C的DOM层级树，标注每层布局方式
2. 若存在现有组件，同步绘制现有组件DOM层级树
3. 逐层对比，输出差异清单（删除/新增/移动/布局变更）
4. 确定实现策略：差异涉及布局重构→结构重写；差异仅为样式数值→样式迁移
### API 接口优化
约定需求描述中存在`@API`（接口Id），会走到API解析链路。Agent拿到接口定义后需完成三件事：
1. **类型生成**：根据params生成请求参数interface，根据response.model生成响应VO
2. **结构处理**：检查success字段、分页字段统一在model中
3. **接口数据mock**：生成mock数据并返回，注释保留真实调用逻辑供后续切换
### 知识沉淀正向循环
每次需求迭代完成后，可一键触发功能树沉淀流程：
- 基于AI生成结果及人工干预过程进行Skill新增或扩充
- 自动挂靠在对应功能点
- 功能树覆盖的需求，生码完成度从40%~50%提升至80%~90%
---
## 五、核心方法论
1. **给恰好够用的精确知识，而非更多知识**：知识的精确度比完整度更重要，上下文过载是生码质量下滑最常见的根因
2. **确定性逻辑交还工程，不确定性决策留给Agent**：将可枚举的路由、映射、格式处理收口到工程链路，让Agent专注于真正需要推理的创作任务
3. **知识要形成正向循环，而非一次性投入**：每次需求迭代的产出不只是代码，还会回流为下次生码的知识资产，构建可持续改善的提效飞轮
---
## 六、团队信息
- **团队**：淘天集团-营销前台技术团队
- **定位**：专注建设核心电商系统技术底座，直接支撑淘宝天猫的商业运转效率
- **职责**：通过智能新方法优化消费者体验，对商家经营效率负责；将前沿AI知识与澎湃算力转化为实实在在的生产力