本文提出”面向 Skills 编程“范式——将领域知识、工作流、约束规则封装为可版本化的 Skills 单元,让 LLM 在确定性框架内生成代码,实现从”人写代码”到”人沉淀 Skills,AI 写代码”的研发范式升级。以企业购客户对接场景为实战验证,通过项目评估、技术方案、代码生产的研发 SOP 构建,实现商品域端到端交付周期缩短 65%,代码一次生成成功率达 90%。
过去我们应对业务变化的经典策略是 DDD 分层 + 配置化:通过领域建模拆分业务能力,通过配置参数驱动行为差异。这套模式在以人为主的传统研发模式下行之有效,但面对高频定制化需求时,由于人力的稀缺,依然可能存在交付瓶颈:
当定制化需求高频出现时(如企业购每个客户接口都不同),配置化的参数空间爆炸,SPI 扩展点变成了”每次都要写的代码”,开发者本质上还是在手写适配逻辑——DDD 实现了架构解耦,但没有解决重复编码的问题。
面向 Skills 编程的核心思想是:将”人写代码”转变为”人写 Skills,LLM 基于 Skills 写代码”。 程序员向更高一层抽象——从”实现逻辑”上升为”定义 Skills”,基于 Skills 将个人经验转化为可复用的 AI 能力单元。
类比理解:如果说传统编程中”接口/抽象类”定义了代码的契约,那么 Skills 就是定义了 AI 行为的契约——它告诉 LLM”做什么、怎么做、不能做什么”,就像接口定义告诉实现类”必须实现什么方法”,让大模型从”知道分子”成为”行动专家”。
不论你在什么业务域,都可以按以下四步构建自己的 Skill 体系:
识别重复模式 → 封装不变量为 Skills → 将变化的部分作为输入 → LLM 在约束下执行。
面向企业客户的采购需求,淘宝企业购提供一整套包含淘宝全平台丰富供给以及私有化企业采购服务产品链路的解决方案。在标准模式(SKA 模式)下,淘宝企业购已提供完善的基于淘宝开放平台的 TOP 标准接口,支持外部客户自主对接,覆盖标准化的商品、交易和结算服务。
然而在实际业务拓展中,大量大中型客户自身已经具备成熟的系统和接口规范:
这些客户改造自身系统来适配淘宝企业购标准接口成本较高,因此需要企业购反向适配其系统接口。出于业务发展的需要,企业购需要主动适配客户系统的接口规范,由此衍生出客户定制对接这一高频研发场景。
客户对接的核心工作是:基于客户提供的对接文档,理解其接口规范,开发适配层代码,实现企业购标准服务与客户系统的互通。对接工作涉及三大业务域——商品(商品信息同步、类目映射)、交易(订单创建、物流同步、逆向)、结算(对账、结算单、发票管理)。由于每个客户的接口规范各不相同,适配代码几乎无法跨项目复用,每次对接都需要从文档评估到代码开发全流程重新执行。
这一业务模式具有四大典型特征:对外对接高频、需求碎片化、技术方案重复度高、交付周期敏感。在传统研发模式下,面临以下瓶颈:
核心问题:当前以人工为中心、AI 辅助的研发模式无法满足业务”快交付、低成本、高灵活”的诉求。
经过近半年的系统性探索与实践(2025.8 - 2026.2),团队在研发范式、研发效率、技术沉淀三个维度取得了阶段性成果:
研发范式升级:从”依赖个人经验的对话式编程”迈向”基于 Skills 的工程化 AI 协作”,实现端对端编程实践探索,以人为主导,逐步转向人通过 Skills 传递经验给 AI,指挥 AI 编程。
研发效率提升:商品域端到端交付周期从 23.5 人日缩短至 8 人日,整体提效 65%,代码一次生成成功率达到 90%。
技术沉淀:构建了覆盖全链路的 Skills 体系和端到端生码平台,将个人经验转化为可复用的组织能力资产。
过去半年,团队在巨大的交付压力下,围绕架构解耦、AI 编程、AI 工具应用三大方向进行了系统性探索。演进路径与 AI 技术发展趋势高度一致,每一阶段都是对前一阶段”天花板”的突破:
| **2025 年 8 月 | 落地项目:某大型 ISV** |
做法:基于弹外架构独立部署的安全性优势(可使用所有开源代码、最新大模型和 AI 工具),团队开始尝试以自然语言对话驱动代码生成。开发者通过与 AI 对话描述业务需求,AI 直接生成适配代码。
效果:迈出了 AI 编程的第一步,验证了对话式编码在外部接口适配场景中的可行性。基于某 ISV 项目完成了整体架构落地,实现企业购标准服务与客户适配逻辑解耦。
瓶颈:
| **2025 年 9 月 | 落地项目:某大型企业** |
做法:采用流程模板化 + 子任务 Prompt 模板双轨策略,取得阶段性成效:
效果:
瓶颈:
| **2025 年 12 月 | 落地项目:SAAS 项目** |
做法:引入 SDD 方法论,用结构化规格文档驱动 AI 生成。在 SAAS 项目中使用 OpenSpec 工具验证了 Spec 编程的可行性——从对话式编程到用规范约束 AI,通过工程规范、开源知识库、业务约束三层引导,让 AI 输出能落地的代码。
效果:AI 生成代码可用率从 40% 提升至 80%。
瓶颈:SDD 方法论验证了 Spec 驱动的可行性,但在实际落地过程中暴露出规模化推广的瓶颈:
| **2026 年 1-2 月 | 落地项目:某大型 ISV** |
做法:企业购客户对接场景天然适合 Skill 体系——每一次客户对接都是一个全新的项目,但执行的流程高度重复(文档评估→技术方案→代码开发),变化的只是客户接口规范、字段映射关系和业务流程编排。这与 Skills 倡导的可复用技能包理念高度契合:将不变的流程、规则、领域知识封装为 Skill,每次对接只需输入客户文档,Skill 即可驱动 AI 按标准化流程产出结果。
基于这一判断,团队采用 Anthropic 的 Agent Skills 标准(SKILL.md + references/ + scripts/)将领域经验封装为 Skill,实现”经验即代码”——工作流写在 SKILL.md 里,领域知识放 references 目录,通过版本控制管理,换人、换模型、换平台都能复用。
最终构建了一条从客户接口文档评估到代码生产的 AI 全链路流水线,覆盖”文档评估 → 技术方案 → 编码”的完整链路,用 xx 项目(15 个接口)跑通了商品域整个流程。
瓶颈:Skill 体系在技术研发侧取得了显著成效,但其使用门槛决定了受众仍局限于技术同学:
| **2026 年 2 月 | 探索中** |
做法:技术先行,利用 OneDay 搭建前端交互界面,结合 Aone 沙箱提供的代码编译与执行环境,自行搭建了端到端的生码平台原型。核心思路是将已验证的 Skill 能力从本地 IDE 迁移到云端,让非技术人员通过 Web 界面即可触发全链路流水线——上传客户对接文档后,平台自动完成文档解析、评估报告生成、技术方案输出、适配代码生产的完整流程。
当前进展:
为什么架构优化是 AI 编程的前提? 代码分层越清晰,AI 生成质量越高。架构优化不是为了优化而优化,而是为了让 AI 能够更好地理解和生成代码。分层架构设计是 AI 编程的基础设施,它通过清晰的结构和明确的边界,让 AI 能够像人类开发者一样理解代码的组织逻辑,从而生成更高质量、更符合规范的代码。
通过代码分层,将系统拆分为原子能力层、模板层、适配层三层架构。这种分层不仅是传统工程意义上的解耦,更是为 AI 编程量身设计的——通过流程模板化限定 AI 行为边界,避免发散,让 AI 聚焦于专一任务(仅实现适配层逻辑)。
原子能力层和模板层是稳定不变的,AI 生成的代码仅聚焦于适配层——这将 AI 的工作范围从”理解整个系统”收敛为”在固定框架内填充适配逻辑”,大幅降低了 AI 生成的复杂度和出错概率。
实际效果:
为什么做垂直领域 Skills? 回到 Skills 的本质,构建领域专家,而不是通用方案;围绕企业购做垂直域深耕,真正实现业务提效。
我们所构建的 Skills 专注于企业购对接这一专业领域的具体需求,与企业购业务强相关——所需的领域知识是 SPU/SKU 模型、推拉模式、字段映射规则等专业知识,而非通用能力(如 PDF 解析、代码格式化等通用 Skill)。
Skill 构建思路:
实际案例:成功率从早期不足 50% 提升至当前 90%,核心在于解决了接口提取幻觉、复杂逻辑输出不稳定、长上下文导致信息丢失三大类问题。调优过程按链路节点逐段攻破:
评估报告阶段(评估报告是整条链路的输入源头,类似于 PRD 的理解):
技术方案阶段(评估报告准确后,技术方案阶段暴露出两个新问题:推拉模式混杂导致 API 不对齐和长文档输出崩塌):
问题闭环:同类问题跨项目、跨模型反复出现(如 XX 系统修了 SPU/SKU 混淆,换 B 系统又犯),通过 ADJUSTMENT_PLAN 机制(发现→定位 Skill→补约束→验证→交叉验证)将 11 类高频问题全部沉淀为 Skill 约束,不再复现。
代码生产阶段(评估报告和技术方案准确后,代码生产阶段的核心瓶颈是代码规范和编译成功率):
基础认知:
质量控制:通过「事前约束→运行时约束→事后审查→人工卡点」四层防线,贯穿评估→方案→代码全链路。
实际效果(xx 项目):审查 Skill 对评估报告审查结果为接口覆盖 15/15、字段遗漏率 0%、映射方向正确。早期(xx 项目)的 11 类高频问题已全部通过约束沉淀解决。
为什么需要知识库? 建设专有知识库,能让 AI 懂得业务现有的技术背景、领域知识、架构、流程、代码结构等知识。在 Skill 体系中,领域知识通过 references 目录内嵌到每个 Skill 中,但随着 Skill 数量增长,出现了知识分散、更新不同步、跨 Skill 复用困难等问题,需要构建统一的知识库体系来支撑。
知识库全景:知识库采用三种存储载体协同的架构,覆盖从代码到文档的全域知识管理。
知识的生产与使用:
标准化知识管理:参考 Anthropic 官方 Skill 的渐进式加载策略(SKILL.md 触发时加载 + REFERENCE.md 按需加载),构建了三级索引结构(GUIDE.md → rules/index.md → 具体规则文件),实现知识的按需发现和加载。
知识分发工具:构建了 CLI 工具 kn-fetcher,支持知识的拉取、搜索和批量分发(kn-fetcher pull --platform aone-copilot --rules java-coding-standards)。
当前进展:
当前评估→方案→编码链路已验证,但沙箱测试(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 产品三大方向持续突破,以 AI 驱动企业采购在项目交付、产品体验、经营效率上的全面升级,助力企业采购实现规模化与高质量增长。团队当前急需前端、后端、QA 等方向的伙伴,如果你愿意一起来探索,欢迎联系 zezhou.jzz@taobao.com。