为什么产品经理需要理解Skill结构 ？
产品经理学习 Skill，不是为了立刻成为工程师，而是为了能够与 AI、工程师、业务团队和供应商共同设计一种新的能力模块。
如果产品经理只知道“Skill 是可复用任务能力模块”，但不了解它的基本结构，就会出现三个问题。
第一，无法判断 Skill 是否写得好。一个 Skill 名称可能很漂亮，例如“智能 PRD 生成器”“超级用户研究助手”“竞品分析专家”，但它内部结构可能非常混乱。产品经理如果看不懂结构，就只能被名称和演示效果误导。
第二，无法向工程师提出清晰需求。很多产品经理会说“我们需要一个能自动写 PRD 的 Skill”，但这不是需求说明，而是愿望表达。工程师真正需要知道的是：什么时候触发、输入什么、处理什么、输出什么、不做什么、成功标准是什么。
第三，无法治理团队 Skill。一个团队一旦积累几十个 Skill，如果没有结构意识，就会出现重复、边界冲突、触发混乱、输出不一致、无人维护等问题。
因此，本章的目标不是讲工程细节，而是帮助产品经理建立最小必要结构认知。
本章只讲五个核心问题：
- 这个 Skill 叫什么？
- 它什么时候该被使用？
- 它需要什么输入？
- 它应该怎样处理？
- 它应该输出什么？
- 它不应该做什么？
如果一个产品经理能回答这六个问题，就已经具备了理解 Skill 结构的基础能力。
Skill的最小结构模型
从产品经理视角，一个 Skill 可以被理解为六个部分：
Name + Description + Input + Process + Output + Boundary
中文可以表达为：
名称 + 描述 + 输入 + 处理规则 + 输出 + 边界
这不是某个平台唯一的技术标准，而是本教材为了产品经理学习和沟通建立的通用结构模型。不同平台可能使用不同字段、不同文件格式、不同触发机制，但大多数有效 Skill 都离不开这些要素。
Name：这个Skill叫什么
Name 是 Skill 的名称。它帮助用户、团队和系统识别这个 Skill。
好的名称应该简短、具体、任务导向。
不理想的名称：
- “产品经理助手”
- “超级分析专家”
- “AI 文档神器”
这些名称就更为清晰：
- “PRD完整性检查”
- “用户反馈需求提取”
- “会议行动项整理”
- “竞品功能对比分析”
名称不应该追求营销感，而应该帮助用户快速判断任务用途。
对产品经理来说，Skill 名称最好回答一个问题：
它处理哪一类任务？
Description：这个Skill什么时候使用
Description 是 Skill 中非常关键的结构。它不仅是给人看的简介，也常常是模型判断是否调用 Skill 的重要依据。
在 OpenAI Codex Skills 文档中，SKILL.md 文件需要包含 name 和 description，并建议通过测试提示来确认 Skill description 是否带来正确的触发行为。Anthropic 的公开 Skill 创建说明也明确提到，description 字段是决定 Claude 是否调用某个 Skill 的主要机制。阿里云文档同样强调，智能体会先读取 Skill frontmatter 中的 name 和 description 来判断相关性，只有任务匹配时才加载完整内容。
因此，对产品经理来说，description 不是宣传语，而是触发说明。
不好的 description：
这个描述太宽泛，模型和用户都很难判断何时使用。
可以修改成下面的 description：
这个描述明确说明了三件事：
- 使用场景；
- 输入材料；
- 任务目标。
好的 description 应该尽量回答：
- 什么情况下使用？
- 用户会提供什么？
- Skill 要完成什么？
- 什么情况下不要使用？
Input：这个Skill需要什么输入
Input 是用户或系统需要提供给 Skill 的材料。
例如，一个“用户反馈需求提取 Skill”的输入可能包括：
- 用户反馈原文；
- 用户来源；
- 产品背景；
- 反馈时间；
- 用户类型；
- 当前功能状态；
- 分析目标。
如果输入不清楚，Skill 输出就容易漂移。很多 Skill 表面上失败，是因为输入要求没有被定义清楚。
产品经理要注意，Input 不只是“用户输入一段文字”。它还包括任务所需的上下文、约束条件和判断依据。
例如，如果用户要求 AI 生成 PRD，但没有提供目标用户、业务目标和约束条件，Skill 不应该假装知道，而应该提示用户补充。一个成熟的 Skill 应该能够识别输入不足。
Process：这个Skill如何处理任务
- 先识别会议主题；
- 再区分结论、讨论观点、行动项和未决问题；
- 再为每个行动项提取负责人和截止时间；
- 如果没有负责人或截止时间，标记为“未明确”；
- 最后输出结构化表格。
Output：这个Skill输出什么结果
Output 是 Skill 的交付物。它决定了结果是否可用。
例如，一个“竞品功能对比 Skill”的输出可以规定为：
- 竞品名称；
- 目标用户；
- 核心场景；
- 关键功能；
- 定价方式；
- 体验亮点；
- 潜在弱点；
- 对本产品的启示；
- 信息来源；
- 不确定性。
输出结构越清晰，结果越容易进入后续流程。对于产品经理工作来说，好的 Output 通常不是一段自然语言，而是可评审、可复制、可追踪的结构化结果。
Boundary：这个Skill不做什么
- 它只能识别潜在风险点；
- 不能替代律师意见；
- 不能给出最终合规结论；
- 遇到合同、劳动、人事处罚、医疗、金融等高风险事项时，应提示人工专家确认。
SKILL.md 是什么？
在很多主流 Skill 体系中，SKILL.md 是 Skill 的核心说明文件。OpenAI Academy 将 SKILL.md 解释为 Skill 的 playbook，也就是告诉 ChatGPT 如何一致运行某个工作流的纯文本说明。Anthropic 的工程文章也说明，最简单的 Skill 是一个包含 SKILL.md 文件的目录，并且该文件以 YAML frontmatter 开始，包含必要元数据。
产品经理不需要在本章掌握完整文件系统，但需要理解 SKILL.md 的作用：
SKILL.md 是 Skill 的任务说明书。它告诉智能体：这个 Skill 是什么、什么时候使用、使用后按什么规则执行。
可以把 SKILL.md 想象成一份给 AI 员工看的 SOP。
传统 SOP 是写给人看的，告诉员工如何处理一类工作。
SKILL.md 是写给智能体看的，告诉 AI 如何识别任务、加载方法、执行步骤、生成结果。
二者的区别在于：SKILL.md 不只是说明文档，它会影响智能体的行为。2026年的一项关于 SKILL.md 安全风险的研究指出，SKILL.md 中的自然语言元数据和指令会影响 Skill 如何被发现、选择和加载，因此它不是被动文档，而是会塑造智能体行为的“操作性文本”。
这意味着，产品经理不能把 SKILL.md 当成普通 README。它的每句话都可能影响模型判断、任务执行和输出边界。
SKILL.md 的最小结构
不同平台对 SKILL.md 的具体要求不同，但常见形态通常包括两部分：
- 第一部分：元数据。
- 第二部分：正文说明。
元数据：让系统知道“这是什么”
元数据通常写在文件开头，用于告诉系统 Skill 的基本信息。许多平台采用 YAML frontmatter 的形式。阿里云文档说明，Agent Skills 是以 SKILL.md 为中心的版本化目录，SKILL.md 包含 YAML frontmatter 和 Markdown 正文；智能体先读取 frontmatter 判断相关性，再在激活后加载完整正文。VS Code 的 Agent Skills 文档也给出示例：SKILL.md frontmatter 中包含 name 和 description，正文则包含详细说明。
最小元数据通常包括：
name: prd-review
description: Use this skill when the user provides a PRD draft or feature requirement and wants to check whether key product requirement elements are missing.对产品经理来说，你不需要纠结 YAML 语法，但要理解：
name 是 Skill 的身份；
description 是 Skill 的触发说明。
如果 description 写得不好，Skill 可能不会在该用时被调用，也可能在不该用时被调用。
正文说明：让AI知道“怎么做”
正文通常用 Markdown 写，说明任务处理规则。它可以包括：
- 任务目标；
- 适用场景；
- 输入要求；
- 处理步骤；
- 输出格式；
- 质量标准；
- 边界条件；
- 示例。
例如：
# PRD Review Skill
## Purpose
Check whether a PRD draft contains the minimum elements required for product review.
## Input
The user should provide a PRD draft, feature brief, or requirement description.
## Steps
1. Identify the product goal and target user.
2. Check whether user scenario, business metric, functional scope, edge cases, acceptance criteria, and analytics plan are included.
3. Mark missing items explicitly.
4. Do not invent missing information.
## Output
Return a table with: item, status, evidence, issue, suggested revision.
## Boundaries
Do not decide whether the feature should be built. Only review document completeness.
Description：最容易被低估的结构
在 Skill 结构中，description 是最容易被低估、但又非常关键的部分。
很多初学者会把精力放在正文指令上，写很长的处理规则，却随便写一句 description：
“用于产品经理工作。”
这会导致触发混乱。因为系统或模型在发现 Skill 时，常常首先看到的是 name 和 description，而不是完整正文。OpenAI Codex Skills 文档明确把测试 skill description 的触发行为作为建议步骤。阿里云文档也说明，在 Discovery 阶段，智能体只读取每个 Skill frontmatter 中的 name 和 description 来评估相关性。
好的description应该具体
不好的 description：
问题是太宽泛。用户需求有很多种：访谈分析、反馈归类、需求优先级、需求澄清、PRD 检查、用户故事生成。系统不知道何时触发。
较好的 description：
这个描述清楚说明了输入类型和任务目标。
好的description应该包含触发信号
- “帮我整理用户反馈。”
- “从这些访谈里提取需求。”
- “看看这些客服记录反映了什么痛点。”
- “把这些用户原话转成产品机会。”
好的description应该避免过度泛化
如果 description 写成“适用于所有产品经理任务”，它很可能在不该触发时触发。
Skill 的触发范围越宽，误触发风险越高。误触发会导致 AI 用错误方法处理任务。
例如，用户只是想“解释一下用户故事是什么”，结果触发了“用户故事生成 Skill”，输出了一份表格。这就是触发范围过宽。
Input：输入设计决定输出上限
Skill 的输入设计要回答三个问题：
- 用户必须提供什么？
- 用户最好提供什么？
- 缺少信息时怎么办？
必需输入
必需输入是没有它就无法完成任务的信息。
例如，会议纪要 Skill 的必需输入是会议记录。没有会议记录，就无法整理纪要。
PRD 检查 Skill 的必需输入是 PRD 初稿或需求说明。没有文档，就无法检查完整性。
推荐输入
推荐输入不是绝对必要，但会显著提升输出质量。
例如，用户反馈分析 Skill 的推荐输入包括产品背景、用户类型、反馈来源、时间范围。缺少这些信息，仍然可以初步整理，但分析质量会下降。
缺失处理
成熟 Skill 应该说明输入不足时怎么办。
常见做法有三种：
- 要求用户补充；
- 标记为“信息不足”；
- 只基于当前材料输出初步结果。
不成熟 Skill 的典型问题是：输入不足时仍然给出完整结论。
例如，用户只提供一句“用户觉得会员功能不好用”，AI 却输出“用户主要痛点是价格敏感、权益感知弱、续费意愿低”。这可能看起来专业，但实际上是在编造。
好的 Skill 应该写明：
“如果输入材料中没有明确证据，不得推断为确定结论。”
Output：输出不是结果，而是交付格式
很多人以为 Output 就是“AI 回答什么”。对产品经理来说，Output 应该被理解为“交付格式”。
一个 Skill 的输出设计至少要回答：
- 输出给谁看？
- 输出用于什么流程？
- 输出需要哪些字段？
- 输出是否需要证据？
- 输出是否需要下一步建议？
- 输出是否需要标记不确定性？
例如，“需求机会分析 Skill”的输出不是“总结一下用户需求”，而应是：
| 字段 | 含义 |
|---|---|
| 用户原话/证据 | 来自输入材料的事实依据 |
| 使用场景 | 用户在什么情境下遇到问题 |
| 痛点 | 用户表达或行为体现的困难 |
| 需求假设 | 产品经理可以进一步验证的需求判断 |
| 产品机会 | 可能的功能或服务方向 |
| 证据强度 | 强、中、弱 |
| 不确定性 | 需要继续验证的问题 |
输出格式要稳定
Skill 的输出格式不应每次变化太大。否则团队很难复用。
如果第一次输出表格，第二次输出段落，第三次输出项目符号，说明输出结构不稳定。
输出字段要有业务意义
输出字段不是越多越好。字段必须服务于后续决策。
例如，会议纪要中“会议氛围”不是所有团队都需要；但“行动项、负责人、截止时间、未决问题”通常是必要字段。
输出要区分事实和推测
分析型 Skill 尤其要区分：
- 输入中明确出现的事实；
- AI 根据事实做出的推测；
- 建议采取的行动。
如果三者混在一起，结果很容易误导决策。
Trigger：触发逻辑的产品经理理解
Trigger 可以理解为：什么情况下 Skill 会被调用。
不同平台的触发机制不同。有的平台由模型自动判断，有的平台由用户显式选择，有的平台由工作流节点固定调用，有的平台通过插件、工具或配置触发。因此，本章不讨论具体实现，只讲产品经理必须理解的触发逻辑。
从产品经理角度，触发有三种常见方式：
显式触发
用户明确选择或点选某个 Skill。例如：
“使用 PRD 检查 Skill 帮我看这份文档。”
这种方式最清楚，误触发少，适合团队培训和早期使用。
隐式触发
用户没有明确选择 Skill，但系统根据任务判断自动使用。
例如，用户说：
“帮我检查这份 PRD 有没有遗漏。”
系统判断这与 PRD 检查 Skill 匹配，于是自动调用。
隐式触发体验更自然，但对 description 要求更高。如果 description 模糊，就容易漏触发或误触发。
流程触发
- 转写；
- 清洗；
- 痛点提取 Skill；
- 需求机会生成 Skill；
- 人工审核。
Resources：资源文件的最小理解
有些 Skill 不只有 SKILL.md，还可能包含模板、示例、脚本、参考资料、品牌规范、表格文件或代码文件。Anthropic 的公开仓库说明，Skills 是由 instructions、scripts 和 resources 组成的文件夹，Claude 会动态加载它们以提升特定任务表现。阿里云也将 Agent Skills 定义为按需加载的指令和资源包。
产品经理不需要掌握这些资源如何存放，但必须理解它们的产品意义。
资源文件可以让 Skill 更稳定。
例如：
- PRD Skill 可以包含公司 PRD 模板；
- 品牌写作 Skill 可以包含品牌语气指南；
- 竞品分析 Skill 可以包含标准对比表；
- 数据报告 Skill 可以包含图表格式规范；
- 供应商评估 Skill 可以包含评分表。
资源文件的价值是减少模型自由发挥，让输出更符合组织标准。
但资源越多，维护成本越高。过时模板、旧品牌规范、废弃字段都会影响 Skill 输出。因此，资源文件必须有版本管理和责任人。
Skill结构示例
下面是一个简化示例。它不是要求你现在就写代码，而是帮助你理解 Skill 的基本结构。
示例：PRD完整性检查Skill
name: prd-completeness-review
description: Use this skill when the user provides a PRD draft, feature brief, or requirement document and wants to check whether key product requirement elements are missing before review.
---
# PRD Completeness Review
## Purpose
Check whether a PRD draft is complete enough for product review.
## Input
The user should provide:
- PRD draft, feature brief, or requirement description
- Product background if available
- Target users if available
- Business goal if available
## Process
1. Identify the product goal, target user, and core user scenario.
2. Check whether the document includes:
- Problem statement
- Target user
- User scenario
- Functional scope
- Non-goals
- Edge cases
- Acceptance criteria
- Analytics or success metrics
- Dependencies and risks
3. Mark each item as complete, partially complete, missing, or unclear.
4. Use evidence from the provided document.
5. Do not invent missing information.
## Output
Return a table with:
- Check item
- Status
- Evidence from document
- Issue
- Suggested revision
Then provide:
- Top 3 risks
- Questions产品经理should clarify before review
## Boundaries
Do not decide whether the feature should be built.
Do not estimate engineering workload unless the user provides technical constraints.
Do not treat missing information as automatically wrong; mark it as requiring clarification.
- Name 说明身份；
- Description 说明触发场景；
- Input 说明需要材料；
- Process 说明处理步骤；
- Output 说明交付格式；
- Boundary 说明不做什么。
Skill结构的常见问题
名称过大
例如：
“万能产品经理 Skill”
“AI 商业分析专家”
“全流程增长助手”
这类名称听起来强，但任务边界太宽。名称过大通常意味着 Skill 过大。
Description过泛
例如：
“用于提高工作效率。”
“用于分析产品问题。”
“用于帮助用户完成任务。”
这类 description 无法提供清晰触发信号，容易误触发或不触发。
输入没有定义
如果 Skill 没有说明输入要求，用户就会随意提交材料。结果差时，也很难判断是 Skill 问题还是输入问题。
处理步骤缺失
只有输出模板，没有处理步骤，会导致 AI 只是填表，而不是分析。
例如，一个竞品分析 Skill 如果只规定输出“优势、劣势、机会、威胁”，但没有说明如何从资料中提取依据，输出就容易空泛。
输出格式不稳定
输出格式不稳定会让 Skill 难以进入团队流程。团队需要的是可复用格式，而不是每次都重新整理的自然语言。
边界缺失
边界缺失是高风险问题。尤其在合规、合同、人事、财务、医疗、投资、安全等场景，Skill 必须说明不能替代专业判断。
资源过时
Skill结构与产品需求说明的关系
产品经理可以把 Skill 结构理解为一种新的产品需求说明。
传统功能需求通常描述：
- 用户是谁；
- 用户要做什么；
- 系统提供什么功能；
- 页面如何展示；
- 数据如何流转；
- 成功标准是什么。
Skill 需求则更关注：
- 用户在什么任务场景下需要 AI；
- AI 需要什么输入；
- AI 按什么规则处理；
- AI 输出什么交付物；
- AI 不能做什么；
- 用户如何判断结果好坏。
也就是说，Skill 是一种“AI 能力需求”，而不是传统页面功能需求。
这也是为什么本课程后续会专门讲“如何向工程师描述 Skill”。因为 Skill 结构天然连接了产品经理语言和工程语言。
如果产品经理能清楚写出：
- description；
- input；
- output；
- boundary；
- success criteria；
工程师就更容易把它转化为实际 Agent 能力。
最小Skill结构检查表
| 检查项 | 判断问题 |
|---|---|
| Name | 名称是否具体说明任务？ |
| Description | 是否说明何时使用、输入什么、完成什么？ |
| Input | 是否说明必需输入和推荐输入？ |
| Process | 是否说明处理步骤和判断规则？ |
| Output | 是否规定稳定输出格式？ |
| Evidence | 是否要求引用输入材料作为依据？ |
| Boundary | 是否说明不做什么、何时需要人工确认？ |
| Trigger | 是否容易被正确触发，避免过宽或过窄？ |
| Resources | 是否依赖模板、资料或脚本？这些资源是否可信和更新？ |
| Evaluation | 是否能检查输出质量？ |
学习案例：为什么这个Skill结构不好
原始Skill说明
描述：帮助产品经理完成各种产品工作，提高效率。
正文：
“你是一名资深产品经理。请根据用户要求完成产品分析、需求文档、竞品分析、用户研究、商业模式分析、项目管理等任务。输出要专业、清晰、有逻辑。”
问题分析
这个 Skill 看起来强大，但结构很差。
第一，名称过大。“产品经理助手”不是一个清晰任务，而是一个角色。
第二，description 过泛。“完成各种产品工作”无法告诉系统何时触发。
第三，输入缺失。它没有说明用户应提供什么材料。
第四，处理规则缺失。不同任务的处理方法完全不同，不可能用一句“专业、清晰、有逻辑”覆盖。
第五，输出缺失。它没有规定输出格式。
第六，边界缺失。它没有说明不能替代产品决策、不能编造数据、不能在信息不足时给确定结论。
改写方向
如果要改进，不应继续扩展这个大 Skill，而应拆分为多个小 Skill：
- PRD 完整性检查 Skill；
- 用户反馈需求提取 Skill；
- 竞品功能对比 Skill；
- 会议行动项整理 Skill；
- 需求澄清问题生成 Skill。
这说明一个重要原则：
好的 Skill 不是把更多能力塞进一个模块，而是把一个任务讲清楚。
小结
本章讲的是产品经理对 Skill 结构的最小必要理解。
Skill 的通用结构可以理解为：
- Name：它叫什么；
- Description：什么时候使用；
- Input：需要什么材料；
- Process：按什么方法处理；
- Output：输出什么结果；
- Boundary：不做什么。
在许多主流 Skill 体系中，SKILL.md 是核心说明文件。它通常包含元数据和正文说明。元数据帮助系统识别 Skill，正文说明告诉智能体如何执行任务。
对产品经理来说，最重要的不是掌握文件系统细节，而是理解结构背后的产品意义：
- description 影响触发；
- input 影响输出质量；
- process 影响专业性；
- output 影响可交付性；
- boundary 影响安全性；
- resources 影响组织标准；
- evaluation 影响能否进入团队流程。
一个 Skill 是否专业，不取决于它看起来有多复杂，而取决于它是否把一类任务讲清楚、做稳定、可检查、可复用。
课后练习
练习一：识别Skill结构
请阅读下面这个 Skill 描述，指出它缺少哪些结构。
请判断它是否说明了：
- 名称是否具体？
- 何时使用？
- 需要什么输入？
- 按什么步骤分析？
- 输出什么格式？
- 不适合什么场景？
- 结果如何检查？
练习二：补全一个Skill结构
请为“会议行动项整理 Skill”补全以下内容：
- Name：
- Description：
- Input：
- Process：
- Output：
- Boundary：
练习三：改写description
原始 description：
练习四：判断边界是否充分
AI 助教
提示：您可在此提出学习中遇到的问题。回答由 AI 生成，可能存在错误，请注意甄别。