跳到正文
观猹观猹学社

把人的经验，变成 Agent 可复用的能力

从 Skill 的结构与渐进式加载出发，把知识、脚本和企业系统封装成 Agent 可稳定复用的业务能力。

✦全文约 5800 字 阅读需 20 分钟 悟鸣 最近更新 2026.08

01课程介绍#

本节课讨论怎样把人的经验变成 Agent 可重复使用的 Skill。课程从业务场景选择开始，再沿着输入、输出、流程、工具和评测逐步建立一项能力。

Skill 的价值不在于多写一个文件，而在于把已经验证过的判断和执行过程沉淀下来，并在真实任务中稳定复用。

你将学到什么

  • 理解 Skill 的基本结构、加载方式与适用边界。
  • 判断哪些重复任务值得被封装成 Skill。
  • 按照输出、输入、流程与评测完成一项 Skill。
  • 把知识处理、脚本与企业系统操作纳入可评测的交付闭环。

02课程回放#

正在准备课程回放…
本节课的核心判断 Skill 的价值不在于多写一个 Markdown 文件，而在于把已经验证过的 业务判断、执行步骤、工具能力和验收标准 交给 Agent 稳定复用。先找到值得解决的问题，再设计 Skill。

03课程课件#

完整课件正在载入…

04Skill：Agent 的可复用能力包#

AI 工作方式正在从“人操作工具”转向“人定义目标并把关，Agent 执行任务”。角色边界也随之变得模糊：产品、运营、销售和工程师都开始使用 Coding Agent、Git、脚本与自动化工具。Skill 正是连接人的经验与 Agent 执行力的一种载体。

一个 Skill 可以是一份操作说明、一个工具包、一套行业最佳实践，也可以把三者组合起来。它通常由一个目录承载，其中 SKILL.md 是入口，还可以包含参考资料、脚本、模板和其他素材。

元信息名称与描述，告诉 Agent 这项能力解决什么问题、何时应该触发。
主体指令定义目标、关键步骤、判断标准、异常处理和输出要求。
参考资料放置模型无法可靠获取的规则、范例、术语和相对静态知识。
脚本与工具承载确定性计算、格式转换、接口调用、检查与自动化操作。
评测用例记录代表性输入、期望输出和评分规则，验证每次修改是否真的变好。

渐进式加载为什么重要

Skill 的关键设计之一是渐进式加载。Agent 启动时只需看到每个 Skill 的名称和简短描述；命中任务后才读取对应的 SKILL.md；真正执行时，再按当前步骤加载必要的参考文件或脚本。

  1. 发现能力先用精简元信息判断当前任务是否需要这个 Skill。
  2. 理解流程触发后读取主体指令，确认目标、边界和执行步骤。
  3. 按需取材只加载当前步骤需要的知识、脚本或样例，避免一次塞满上下文。
  4. 执行并验证调用工具完成任务，再依据检查项和评测标准确认结果。

因此，Skill 不是“更长的提示词”，也不只是单个 Markdown。它解决的是上下文如何组织、知识如何按需进入、工具如何被调用，以及经验如何持续进化的问题。

提示词工程并没有过时 只要人仍需要向 Agent 表达目标，需求澄清、任务拆解、边界定义和反馈方式就仍然重要。Skill 将这些能力工程化，并不意味着可以跳过对业务和模型边界的理解。

05先判断什么值得做成 Skill#

创建 Skill 之前，首先要判断任务是否有价值。能生成出来不等于值得维护，更不等于客户愿意付费。课程给出的筛选标准可以归纳为四类：

  1. 节省时间 高频、重复、需要多次查资料或在多个系统间搬运信息的任务。
  2. 改善体验 人不愿反复做、容易遗漏步骤，或依赖少数熟练员工才能完成的任务。
  3. 降低成本 能减少人工处理、返工、外部采购或低价值沟通成本的任务。
  4. 创造业务价值 能解决明确痛点、提高交付质量，或形成客户愿意购买的专业能力。

