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

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

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

效果：迈出了AI编程的第一步，验证了对话式编码在外部接口适配场景中的可行性。基于某ISV项目完成了整体架构落地，实现企业购标准服务与客户适配逻辑解耦。

瓶颈：

• 产出质量不稳定：完全依赖个人Prompt技巧，同一需求不同人写出的Prompt质量差异巨大

• 难以复用：知识散落在临时对话中，新人无法继承前人的经验

• 强依赖个人能力：AI输出质量与开发者的提示词工程能力强相关

做法：采用流程模板化 + 子任务Prompt模板双轨策略，取得阶段性成效：

• 流程模板化：将共性环节（如"商品同步"）抽象为可复用的对接模板——抽象商品同步流程，分离变与不变的逻辑，对接新客户仅需在已有模板基础上开发变化部分，即可快速生成可用流程，避免从零编排。其核心目的是让AI做确定性的具体事情，避免发散——通过预定义流程骨架，将AI的工作从"自由设计一个同步流程"收敛为"在已有模板上填充差异化逻辑"。这本质上是将"参数驱动"的旧范式，升级为"任务视角"的结构化表达——以终为始，围绕业务目标组织流程节点。

• 子任务Prompt模板：将开发过程拆分为多个子任务（脚手架搭建、接口对象生成、对象映射、接口串联），为每个子任务预置结构化Prompt模板，统一输入格式、约束输出维度、嵌入业务规则。此举显著降低了AI调用的随意性，提升了结果一致性与可维护性，是模板化在认知层的延伸补充。

示例：通过商品域主流程抽象，分离变化的部分和不变的部分，收敛AI的任务

• 流程抽象

效果：

• AI生成代码采纳率 70%

• 4类Prompt模板形成可复用资产，新人可快速上手

瓶颈：

Prompt模板虽然在单个子任务上效果显著，但暴露出两个核心问题：

问题一：AI发散不可控，无法提前预览设计思路

Prompt模板只约束了输入和输出格式，但无法约束AI中间的"思考过程"。开发者无法在代码生成前预览AI的设计思路（如接口如何拆分、DTO如何设计、调用顺序如何编排），导致AI生成的代码与预期不符——发现问题时代码已经生成完毕，只能推翻返工，反而拉长了迭代周期。

问题二：单点提效，无法承载SOP

Prompt模板无法支撑端到端的标准化操作流程（SOP），核心原因在于：

• 执行不可控：Prompt模板受限于上下文长度和状态记忆缺失，易出现步骤跳过、顺序错乱、工具误调用等问题，无法保障流程的确定性执行

• SOP与推理任务的本质冲突：SOP本质是有约束的确定性流程，而非开放性推理任务——需要将"自由发挥"转化为"受控选择"，但Prompt模板缺乏这种约束能力

• 缺乏能力基座：当前仍依赖人工保证流程正确性，根源在于缺乏流程节点标准化、工具参数模板化、决策边界显性化的能力基座

做法：引入SDD方法论，用结构化规格文档驱动AI生成。在SAAS项目中使用OpenSpec工具验证了Spec编程的可行性——从对话式编程到用规范约束AI，通过工程规范、开源知识库、业务约束三层引导，让AI输出能落地的代码。

效果：

• AI生成代码可用率从 40%提升至80%

瓶颈：

SDD方法论验证了Spec驱动的可行性，但在实际落地过程中暴露出规模化推广的瓶颈：

• 流程执行成本高：SDD要求严格遵循"提案（Proposal）→ 实施（Apply）→ 归档（Archive）"三个环节顺序执行，且过程中涉及多轮需求澄清和方案迭代，单个Spec从编写到定稿往往需要3-5轮人工交互，流程本身的投入不可忽视

• 强依赖个人经验，无法规模化：Spec的编写质量高度依赖编写者对领域知识的掌握程度——如SPU/SKU模型理解、推拉模式选择、字段映射方向等关键决策，仍然散落在个人脑中，缺乏标准化的知识载体。新人面对同一份客户文档，写出的Spec质量与老手差距悬殊，无法通过简单培训弥合

• 领域知识未固化：SPU/SKU混淆、ID字段混淆等问题跨项目反复出现，说明领域经验没有沉淀为可复用的约束规则，每次仍需人工记忆和校验

做法：企业购客户对接场景天然适合Skill体系——每一次客户对接都是一个全新的项目，但执行的流程高度重复（文档评估→技术方案→代码开发），变化的只是客户接口规范、字段映射关系和业务流程编排。这与Skills倡导的可复用技能包理念高度契合：将不变的流程、规则、领域知识封装为Skill，每次对接只需输入客户文档，Skill即可驱动AI按标准化流程产出结果。

