AI概念层出不穷，但真正理解其底层逻辑的产品经理才能避免被概念泡沫迷惑。本文从Prompt到Skill，层层拆解AI产品经理必备的核心概念体系，用家政阿姨的生动类比还原技术本质，并揭示Notion与Cursor两大产品的真实案例如何验证Skill正在成为AI时代的决策基本功。

为什么要懂这些

作为一名拥有12年海内外互联网从业经历的产品经理，我见过太多被包装成“趋势”的概念泡沫。

目前，每隔三个月，AI 圈就会诞生一个新词。

这个词被人反复引用，出现在每一场 Demo Day 的 PPT 里，被写进产品路线图，被 VC 当作投资判断的关键词。

然后，六个月后，大家发现它其实就是某个老东西换了件新衣服。

Skills，就是这样一个词。

Skill 不是新概念，而是 Prompt、规则、工具与流程的重新封装。

我想告诉你的是：Skills的本质并不神秘，神秘的只是它被包装的方式。

当你真正理解它，你会发现自己站在了一个新的视角上——不是被概念牵着走，而是开始用概念来思考产品。

作为产品经理，你不需要会写代码，但你必须理解这套逻辑。因为未来两年，你的每一个 AI 产品决策，都会和这些概念直接相关。

本文会按照 Prompt → Command → Sys Prompt → MD → Skill 的顺序，一步步用生活化的方式拆开讲透，保证你能顺着一路看懂；同时，我也会把 Skill、Workflow和MCP的区别讲明白。

最后，我会用 Cursor 和 Notion 的真实案例，带你看懂为什么 Skill 正在成为 AI 产品经理的新基本功。

1. Prompt 是什么

让我先从最简单的地方开始。

你打开 ChatGPT，在输入框里敲了一句话：”帮我写一封给客户的道歉邮件。

“这句话，就是 Prompt——提示词。它是你和 AI 之间最原始的沟通方式。

简单，直接，但结果往往不可控。

想象一下，你妈妈第一次让家政阿姨打扫房间，只说了一句”帮我打扫一下”。

结果阿姨把客厅扫了，厨房没动，卫生间更是没进去。不是阿姨偷懒，是你说得不够清楚——她不知道你的标准是什么，不知道哪里更重要，不知道”打扫”在你家意味着什么。

AI 也一样。你说”帮我写道歉邮件”，它可能给你一封正式到像法律文件的信，也可能给你一封像朋友聊天的随意文字。

为了让结果更可控，我们开始在提示词里加规则：语气要正式、字数控制在 200 字以内、第一段要表达歉意、第二段要给出解决方案……这种详细规定步骤和格式的提示词，叫做Structured Prompt（结构化提示词）。

这就像你不再只说”帮我打扫”，而是给阿姨留了一张清单：”客厅先扫后拖，厨房重点擦灶台，卫生间马桶要消毒，书房的东西不要动。”她拿着这张清单干活，出错的概率自然就低了。

2. Command 是什么

结构化提示词解决了质量问题，但带来了新麻烦：太长了。

想象一下，你妈妈每次叫阿姨打扫，都要把那张清单重新手写一遍。一周用三次，就要写三遍。这不叫效率，这叫折磨。

Command，就是解决这个折磨的工具。

它的逻辑非常朴素：把你常用的那段长提示词存成一个文件，给它起一个短名字，比如/email。

下次你只需要输入 /email，系统自动把那段完整的结构化提示词替换进去，发送给 AI。

这就像你妈妈把那张清单贴在冰箱门上，以后每次只需要指着冰箱说”按上面的来”。清单还是那张清单，但调用它的成本从”重新手写”变成了”一句话”。

Claude Code 就支持这个功能，你可以把常用的提示词固化成 .md 文件，通过斜杠命令快速调用。

3. System Prompt 是什么

Command 解决了输入效率，但还有一个更深的问题没有被触及：AI 为什么有时候不听话？

你在提示词里写了”请用表格展示”，它给你纯文本。你写了”回复控制在 100 字以内”，它洋洋洒洒写了 500 字。提示词明明写得很清楚，为什么 AI 就是不照做？

答案在于，你输入框里敲的内容，在大模型的世界里有一个正式的名字：User Prompt（用户提示词）。它的优先级，并不是最高的。