更适合封装的通常是重复发生、输入输出可描述、已有经验可复用、结果可以检查的任务。尚未理解清楚的一次性问题，不必急着包装；先通过人工或 Agent 协作跑通，再沉淀其中稳定的部分。

判断问题 适合继续 需要先停下来
业务价值 使用者能说明当前耗时、成本或质量问题 只是觉得“做一个 Skill 很酷”
任务稳定性 核心流程重复出现，例外情况可以枚举 每次目标都完全不同，尚无共性
输入条件 必要材料可以取得，质量和权限可确认 关键数据长期缺失，却要求稳定结果
验收方式 领域专家能判断好坏，并提供样例 没有人能说清什么算正确
维护责任 有人负责反馈、版本和知识更新 创建后无人使用，也无人维护

06创建 Skill 的标准流程#

非技术背景最大的障碍通常不是写文件，而是把模糊想法变成具体、可执行、可验证的说明。课程提出的核心顺序是：先定义输出，再反推输入，然后拆解流程，最后建立评测。

  1. 明确业务结果 先写清为谁解决什么问题、当前为什么不满意，以及结果将用于什么决策或流程。
  2. 定义输出契约 列出最终交付物由哪些部分组成，每一部分的格式、质量标准、相互关系和不能出现的内容。
  3. 反推完整输入 根据每项输出确认所需材料、用户背景、业务规则、历史样例和系统数据，避免让模型填补关键事实。
  4. 拆解处理流程 写出先后步骤、判断分支、异常路径、人工确认点，以及每一步如何知道已经完成。
  5. 选择自由度 确定哪些步骤必须严格执行，哪些允许模型在给定框架内发挥，哪些适合开放探索。
  6. 配置知识与工具 把静态规则、参考资料、脚本、CLI 或 API 放到合适位置，只向上下文暴露当前任务真正需要的部分。
  7. 生成并人工审查 使用能力较强的模型创建初版，再检查触发条件、步骤完整性、文件引用、权限与危险操作。
  8. 建立评测与反馈闭环 用代表性用例运行初版，记录失败案例，让真实用户持续反馈，再小步修改和回归验证。
输出不清楚，就无法判断输入是否完整；输入和流程不清楚，Skill 再精致也只能稳定地产生不可靠结果。

输入完整性决定上限

课程以员工材料评分为例：如果真人评委会同时参考申报文档、答辩内容和个人经验，那么只把申报文档与评分表交给 Agent，得到的分数就很难与真人一致。问题未必出在模型或评分提示词，而是自动化流程看到的事实少于真人。

错误做法只复制一份评分标准，要求 Agent “像专家一样打分”。
补全输入加入申报材料、答辩转写、历史样例和可解释的专家判断依据。
固定输出不仅给出总分，还要逐项说明证据、缺失信息与置信程度。
验证差异比较 Agent 与评委结果，区分输入缺失、规则冲突和模型判断错误。

高质量 Skill 往往需要两种专家

AI 专家熟悉模型边界、上下文、工具调用和评测，但未必了解资产评估、财务、客服或设计等具体业务；行业专家掌握判断标准，却未必能把隐性经验表达成可执行流程。二者协作，通常比任何一方独立完成更可靠。

如果由行业专家独立创建，应先练习程序化表达：把输入、输出、步骤、条件和异常说清楚。如果由 AI 工程师创建，则必须通过访谈、真实样例和现场反馈补齐领域知识，不能只根据一段概述推测业务。

07两个案例：从知识处理到企业系统操作#

案例一：文章与研究资料解读 Skill

“帮我总结这篇文章”只能得到通用摘要。真正有价值的目标，是让阅读结果直接服务于当前的学习、研究或工作。因此，这个 Skill 不只需要原文，还需要使用者的岗位、研究方向和近期问题。

模块 输出要求 需要的输入
一句话总结 说明材料解决什么问题、给出什么核心结论 文章、论文或报告全文
关键要点 提取重要事实、方法、数据和因果关系 原始材料与必要背景
个性化启发 连接当前岗位、研究方向与近期困惑 使用者背景与希望解决的问题
批判性思考 检查证据、适用范围、遗漏条件与可能偏差 论据、引用和作者假设
延伸讨论 从更高层次、更深机制和相邻领域继续推演 领域知识与外部可信资料