基于这一判断，团队采用Anthropic的Agent Skills标准（SKILL.md + references/ + scripts/）将领域经验封装为Skill，实现"经验即代码"——工作流写在SKILL.md里，领域知识放references目录，通过版本控制管理，换人、换模型、换平台都能复用。

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

效果：

瓶颈：

Skill体系在技术研发侧取得了显著成效，但其使用门槛决定了受众仍局限于技术同学：

• 面向技术同学，产品和业务上手门槛高：Skill的安装、配置、调用均依赖Cursor等本地IDE环境，需要理解SKILL.md工作流、references目录结构、脚本执行等技术概念。产品经理和业务运营无法直接使用，仍需研发作为中间人代为执行，AI提效的红利无法辐射到更广泛的角色

• 依赖本地IDE环境，无法规模化推广：Skill运行在开发者个人的本地IDE环境中，换人、换机器需要重新配置环境，团队协同和知识同步成本高

• 能力无法产品化输出：技术侧已验证的全链路能力（文档评估→方案生成→代码生产）缺乏产品化载体，无法作为标准化工具赋能给产品和业务团队自主对接

▐  阶段5：云端集成——打造端到端AI研发产品

2026年2月 | 探索中

通过代码分层，将系统拆分为原子能力层、模板层、适配层三层架构。这种分层不仅是传统工程意义上的解耦，更是为AI编程量身设计的——通过流程模板化限定AI行为边界，避免发散，让AI聚焦于专一任务（仅实现适配层逻辑），从而显著提升AI输出的准确性和一致性。

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

实际效果：

• 适配层代码量减少60%：客户差异化开发聚焦协议转换等核心逻辑

• 多客户并行开发零冲突：支持多项目并行开发与独立部署

• 原子服务复用：覆盖90%+对接场景，AI无需重复生成基础能力代码

回到Skills的本质，构建领域专家，而不是通用方案；围绕企业购做垂直域深耕，真正实现业务提效。

我们所构建的Skills专注于企业购对接这一专业领域的具体需求，与企业购业务强相关——所需的领域知识是SPU/SKU模型、推拉模式、字段映射规则等专业知识，而非通用能力（如PDF解析、代码格式化等通用Skill），选择垂直深耕而非通用方案，基于两个核心判断：

• 垂直域深耕ROI更高：基于Spec范式、Skills、SubAgent技术体系，围绕企业购项目对接集中人力进行实践和应用，最大程度提升研发效率（质量可控、可复用、可迭代），并通过产品化实现技术赋能业务

• 通用方案短期不可行：Spec范式的流程验证和可行性验证已经完成，但网站技术域涉及广，做通用的研发方案成本高、短期成功率低，且集团已有较多的专门团队在投入

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

成功率从早期不足50%提升至当前90%，核心在于解决了接口提取幻觉、复杂逻辑输出不稳定、长上下文导致信息丢失三大类问题。调优过程按链路节点逐段攻破：

评估报告阶段

评估报告是整条链路的输入源头，类似于PRD的理解，这个阶段要解决两个问题：接口提取不准和领域知识缺失。

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

早期完全依赖模型提取接口，模型幻觉导致接口遗漏或误提，错误沿流水线逐级放大——提取漏一个接口，评估就少评一个，方案就少写一个，代码就少生成一个。

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

解决方案：脚本提取为主，AI辅助校验

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

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

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

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

技术方案阶段

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

代码生产阶段

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

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

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

质量控制

通过「事前约束→运行时约束→事后审查→人工卡点」四层防线，贯穿评估→方案→代码全链路：

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

▐  知识库建设

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

知识库采用三种存储载体协同的架构，覆盖从代码到文档的全域知识管理：

• 知识的生产与使用

生产知识：

• 多模态支持：钉钉文档、代码、PDF等多种格式

• 多数据源：Git知识仓库、Code Wiki、KBase等

• 多种生成方式：人工维护（研发过程中沉淀的Rules、可复用的原子Skills）+ 自动生成&增量更新（如KBase支持的钉钉知识库同步、需求完成后Hooks自动更新）

使用知识：

• AI研发流程自动加载知识，通用Skills隐藏底层检索细节

• Git知识仓库：自建索引，支持渐进式拉取

• KBase：RAG召回（文本块/原文），自然语言提问可召回代码片段+原文档链接

参考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/            # 包配置（批量操作）

• 知识分发工具

# 拉取编码规范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

• Code Wiki已完成试跑，生成的数据模型、开发指南、核心模块、API参考符合预期，可通过MCP召回知识

• KBase已完成试跑，自然语言提问可召回代码片段+原文档链接

• 三级索引结构和元数据规范已定义完成

• kn-fetcher CLI工具6个基础命令（pull / list / search等）已完成，待对接Skill体系

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

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

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

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

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

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