---
title: "面向Skills编程-淘宝企业购端对端研发提效实践"
source_url: "https://mp.weixin.qq.com/s/8wJhwC4YuaOX-8GXMaFU5g"
publisher: "大淘宝技术（行业运营技术）"
author: "官亭（淘天集团-行业运营技术团队）"
published: "2026-06-17"
ingested: "2026-06-17"
sha256: "e243af981ced29d0c56175cd2bce7b3aefbeb4a7c1c8e942e07132403d4ac665"
type: raw
tags:
  - skills-driven-programming
  - agent-skills
  - anthropic-skill-standard
  - skill-md
  - enterprise-domain
  - taobao
  - sddspec-driven
  - vibe-coding
  - three-layer-architecture
  - adjustment-plan
  - knowledge-engineering
  - progressive-disclosure
---

# 面向Skills编程-淘宝企业购端对端研发提效实践

> 本文提出"面向Skills编程"范式——将领域知识、工作流、约束规则封装为可版本化的Skills单元，让LLM在确定性框架内生成代码，实现从"人写代码"到"人沉淀Skills，AI写代码"的研发范式升级。以企业购客户对接场景为实战验证，通过项目评估、技术方案、代码生产的研发SOP构建，实现**商品域端到端交付周期缩短65%，代码一次生成成功率达90%**。

## 核心理念：从"配置化编程"到"面向Skills编程"

### 传统范式的天花板

过去我们应对业务变化的经典策略是 DDD 分层 + 配置化：通过领域建模拆分业务能力，通过配置参数驱动行为差异。这套模式在以人为主的传统研发模式下有效，但面对高频定制化需求时，由于人力的稀缺，依然存在交付瓶颈。

当定制化需求高频出现时（如企业购每个客户接口都不同），**配置化的参数空间爆炸，SPI 扩展点变成了"每次都要写的代码"**，开发者本质上还是在手写适配逻辑——DDD 实现了架构解耦，但没有解决重复编码的问题。

### 新范式：面向 Skills 编程

面向 Skills 编程的核心思想是：将"人写代码"转变为"人写 Skills，LLM 基于 Skills 写代码"。程序员向更高一层抽象——从"实现逻辑"上升为"定义 Skills"，基于 Skills 将个人经验转化为可复用的 AI 能力单元。

**类比理解**：如果说传统编程中"接口/抽象类"定义了代码的契约，那么 Skills 就是定义了 AI 行为的契约——它告诉 LLM "做什么、怎么做、不能做什么"，就像接口定义告诉实现类"必须实现什么方法"，让大模型从"知道分子"成为"行动专家"。

### 范式对比

| 维度 | DDD + 配置化 | 面向 Skills 编程 |
|------|-------------|------------------|
| 抽象对象 | 领域模型 + 配置参数 | Skills（工作流 + 知识 + 约束） |
| 复用单元 | 领域服务 | Skill 单元（SKILL.md + references/ + scripts/） |
| 开发者角色 | 编码实现者 | Skills 定义者 + AI 编排者 |
| 适配逻辑 | 散落配置 | 集中在适配层 Skill |
| 适合场景 | 业务稳定期 | 高频定制化需求 |

### 通用架构

垂直领域的 Skills 本身不通用，但**构建 Skill 的方法论是通用的**——识别重复模式 → 封装不变量为 Skills → 将变化的部分作为输入 → LLM 在约束下执行。

### 维度评估：你的场景是否适合引入 Skills

适用场景：
- 重复模式明显（执行流程高度相似，变化只是输入数据）
- 领域知识丰富（专家经验可显式化、可文档化）
- 输出可控（可定义验收标准、自动测试）
- 价值密度高（高频定制 + 重复劳动严重）

不适用场景：
- 一次性任务（沉淀成本 > 收益）
- 领域知识模糊（专家都说不清楚）
- 输出难以验证（无客观 ground truth）

### 四步构建 Skill 体系

不论你在什么业务域，都可以按以下四步构建自己的 Skill 体系：
1. **识别重复模式** — 找出高频出现、流程相似的任务
2. **封装不变量** — 把不变的流程、规则、领域知识封装为 Skill
3. **变化部分作为输入** — 把客户特定信息作为 Skill 输入参数
4. **LLM 在约束下执行** — Skill 驱动 LLM 按标准化流程产出结果

## 业务背景：企业购客户对接

### 业务模式

面向企业客户的采购需求，淘宝企业购提供完整的解决方案。在标准模式（SKA 模式）下，企业购提供完善的 TOP 标准接口，支持外部客户自主对接。