在用户提示词之上，还有一层更高优先级的指令，叫做 System Prompt（系统提示词）。这是 AI 客户端在你看不见的地方，提前发给大模型的一套规则。

打个比方：你去银行办业务，你是客户，你的要求是 User Prompt。但银行柜员首先要遵守银行的内部操作规程——单日取现超过 5 万要申报，这是银行的 System Prompt。不管你说什么，这条规程的优先级永远高于你的要求。

同样的要求，放在 System Prompt 里，模型的遵循效果会显著好于放在 User Prompt 里。这是大模型设计层面的特性，不是 bug，是 feature。

一些 AI 工具专门留了入口，让用户可以自定义 System Prompt。Cursor 的 .cursorrules 文件、Claude Code 的 claude.md 文件，都是这个逻辑——你把”请始终用中文回复””代码注释必须包含函数用途说明”这类全局规则写进去，它就会在每次对话里自动生效，不需要你每次重复说。

就像你雇了一个长期家政阿姨，第一天入职时你跟她谈好了”我家规矩”：拖把用完要晾干、冰箱里的东西不能随便动、我不在家时不要开电视。这些规矩不需要每次打扫前重复，她已经记住了，每次来都自动遵守。

4. Metadata 是什么

现在，我们已经有了Structured Prompt、Command和 System Prompt这三件武器。但新问题来了：场景太多，文件太多，AI 怎么知道该用哪一个？

你有写简历的提示词文件，有写周报的，有写邮件的，有写产品需求文档的，有做竞品分析的……如果把它们全塞进一个 System Prompt 文件里，这个文件会变得无比臃肿，AI 读起来费劲，你维护起来更费劲。

最自然的解法是按场景拆分：每个场景一个独立的 .md 文件。但拆完之后，新问题出现了：AI 怎么知道在”帮我写个简历”这个请求下，应该去加载哪个文件？

如果让 AI 把所有文件都读一遍再判断，那 token 消耗会非常大。文件内容最终都会被转换成 token，文件越多越长，费用越高。对于一个每天要处理几百个请求的团队来说，token 成本是真实的运营成本。

Metadata（元数据）就是为了解决这个问题而生的。

做法很简单：在每个文件的开头，加一小段描述信息，说清楚这个文件是干什么的、适用于什么场景。

这就像你家冰箱门上贴了一张便条，写着：”左边抽屉是蔬菜、右边是猪肉牛肉、冷冻层左边是饺子右边是汤圆、最上层是剩菜。”你妈妈不需要打开每一层去翻找，看一眼便条就知道去哪里拿——这张便条就是 Metadata。

当你发出”帮我写个简历”时，AI 客户端不需要把所有文件的完整内容都发给模型，只需要把各个文件的 Metadata 发过去。模型读完这些轻量的描述，判断出”这是简历场景，应该调用简历写作专家文件”，然后客户端再去加载那个文件的完整内容作为 System Prompt 发给模型。

这个设计的精妙之处在于：它把“判断成本”和“执行成本”分开了。 判断用 Metadata（轻量），执行才加载完整文件（按需）。这是一种非常工程化的思维方式，也是很多成熟产品系统设计的底层逻辑。

5. References 和 Scripts 是什么

Metadata 解决了”选哪个文件”的问题，但随着需求越来越细，单个文件本身也会变得越来越大。

还是以写简历为例。同样是写简历，产品经理的简历需要突出业务理解和数据驱动；开发工程师的简历要体现工程复杂度和技术深度；算法工程师的简历则要展示论文成果和模型指标。这三种写法差异很大，如果都塞在一个文件里，文件会膨胀到难以维护。

解法是：继续拆。

在”写简历”的主文件里，只保留一个岗位入口——根据用户说的是什么岗位，路由到对应的子文件。如果子文件还是太大，就继续拆成更细的颗粒。这样，AI 客户端通过系统命令读取文件总纲，再根据当前需求一路下钻，只加载真正需要的那部分内容。

这种”按需加载、逐层下钻”的方式，有一个专业术语叫渐进式披露（Progressive Disclosure）。用不到的文件完全不消耗 token，系统只在真正需要的时候才去读取对应内容。

