3.0 KiB
3.0 KiB
淘天营销中后台生码工作流最佳实践
来源： 微信公众号 - 大淘宝技术 作者： 营销前台技术团队（大淘宝技术） 日期： 2026年4月27日 16:16 标签： #淘天 #营销中后台 #AI生码 #云端托管 #工作流 #大淘宝技术
升级路径总览
核心决策：从"本地+云端双路径" → 统一收敛至云端托管生码（基于 AoneSuper）
三个核心工程：
- 跨仓库工作区（git submodule + turborepo）
- 可编排场景化工作流
- 知识自动沉淀（功能树 + 领域 Skill）
核心方法论：
- 给恰好够用的精确知识
- 确定性逻辑交工程
- 知识建正向循环
为什么弃用本地研发
| 问题 | 具体表现 |
|---|---|
| 环境配置难统一 | 系统版本、Node 版本、网络代理差异巨大，排查困难 |
| AK 管理困难 | 生态用工需明文存储 AK 在个人设备，分发/轮换/回收无管控 |
| 执行易中断 | 电脑息屏/网络断开导致长任务中断，需手动续跑 |
为什么选 AoneSuper 而非自建
S1 自建了基于 LangGraph 的多 Agent 架构，但发现：
- 基建维护成本高
- CodeAgent CLI 社区生态（Skills、MCP、SubAgent）迅速成熟
- 自建 LangGraph 方案边际收益递减
结论： 接入 AoneSuper，投入重心从基建打磨转向业务效果优化。
跨仓库工作区
设计思路
- 聚合需求仓库：创建"需求工作区"文件夹，聚合所有相关仓库
- 引入 git submodule：外层文件夹作为独立 git 空间，用于存放 Agent 配置（Skills、MCP、SubAgent）和中间产物（需求理解、方案设计、任务列表等）
- 消除副作用：通过脚本自动化 submodule 操作，降低同学理解成本
研发调试优化
利用 turborepo 的 monorepo 构建能力，实现：
- 一键启动所有需求子仓库服务
- 自动配置子仓库间的依赖 link
- 解决多层依赖（基础组件 → 业务组件 → 前端业务）的调试问题
可编排场景化工作流
两种场景的差异化策略
场景一：迁移/重构（高确定性）
- 已有明确的"A 迁移到 B"的确定性逻辑
- 架构说明文档 + 领域 Skill 固化规则
- 将迁移/重构的逻辑转化为可复用的领域能力
场景二：日常迭代（低确定性）
- 需求边界模糊，需要大量上下文
- 引入功能树实现精准查表式知识供给
- 辅助 D2C（Design-to-Code）/ API 还原优化
功能树
核心思想：将一个项目的结构化知识（路由、组件、数据流、API）提取为树形索引，Agent 在接到需求时可以快速"查表"定位到代码位置，而不是大海捞针。
知识自动沉淀
通过持续积累，形成提效飞轮：
- 生码过程中发现知识盲区
- 补充功能树 / 领域 Skill
- 下次生码质量提升
- 释放人力持续补充更多知识