然而在实际业务拓展中，大量大中型客户自身已具备成熟的系统和接口规范：
- **自研内部商城**：如某大型政府机构，内部自建采购商城系统，有自己的接口协议
- **外部 SAAS 商城**：如使用第三方 SAAS 采购平台的客户，遵循 SAAS 平台的接口规范

这些客户改造自身系统来适配企业购标准接口成本较高，**因此需要企业购反向适配其系统接口**——由此衍生出"客户定制对接"这一高频研发场景。

### 三大业务域

对接工作涉及三大业务域：
- **商品**：商品信息同步、类目映射
- **交易**：订单创建、物流同步、逆向
- **结算**：对账、结算单、发票管理

由于每个客户的接口规范各不相同，适配代码几乎无法跨项目复用，每次对接都需要从文档评估到代码开发全流程重新执行。

### 四大典型特征

这一业务模式具有四大典型特征：
1. 对外对接高频
2. 需求碎片化
3. 技术方案重复度高
4. 交付周期敏感

**核心问题**：当前以人工为中心、AI 辅助的研发模式无法满足业务"快交付、低成本、高灵活"的诉求。

## 成果速览（2025.8 - 2026.2）

经过近半年的系统性探索与实践，团队在三个维度取得了阶段性成果：

### 研发范式升级
从"依赖个人经验的对话式编程"迈向"基于 Skills 的工程化 AI 协作"。

### 研发效率提升
**商品域端到端交付周期从 23.5 人日缩短至 8 人日，整体提效 65%**，代码一次生成成功率从早期不足 50% 提升至当前 **90%**。

### 技术沉淀
构建了覆盖全链路的 Skills 体系和端到端生码平台，将个人经验转化为可复用的组织能力资产。

## 五阶段演进路径

过去半年，团队围绕架构解耦、AI 编程、AI 工具应用三大方向进行了系统性探索，演进路径与 AI 技术发展趋势高度一致，每一阶段都是对前一阶段"天花板"的突破。

### 阶段 1：Vibe Coding — 以对话驱动需求具象化（2025.8）

**落地项目**：某大型 ISV

**做法**：基于弹外架构独立部署的安全性优势（可使用所有开源代码、最新大模型和 AI 工具），团队开始尝试以自然语言对话驱动代码生成。开发者通过与 AI 对话描述业务需求，AI 直接生成适配代码。

**效果**：迈出了 AI 编程的第一步，验证了对话式编码在外部接口适配场景中的可行性。

**瓶颈**：
- 产出质量不稳定：完全依赖个人 Prompt 技巧
- 难以复用：知识散落在临时对话中
- 强依赖个人能力：AI 输出质量与提示词工程能力相关

### 阶段 2：Prompt 模板 — 标准化"业务→技术"的语义翻译器（2025.9）

**落地项目**：某大型企业

**做法**：采用流程模板化 + 子任务 Prompt 模板双轨策略：
- **流程模板化**：将共性环节（如"商品同步"）抽象为可复用的对接模板，分离变与不变的逻辑，对接新客户仅需在已有模板基础上开发变化部分
- **子任务 Prompt 模板**：将开发过程拆分为多个子任务（脚手架搭建、接口对象生成、对象映射、接口串联），为每个子任务预置结构化 Prompt 模板

**效果**：
- AI 生成代码**采纳率 70%**
- 4 类 Prompt 模板形成可复用资产

**瓶颈**：
- **问题一**：AI 发散不可控，无法提前预览设计思路（发现问题时代码已生成）
- **问题二**：单点提效，无法承载 SOP（执行不可控 + SOP 与推理任务本质冲突 + 缺乏能力基座）

### 阶段 3：SDD（规范驱动开发）— 构建研发流水线的"数据契约"（2025.12）

**落地项目**：SAAS 项目

**做法**：引入 SDD 方法论，用结构化规格文档驱动 AI 生成。在 SAAS 项目中使用 **OpenSpec 工具** 验证 Spec 编程的可行性——通过工程规范、开源知识库、业务约束三层引导。

**效果**：
- AI 生成代码**可用率从 40% 提升至 80%**

**瓶颈**：
- 流程执行成本高（单个 Spec 从编写到定稿需 3-5 轮人工交互）
- 强依赖个人经验，无法规模化
- 领域知识未固化（SPU/SKU 混淆、ID 字段混淆等问题跨项目反复出现）

### 阶段 4：Skill 沉淀 — 将经验固化为可复用的 AI 能力单元（2026.1-2）