这就像你妈妈去菜市场买菜，不是把整个菜市场所有摊位都逛一遍，而是先看一眼今天想做什么菜，然后直奔对应的摊位。猪肉摊、蔬菜摊、豆腐摊——需要什么走哪里，不需要的地方一步都不多走。这就是渐进式披露：只在需要的时候，才去拿需要的东西。

这些被拆分出来的资料文件，统一放入一个叫 references 的文件夹，作为模型随时可以参考的知识库。

但光有文字还不够。AI 能读文件，那它能不能执行代码？当然可以。既然客户端能调用系统命令读取文件，那它同样可以执行 Python 脚本。比如，把 AI 生成的简历文字写入 Word 文档，再自动导出成 PDF——这完全可以通过一个脚本来实现。

把这些可执行的代码文件放入 scripts 文件夹，在提示词里写清楚”当用户需要导出 PDF 时，执行 export_pdf.py”，AI 就能和客户端配合，完成纯文本聊天之外的实际操作。

6. Skill 是什么

现在，把前面所有的东西放在一起：

• 一个主入口文件 skill.md，定义了这个能力包的核心逻辑和 Metadata
• 一个 references/ 文件夹，存放按需加载的参考资料
• 一个 scripts/ 文件夹，存放按需执行的代码脚本

把这三样东西打包成一个文件夹，给它起一个名字——写简历的叫resume-writer，写文章的叫article-writer——这个文件夹，就是 Skill。

Skill 的本质，是“被外化为文件夹形式、可动态加载的系统提示词能力包”。

它的完整工作流程是这样的：

这个流程里有一个关键特征值得注意：每一步都是按需触发的，没有任何一个步骤是预先写死的。 模型在执行过程中，根据实际情况决定要不要读参考资料、要不要执行脚本、要读哪份资料。这种灵活性，是 Skill 区别于传统配置文件的核心所在。

7. Skill 和 MCP 的区别

说到这里，很多人会问：这不就是 MCP 吗？

不是。它们解决的是完全不同层面的问题。

MCP（Model Context Protocol）解决的是“模型能不能用工具”的问题。

大模型本质上是一个文字处理系统，它的原生能力是读文字、写文字。但真实世界里，我们需要它去搜索网页、查询数据库、发送邮件、操作文件……这些都不是纯文字操作，需要调用外部系统的接口。MCP 就是为了解决这个问题而设计的协议——它给大模型配上了”手”，让模型可以通过标准化的方式调用各种外部工具。

但有了手，不代表会干活。

这就像你妈妈第一次用智能手机。手机给了她微信、支付宝、美团、地图……工具都在那里，但她不知道订外卖要先选地址再选餐厅，不知道转账之前要先加好友，不知道打车要提前输入目的地。工具齐全，但缺的是”怎么用这些工具完成一件事”的经验。

这就是 Skill 存在的意义。

Skill 是”操作经验”——它规定了在什么场景下、按照什么顺序、组合使用哪些工具。MCP 插件是工具，Skill 是使用工具的方法论。

两者是互补关系，不是替代关系。没有 MCP，Skill 只能操作本地文件；没有 Skill，MCP 给了工具但不知道怎么用。

8. Skill 和 Workflow 的区别

还有一个更容易混淆的概念：Workflow。

Workflow 这个词在 AI 圈被用滥了，但它的本质很清晰：把多个步骤预先定义好，按照固定顺序执行。 N8N、Dify、Coze 这类工具，都是做 Workflow 的——你用拖拽的方式搭建一条流水线，定义好”步骤 A 完成后触发步骤 B，步骤 B 的输出作为步骤 C 的输入”。

Workflow 的优势是可预测、可审计、可复现。你知道它会怎么跑，出了问题也知道在哪个节点出错了。

但 Workflow 的局限也很明显：它的流程在设计阶段就已经固定了，执行时没有弹性。

这就像你妈妈每天按照固定菜谱做饭——周一红烧肉、周二清蒸鱼、周三炒青菜……流程清晰，不会出错。但如果今天菜市场没有鱼，她就不知道该怎么办了，因为菜谱上写的是鱼。这是 Workflow 的天花板：它只能处理设计时预见到的情况。

而 Skill 更像是一个有经验的厨师。你告诉他”今天来了 6 个客人，其中一个不吃辣，预算 200 块”，他会根据当天市场的食材、客人的口味、预算的限制，动态决定做什么菜、先做哪道、哪道可以提前备好。他的”经验”不是一张固定菜谱，而是一套在任何情况下都能做出合理决策的能力。

