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