**落地项目**：某大型 ISV

**做法**：采用 **Anthropic Agent Skills 标准**（SKILL.md + references/ + scripts/）将领域经验封装为 Skill，实现"经验即代码"——工作流写在 SKILL.md 里，领域知识放 references 目录，通过版本控制管理。

最终构建了一条从客户接口文档评估到代码生产的 AI 全链路流水线，覆盖"**文档评估 → 技术方案 → 编码**"的完整链路，用 15 个接口项目跑通了商品域整个流程。

**效果**：
- 代码一次生成成功率从 50% → 90%
- 适配层代码量减少 60%
- 原子服务复用覆盖 90%+ 对接场景

**瓶颈**：
- 面向技术同学，产品和业务上手门槛高（依赖 Cursor 等本地 IDE 环境）
- 依赖本地 IDE 环境，无法规模化推广
- 能力无法产品化输出

### 阶段 5：云端集成 — 打造端到端 AI 研发产品（2026.2 探索中）

**做法**：利用 **OneDay 搭建前端交互界面**，结合 **Aone 沙箱**提供的代码编译与执行环境，自行搭建了端到端的生码平台原型。核心思路是将已验证的 Skill 能力从本地 IDE 迁移到云端，让非技术人员通过 Web 界面即可触发全链路流水线。

**当前进展**：
- 基于 OneDay + Aone 沙箱的生码平台已搭建完成
- 商品域全流程已在平台上端到端验证通过
- 验证了 Skill 从本地 IDE 到云端平台迁移的可行性

## 方法论沉淀

### 架构先行：分层架构设计

**为什么架构优化是 AI 编程的前提？**

代码分层越清晰，AI 生成质量越高。架构优化不是为优化而优化，而是**为了让 AI 能够更好地理解和生成代码**。

通过代码分层，将系统拆分为**原子能力层、模板层、适配层**三层架构：
- **原子能力层**：稳定不变的底层服务（如 ItemClientWrapper、请求/响应基类）
- **模板层**：标准化流程模板（业务流程骨架 + 通用处理逻辑）
- **适配层**：客户特定适配逻辑（接口转换、字段映射、协议适配）

**AI 生成的代码仅聚焦于适配层**——这将 AI 的工作范围从"理解整个系统"收敛为"在固定框架内填充适配逻辑"，大幅降低了 AI 生成的复杂度和出错概率。

**实际效果**：
- 适配层代码量减少 60%
- 多客户并行开发零冲突
- 原子服务复用覆盖 90%+ 对接场景

### 垂直领域 Skill 的构建与调优

**为什么做垂直领域 Skills？**

构建领域专家，而不是通用方案。选择垂直深耕而非通用方案，基于两个核心判断：
- 垂直域深耕 ROI 更高（围绕企业购做深耕，最大程度提升研发效率）
- 通用方案短期不可行（Spec 范式流程验证已完成，但网站技术域涉及广，做通用方案成本高）

**期望**：在构建专业垂直领域 Skill 的过程中沉淀调优经验和方法论，使之可复用于其他领域快速构建 Skill——垂直领域的 Skill 本身不通用，但构建 Skills 的方法论是通用的。

**Skill 构建思路**：
- **Spec 驱动原则**：通过提升项目评估、技术方案等前置链路准确性，实现生码准确率提升——**前序环节的质量决定了后续环节的天花板**
- **工程师思维**：先完成链路搭建，再基于实际项目拆解到不同节点进行问题分析
- **借鉴和学习**：参考 Anthropic 官方最佳实践（三层架构）、优秀开源项目经验（everything-claude-code、superpowers）

### 实际案例：成功率 50% → 90% 的攻破过程

核心在于解决三大类问题：
1. **接口提取幻觉**
2. **复杂逻辑输出不稳定**
3. **长上下文导致信息丢失**

#### 评估报告阶段

**问题 1：接口提取——AI 幻觉导致遗漏**

早期完全依赖模型提取接口，模型幻觉导致接口遗漏或误提，错误沿流水线逐级放大。

**典型案例**：客户项目 A4.5 节标题为"获取所有图片信息"，模型未识别为接口定义，直接跳过。

**解决方案**：**脚本提取为主，AI 辅助校验**。核心思路是把"提取"这个对准确性要求极高的环节从模型能力中剥离出来，改用确定性的脚本解析，AI 只负责前后两端（理解格式 + 检查补漏）。

**问题 2：领域知识缺失——映射关系混乱**

