什么是 Skill ？
在传统 AI 使用方式中，用户通常会通过提示词（ Prompt ）发起一次任务。通常而言，Prompt 是一次性的指令，Chat 是多轮对话过程，Tool 是模型可以调用的外部能力，而 Skill 则更接近“被封装起来的任务方法”。
目前，各大主流厂商虽然各自对 Skill 的定义并不完全一致，但总体上这些概念高度相似。OpenAI 对 ChatGPT Skills 的说明是：Skills 是可复用、可分享的工作流，用来告诉 ChatGPT 如何完成特定任务，可以包含指令、示例和代码，并在安装后由 ChatGPT 在有帮助时自动使用。Anthropic 对 Claude Agent Skills 的说明则强调，Skills 是可复用的、基于文件系统的资源，可以为 Claude 提供特定领域的专业能力，包括工作流、上下文和最佳实践。阿里云对 Agent Skills 的定义也强调“按需加载的指令与资料集合”，以独立目录组织，每个 Skill 的核心是 SKILL.md，智能体据此判断何时加载、如何执行。
你会发现，虽然这些定义虽然来自不同的厂商平台，但它们都共同指向三个关键词：
第一，可复用。 Skill 不是一次性的提问，而是可以在多个会话、多个任务、多个成员之间重复使用的能力。
第二，任务化。 Skill 面向的是一类任务，而不是一个宽泛主题。例如“市场分析”太宽，“根据指定竞品网页输出三栏竞品对比表”更接近 Skill。
第三，可触发。 Skill 不是永远塞进模型上下文里的长提示词，而是在任务匹配时被加载或调用。不同平台的触发机制不同，有的平台强调模型自动判断，有的平台强调用户显式选择，有的平台把类似能力放在工作流、插件、组件或智能体配置中。
对产品经理来说，我们可以暂时不纠结不同平台的底层实现方法。最重要的是先形成一个基本认知：
如果只是一次性的问题，使用提示词即可；但如果你希望 AI 以后遇到类似任务都同样处理，那就需要用到 Skill。
Skill 的任务能力模块
为了让产品经理真正理解 Skill，你可以先记住一个简化模型：
Skill = 任务目标 + 输入要求 + 处理方法 + 输出标准 + 使用边界
这五个部分构成了 Skill 的 PM 认知模型。
任务目标：这个 Skill 要完成什么事
每个 Skill 必须有清晰任务目标。目标越具体，Skill 越稳定。
不好的目标是：
更清晰的任务目标是：
更具体一点，你可以这样修改：
产品经理在设计 Skill 时，首先要问的不是“AI 能做什么”，而是“这个任务是否真的值得被重复执行”。只有重复出现、标准相对稳定、产出可以被检查的任务，才适合转换成 Skill。
Skill 的输入要求：用户需要提供什么材料？
Skill 的输出质量高度依赖输入。很多 AI 任务失败，往往并非因为模型能力不足，而是输入材料不完整、上下文不清楚、约束条件不明确。
例如，一个“PRD生成Skill”至少需要以下输入：
- 产品背景是什么？
- 目标用户是谁？
- 要解决什么问题？
- 当前已有功能或流程是什么？
- 业务目标是什么？
- 是否有约束条件，例如上线时间、合规要求、技术依赖？
如果输入缺失，Skill 应该能够提醒用户补充，而不是假装知道答案。对产品经理而言，这是一个非常重要的产品意识：好的 Skill 不是“无论用户给什么都输出一大段文字”，而是能够判断输入是否足够，并在必要时要求澄清。
Skill 的处理方法：AI 应该按什么步骤完成任务？
Skill 的核心不是一句“请帮我写”，而是隐藏在任务背后的处理流程。
例如，“竞品分析Skill”不应只是让 AI 输出竞品优缺点，而应包含一套分析路径：
- 先识别竞品所属品类；
- 再提取核心用户和使用场景；
- 然后比较核心功能、定价方式、交互路径、差异化价值；
- 最后输出对本产品的启示，而不是停留在信息罗列。
处理方法越清晰，Skill 输出越稳定。PM 不一定要写代码，但必须能够把任务拆成合理步骤。这也是本课程后续“多步骤 Skill 设计”和“Skill 组合”的基础。
Skill 的输出标准：结果应该是什么？
Skill 的价值很大程度体现在输出标准化上。对团队协作而言，“每次都能得到类似结构的结果”比“偶尔生成一篇惊艳文字”更重要。
例如，一个“会议纪要Skill”的输出标准可以是：
- 会议主题；
- 参会角色；
- 关键结论；
- 未解决问题；
- 行动项；
- 负责人；
- 截止时间；
- 风险提醒。
如果没有输出标准，AI 会根据当前对话自由发挥。自由发挥适合探索，不适合交付。产品经理使用 Skill 的一个关键目的，就是把 AI 从“聊天对象”转化为“稳定任务处理器”。
Skill 的使用边界：这个Skill不该做什么？
很多失败的 AI 应用并非自身能力太弱，而是边界太模糊。Skill 也一样。一个 Skill 不能什么都做。
例如，“用户研究分析Skill”可以帮助整理访谈记录、归纳痛点、提出假设，但不能自动宣称“这就是市场真实需求”；“合规风险初筛Skill”可以指出可能风险，但不应替代律师意见；“数据分析Skill”可以解释趋势，但不应在数据不足时给出确定性结论。
边界意识对产品经理尤其重要。产品经理在组织中经常负责把 AI 结果转化为产品决策。如果 Skill 的边界不清楚，AI 生成的内容很容易被误当成事实、结论或承诺。
Skill、Prompt、Chat、Tool 的区别
Skill vs Prompt
Prompt 是一次指令。Skill 是一套可复用任务方法。
Prompt 更像“临时对助理说的一句话”：
“帮我把这段会议记录整理成纪要。”
Skill 更像“给助理的一本岗位操作手册”：
“以后遇到会议记录整理任务时，先识别会议主题和参与角色，再区分事实、结论、行动项和风险；输出必须包含负责人、截止时间和未决问题；如果记录中没有截止时间，要标记为‘未明确’，不能自行编造。”
Prompt 的优点是灵活，适合探索、临时任务和一次性问题。Skill 的优点是稳定，适合重复任务、团队标准和组织级复用。
因此，产品经理不应把所有 Prompt 都做成 Skill。只有当某类 Prompt 被反复使用、反复调整、反复复制粘贴，且输出质量影响团队协作时，才值得沉淀为 Skill。
Skill vs Chat
Chat 是对话过程。Skill 是对话中可能被调用的能力模块。
在 Chat 中，用户可以随时追问、补充背景、改变方向。Chat 的优势是开放、自然、适合探索。但 Chat 的问题是过程不可控，结果依赖上下文。一次对话中出现的好结果，不一定能在下一次对话中稳定复现。
Skill 则试图把对话中的优秀方法沉淀下来。它不是替代 Chat，而是让 Chat 在处理某些任务时拥有更稳定的“工作习惯”。
例如，PM 和 AI 多轮讨论后，发现一套需求拆解方法很好用：先定义用户场景，再识别行为目标，再拆解功能路径，再写验收标准。此时，就可以把这套方法沉淀为“需求拆解Skill”。以后用户不必每次重新解释这套方法，只需提供需求背景，Skill 就可以按固定方法处理。
Skill vs Tool
Tool 是外部工具或能力，通常用于让模型完成自己不能直接完成的操作。例如搜索网页、查询数据库、调用 API、生成图片、读写文件、发送邮件、执行代码。
Skill 不是 Tool。Skill 更像“如何使用能力完成任务的方法”。一个 Skill 可以只包含指令和模板，也可以包含对工具的调用规则。Anthropic 的公开说明中提到，Skills 可以通过指令和代码为 Claude 提供新能力，但同时也指出这会引入安全风险，因为恶意 Skills 可能影响环境、窃取数据或导致非预期行为。
用产品经理的话来说：
- Tool 回答的是：“AI 能调用什么外部能力？”
- Skill 回答的是：“AI 应该在什么场景下，按什么流程，使用哪些能力，产出什么结果？”
例如，网页搜索是 Tool；“用网页搜索完成一份竞品功能更新分析，并按公司模板输出结论”才是 Skill。
Skill vs Workflow
Workflow 是显式流程，通常强调步骤编排、节点连接、条件分支和可观测执行。Dify 将自己定位为生产级 Agentic Workflow 平台，强调在一个协作画布中构建智能体工作流、RAG 管道、模型和工具。阿里云百炼也把智能体和工作流列为应用构建的核心模式，用于突破大模型在私有知识、实时信息、固定流程和复杂任务规划方面的限制。
Skill 与 Workflow 的区别在于：
- Skill 更像“能力说明书”或“任务处理模块”；
- Workflow 更像“流程编排图”或“自动化流水线”。
在简单任务中，Skill 可以独立使用。在复杂任务中，一个 Workflow 可能调用多个 Skill；一个 Skill 也可能包含对某些流程步骤的说明。对 PM 来说，本章只需要理解：Skill 是能力单元，Workflow 是流程组织方式。二者不是互斥关系。
主流平台中的Skill差异：同一个概念，不同实现
目前，Skill 仍处于快速发展阶段。不同厂商、不同产品线对 Skill 的命名、形态和使用方式并不完全一致。也就是说，目前还不能把某一家厂商的实现方式当成行业唯一标准。这是使用和开发产品是要注意的问题。
OpenAI：从可复用工作流理解Skill
OpenAI 的 ChatGPT Skills 更强调“可复用、可分享的工作流”，目标是让 ChatGPT 按照特定方式更一致地完成任务。官方帮助文档说明，Skill 可以包含指令、示例和代码，并在创建和安装后由 ChatGPT 在有帮助时自动使用。OpenAI Academy 的说明还把 SKILL.md 解释为 Skill 的 playbook，即告诉 ChatGPT 如何一致运行某个工作流的文本说明。
对产品经理来说，可以把 OpenAI Skills 理解为：把一个经过验证的工作方法封装起来，让 ChatGPT 在合适场景中自动复用。
Anthropic Claude：从文件化能力包理解Skill
Anthropic 更强调 Agent Skills 是自包含的资源包。其公开仓库说明，每个 Skill 都位于自己的文件夹中，并包含一个 SKILL.md 文件，其中有 Claude 使用该 Skill 所需的指令和元数据。Claude API 文档则强调 Skills 为 Claude 提供领域专业能力，包括工作流、上下文和最佳实践。
对产品经理来说，Claude 的 Skill 形态更容易让人理解为“能力包”：里面不仅可以有说明，还可以有参考资料、脚本、模板等。但在本课程第一部分，我们暂时不深入文件系统细节，只把它理解为可复用能力模块。
阿里云百炼：从企业级Agent能力治理理解Skill
阿里云文档将 Agent Skills 定义为智能体按需加载的指令与资料集合，强调可复用、按需加载、可版本化和可组合。这对企业产品经理很重要，因为企业场景中的 Skill 不只是个人效率工具，还涉及知识沉淀、团队协作、版本管理、权限控制和治理。
对产品经理来说，企业级 Skill 的价值不只是“个人写得更快”，而是“组织能力可以被封装、复用、审查和迭代”。
扣子、Dify、千帆等平台：Skill常与工作流、插件、组件、智能体交织
中国市场中，很多平台并不一定都以同一种方式使用“Skill”这个词。扣子文档中提到，技能是快速封装可复用 AI 能力单元，可以嵌入扣子 AI 中，提供模块化功能扩展。百度千帆则更多以 Agent 引擎、工具及 MCP、模型服务、企业级服务等要素来描述 Agent 应用开发底座。
这意味着，中国客户和供应商在讨论 Skill 时，可能会把类似概念称为“技能”“插件”“组件”“工作流节点”“子Agent”“应用能力”或“SOP模块”。产品经理不应被名称困住，而应回到本章定义：
只要它把一类任务能力封装起来，并能被 AI 或 Agent 在合适场景中复用，就可以从 Skill 的视角来理解。
Skill 能帮产品经理解决哪些问题？
解决重复劳动问题
产品经理每天有大量重复性知识工作：
- 写需求背景；
- 整理会议纪要；
- 提炼用户反馈；
- 生成验收标准；
- 总结竞品变化；
- 撰写发布说明；
- 把业务方口语化需求转化为功能清单。
这些任务并不一定难，但频繁、耗时、易出错。Prompt 可以帮 PM 临时完成一次，Skill 则可以把这些任务沉淀为长期可复用能力。
解决输出不一致问题
团队使用 AI 最大的问题之一是标准不一致。每个人都会问 AI，但每个人问法不同，结果也不同。
对团队来说，真正重要的不是“某个人用 AI 很厉害”，而是“整个团队能不能稳定地产出符合共同标准的材料”。
例如，一个团队可以建立“PRD初稿Skill”“需求评审准备Skill”“用户访谈分析Skill”“版本发布说明Skill”。这些 Skill 可以统一输出结构、术语、字段和质量要求。这样，新人也能更快接近团队标准，资深 PM 也能减少重复审稿工作。
解决知识难以沉淀问题
很多组织的知识沉淀停留在文档、模板和培训材料中。但文档不会主动工作，模板也不会自动判断上下文。
Skill 的价值在于：它把知识从“静态资料”转化为“可执行的任务方法”。
例如，公司过去有一份《需求评审规范》，但 PM 经常忘记使用。把它转化为“需求评审检查Skill”后，AI 可以根据 PRD 自动检查是否缺少目标用户、业务指标、异常场景、埋点方案和验收标准。
这不是简单的信息存储，而是把组织经验转化为可反复调用的能力。
解决人机协作边界问题
在 AI 使用早期，很多 PM 会把 AI 当成“万能实习生”。但 AI 的输出质量并不稳定，也不总是知道组织上下文。Skill 可以帮助明确人机分工：
- AI 负责按规则整理、生成、转换、检查；
- PM 负责提供上下文、判断取舍、确认结论、承担决策责任。
这一区分非常关键。Skill 不应让 PM 放弃判断，而应减少低价值重复劳动，让 PM 把注意力放在更高价值的产品判断上。
案例：把“用户反馈整理”从 Prompt 升级为 Skill
案例背景
某 SaaS 公司每周会从客服系统、销售记录和用户访谈中收集大量用户反馈。过去，产品经理通常把这些反馈复制给 AI，然后输入：
“请帮我总结这些用户反馈。”
AI 会给出一些总结，但经常出现三个问题：
第一，输出过于概括，例如“用户希望功能更简单”“用户关注价格”“用户需要更好体验”。
第二，AI 会把用户原话、PM猜测和解决方案混在一起。
第三，不同 PM 得到的输出结构不同，无法进入统一的需求池。
Prompt 版本
原始 Prompt：
这个 Prompt 能用，但不稳定。它没有说明输入是什么、痛点如何定义、产品建议如何从证据中推导、输出结构是什么，也没有要求区分事实和推测。
Skill 版本
如果把它升级为 Skill，任务说明可以变成：
对比分析
- Prompt 关注的是“这一次帮我做什么”。
- Skill 关注的是“以后遇到同类反馈材料时，应该按什么标准处理”。
- Prompt 的结果适合临时阅读。
- Skill 的结果适合进入产品流程。
- Prompt 解决个人效率。
- Skill 解决团队复用和质量稳定。
这就是 Skill 对产品经理的真正价值。
常见误解
误解一：Skill 就是更长的 Prompt
Skill 可以包含提示词，但不能被等同于长 Prompt。长 Prompt 只是把更多要求写在一起；Skill 则强调任务封装、触发条件、输入输出、边界和复用。
如果一个“Skill”只是把几十条零散要求堆在一起，它可能比普通 Prompt 更难用。好的 Skill 应该更清晰，而不是更长。
误解二：Skill 越通用越好
很多初学者希望做一个“万能产品经理Skill”，能写 PRD、做调研、分析竞品、设计原型、写汇报、生成路线图。这个方向通常会失败。
Skill 越大，边界越模糊，输出越不稳定。初学阶段应该优先设计“小而清晰”的 Skill。例如：
- “把会议记录转成行动项”；
- “根据用户反馈提取需求假设”；
- “检查 PRD 是否缺少验收标准”；
- “把功能说明转成用户故事”。
真正强大的 Agent，不是靠一个万能 Skill，而是由多个边界清晰的 Skill 组合而成。
误解三：Skill 可以替代产品判断
Skill 可以帮助整理信息、生成初稿、检查遗漏、提供结构化分析，但不能替代 PM 对用户、市场、业务和组织约束的判断。
例如，Skill 可以根据反馈频次和证据强度建议优先级，但最终是否进入路线图，还要考虑战略方向、资源约束、商业价值、技术依赖和竞争窗口。
把 Skill 当成判断辅助是正确的；把 Skill 当成决策主体是危险的。
误解四：Skill 只是个人效率工具
在第一部分课程中，我们先从个人生产力工具学习 Skill，这是因为入门最容易。但从更长期看，Skill 不只是个人效率工具。它会成为 Agent 产品设计的一种语言。
当产品经理能够用 Skill 描述“一个智能体应该具备哪些能力模块”时，就能更清晰地与工程师、算法团队、业务团队和客户沟通。后续课程会进一步讨论：Skill 如何成为产品能力模块，如何组合成 Agent，如何与 RAG、工具调用、工作流和微调等方案区分。
小结
Skill 是 AI 智能体时代的一种关键抽象。对产品经理来说，最重要的不是一开始掌握它的工程实现，而是建立正确认知：
- Skill 是可复用任务能力模块。
- Prompt 是一次指令，Skill 是一类任务的稳定做法。
- Chat 是对话过程，Skill 是对话中可调用的能力。
- Tool 是外部能力，Skill 是使用能力完成任务的方法。
- Workflow 是流程编排，Skill 是能力单元。
- Agent 不是单个 Skill，而是多个能力模块的组合系统。
在真实产品工作中，Skill 的价值主要体现在四个方面：减少重复劳动、统一输出标准、沉淀组织知识、明确人机协作边界。
从本章开始，您需要逐渐形成一个新的 产品思维习惯：不要只问“我该怎么提示 AI”，而要进一步思考“这类任务是否值得被封装为可复用能力”。
这正是从普通 AI 使用者走向 AI 产品经理的第一步。
课后练习
练习一：识别Skill场景
请判断以下任务是否适合做成 Skill，并说明理由。
- “帮我想几个新产品名字。”
- “每周把客服反馈整理为需求机会表。”
- “解释一下什么是北极星指标。”
- “按照公司模板检查 PRD 是否完整。”
- “和 AI 随便聊聊某个创业想法。”
- “把用户访谈记录转化为痛点、场景、证据和需求假设。”
练习二：把Prompt改写成Skill思维
请把它改写为 Skill 任务说明，至少包含以下要素：
- 任务目标；
- 输入材料；
- 分析步骤；
- 输出格式；
- 边界条件。
练习三：寻找自己的第一个Skill
- 每周或每月重复出现；
- 每次处理方法大致相同；
- 输出需要给别人看；
- 质量不稳定会影响协作；
- 可以用明确格式表达结果。
AI 助教
提示：您可在此提出学习中遇到的问题。回答由 AI 生成，可能存在错误，请注意甄别。