淘天营销中后台生码工作流最佳实践¶

Ch01.196 淘天营销中后台生码工作流最佳实践¶

📊 Level ⭐⭐ | 19.3KB | entities/tmall-marketing-ai-workflow-best-practices.md

淘天营销中后台生码工作流最佳实践¶

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 配置示例：

{
  "workspaces": ["projects/*"],
  "scripts": {
    "build": "turbo run build",
    "lint": "turbo run lint",
    "test": "turbo run test",
    "start:workspace": "turbo run start:workspace"
  },
  "devDependencies": { "turbo": "latest" }
}

{
  "$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成本极高 解决思路：
将规则前置固化：架构说明文档
新旧架构对照：明确旧写法对应新写法，不留歧义空间
禁止行为清单：强制规则形式写入（如"禁止在组件层写业务逻辑"）
接口映射规则：预定义字段映射关系，Agent按映射表转换
将验证系统化：每个关键迁移点都有明确的检查项
领域知识编码：Skill作为按需手册
表单开发Skill（ProForm）：基于ProForm+useForm的表单开发范式
表格开发Skill（ProTable）：基于ProTable+useTable的表格开发范式
工作流节点化：
了解旧架构：编码启动前加载旧架构仓库
计划制定阶段：规格撰写→歧义澄清→迁移计划生成→任务拆解→跨文档一致性分析
编码实现阶段：严格按计划逐文件生成
验证收尾阶段：表单迁移逐字段生成测试用例；通用重构生成验收检查清单 落地效果：
赠品重构场景：功能点完成率 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%

五、核心方法论¶

给恰好够用的精确知识，而非更多知识：知识的精确度比完整度更重要，上下文过载是生码质量下滑最常见的根因
确定性逻辑交还工程，不确定性决策留给Agent：将可枚举的路由、映射、格式处理收口到工程链路，让Agent专注于真正需要推理的创作任务
知识要形成正向循环，而非一次性投入：每次需求迭代的产出不只是代码，还会回流为下次生码的知识资产，构建可持续改善的提效飞轮

六、团队信息¶

团队：淘天集团-营销前台技术团队
定位：专注建设核心电商系统技术底座，直接支撑淘宝天猫的商业运转效率
职责：通过智能新方法优化消费者体验，对商家经营效率负责；将前沿AI知识与澎湃算力转化为实实在在的生产力

深度分析¶

云端托管策略的本质是环境一致性的工程问题：选择AoneSuper而非自建LangGraph多Agent架构，核心考量是基建维护成本与社区生态成熟度的权衡。CodeAgent CLI的Skills、MCP、SubAgent等原生能力已形成生态，选择借力而非自建是边际收益递减后的理性决策
跨仓库工作区的设计揭示了Monorepo的另一种形态：通过git submodule聚合需求相关仓库，外层文件夹作为独立git空间存放配置和中间产物，内层业务仓库通过软链接聚合。这种方案在保持仓库独立性的同时实现了跨仓库代码感知，与传统Monorepo的"大一统"思路截然不同
功能树解决的不是知识获取问题，而是知识精确度问题：日常迭代任务中，Agent信息过载的根因不是知识不够，而是知识太泛。功能树将通用架构知识预编译为功能点粒度的精确信息，查表操作替代推理链路，本质上是将"知识密度"从低频宽泛转为高频精准
两化策略的划分标准是任务确定性而非任务类型：高确定性任务（迁移/重构）采用规则前置固化+验证系统化，低确定性任务（日常迭代）采用功能树+按需获取。这种差异化策略的核心洞察是：确定性越高越适合前置固化，确定性越低越适合按需召回
知识正循环的构建依赖每次需求的闭环沉淀：功能树覆盖的需求生码完成度从40%~50%提升至80%~90%，这个提升不是来自单次优化，而是来自多次需求的累积效应。每次迭代后的产出回流为下次生码的知识资产，形成可持续改善的提效飞轮

实践启示¶

将AK管理、脚本自动化纳入AI生码基建范畴：本地环境的核心问题不只是环境不一致，还有AK明文存储、分发轮换回收缺乏管控等安全和管理问题。云端托管不仅是效率选择，也是安全治理选择
对于跨仓库依赖场景，优先用turborepo实现一键启动和自动link配置：手动管理多仓库依赖关系极易出错，turborepo的pipeline机制可以自动处理仓库间的build依赖顺序，避免人工串联引入的失误
建立功能树时优先覆盖高频迭代场景，放弃追求全量覆盖：功能树的价值在于精确而非全面，优先覆盖日常迭代中高频的功能点远比追求全链路覆盖更有价值。低频场景用应用层通用规范兜底即可
MCP工具的调用应封装为统一接口，隐藏内部路由逻辑：营销中后台资产查询MCP应该对Agent暴露简单统一的调用接口，让Agent专注于创作任务而非工具选择逻辑。确定性路由收口到工程侧是提升Agent执行稳定性的关键
迁移类任务的验收检查清单应在编码前生成，而非编码后补充：跨越大量文件的迁移任务，如果验证环节缺失，人工review成本极高。应该在计划制定阶段就将验收检查清单前置，确保每个关键迁移点都有明确的检查项

淘天营销中后台生码工作流最佳实践¶

Ch01.196 淘天营销中后台生码工作流最佳实践¶

淘天营销中后台生码工作流最佳实践¶

核心摘要¶

一、生码提效路径的重新梳理¶

现状与痛点¶

收敛决策：统一至云端托管生码¶

云端一体化研发流程¶

二、跨仓库研发工作区方案¶

设计背景¶

方案设计¶

研发调试优化¶

三、可编排的场景化工作流¶

设计背景¶

工作流整体架构¶

落地工作流示例¶

四、两化研发任务的差异化生码优化策略¶

高确定性任务：迁移/重构¶

低确定性任务：日常迭代¶

功能树（核心载体）¶

研发指引分层¶

按需获取（动态）¶

D2C 还原效果优化¶

API 接口优化¶

知识沉淀正向循环¶

五、核心方法论¶

六、团队信息¶

深度分析¶

相关链接¶

实践启示¶

相关实体¶