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

营销中后台在财年初，面向业务研发的简单需求和复杂需求探索出了两条提效路径：对于简单需求，可以从aone工作项出发，直接在云端Alex平台完成迭代创建和编码研发，一站式托管生码。对于复杂需求，考虑到云端不能一次性完成所有研发任务，人工二次干预成本较高，降级到用本地Cursor/CodeAgent CLI工具，配合业务自定义规则辅助生码。

实际需求研发被分割成了两条路径，天然增加了业务开发的评估判断成本。同时，AI辅助提效只覆盖到了几个节点（核心是编码研发），在完整的需求交付生命周期中，还需要大量的人力来做流程串联，才能完成最终需求交付。

本地研发模式在团队实际推行中，遇到了以下三个实际问题：

环境配置难以统一，问题排查协作成本高：不同同学的本地环境（系统版本、Node 版本、网络代理等）差异巨大，同一套插件和 MCP 配置在部分同学环境中频繁出问题；当某位同学本地 AI 工具出现异常时，由于环境差异，其他人很难复现问题，远程协助排查效率低，往往只能“到工位上看一眼”。

生态用工的 AK 管理困难：团队中有不少生态用工同学，本地研发模式下 AK 需明文存储在个人设备上，分发、轮换、回收缺乏统一管控机制，安全隐患和管理成本并存。

执行易中断：本地执行需要依赖电脑持续在线，且网络链接稳定，经常遇到一个长任务在执行过程中，电脑自动息屏或网络断开，导致任务中断，需要手动触发继续执行，增加了任务执行的总耗时，且需要时刻关注任务状态，无法专注做其他工作。

虽然云端托管生码可以解决上述本地研发的实际问题，但其也存在一些固有劣势，需要投入大量精力去做打磨，才能搭建出一套好用、可靠的云端生码环境。这里我们选择借力集团已有AI基建，将底层云端环境切换至AoneSuper（集团内提供云端生码沙箱环境的平台），在此基础之上结合业务特性，来做工程能力定制，和AI生码效果优化。

为什么选择 Aone Super 而非继续自建？

但在实际生码场景下，还需要在“空文件夹”下存放Agent消费的配置项（Skills、MCP、SubAgent等），如果这个“空文件夹”脱离了git体系，很难维护管理这些配置项。此外，在复杂需求场景下，生码过程中可能会生成一些中间产物（需求理解、方案设计、任务列表等）用来聚焦Agent执行任务的注意力，类spec-kit的思想，这些中间产物不适合离散的存放“空文件夹”下的业务仓库，更适合存放在“空文件夹”下。

因此，在用“文件夹”聚合需求仓库的基础上，借助git submodule的能力，将外层的“文件夹”作为一个独立的git空间，使其具备git托管的能力。同时，在其内部可以关联已有业务仓库git空间，通过“软链接”将多个业务仓库聚合到一起。

需求交付过程中，可以仅面向需求工作区进行研发（聚合多个仓库，无需再多个仓库来回切换开发），对子仓库的代码修改会提交到对应子仓库的git空间，不改变业务代码的维护方式：

需求工作区和需求子仓库关联关系

研发调试优化

对于项目间相互依赖（前端业务仓库 <-- 业务组件仓库 <-- 基础组件仓库）的跨仓库研发场景，还有一个比较头疼的问题是：如何在研发调试过程中，修改完基础组件或业务组件的代码后，前端业务仓库能实时应用到修改后的代码，并在预览页面中体现出来。以往这种场景下，需要为每一层依赖手动配置link，过程中还会因为环境等因素，导致link较难生效。因此，考虑对工作区方案做进一步优化，尝试来提升这类场景的研发调试体验。

上面的完整工作区结构设计，在忽略git submodule这一层后，不难发现和传统的monorepo项目几乎一致，外层的“文件夹”对应monorepo的主仓库，内部聚合的业务需求仓库对应monorepo的一个个子包。因此，可以借助monorepo相关构建工具（turborepo、nx等），来进行优化。

拿turborepo工具举例，可以通过以下配置实现一键启动所有需求子仓库的服务，同时自动配置子仓库间的依赖link：

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

