从Prompt到Skill的进化，标志着AI应用进入更深度的SOP化阶段。本文作者通过实战经验揭示了Skill与Prompt的本质差异：前者是一套完整的作业系统，能整合规则、脚本、素材库等资源，实现复杂任务的自动化执行。文章不仅拆解了Skill的组织结构与迭代逻辑，更分享了'先跑通再封装'的核心方法论，为AI深度融入工作流提供了新思路。 最近一段时间，我干的最多的一件事，就是写各种Skills。 我在尝试把工作和日常生活中更多事情交给AI，让它更深度地融入到我的工作流。 正好最近表达欲恢复了一些，就想写篇文章，和大家聊聊我这段时间写Skill的方法和思考。 1. Skill和Prompt的区别是什么 在我刚接触Skill的时候，我在体验完后和朋友说的第一反应就是：这不就是一个大号的prompt吗？感觉好像也没有什么特别新的内容出来啊。 但在亲手写了很多Skill后，我觉得它们之间确实有连续性，但是也有很多明显的差别。 从底层逻辑上来讲，Skill和Prompt做的是同一件事情：让AI按照一套SOP标准去作业。 所以最简单的Skill和Prompt没有本质区别，比如Claude官方的设计Skill，它就是一个单Skill.md文件构成的Skill，里面对整体设计思路进行了描述，让模型能够基于这套逻辑去作业，放到Prompt上来也是一样的效果。 但在模型的调用方式上，Skill比Prompt更友好。 模型在作业时，可以先看到多个Skill的基础说明，然后根据当前任务判断要调用哪个Skill。而Prompt只能通过人工手动指定的方式来进行加载，很难在全局工作流里形成稳定的调用机制。 同时在复杂的SOP流程上，Skill能够实现更多Prompt做不到的事情了，它可以包含各种规则、参考文档、Python脚本、素材库，在不同的阶段让模型调用不同的内容。 而 Prompt则需要一次性把所有内容都喂给模型，但这样能够承载的信息量和复杂度都是有限的。内容一多不仅会占用大量上下文，也容易让模型在执行时抓不住重点。 所以我后来对Skill的理解就变了：Skill并不是一个大号的Prompt，它是一套可以让AI完成更加复杂SOP的作业系统。 2. 写Skill的流程：跑通、复盘、封装、回溯。 如果只说一个最核心的经验，那我认为是：不要一开始上来就是设计Skill，先和AI跑出效果，再封装成Skill。 这个逻辑和我之前写提示词有很大区别。 写提示词的时候，我是和AI一起先思考目标是什么，然后提示词的作业流程是什么，基于此设计出来一版提示词，再拿去测试，最后基于效果进行调整。 但这有一个大的前提：之前的AI作业更偏Chatbot，基本上都是网页里进行对话的。 而在Agent作业逻辑下，任务的复杂度是明显变高的，它不再只是多轮对话，中间会掺杂各种脚本、工具调用、文件读取、subagent分工的情况，所以很多流程很难在一开始就完整设计出来。 所以我现在更倾向于先和AI定一个目标，然后想办法达到对应的结果，再回头把这个过程封装成Skill。 这样做的试错成本最低，也可以降低很多的测试成本。 我目前的作业流程分为这四步。 1. 先和AI定好目标，然后把这个真实场景跑通：不需要刚开始就做到了一个完美的效果，但要先基于自己定好的目标拿到一个自己认可的结果。 2. 和AI复盘这个结果是怎么跑出来的：主要是和AI讨论整个过程中有哪些是正向的流程，哪些是负向的流程，哪些内容是应该保留沉淀下来的。 3. 把这套过程封装成Skill：让AI基于我们的复盘结果进行Skill封装即可，从真实成功经验中提炼出来的流程往往比凭空设计的流程效果好很多。 4. 做回溯测试：开一个新的对话，测试这个Skill能否稳定复现类似的结果，如果不稳定的话就要去看看问题出现在哪，然后对对应的Skill流程进行优化。 所以这套流程本质上不是先设计，再验证，而是先跑通，再复盘，再封装，再回溯。 3. Skill的组织结构 这里我准备单独开一个小节，讲一下Skill的组织结构，主要是方便大家理解模型是如何去加载一个Skill的。 当Claude Code、Codex这些Agent调用Skill时，并不是一上来就把整个Skill的全部内容都塞给模型，它是分多层级进行渐进式加载的。 第一层是Skill的描述：它由name和description两个字段构成，这两个字段会告诉模型这个Skill是做什么用的，方便模型在作业场景里要判断调用哪个Skill。 在一次对话中，模型是会把读取到的所有的Skill描述都加载进去的，所以在写Skill描述的时候，最好清晰明了的讲清楚场景是什么，比如说Skill是写PRD文档的，那description就要明确的告诉模型，当用户提出需求整理成结构化 PRD、补全背景、目标、功能范围和验收标准时，应该使用这个Skill。 如果description写得太泛，有的时候模型会错误的进行调用，比如一个是网页设计skill，一个是app设计skill，如果不能清晰的写明使用场景，模型可能会在app设计的时候误调用网页设计skill。 第二层是SKILL.md文件：当模型判断需要调用某个Skill后，它会再去读取SKILL.md，来了解这个Skill的主流程。 所以最简单的 Skill，其实只需要一个SKILL.md就够了，里面写清楚这个Skill是干什么的、适合什么场景、整体作业流程是什么、最后应该输出什么结果。 比如说我的设计Skill，它就是只有一个SKILL.md文件：它会先理解需求，再确设计方向，和用户确认ASCII图，然后再生成页面方案，它不需要复杂的外部资源。 第三层是参考资料：我习惯把references、scripts、assets这些内容都定义为参考资料，因为他们是主流程下各个阶段调用内容的补充，不管是md文件也好、还是python脚本、还是各种素材，其实都是让模型能够在对应流程下进行更标准的作业。 比如我之前做的多视角深度分析Skill，它里面还包含了各种subagent 的语料库，AI 在执行任务时，会根据不同专家视角，把对应资料发给subagent，让它们按照更稳定的逻辑去分析。 最后汇总一下我对Skill组织的理解：name和description负责触发，Skill.md负责主流程，参考资料负责在复杂场景下补充能力。 关键不是目录看起来多完整，而是每一层都要服务于模型的真实作业流程。 4. Skill的进化：像做产品一样迭代 Skill并不是一次就可以做出一个非常棒的产品，它往往依赖人的多次迭代。 我现在在优化Skill的时候主要是会围绕两个维度来进行： 1. 这个Skill根本上要做的问题是什么？不要做着做着过界了。 2. 当前Skill做的不好的点是什么，这次要优化重点要解决什么问题。 比如我之前做多视角深度分析Skill时，第一版就是让subagent自由选择视角，对内容进行评估。测试完后发现一个问题：subagent的作业逻辑一直在变，很难稳定用同一个视角帮我复盘。 所以从1.0版本到2.0版本，我主要解决的问题是视角稳定性。 我给每一个subagent的派单增加了语料库，把不同专家视角的判断逻辑标准化，让subagent能够基于一套相对稳定的流程进行分析。 2.0版本的时候，我觉得5个顾问的数量不太够，于是我就又筛选增加了一批顾问数量到10个，这就是3.0版本。 但在3.0版本的时候，我想用这个Skill去写代码和做设计，当时我就在想给这个Skill增加更多的能力进去。 这时候就需要会看多视角深度分析Skill的初衷是什么，它其实就是用来做思维复制分析的产品，不应该承担设计、debug、写代码相关的内容，所以我就没有把它做成一个万能分析Skill。 而是新开了设计Skill和debug Skill，让每一个Skill对应一个更明确的场景。 另一个例子是做PPT的Skill，它的目标很明确，就是让AI帮人做出更精美的PPT。 1.0先解决的是AI能不能做的问题，效果没多好，可能有个60分的水平。 2.0解决的是样式丰富度的问题，通过增加更多的底板和参考样式，让效果能够达到65分。 3.0引入subagent的设计逻辑，让页面不只是套模板，而是能根据内容做更适配的设计。 4.0再优化整体PPT设计的流程，减少人的干预程度，让AI更加自主的作业。 每个版本其实都是解决一个当下最明显的问题。 所以Skill优化和产品迭代很像：不要一开始就追求完美，而是先跑起来，再一轮一轮解决关键问题。 5. 对Skill的思考：本质是把经验SOP化 我和朋友们也讨论过很多次：Skill到底考验人的什么能力？ 我现在的理解是：Skill本质上是人把一件事SOP化的能力。 也就是人能不能把一个真实场景里反复出现的问题，沉淀成一套AI可以复用的流程。 这里根据我自己的测试经验，总结出来了两种不同的场景。 第一种是人熟悉的领域。 这种时候写Skill，更像是经验蒸馏。 因为人本来就知道这个事情应该怎么做，也知道什么样的结果是好的。人要做的是把自己的经验拆出来，变成 AI 能理解、能执行、能复用的流程。 第二种是人不熟悉的领域。 这种时候写Skill，最重要的就是建立一套回溯验证机制。 因为这个场景下其实难得并不是让AI产出内容，而是判断它做的对不对。 比如我之前一直想做一个六爻占卜Skill。 这个场景看起来很适合Skill化，因为它有规则、有流程，也有很多资料可以参考。但真正做成Skill的时候，我发现它很难稳定下来。 我自己不够懂占卜，我其实对于怎么解卦毫无思路，然后AI也不懂，我们俩加一起没办法构建一个可靠的回溯测试系统。 我压根不知道解卦到底是准还是不准，最后这个Skill我打磨了半个月还是放弃了。 测完这个Skill让我感慨万分，人不熟悉的领域倒不是说一定做不出来Skill，核心还是要看能否通过回溯机制来验证。 比如在编程的自动化测试上，我也不是专业的测试工程师，但我可以让AI设计一套测试逻辑，然后不断通过回溯测试优化这套逻辑的合理性，最后让AI把稳定运行的流程封装成Skill。 所以写Skill到最后考验的不是语法，也不只是提示词能力，而是人把场景SOP化的能力。 本文由人人都是产品经理作者【云舒】，微信公众号：【云舒的AI实践笔记】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。 题图来自Unsplash，基于 CC0 协议。