跳转至

面向 Skills 编程：大淘宝企业购 5 阶段演进与 Anthropic Agent Skills 标准实战

Ch04.034 面向 Skills 编程：大淘宝企业购 5 阶段演进与 Anthropic Agent Skills 标准实战

📊 Level ⭐⭐ | 27.4KB | entities/skills-driven-programming-taobao-enterprise-5-phase-evolution-2026-06-17.md

面向 Skills 编程：大淘宝企业购 5 阶段演进与 Anthropic Agent Skills 标准实战

原文存档：原文存档

概述

大淘宝技术（行业运营技术）官亭 2026-06 发布的 企业购端到端研发提效实战 是中文圈公开材料中最完整、最有数据、最有方法论沉淀的"面向 Skills 编程"案例库——5 阶段演进（Vibe Coding → Prompt 模板 → SDD → Skill 沉淀 → 云端集成）+ 完整数据（50% → 90% 代码一次生成成功率 / 23.5 人日 → 8 人日交付周期 -65% / 适配层代码量 -60% / 原子服务复用 90%+）+ Anthropic Agent Skills 标准深度落地（SKILL.md + references/ + scripts/）+ 三层架构（原子能力/模板/适配）+ ADJUSTMENT_PLAN 11 类高频问题闭环 + 三级索引知识库 + kn-fetcher CLI 6 命令。

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

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

1. 范式跃迁：从 DDD + 配置化到面向 Skills 编程

1.1 传统范式的天花板

过去应对业务变化的经典策略是 DDD 分层 + 配置化：通过领域建模拆分业务能力，通过配置参数驱动行为差异。这套模式在以人为主的传统研发模式下有效，但面对高频定制化需求时，配置化的参数空间爆炸，SPI 扩展点变成了"每次都要写的代码"——DDD 实现了架构解耦，但没有解决重复编码的问题。

1.2 新范式：面向 Skills 编程

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

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

1.3 范式对比

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

1.4 通用方法论

垂直领域的 Skills 本身不通用，但构建 Skill 的方法论是通用的——

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

2. 业务背景：企业购客户对接场景

2.1 业务模式

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

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

客户改造自身系统来适配企业购标准接口成本较高，因此需要企业购反向适配客户接口——"定制对接"模式由此诞生。

2.2 三大业务域

  • 商品：商品信息同步、类目映射
  • 交易：订单创建、物流同步、逆向
  • 结算：对账、结算单、发票管理

由于每个客户的接口规范各不相同，适配代码几乎无法跨项目复用。

2.3 四大典型特征

  1. 对外对接高频
  2. 需求碎片化
  3. 技术方案重复度高
  4. 交付周期敏感

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

3. 五阶段演进路径（2025.8 - 2026.2）

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

3.1 阶段 1：Vibe Coding（2025.8）

落地：某大型 ISV 项目 / 做法：自然语言对话驱动代码生成 / 效果：迈出 AI 编程第一步 / 瓶颈：产出质量不稳定 + 难以复用 + 强依赖个人能力

3.2 阶段 2：Prompt 模板（2025.9）

落地：某大型企业 / 做法：流程模板化 + 子任务 Prompt 模板双轨策略 / 效果：AI 生成代码采纳率 70%，4 类 Prompt 模板形成可复用资产 / 瓶颈：AI 发散不可控（无法提前预览设计思路）+ 单点提效无法承载 SOP

3.3 阶段 3：SDD 规范驱动开发（2025.12）

落地：SAAS 项目 / 做法：用结构化规格文档驱动 AI 生成，使用 OpenSpec 工具验证 / 效果：AI 生成代码可用率从 40% 提升至 80% / 瓶颈：流程执行成本高（单个 Spec 需 3-5 轮人工交互）+ 强依赖个人经验无法规模化 + 领域知识未固化

3.4 阶段 4：Skill 沉淀（2026.1-2）