{  "$schema": "https://turbo.build/schema.json",  "globalDependencies": [    ".env",    "tsconfig.json"  ],  "globalEnv": [],  "daemon": true,  "concurrency": 3,  "pipeline": {    "build": {      "dependsOn": ["^build"],      "outputs": [        "build/**",        "dist/**",        ".next/**",        "!.next/cache/**"      ],      "inputs": [        "**/*",        "!**/?(*.)+(spec|test).[jt]s?(x)?(.snap)",        "!tsconfig.spec.json",        "!.eslintrc.json",        "!eslint.config.js"      ],      "cache": true    },    "lint": {      "outputs": [],      "cache": true    },    "test": {      "outputs": [],      "cache": true    },    "docs:build": {      "outputs": [],      "cache": true    },    "start:workspace": {      "dependsOn": ["^build"],      "cache": false,      "persistent": true    },    "clean": {      "cache": false    }  }}

完整的需求研发工作区结构如下，其本身只是工程能力上的建设，因此不限制是在云端生码平台使用，还是本地AI辅助研发使用，把其当作一个正常monorepo仓库即可，projects目录会通过git submodule聚合需求相关的所有子仓库：

整体设计以 CodeAgent CLI 的 Command 机制作为工作流节点的推进方式，每次触发时将文件内容作为 Prompt 注入当前对话，天然支持在 Prompt 中声明调用 MCP 工具和 Skills。我们将每个交付节点的任务意图写成一个 Command，由平台在适当时机依次触发，从而将 CodeAgent CLI 的单次对话能力串联为一条可编排的多节点工作流。

工作流由固定节点和动态节点两类构成，动态节点的数量与内容由需求场景定义，整体执行顺序为：需求准备 → 动态节点（1~N 个）→ 构建部署：

特点：任务确定性低，需求方向由产品随业务发展决定，无法提前穷举；改动范围跨功能模块，Agent 需要在运行时理解架构、定位入口、正确调用组件 API，任何一步出偏差都会导致生码质量大幅下滑。

• 核心挑战及解决思路

迁移重构方案成立的前提是“规则可穷举”——旧写法有限、新写法固定，架构说明文档可以覆盖所有场景。但日常迭代打破了这个前提：需求由产品随业务发展决定，功能点的组合无法预先穷举，每个需求涉及的改动无法预知。

该场景落地初期，沿用了迁移重构场景的思路，用一份大而全的架构规范文档 + 多个领域 Skills来覆盖所有日常迭代场景，但效果远低于预期，暴露出系统性缺陷：

信息过载：单次生码任务注入过多的上下文知识，关键信息容易被低价值信息稀释，实际起作用的知识密度很低。

知识来源多元、优先级不明确：架构规范、大而全的领域Skills、CodeBase 检索结果同时注入上下文，各来源对同一问题的描述存在重叠甚至冲突（如 Formily 用法在架构规范和 Skill 中均有描述），Agent 无法判断以谁为准，容易产生幻觉。

链路过长、衰减严重：需求输入 → 理解架构规范 → 加载 Skills → 搜索代码位置 → 推导方案 → 生码，6+ 步链路，每步都可能引入噪声，最终输出与预期的偏差随链路长度指数级放大。

核心问题在于：给 Agent 的是通用、抽象的知识，但生码需要的是具体、精确的信息。优化方向不是“给更多知识”，而是“给恰好够用的精确知识”。

因此，日常迭代场景的优化核心在于两点：将知识预编译（把通用架构知识转化为功能点粒度的精确信息，让 Agent 生码前可以先精确召回本次需求需要的研发指引）；将获取动静分离（按需求点一次性召回静态研发指引，生码过程中再按需动态查询组件、 API 等知识，避免无关信息占用上下文）。整体基于「产品功能树」的思路，为每个业务应用预先梳理功能点与代码位置的映射关系，配合分层研发指引（功能点层 → 应用层）沉淀精细化知识，以检索替代推理，实现确定性更高的生码效果。

以下拿「商家营销工具日常迭代」场景举例，介绍日常迭代研发任务的生码优化策略：