这个案例揭示了 Skill 设计的本质：同样是“读文章”，只有把使用目的、输出结构和个体上下文放进去，结果才会从信息压缩升级为决策支持。

案例二：用 Skill 封装企业 CLI

企业内部往往存在报销、客户、内容、审批等大量系统。若每个平台都把几十个 MCP 工具永久放进上下文，即使当天不用，也会持续占用注意力。课程展示了另一种组合：

自然语言 → Skill → CLI → 企业 API / 内部系统 Skill 负责识别意图、解释流程与选择命令；CLI 负责稳定调用系统。用户只描述任务，Agent 在需要时发现并安装 CLI，再执行相应操作。
  1. 先把系统能力做成 CLI提供版本、帮助、登录、登出、当前用户和核心业务命令，并保证错误信息可理解。
  2. 让 Skill 负责发现和引导在描述中写清平台能力和触发场景，在主体中说明认证、常见流程与安全边界。
  3. 自动处理安装从受控包源或内部 Git 地址安装所需 CLI，不要求每位用户先手工阅读安装手册。
  4. 通过帮助命令动态发现能力保留 --help 等入口，不在 Skill 中复制全部命令，降低 CLI 升级后的双重维护。
  5. 补充知识与业务流程除命令外，还可放入稳定规则，并描述跨多个命令的自然语言工作流。
  6. 设置确认和权限查询类操作可以自动执行；提交、删除、付款等高风险操作必须有明确授权或人工确认。
不要把危险能力无条件交给 Agent 企业 Skill 必须与身份、权限、审计和数据边界一起设计。高风险接口可以不暴露在 CLI 中，也可以要求 Skill 在执行前展示影响并等待确认。自动化程度越高，越需要清晰的责任边界。

08企业级最佳实践与评测闭环#

Skill 进入团队和生产环境后，重点从“能跑一次”转为“不同用户、不同模型和不同版本下仍然可控”。以下原则决定了它能否长期维护。

原则 实践方式 避免的问题
确定性优先交给代码 计算、格式转换、校验与批处理使用脚本，并补测试 模型执行慢、耗 Token、结果漂移
描述保持精简 只写能力、触发和关键限制，详细内容放主体或引用 元信息被截断，或多个 Skill 误触发
静态与动态知识分离 稳定规则放 Skill，频繁变化内容通过知识库 API 或 RAG 获取 每次知识更新都要求重新发布 Skill
按风险配置自由度 迁移与财务低自由度，结构化写作中自由度，探索与审查高自由度 关键流程失控，或创作任务过度僵化
控制目录深度 引用最好不超过两到三层，长文档顶部提供目录 Agent 找不到资料，加载无关内容
显式跟踪复杂流程 超过三个连续步骤时使用 Checklist，逐步记录完成状态 模型跳步骤，完成情况不可见
保存中间状态 批量任务用 JSON 等结构记录文件、阶段、结果与错误 中断后全部重做，问题无法定位
观察执行路径 除最终结果外，检查调用顺序、资料来源与确认动作 好模型偶然掩盖了错误指令

复杂任务需要 Skill、Subagent 和 Hook 协同

单个主 Agent 持续几十轮对话，很容易因上下文膨胀而丢失关键约束。可把相对独立的阶段交给不同 Subagent，每个 Subagent 只挂载所需 Skill；相互独立的任务还可以并行执行。Hook 则适合在固定生命周期触发脚本，例如代码审查完成后发送通知。

Skill提供可复用的知识、步骤、规则和工具入口。
Subagent隔离任务上下文，承担一个边界清晰的阶段或专业角色。
CLI / MCP连接底层系统，提供结构化、可审计的操作能力。
Workflow / Script执行稳定、确定、可测试的处理逻辑。
Hook在开始、完成、失败等节点自动触发固定动作。
Knowledge Base维护频繁更新、规模较大的外部知识。

评测像单元测试一样进入仓库

