怎样把员工经验变成企业AI Skill？先分清知识、流程和执行权限

一、从员工真正要完成的结果开始

不要先问“能做多少个Skill”，先问员工接到一项任务后，最终需要交出什么。售后任务的结果可能是有依据的处理草稿，也可能是经过审批的维修安排。两者需要的接口和责任不同。把入口、必要字段、资料来源、输出格式、确认人和停止条件写出来，再决定是知识问答、固定工作流还是带有判断的Agent。

整理专家经验时，应使用一项已脱敏的实际流程逐步访谈：为什么先查这份资料，遇到什么条件会改变路线，缺少哪些信息不能继续。不要把专家口头说的“正常处理”当成可执行规则。首次试点应允许输出“信息不足，需人工确认”，而不是要求每个问题都必须自动完成。对低频且无法形成稳定规则的工作，保留人工处理可能更合理。

二、Skill、RAG和工作流各自负责什么

知识库回答“有什么依据”，例如现行保修规则和产品说明；Skill描述“怎样处理”，例如先验证订单归属，再判断资料是否齐全，最后生成待审草稿；工作流负责必须执行的状态和审批。它们可以配合，也可以单独使用。如果问题只是查找一段制度，不必增加执行工具；如果只是确定顺序的表单审批，也不必让模型重新规划每一步。

Skill通常可以组织操作说明、参考资料、模板和脚本，供兼容的Agent在合适任务中使用。是否能识别、加载和运行这些内容，仍取决于具体平台及配置。不要把在一个工具中可用的目录，直接承诺为所有平台通用的应用。方案中应列出测试过的平台、工具接口和依赖；更换运行工具时，需要重新验证触发、文件访问、权限和输出，而不是只复制一个文件。

窄屏可左右滑动表格查看全部列。

三、售后处理Skill的具体设计示例

以下是实施设计示例，不是知华客户上线成果。员工选择一张有权查看的工单，系统核对产品、订单和故障描述；若缺少购买凭证，返回需要补充的字段。资料完整后，按有效保修规则提出处理草稿，并标出依据。员工确认后，正式工单系统创建待办并返回编号。Skill负责组织方法，订单接口负责取数，审批和创建待办的权限仍由业务系统控制。

这项任务不应默认开放退款、发送承诺或关闭工单。客户无法确认身份、保修规则存在冲突、接口不可用或结果不能核实时，进入人工队列，保存已完成步骤和原因。演示中显示“处理完成”不算验收；需要在目标系统查看实际记录。客户可先验收只生成草稿的版本，再按风险开放一项受限写入，避免把首次试点直接变成全自动售后。

四、企业Skill怎样测试、发布和更新

建立固定样本，包含资料完整、缺字段、规则例外、用户无权查看、接口超时和重复触发。分别检查是否选择了正确方法、是否引用有效资料、草稿字段是否正确，以及是否越过人工确认。不能只看文字是否流畅。对同一条样本记录输入、Skill版本、模型和工具版本、实际输出与人工意见，更新前后使用相同口径比较。

业务规则改变时，先更新负责人批准的资料，再修改方法和受影响的测试，经过审核后发布。保留上一版本与已知限制，明确正在运行的任务使用哪个版本。不要让Agent直接把某次成功对话永久写成全公司的规则，也不要导入来源不明的脚本和资源。脚本的依赖、外网访问和文件权限需要单独检查，内容包并不是天然安全的组件。

五、报价与交付不能只有提示词

费用由流程整理、资料治理、方法编写、工具接入、权限、测试和员工入口共同决定。已有可靠接口与明确规则时，试点可以更小；需要补订单关联、身份和审批时，成本来自系统工程。分别列研发费用与运行费用，模型、存储、软件订阅和维护不应默认都包含在一个“Skill制作费”里。先确认建设范围，再给出阶段报价。

交付应包含任务范围、内容目录、版本、模板脚本、接口说明、权限矩阵、评测样本、发布方法与维护责任。客户应能判断哪些资产属于项目成果，哪些依赖第三方服务，以及换团队后如何继续修改。知华可以先评估一个岗位的一项流程，形成试点方案；有固定软件已经满足要求时，也会优先讨论配置与集成，不把新建平台当成默认答案。

官方资料与核对范围

参考资料核对日期：2026-10-06。平台能力会随版本、套餐、地区和权限变化；资料用于说明技术能力，不代表搜索量、知华客户成果或原厂合作资质。

• 阿里技术：AI Native研发范式实践手册（外部参考）
• Anthropic：Agent Skills结构、评测与安全说明