AI 缺乏商品域业务知识，导致字段映射方向搞反、ID 混淆、参数丢失等问题。

**解决方案**：**领域知识内嵌**——把人脑中的业务经验转化为 Skill 的 references 和约束规则，让 AI 从"通用地写代码"变成"带着领域知识写方案"。

#### 技术方案阶段

**问题 1：推拉模式混杂——生成代码与实际系统 API 不对齐**

早期推模式和拉模式混在一个 Skill 里生成方案，导致上下文膨胀、AI 凭空编造接口签名和 DTO 结构。

**解决方案**：**领域架构拆分**，按调用方向拆分链路 + 系统 API 抽象注入。

**问题 2：长文档输出崩塌**

某 ISV 15 个接口，AI 仅完整实现前 4 个，后续用"类似"带过。

**解决方案**：**将方案生成 Skill 拆为 4 个子 Skill**，每个接口在独立上下文中处理。本质是用架构手段解决模型能力边界问题——不指望模型在超长上下文中保持一致性，而是把问题拆到模型能稳定处理的粒度。

```
pull-generator（编排）
    │
    ├── pull-indexer              脚本解析评估报告 → JSON 索引（含子章节行号）
    ├── pull-model-designer       按子章节精确读取参数 → 设计通用基类
    ├── pull-interface-generator × N    单个接口独立处理（每个 ~8k tokens）
    └── 汇总组装                  拼装 N 个接口文件 → 最终文档
```

**问题闭环**：同类问题跨项目、跨模型反复出现（如 X 系统修了 SPU/SKU 混淆，换 B 系统又犯），通过 **ADJUSTMENT_PLAN 机制**（发现 → 定位 Skill → 补约束 → 验证 → 交叉验证）将 11 类高频问题全部沉淀为 Skill 约束，不再复现。

#### 代码生产阶段

**问题：AI 生成的代码不可用**

**典型案例**：
- 项目骨架未初始化（pom.xml 占位符未替换、AKSK 未配置），代码放进去编译不过
- AI 用 ItemClient 而不是 ItemClientWrapper（后者封装了 ID 映射和参数校验），运行时报空指针
- 生成顺序不对：先生成 SPI 实现类，此时请求/响应基类还不存在，编译报错

**解决方案**：
1. **工程初始化 Skill 前置**：将项目骨架搭建（占位符替换、AKSK 生成、Maven 编译验证）拆为独立的 `ego-project-initialization` Skill，确保代码生成在一个可编译的工程上进行
2. **代码模板驱动生成**：将 ItemClientWrapper 使用方式、工具类 API、注解规范、Request/Response/Converter/SPI 四类代码模板注入 Skill 的 `references/code-templates/`，AI 按模板填充而非凭空编写
3. **按依赖顺序生成**：拉模式按"通用基类 → 请求类 → 响应类 → 转换器 → SPI 实现"的依赖顺序逐接口生成，避免前置类不存在导致编译失败

### 经验总结：Skills 构建原则

**基础认知**：

1. **Skills 是 AI 研发的最小可复用单元**：类比软件工程中"函数/类"封装逻辑，Skill 封装的是工作流 + 领域知识 + 约束规则——做什么（SKILL.md）、用什么知识做（references）、不能怎么做（约束与禁止项）。新客户对接不是从零开始，而是换一份输入文档跑同一条流水线。

2. **质量瓶颈不在模型，在知识工程**：50% → 90% 的提升**全部来自知识注入和约束迭代**，不是换更强的模型。领域知识（映射规则、API 签名、模式判定）不会从训练数据中涌现，必须显式注入。

3. **确定性工程 + 不确定性 AI = 可控的研发流水线**：高精度环节用脚本（接口提取），模型不稳定的用架构拆分绕过（推拉分离、子 Skill），反复出错的沉淀为约束——三者配合把"不可控的对话"变成"可复现的流水线"。

**质量控制四层防线**：事前约束 → 运行时约束 → 事后审查 → 人工卡点

**实际效果**（某 ISV 项目）：审查 Skill 对评估报告审查结果为**接口覆盖 15/15、字段遗漏率 0%、映射方向正确**。早期（X 项目）的 11 类高频问题已全部通过约束沉淀解决。

### 知识库建设

**为什么需要知识库？**

建设专有知识库，能让 AI 懂得业务现有的技术背景、领域知识、架构、流程、代码结构等知识。在 Skill 体系中，领域知识通过 references 目录内嵌到每个 Skill 中，但随着 Skill 数量增长，出现了知识分散、更新不同步、跨 Skill 复用困难等问题，需要构建统一的知识库体系来支撑。

