​一场 Skill 圆桌会议的总结分享

一场 Skill 圆桌会议的总结分享

长沙同盟近期 Agent Skill 开发与落地圆桌会议复盘

近期，长沙同盟组织了一场关于 Agent Skill 开发与落地 的圆桌交流会议。

本次会议围绕 AI Agent 时代下，Skill 如何从简单的 Prompt

封装，逐步演进成为企业级 AI 能力资产展开讨论。

会议中，各位老师围绕：

Skill 工程化规范

CDM（Code Development Model）流程

企业级落地方法

数据治理

网络环境优化

知识蒸馏

Skill 平台建设

Skill 与代码的边界

进行了深入交流。

本文整理会议中的核心观点，并加入个人理解。

一、为什么 Skill 会成为 AI 工业化的重要方向？

大模型（LLM，Large Language Model）快速发展后，AI

已经具备越来越强的推理和生成能力。

但是企业真正落地时，会发现：

模型拥有智能，但不天然具备稳定、可控、可复用的业务能力。

传统 Prompt 使用方式：

用户

↓

Prompt

↓

LLM

↓

输出结果

存在：

幻觉问题

不稳定

难复用

难测试

难版本管理

Skill 的价值，就是在模型能力之上增加工程化能力。

它将：

专家经验

业务规则

操作流程

输入输出规范

验收标准

封装成为可复用能力。

简单理解：

模型决定智能上限，Skill 决定业务可用性，治理平台决定规模化。

二、Skill 的本质：从 Prompt 到工程资产

周老师分享中强调，Skill 并不是简单的 Prompt。

Prompt 解决：

如何让模型理解需求。

Skill 解决：

如何让 AI 能力成为稳定、可管理、可复用的工程组件。

一个成熟 Skill 应具备：

1. 输入输出契约

明确：

输入内容

输出格式

执行边界

异常处理

使其可以：

自动测试

质量检查

系统调用

1. 能力边界冻结

Skill 开发前需要定义：

这个能力解决什么问题？

不解决什么问题？

避免 AI 无限扩展理解范围。

1. 生命周期治理

企业级 Skill 需要：

版本管理

测试

发布

迭代

从而成为真正的数字资产。

三、CDM（Code Development Model）方法论

周老师重点介绍了 CDM 流程。

核心目标：

将模糊的人类意图转化为结构化、可执行、可验证的 Skill。

主要流程：

需求澄清

↓

能力规格定义 Capability Spec

↓

多模型评审

↓

风险审查

↓

版本冻结

↓

发布调用

1. 需求澄清

AI 落地最大的挑战，往往不是技术，而是需求不明确。

需要明确：

使用场景

用户角色

输入条件

输出目标

验收标准

1. Capability Spec（能力规格）

类似软件工程中的接口设计。

提前冻结：

Skill 能力

输入输出

限制条件

验收方式

1. AI 多模型互审

会议中提出一个非常有价值的观点：

用 AI 互审给 AI "踩刹车"。

通过不同模型之间的多轮评审，降低：

幻觉

错误假设

风险输出

四、Skill 的落地路径

Skill 的发展可以分为三个阶段：

第一阶段：单点技能

解决岗位中的高频重复工作。

例如：

固定消息发送

信息催办

数据整理

第二阶段：流程组合

多个 Skill 组合形成业务链路。

例如：

催办 Skill

↓

信息收集 Skill

↓

结果整理 Skill

↓

异常处理 Skill

第三阶段：个人能力资产

未来每个人都可能拥有自己的 AI 技能库。

五、Skill 的真实业务场景讨论

1. 数据治理与执行器封装

针对大量执行器封装需求，会议讨论：

是否可以通过记录系统操作日志，例如：

Binlog

HDR Log

让智能体理解执行过程，自动生成 Skill。

同时提出：

不要重复造轮子。

已有成熟工具能力，可以通过 Skill 封装控制逻辑。

1. 复杂网络环境优化

针对金融等复杂内网环境：

提出：

利用 AI 生成 Mock 服务。

模拟：

网络行为

接口响应

子系统交互

实现并行开发。

同时可以利用：

eBPF（Extended Berkeley Packet Filter）

采集：

网络数据

性能指标

辅助分析复杂系统问题。

1. 测试数据生成

讨论了两种方式：

第一：

通过 API 调用生成测试数据。

第二：

基于数据库结构、数据字典生成业务数据。

1. 知识蒸馏

通过：

Open Wiki

LM Wiki

RAG Flow

将专家经验和书籍知识转化为知识库。

进一步封装成为：

具有特定领域能力的人格化 Skill。

六、Skill 与代码的边界

这是会议中非常值得思考的问题。

Skill 并不是所有自动化问题的答案。

对于：

明确规则

强确定性

高性能要求

强事务要求

应该优先使用：

Python

Java

后端服务

Workflow

原因：

代码提供确定性。

Skill 提供智能性。

未来更合理的模式：

Agent

↓

Skill

↓

Code / Tool

↓

Infrastructure

而不是：

所有问题

↓

LLM

↓

解决

七、Skill 与模型绑定问题

会议中讨论了一个重要问题：

Skill 是否独立于模型？

实际上并不是。

Skill 的效果依赖：

模型能力

模型版本

工具调用能力

上下文理解能力

因此未来 Skill 治理需要考虑：

Skill Version

+

Model Version

+

Runtime Environment

+

Evaluation Dataset

否则：

模型升级后，旧 Skill 可能出现性能下降。

八、我的个人思考

结合本次圆桌，我认为：

1. Skill 应该用于"经验和流程沉淀"

符合以下条件：

高频复用

有明确输入输出

包含专家经验

有验收标准

这类场景非常适合 Skill。

例如：

企业 SOP、分析流程、专家咨询能力。

1. 不适合 Skill 的场景应该回归程序

对于确定性的任务：

例如：

数据同步

财务处理

ERP 流程

批量计算

更应该使用：

Python 程序或者传统软件工程方式。

核心原则：

能写死的逻辑，不应该交给模型自由发挥。

代码负责确定性。

Skill 负责不确定性的智能处理。

1. Skill 与模型绑定关系需要长期关注

未来企业 AI 架构，不只是管理 Skill。

还需要管理：

Skill

模型

运行环境

测试数据

只有这样，AI 能力才能真正进入生产环境。

九、总结

Skill 的价值，不只是让 AI 完成更多任务。

更重要的是：

它尝试把 AI 能力从一次性的对话，转化成为：

可复用

可治理

可测试

可商业化

的工程资产。

未来 AI 工业化落地，很可能不是单纯依靠更大的模型，而是依靠：

更好的模型能力 + 更成熟的 Skill 工程体系 + 更完善的治理平台。