• 引入功能树：以查表替代推理

在前期一股脑丢改Agent足够多的知识受挫后，尝试大道至简，发现只给Agent当前需要实现功能的代码入口，结合它自身的CodeBase检索，也能比之前的生码效果好，于是摸着这个“石头”进一步引入了产品功能树的能力。功能树是日常迭代生码优化的核心载体，它将每个业务应用的所有功能点预先整理成一棵树状结构：

└─ 优惠券   ├─ 首页   │  ├─ 首页_面包屑   │  ├─ 首页_公告   │  ├─ Banner   │  │  └─ 推荐设置入口   │  ├─ Tab切换   │  │  └─ Tab拓展区   │  │     ├─ 批量创建   │  │     └─ 存储版数量查看   │  ├─ 券管理列表   │  │  ├─ 券管理列表_筛选表单   │  │  ├─ 券管理列表_单元格展示   │  │  └─ 券管理列表_列表操作   │  ├─ 查看活动数据   │  └─ 创建页入口列表

生码之前先对原始需求进行需求系分，拆解为多个需求点，每个需求点独立执行生码逻辑，在生码前 Agent 通过 alex-code-knowledge MCP  将当前需求点与功能树节点进行匹配，若匹配到，直接返回精确的代码位置和研发指引，整个“理解架构 → 搜索代码 → 推导方案”的推理链路被压缩为一次查表操作。

• 研发指引的分层与按需获取

功能树解决了“匹配到功能点时，如何给精确知识”的问题，还需要在此基础之上设计分层研发指引，来保证可以覆盖更多场景。

分层：提上限与保下限

功能树只能覆盖当前已有的功能，无法预知未来产品新增的功能，因此需要设计分层的研发指引，把和功能点不强相关的部分放在应用层。

当需求点匹配到了功能树中已有的节点时，Agent 可以获得高度精确的指引。当需求点涉及全新功能或功能树尚未覆盖时，应用层的通用规范承担了兜底研发指引的职责，确保 Agent 即便在“未知领域”生码，也能遵循当前应用的技术选型和开发规范，提上限、保下限。

按需：编码中动态查组件

即便静态指引覆盖了大部分场景，生码过程中仍会遇到“这个组件具体支持哪些 Props”这类组件 API 层面的知识缺口。集团内的luna资产中心可以解决这类问题，但由于营销中后台公共组件、utils较多，全量迁移至luna成本较高，因此先通过一个资产使用指引Skill来包装各种资产的查询方式，内部调用各个平台（luna、codewiki、anpm）的开放接口，但实际执行过程中发现Agent的指令遵循度较差，常常弄错当前npm包应该调用哪个开放接口获取。

后面思路做了转变，这个Skill内部的逻辑本质就是一堆switch case，如果把这堆死板的路由逻辑直接丢给Agent，相当于让一位米其林主厨不去专注火候与调味，而是被按在仓库里靠翻纸质台账核对配料编号——不仅大材小用，更会严重干扰他的核心创作节奏。改变后，我们通过包装统一的营销中后台资产查询MCP，将组件和Utils的参数获取收敛到工程链路中，Agent只需按需调用，即可动态获取精确上下文。这也成为了我们后续的最佳实践：确定性逻辑交还工程，不确定性决策留给Agent，真正做到“合适的角色做合适的事”。

• D2C & API 还原效果优化

日常迭代需求中，经常包含设计稿（D2C）和接口（API）的引用，这两类输入在早期版本中也是生码质量下滑的高频原因，需要专项优化。

D2C 还原：结构分析驱动实现策略

约定需求描述中存在 @D2C（d2c模块Id），会走到D2C还原链路。借助Imgcook D2C MCP可以将设计稿一键转换为 React 组件代码，早期实现中 Agent 获取到 D2C 结果后直接开始编码，忽略了一个关键问题：当前项目中可能已存在对应组件，此时应该“样式迁移”还是“结构重写”，Agent 完全靠猜，导致频繁选错策略。

对应的优化方式是：Agent在生码过程中先判断当前功能点是否已经存在，同时结合D2C的结果执行结构分析流程，再决定实现策略：