领域负责人需要建立自己的评测集，而不是在每次优化后凭感觉判断。可以在 Skill 目录中维护 evals/，为每个用例记录输入、必要文件、期望输出与评分规则。

skill-name/
├── SKILL.md
├── references/
├── scripts/
└── evals/
    ├── cases.json
    └── files/
  1. 选择代表性用例覆盖常规任务、边界情况、历史失败案例和高风险输入。
  2. 定义可检查的预期记录必须出现、不得出现、格式约束和业务评分维度。
  3. 修改前建立基线保存当前版本在同一模型和输入下的结果与分数。
  4. 修改后批量回归比较新旧版本，防止修复一个问题却破坏其他场景。
  5. 吸收真实反馈把用户发现的 Bad Case 变成新用例，再更新规则、脚本或知识。

课程演示的 Skill Optimizer 思路，是用 Anthropic 的实践、Google 的设计模式和个人经验审查 Skill，按优先级列出问题，再由维护者确认修改计划。这相当于给 Skill 增加代码审查，但最终的业务正确性仍需领域专家负责。

09从现场 Skill 到 FDE 产品化#

瑞老师的分享把 Skill 放回 FDE 的完整工作中：模型能力很强，但企业仍需要有人理解业务、接入系统、满足合规要求，并把演示结果变成真实生产力。这个“最后一公里”正是 FDE 的主要工作场。

从碎石路到柏油马路

客户第一次提出的新问题，往往没有标准答案。FDE 先在现场快速做出能运行的方案，这是一条只适用于当前场景的“碎石路”；当多个客户反复出现相似需求后，团队抽取其中七八成通用逻辑，把它沉淀为标准组件、Skill、工作流或产品能力，形成可以快速复用的“柏油马路”。

  1. 进入真实现场观察客户如何工作，理解数据、系统、角色和例外情况。
  2. 用 Demo 对齐需求让客户看到具体流程，在真实反馈中修正双方理解。
  3. 完成当前项目通过开发、模型、集成、部署与培训解决眼前业务问题。
  4. 识别重复模式比较不同项目，区分客户特有部分与稳定共性。
  5. 返回产品底座将共性沉淀为平台组件、连接器、评测集、Skill 或标准方案。

这也是 FDE 与普通定制外包的重要区别：不只做完一单，而是让每次现场工作都改善下一次交付。

FDE 同时对三类价值负责

对象 核心价值 工作结果
客户 把 AI 演示变成可量化的生产力 真实用户能使用，业务指标得到改善
公司 连接客户需求、交付成本与收入 项目可成交、可验收、可持续服务
产品 把现场摩擦转化为产品发现 需求进入平台底座，后续项目更快交付

因此，FDE 既需要工程能力，也需要顾问和产品能力。日常工作不只写代码，还包括售前演示、需求拆解、现场集成、跨角色沟通、培训、知识转移和产品反馈。驻场、出差与客户拉扯也是岗位的真实组成部分。

非技术背景如何开始

课程建议先用 Dify、Coze 等低代码平台跑通一个小型 RAG 或 NL2SQL 场景，理解数据如何进入、Agent 如何处理、结果如何评估，再逐步补齐一门编程语言、部署集成和工程化知识。

硬技能基础编程、Prompt、Context 与 Harness Engineering、RAG、NL2SQL、部署集成、评测。
软技能模糊问题拆解、跨角色沟通、快速学习、现场适应、耐心与业务判断。
入门练习先完成一个可演示、可测试的小闭环，而不是一次搭建完整企业平台。
长期积累持续关注模型与工具变化，把新能力映射到真实业务，而不是只追逐概念。

产品案例：袋袋 AI

未来式智能把现场积累继续产品化，形成袋袋 AI。产品尝试将“专家市场、能力商店、对话式 Skill 蒸馏、长期记忆与企业协作工具接入”组合起来，让被验证过的方法能够作为专家能力被重复调用。

直播展示的 HR 简历筛选、PPT 生成等场景，都体现了同一条路径：先明确岗位要求和输出标准，再用 Agent 批量处理，保留排序、理由和人工判断入口。产品本身不是终点，更重要的是它如何承接现场已经验证的规则和反馈。