落地：某大型 ISV 项目（15 个接口） / 做法：采用 Anthropic Agent Skills 标准（SKILL.md + references/ + scripts/）将领域经验封装为 Skill / 效果：代码一次生成成功率 50% → 90%；适配层代码量 -60%；原子服务复用 90%+ / 瓶颈：面向技术同学产品和业务上手门槛高 + 依赖本地 IDE 无法规模化推广 + 能力无法产品化输出

3.5 阶段 5：云端集成（2026.2 探索中）

落地：OneDay 前端 + Aone 沙箱 / 做法：将已验证的 Skill 能力从本地 IDE 迁移到云端，让非技术人员通过 Web 界面触发全链路流水线 / 当前进展：平台已搭建完成，商品域全流程已端到端验证

4. 核心技术：三层架构 + Skill 体系

4.1 三层架构：原子能力 + 模板 + 适配

通过代码分层，将系统拆分为原子能力层、模板层、适配层三层架构：

层级 内容 AI 是否介入
原子能力层 ItemClientWrapper、请求/响应基类、工具类 API 否（稳定不变）
模板层 业务流程骨架、通用处理逻辑 否（预定义流程）
适配层 客户特定接口转换、字段映射、协议适配 是（AI 唯一工作范围）

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

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

4.2 为什么做垂直领域 Skills？

构建领域专家，而不是通用方案。选择垂直深耕而非通用方案，基于两个核心判断：

  • 垂直域深耕 ROI 更高：围绕企业购做深耕，最大程度提升研发效率
  • 通用方案短期不可行：网站技术域涉及广，做通用方案成本高

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

4.3 Skill 构建思路

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

5. 成功率 50% → 90% 的攻破过程

团队分三个阶段解决了接口提取幻觉、复杂逻辑输出不稳定、长上下文导致信息丢失三大类问题。

5.1 评估报告阶段

问题 1：接口提取——AI 幻觉导致遗漏。典型案例：客户项目 A4.5 节标题为"获取所有图片信息"，模型未识别为接口定义直接跳过，错误沿流水线逐级放大。

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

问题 2：领域知识缺失——映射关系混乱（字段映射方向搞反、ID 混淆、参数丢失）。解决方案：领域知识内嵌——把人脑中的业务经验转化为 Skill 的 references 和约束规则。

5.2 技术方案阶段

问题 1：推拉模式混杂导致生成代码与实际系统 API 不对齐（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 个接口文件 → 最终文档

不指望模型在超长上下文中保持一致性，而是把问题拆到模型能稳定处理的粒度。

5.3 代码生产阶段

典型问题： - 项目骨架未初始化（pom.xml 占位符未替换、AKSK 未配置） - AI 用 ItemClient 而不是 ItemClientWrapper，运行时报空指针 - 生成顺序不对：先生成 SPI 实现类，此时请求/响应基类还不存在，编译报错

解决方案： 1. 工程初始化 Skill 前置：ego-project-initialization Skill 确保代码生成在可编译的工程上进行 2. 代码模板驱动生成：将 ItemClientWrapper 使用方式、Request/Response/Converter/SPI 四类代码模板注入 Skill 的 references/code-templates/，AI 按模板填充而非凭空编写 3. 按依赖顺序生成：拉模式按"通用基类 → 请求类 → 响应类 → 转换器 → SPI 实现"的依赖顺序逐接口生成

5.4 ADJUSTMENT_PLAN 闭环机制

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

6. 经验总结：Skills 构建的核心原则

6.1 基础认知

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

  2. 质量瓶颈不在模型，在知识工程——50% → 90% 的提升全部来自知识注入和约束迭代，不是换更强的模型。领域知识不会从训练数据中涌现，必须显式注入。

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

6.2 质量控制四层防线

事前约束 → 运行时约束 → 事后审查 → 人工卡点，贯穿评估→方案→代码全链路。

实际效果：审查 Skill 对评估报告审查结果为接口覆盖 15/15、字段遗漏率 0%、映射方向正确。

