从 Vibe Coding 到 SDD：淘宝 AI 编码最佳实践分享

文章目录

[一、当"氛围编程"（Vibe Coding）走进工程世界](#一、当“氛围编程”（Vibe Coding）走进工程世界)
- [为什么 Vibe Coding 会让人"上瘾"](#为什么 Vibe Coding 会让人“上瘾”)
- [Vibe Coding 在工程中的天然缺陷](#Vibe Coding 在工程中的天然缺陷)
[二、淘宝的四个 AI 编码实践阶段](#二、淘宝的四个 AI 编码实践阶段)
- [阶段 A：代码补全 / 单方法改写](#阶段 A：代码补全 / 单方法改写)
- - [示例 1：对象构建自动补全](#示例 1：对象构建自动补全)
  - [示例 2：单方法重构](#示例 2：单方法重构)
  - 收益
  - 局限
- [阶段 B：Agentic Coding（一次性生成完整功能）](#阶段 B：Agentic Coding（一次性生成完整功能）)
- - Prompt示例
  - [AI 生成代码示例](#AI 生成代码示例)
  - 收益
  - 局限
- [阶段 C：Rules 约束 + 技术方案模板（关键转折点）](#阶段 C：Rules 约束 + 技术方案模板（关键转折点）)
- - [Rules 文件结构](#Rules 文件结构)
  - Rules："机器宪法"
  - [技术方案模板：人给 AI 的"标准输入"](#技术方案模板：人给 AI 的“标准输入”)
  - 收益
  - 局限
- [阶段 D：SDD（规格驱动开发）](#阶段 D：SDD（规格驱动开发）)
- - [spec.md 示例](#spec.md 示例)
  - 收益
  - 局限
三、当前最佳实践
- 实践流程
结语

最近阅读了淘宝在 AI 编码方向的最佳实践分享，围绕如何让 AI 在保证工程质量的前提下高效生成代码，系统总结了从早期探索到工程化落地的多个阶段。这些实践并非停留在工具或模型能力本身，而是聚焦于约束、规范与协作机制，对正在尝试将 AI 引入日常研发流程的团队具有很强的参考价值。

一、当"氛围编程"（Vibe Coding）走进工程世界

Vibe Coding 一词由 OpenAI 联合创始人 Andrej Karpathy 提出，其核心理念是：

开发者关注"我要什么结果"，而不是"代码怎么写"。

在这种模式下，开发者的主要工作变成了：

描述功能目标
说明一些约束条件
把实现交给 AI

例如：

"帮我实现一个 NN 红包模块，查询用户可用红包，按门槛排序，生成完整 Java 代码。"

AI 往往可以在短时间内给出一整套实现。

为什么 Vibe Coding 会让人"上瘾"

极快：从想法到可运行代码，分钟级完成
轻心智：不用写模板代码、不用查文档
强正反馈：AI 几乎"什么都能写"

但问题也非常明显。

Vibe Coding 在工程中的天然缺陷

Vibe Coding 的本质是：

重实现、轻约束

这在个人实验中问题不大，但一旦进入团队和长期维护，就会暴露风险：

同样的业务逻辑，不同人、不同时间生成的代码完全不同
AI 不知道项目已有的架构、规范、工具类
Prompt 无法标准化，团队协作极不稳定
短期看很快，长期维护成本急剧上升

于是问题变成了：

如何在不牺牲 AI 效率的前提下，把"工程约束"补回来？

二、淘宝的四个 AI 编码实践阶段

阶段 A：代码补全 / 单方法改写

这是最早、也是最容易落地的阶段。

示例 1：对象构建自动补全

java 复制代码

public List<ItemCardVO> buildItemCards(List<ContentEntity> entities) {
    List<ItemCardVO> result = new ArrayList<>();
    for (ContentEntity entity : entities) {
        ItemCardVO vo = new ItemCardVO();
        vo.setItemId(entity.getItemId());
        vo.setItemTitle(entity.getTitle());
        vo.setItemImg(entity.getPicUrl());
        result.add(vo);
    }
    return result;
}

示例 2：单方法重构

java 复制代码

// 重构前
public String getDiscountText(Long finalPrice, Long nnPrice) {
    if (finalPrice == null || nnPrice == null) {
        return "";
    }
    if (finalPrice <= nnPrice) {
        return "";
    }
    Long discount = finalPrice - nnPrice;
    if (discount <= 0) {
        return "";
    }
    return discount / 100.0 + "元";
}

// AI 重构后
public String getDiscountText(Long finalPrice, Long nnPrice) {
    if (finalPrice == null || nnPrice == null || finalPrice <= nnPrice) {
        return "";
    }
    Money discount = Money.ofFen(finalPrice).subtract(Money.ofFen(nnPrice));
    return discount.getCent() > 0 ? discount.getYuan() + "元" : "";
}

收益

键盘输入显著减少
局部重构效率提升明显

局限

只理解"当前方法"
没有项目级上下文
无法支撑完整功能交付

阶段 B：Agentic Coding（一次性生成完整功能）

为了解决"只能写片段"的问题，淘宝开始尝试 Agentic Coding ：用一段完整 Prompt，让 AI 一次性生成整个功能模块。

Prompt示例

实现 NN 红包模块

创建数据服务 NnRedPacketDataService

创建模块 VO

创建模块构建器

遵循现有项目规范

AI 生成代码示例

java 复制代码

@Component
public class NnRedPacketDataService implements DataService<List<FundQueryDTO>> {

    @Autowired
    private FpProvider fpProvider;

    @Override
    public List<FundQueryDTO> execute(InvocationContext context, JSONObject req) {
        String poolIds = req.getString("nnRedPacketPoolIds");
        List<Long> fundPoolIds = Arrays.stream(poolIds.split(","))
            .map(Long::parseLong)
            .collect(Collectors.toList());

        return fpProvider.queryUserFundBuyPoolId(
            context, fundPoolIds, customRuleId, securityCode
        );
    }
}

收益

功能交付速度从「天」级降到「小时」级
可以一次性生成可运行代码

局限

风格漂移：同一逻辑每次写法不同
没有延续性：AI 永远像"新同事"
团队协作差：Prompt 无法复用

阶段 C：Rules 约束 + 技术方案模板（关键转折点）

淘宝逐渐意识到：

AI 不是写不好代码，而是不知道"该怎么写才算对"。

于是淘宝引入了 Rules 体系，把项目规范"机器化"。示例如下：

Rules 文件结构

text 复制代码

.aone_copilot/
├── rules/
│   ├── code-style.aonerule
│   ├── project-structure.aonerule
│   ├── features.aonerule
├── tech/
│   └── NN红包模块-技术方案.md

Rules："机器宪法"

text 复制代码

- 类名使用 PascalCase
- 集合判空统一使用 CollectionUtils.isEmpty
- 数据服务必须实现 DataService<T>
- 模块构建器必须继承 BaseModuleBuilder

技术方案模板：人给 AI 的"标准输入"

markdown 复制代码

## 业务定义
NN 红包模块用于展示用户可用红包列表。

## 模块领域对象
| 对象 | 字段 |
|----|----|
| NnRedPacketVO | redPacketList / totalAmount |

## 数据服务
- 查询用户红包
- 过滤状态=可用、未过期

## 模块构建器
- 获取红包
- 排序
- 构建 VO

人写"做什么"，AI 负责"怎么写"。

收益

代码一致性显著提升
技术方案成为团队统一语言
新人上手速度明显加快

局限

文档可能滞后
业务语义理解仍然有限

阶段 D：SDD（规格驱动开发）

为了解决"理解偏差 + 文档失效"，淘宝尝试了 SDD，其核心理念如下：

规格是唯一真理源（Single Source of Truth）

所有的代码、测试、文档都从规格生成
规格即文档，文档永不过期

设计先于实现

先用自然语言描述"做什么"（规格）
再让AI生成"怎么做"（代码）

可测试性内建

规格中明确定义测试用例
自动生成完整的单元测试

spec.md 示例

markdown 复制代码

### FR-1 红包数据获取
- 调用 FpProvider 查询
- 过滤条件：
  - payStatus = 2
  - 未过期
  - 门槛 <= 20 元

收益

一致性显著提升
可测试性大幅提升
可维护性显著改善
团队协作效率提升

局限

规格编写成本高
工具链不成熟
不适合存量项目大规模推广

三、当前最佳实践

最终，淘宝没有"全量 SDD"，而是选择了工程实践中的最优解：

技术方案模板 + Rules + Agentic Coding + AI 自动汇总文档

实践流程

（1）人写轻量技术方案（30 分钟）

聚焦于"做什么"，而非"怎么做"。例子：

markdown 复制代码

# [需求名称] - 技术方案

## 一、业务定义
简要描述业务背景和目标（1～2 句话），说明这个需求解决什么问题、带来什么价值。

---

## 二、业务领域对象
如果需要 **新增 / 修改 BO 或 DTO**，在此说明；  
如果复用现有对象，可注明"无（复用 XXX）"。

---

## 三、模块领域对象
需要新增或修改的模块 VO 定义。

| 对象含义 | 实现方案 | 属性及类型 |
|---------|---------|-----------|
| [对象名] | 新增 / 修改 | 1. 字段1：类型 - 说明<br>2. 字段2：类型 - 说明 |

---

## 四、数据服务层
需要新增或修改的数据服务定义。

| 数据服务定义 | 实现方案 | execute 逻辑 |
|------------|---------|-------------|
| [服务名] | 新增 / 复用 | 1. 步骤1<br>2. 步骤2 |

---

## 五、模块构建器
需要新增或修改的模块构建器定义。

| 模块构建器定义 | 实现方案 | doBuild 逻辑 |
|--------------|---------|-------------|
| [构建器名] | 新增 / 修改 | 1. 获取数据<br>2. 处理逻辑<br>3. 构建 VO |

（2）AI 在 Rules 约束下生成代码

保证风格、结构、工具类一致。

（3）AI 自动汇总进架构与业务文档

让文档长期有效、可维护。

结语

Vibe Coding 打开了效率天花板，但工程化决定了能走多远。真正可落地的 AI 编码，不是"让 AI 随便写"，而是：

人定义规则和规格，AI 高效执行，人负责判断和演进。

参考文章：AI编码实践：从Vibe Coding到SDD