1. 提取 D2C 的 DOM 层级树，标注每层布局方式（flex 方向、嵌套层级、元素顺序）

2. 若存在现有组件，同步绘制现有组件的 DOM 层级树，与 D2C 逐层对比

3. 输出差异清单：明确标注哪些元素需要【删除】、【新增】、【移动】、【布局变更】

4. 确定实现策略：差异涉及布局重构 → 结构重写；差异仅为样式数值 → 样式迁移

API 接口：结构化解析 + 服务层 mock

约定需求描述中存在 @API（接口Id，注册在业务功能树上），会走到API解析链路。借助alex-code-knowledge MCP ，可以获取到接口的完整定义（path、method、params、response），Agent 在拿到接口定义后需完成三件事：类型生成、结构处理、接口数据mock：

类型生成：根据 params 生成请求参数 interface，根据 response.model 生成响应 VO。需要注意 params/response 均为 JSON 字符串，使用前必须先解析；response 中的注释往往包含枚举说明（如 status: 1|2|3, //1-草稿,2-审核中,3-生效），需转为代码中的状态映射常量，而非硬编码数字。

结构处理：营销中后台接口遵循统一的响应结构，Agent 需按固定模式处理——检查 success 字段判断请求结果，从 model 字段提取业务数据，将 msgInfo 作为错误提示展示；分页场景下分页字段（curPage、pageSize、totalCount）统一在 model 中。

接口数据mock：需求中出现“接口未实现”时，会在服务函数内部直接生成 mock 数据并返回，同时用注释保留真实调用逻辑，供服务端实现后一键切换。

当需求输入中同时包含 @D2C  和 @API 时，两个 MCP 并行调用后以 API 的 response 为准定义 VO 类型，将 D2C Mock 数据的字段映射到 API 真实字段，避免 D2C Mock 数据结构混入生产代码。

• 知识沉淀的正向循环

功能树最初由人工梳理，随需求量增长，人工维护成本会成为瓶颈。为此，在工作流中引入了知识自动沉淀机制，让每次需求迭代的产出不只是代码，还会同步回流到功能树，每次迭代完成后，可一键触发功能树沉淀流程，基于本次需求AI生成的结果，以及人工干预的过程进行Skill新增或扩充，并自动挂靠在对应功能点上。

通过功能树沉淀能力，可建立起一套正向循环机制，功能树覆盖的需求会越来越多，人工需要的干预会越来越少：

• 落地效果

商家营销工具日常迭代：在已落地的 10+ 业务需求中，基本可实现平均 50% 以上的 AI 生码采纳率，部分需求类型下，采纳率可达80%以上。

整体来看，功能树覆盖的需求点，生码完成度可从原来的 40%~50% 提升至 80%~90%；未覆盖的需求点，Agent 仍可依靠自主研发能力完成基础实现，人工二次干预补齐剩余部分。随着功能树节点的不断扩充，整体覆盖率持续提升，形成可持续改善的提效飞轮。

总结与反思

FY26 S2，营销中后台的AI生码提效探索完成了一次系统性升级——从 S1 的“点状辅助”演进为覆盖需求交付全链路的“一体化工作流”。

在大量实践中，也沉淀出几条可复用的方法论：

• 给恰好够用的精确知识，而非更多知识：上下文过载是生码质量下滑最常见的根因，知识的精确度比知识的完整度更重要。

• 确定性逻辑交还工程，不确定性决策留给 Agent：将可枚举的路由、映射、格式处理收口到工程链路，让 Agent 专注于真正需要推理的创作任务，实现"合适的角色做合适的事"。

• 知识要形成正向循环，而非一次性投入：通过功能树的自动沉淀机制，每次需求迭代的产出不只是代码，还会回流为下次生码的知识资产，构建可持续改善的提效飞轮。

当前方案仍有持续演进空间：功能树的覆盖率随业务迭代自然增长，分层研发指引也会随需求类型的丰富不断完善。从更长远的视角看，随着 AI 能力的持续升级和私域知识库的不断沉淀，营销中后台的AI生码路径将朝着更高自动化程度、更低人工干预成本的方向持续演进。