Skill 的执行流程由大模型在运行时动态决定，这是它和Workflow最根本的区别。

用一句话来区分：Workflow是剧本，Skill 是即兴表演的能力。 剧本的好处是稳定，每次演出都一样。即兴表演的好处是灵活，能应对台下观众的突发反应。两者不是谁取代谁，而是适用于不同的场景。

9. 核心概念总结

走到这里，我们已经把整条概念链条走了一遍。让我用一张关系图把它们全部串联起来：

10. 个人观点

我想用两个真实的产品案例来说明 Skill 这个概念为什么重要，以及它将如何影响产品设计的方向。

案例一：Notion AI 的能力边界与下一步

Notion AI 是目前市面上做得比较成熟的 AI 写作助手之一。它内置了”改写””总结””续写””翻译”等多个功能入口。

这些功能，本质上就是一组预设的 Skill。每个功能背后，都有一套精心设计的 System Prompt，定义了 AI 在这个场景下应该怎么行动。当你点击”总结”，Notion 并不是把你的文章直接扔给模型说”帮我总结”，而是调用了一个包含完整指令的能力包：总结的格式是什么、长度是多少、应该保留哪些关键信息、用什么语气输出。

这套设计在 Notion AI 刚上线的时候效果非常好，因为它把复杂的提示词工程封装成了一键操作，降低了普通用户的使用门槛。但随着用户越用越深，一个根本性的局限开始暴露出来：这些 Skill 是 Notion 团队预设的，用户无法修改，更无法创建自己的。

你是一个法律顾问，你的”总结”需要提取合同条款中的义务和权利，按照甲乙双方分类列出；你是一个投资分析师，你的”总结”需要提炼财务数据和风险因素，用结构化的方式呈现。但 Notion AI 的”总结”功能对所有人都一样——它是为”平均用户”设计的，而现实中并不存在平均用户。

这个差距，就是未来产品竞争的核心战场。谁能率先让普通用户自定义和分享 Skill，谁就能从“工具”升级为“平台”。 工具的价值上限是功能完备，平台的价值上限是生态规模。Notion 目前停留在工具层，而 Skill 的开放化，是它迈向平台层的关键一步。

从产品设计的角度来说，Notion 接下来最值得做的事情，是开放一个 Skill 编辑器——让用户可以定义自己的 AI 行为模板，并在团队内部分享。这不是技术难题，这是产品决策：你愿不愿意把用户变成内容生产者，而不只是内容消费者。

案例二：Cursor 的 .cursorrules 生态——一个意外长出来的 Skill 市场

Cursor 是目前 AI 编程工具里用户黏性最高的产品之一，月活跃用户已超过 40 万开发者。它有一个功能叫 .cursorrules——本质上就是用户自定义的 System Prompt 文件，你可以在里面写”所有函数必须有类型注解””优先使用函数式编程风格””注释必须用中文”等规则，Cursor 会在每次 AI 辅助编码时自动遵守这些规则。

但真正有意思的事情发生在产品之外。Cursor 的用户自发在 GitHub 上建立了一个 .cursorrules 的共享仓库，截至 2025 年初，这个仓库已经收录了超过 400 个不同技术栈、不同场景的配置文件，GitHub star 数超过 2 万。React 开发者有一套，Python 数据科学家有一套，iOS 开发者有一套，甚至连”写干净的 SQL”都有专门的配置……

这个社区行为，本质上就是在自发构建一个 Skill 生态。用户把自己积累的”操作经验”外化成文件，分享给其他人复用。没有任何人组织这件事，没有任何激励机制，它就这样自然地长出来了。

这个现象背后有一个更深的逻辑值得思考：当知识可以被结构化、被文件化、被分享的时候，它的传播速度会发生数量级的变化。 一个资深 React 开发者积累了五年的编码规范，过去只能通过 Code Review 一点点传授给团队成员，现在可以写成一个 .cursorrules 文件，在十分钟内被全球任何一个开发者使用。

这让我想到一个产品层面的判断：Skill 的下一个形态，是可被发现、可被评价、可被交易的资产。