7. 知识库体系：三级索引 + kn-fetcher CLI

7.1 为什么需要知识库？

建设专有知识库，能让 AI 懂得业务现有的技术背景、领域知识、架构、流程、代码结构等知识。

7.2 三种存储载体协同

载体 特性 用途
Git 知识仓库 自建索引 支持渐进式拉取
KBase RAG 召回 文本块/原文，自然语言提问召回代码片段 + 原文档链接
Code Wiki 自动生成 数据模型、开发指南、核心模块、API 参考，通过 MCP 召回知识

7.3 三级索引结构（借鉴 Anthropic 渐进式加载）

参考 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 等）实现自描述，索引文件自动生成维护。

7.4 kn-fetcher CLI 工具

# 拉取编码规范
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 命令一键完成通用知识的初始化下载，降低新人和新项目的知识配置成本。

8. 核心金句（agent 视角提炼）

8.1 "质量瓶颈不在模型，在知识工程"

50% → 90% 的提升全部来自知识注入和约束迭代，不是换更强的模型。领域知识不会从训练数据中涌现，必须显式注入——这是 Skills 范式与传统 Fine-tuning / RAG 的根本区别：Skills 把知识放在工作流旁边，而不是藏在系统提示词深处。

8.2 "确定性工程 + 不确定性 AI = 可控的研发流水线"

高精度环节用脚本，模型不稳定用架构拆分绕过，反复出错沉淀为约束——这是大淘宝官亭的核心方法论，把"AI 编程"从"玄学调 Prompt"转变为"可工程化的流水线"。

8.3 "Skills 是 AI 研发的最小可复用单元"

类比软件工程中"函数/类"封装逻辑，Skill 封装的是工作流 + 领域知识 + 约束规则。做什么（SKILL.md）、用什么知识做（references）、不能怎么做（约束与禁止项）——三个维度决定了 Skill 的可复用性。

8.4 "AI 不是替代者，而是为我们工作的数字专家"

帮助我们从重复劳动中解放，聚焦更高价值的创造。开发者从编码执行者转变为 Skills 定义者 + AI 编排者，这是 AI 时代程序员的核心定位。

8.5 "前序环节的质量决定了后续环节的天花板"

Spec 驱动原则强调项目评估、技术方案等前置环节的准确性——生码准确率的天花板由前置环节决定。这是 SDD/Skills 范式共同的元方法论。

9. 库内相关实体的交叉

9.1 Skill 主题相关

9.2 Harness / 工具 / 范式相关

9.3 实战案例相关

10. 孤儿 raw 提示（pre-existing issue）

发现库内 pre-existing 孤儿 raw：raw/articles/agent-skill-iterative-writing-taobao-logistics.md（淘天物流技术团队 其林, 2026-06-12）—— 有 raw 但无 entity。

建议：后续批处理整合，原因是： 1. 同公司（淘天集团）不同团队（物流 vs 行业运营） 2. 同主题（Agent Skills 实战） 3. 互补视角（其林：Skill 怎么编写；官亭：Skill 怎么落地） 4. 时间相近（其林 2026-06-12 / 官亭 2026-06-17）

本批仅入库官亭文（严格执行单 URL 决策），孤儿 raw 留给后续批处理整合。

11. 后续追踪建议

  1. 沙箱测试（TDD）能力落地：当前评估→方案→编码链路已验证，但沙箱测试尚未完全完成
  2. SubAgent 并行化：编码阶段进一步提速的关键
  3. OneDay + Aone 沙箱产品化进展：是否能成为面向非技术人员的标准化工具
  4. kn-fetcher CLI 6 命令对接 Skill 体系的具体时间点
  5. 三级索引结构是否开源化（参考 Anthropic 官方 Skill 仓库的目录组织）
  6. 同公司物流技术团队（其林）的 Skill 编写实战孤儿 raw 整合