**知识库三种存储载体协同**：
- **Git 知识仓库**：自建索引，支持渐进式拉取
- **KBase**：RAG 召回（文本块/原文），自然语言提问可召回代码片段 + 原文档链接
- **Code Wiki**：已完成试跑，生成的数据模型、开发指南、核心模块、API 参考符合预期，可通过 MCP 召回知识

**生产知识**：
- 多模态支持：钉钉文档、代码、PDF 等多种格式
- 多数据源：Git 知识仓库、Code Wiki、KBase 等
- 多种生成方式：人工维护（研发过程中沉淀的 Rules、可复用的原子 Skills）+ 自动生成 & 增量更新（如 KBase 支持的钉钉知识库同步、需求完成后 Hooks 自动更新）

**使用知识**：
- AI 研发流程自动加载知识，通用 Skills 隐藏底层检索细节
- 通用 Skills 通过标准化接口（如 MCP）访问知识库

**标准化知识管理（三级索引）**：

参考 Anthropic 官方 Skill 的渐进式加载策略（SKILL.md 触发时加载 + REFERENCE.md 按需加载），构建了三级索引结构：

```
ai_coding/
├── GUIDE.md            # 一级索引：使用指导，记录目录结构及索引文件位置
├── rules/              # 编码规范
│   ├── index.md        # 二级索引：记录所有规则的简单描述
│   ├── alibaba/        # 阿里巴巴编码规范
│   │   └── java编码规则规范.md  # 三级：知识本身，含元数据 + 使用示例
│   └── growth/         # Growth 业务规范
├── docs/               # 文档
├── skills/             # AI 技能配置
├── agents/             # AI Agent 配置
├── commands/           # 命令配置
└── package/            # 包配置（批量操作）
```

每个知识文件通过标准化元数据（name、description、tags 等）实现自描述，索引文件自动生成维护，支持按场景检索和按标签检索。

**知识分发工具 kn-fetcher CLI**：

构建了 CLI 工具 **kn-fetcher**，支持知识的拉取、搜索和批量分发：

```bash
# 拉取编码规范
kn-fetcher pull --platform aone-copilot --rules java-coding-standards
# 搜索知识
kn-fetcher search --rules java
# 批量初始化（一键拉取项目所需的所有知识）
kn-fetcher pull --platform aone-copilot --package growth-batch-pull
```

通过 init 命令一键完成通用知识的初始化下载，降低新人和新项目的知识配置成本。

**当前进展**：
- Code Wiki 已完成试跑
- KBase 已完成试跑
- 三级索引结构和元数据规范已定义完成
- kn-fetcher CLI 工具 6 个基础命令（pull / list / search 等）已完成

## 规划与展望：迈向"端到端智能交付"的研发未来

当前评估→方案→编码链路已验证，但**沙箱测试（TDD）、SubAgent 并行化**等能力尚未完全完成，仍有较大的提升空间，下一阶段将继续推进端对端研发闭环，进一步实现交付周期缩短。

## 结语

从 Vibe Coding 到 Skills coding，从 50% 的代码生成成功率到 90%，从 23.5 人日的交付周期到 8 人日——这不仅是工具链的升级，**更是研发范式的重构**。

**传统思维中，文档是代码的注释；而在 SDD 思维中，Spec 是源代码**——开发者维护规范，代码由 AI 生成。开发者的角色从编码执行者转变为审核者、架构师。

在 Skills 编程体系里，Skills 是人类最佳实践的能力封装。**开发者的角色从 AI 辅助研发，变成辅导 AI 进行研发**，人类彻底成为指挥 AI 进行工作的人，人类研发将更多精力投入到架构设计、代码审核、规范设计等更高价值的创造性工作中。

展望未来，当每个领域的最佳实践都能被沉淀为 Skills 时，意味着个人经验的产品化、标准化和资产化，AI 会真正从"知道分子"成为"行动专家"；**AI 不是替代者，而是为我们工作的数字专家**，帮助我们从重复劳动中解放，聚焦更高价值的创造。

## 团队介绍

本文作者**官亭**，来自**淘天集团-行业运营技术团队**。在企业购业务中，面向企业客户的采购需求，团队正深入构建 AI Agent 产品，围绕 AI 运营、AI 研发、AI 产品三大方向持续突破。团队当前急需前端、后端、QA 等方向的伙伴，如果你愿意一起来探索，欢迎联系 `zezhou.jzz@taobao.com`。