这不是科幻。App Store 在 2008 年上线时，很多人也觉得”开发者把应用放上去卖钱”是一件奇怪的事。但今天，App Store 的年交易额超过 1000 亿美元，它改变的不只是软件分发方式，而是重新定义了”谁能创造价值、谁能从中获益”这件事。

Skill Store 的逻辑完全相同。区别只在于：App Store 里卖的是代码，而 Skill Store 里卖的是经验——是一个法律顾问二十年积累的合同审查方法论，是一个资深产品经理对需求文档的结构化思考框架，是一个顶级文案写手对说服力的系统性理解。这些东西过去只存在于人的脑子里，现在第一次有了被外化、被传播、被定价的可能。

Cursor 社区的 .cursorrules 生态，只是这个趋势最早期、最粗糙的雏形。它还没有搜索、没有评分、没有版本管理、没有收益分配。但它证明了一件事：当工具足够开放，用户会自发地去构建生态，而不需要平台方去推动。 这是产品设计里最难得的信号——用户在用脚投票，告诉你他们真正需要什么。

从产品经理的视角来看，Cursor 接下来面临的最大机会，不是继续优化代码补全的准确率，而是把这个自发形成的 Skill 生态正式化：建立一个官方的 Skill 市场，提供搜索、评价、一键安装的能力，并给贡献者建立激励机制。这一步如果做好，Cursor 的护城河将从”更好的 AI 编程工具”升级为”开发者 AI 工作方式的标准制定者”——这两者之间的价值差距，是数量级的。

11. 这对产品经理意味着什么

讲完两个案例，我想在个人观点部分加一个维度，因为这才是我真正想说的。

Skill 的出现，正在重新定义产品经理这个岗位的价值边界。

传统意义上，产品经理的核心工作是”需求翻译”——把用户的模糊诉求翻译成工程师能够实现的技术规格。这个翻译工作的核心能力是：理解用户、拆解问题、写清楚文档。

但在 Skill 出现之后，这个翻译链条发生了根本性的变化。过去，产品经理写完 PRD，交给工程师，工程师写代码，测试上线，这个周期短则两周，长则两个月。而现在，一个懂得设计 Skill 的产品经理，可以直接把自己的业务逻辑封装成一个能力包，在几个小时内让 AI 按照这套逻辑工作——不需要等工程师排期，不需要等测试验收。

这不是在说产品经理要取代工程师。而是说，产品经理的工作边界正在向“直接实现”延伸，而不只是“描述需求”。 会设计 Skill 的产品经理，和不会的，在执行效率上的差距会越来越大。

更深一层：Skill 的设计本质上是在做”知识结构化”的工作——把一个领域的最佳实践、判断标准、操作流程，用 AI 能理解的方式表达出来。这件事，工程师不一定比产品经理做得好，因为它需要的不是编码能力，而是对业务的深度理解和对流程的系统性思考。

这恰恰是产品经理最擅长的事情。

所以我的判断是：

未来两年，“能设计 Skill”会成为产品经理简历上最有区分度的能力之一。

不是因为它技术门槛高，而是因为它要求你把过去停留在脑子里的隐性知识，转化为可被机器执行的显性结构。这个转化能力，才是真正稀缺的。

12. 结语：看穿包装的人，永远不会被包装迷惑

我在文章开头说，Skills 是一个被包装过的老朋友。

走到这里，你应该已经看清楚了：它的每一个组成部分——System Prompt、Metadata、References、Scripts——都不是新发明。新的只是把它们整合在一起、打包成文件夹、赋予它一个朗朗上口的名字这件事。

但这并不意味着 Skill 不重要。

一个概念的价值，不在于它是否原创，而在于它是否让人更容易理解和使用一套复杂的东西。

iPhone 没有发明触摸屏，没有发明手机，没有发明互联网，但它把这些东西整合在一起，让十亿人第一次真正用上了移动互联网。Skill 对于 AI 能力的意义，可能也是类似的——它不是技术突破，而是一种让复杂能力变得可管理、可分享、可积累的组织方式。

黄仁勋说过一句话，我一直记着：“The more you learn， the more you realize how much you don’t know. But the more you know， the faster you can learn.” 理解了 Skill 的底层逻辑，你学下一个 AI 概念的速度会快一倍，因为你已经知道那些包装下面藏的是什么。