年初我在整理自己那套 AI 工作流时发现手头一堆重复性任务——整理笔记、查数据、做演示——每次都要把同样的话术翻来覆去地喂给大模型。后来接触到一个叫 Skills 的玩法才明白这玩意儿的本质不是给 AI 换脑子而是给 AI 发一本工作手册。简单说Skills 就是一段结构化的指令包里面写清楚了某个任务该怎么做、按什么步骤来、输出格式长什么样再配上相应的脚本或模板。AI 一旦加载了这个技能就会按照手册里的标准流程干活而不是每次凭感觉自由发挥。这个机制最早在大模型 Agent 生态里火起来随后各种开源仓库如雨后春笋般冒出来。GitHub 上搜一下相关的合集动辄几千星社区已经把很多高频场景做成了可以直接拿来用的 Skills 包。今天我从里面挑了 5 个非常实用的覆盖笔记整理、客户会议准备、数据查询、演示文稿制作和文章配图结合我自己在真实工作流里的实测经验把原理、用法和坑都给你捋清楚。适合正在折腾 AI Agent 的开发者也适合只想用 AI 提效但不想从零写 Prompt 的普通用户。1. 先说清楚 Skill 机制它和 Plugin、Prompt 到底什么关系很多人第一次听到 Skills 这个词会把它和插件Plugin、函数调用Function Calling搞混。我打个比方Plugin 像是给 AI 装上一个新器官它能感知外部世界比如访问网页、读数据库而 Skill 更像是给 AI 一套SOP 手册告诉它面对某个任务时应该按照怎样的流程思考、使用哪些工具、最终提交什么格式的成果。两者不是替代关系而是互补关系——Skill 里可以调用 PluginPlugin 执行的动作可以由 Skill 来编排。我实际体验下来的核心感受是Skill 解决的是AI 知道该干什么但不知道该怎么干好的问题。举个例子你让 AI帮我整理这份会议记录它大概率会给你输出一份像模像样的纪要。但如果你加载了一个专业的会议纪要 Skill它会要求 AI 先区分决策项、待办项、风险项再要求所有待办必须带上负责人和截止日期最后还要生成一页适合日报传播的摘要。同样的模型输出质量完全不在一个量级。在开源社区Skill 通常以文件夹的形式打包里面必须有一个SKILL.md文件作为入口。这个文件用 Markdown 书写包含技能的元信息名称、描述、适用场景和详细的执行指令。有的 Skill 还会附带脚本、模板、参考数据甚至是一整套提示词链。调用时你只需要把 Skill 的路径告诉 AI 客户端或者在配置里声明启用AI 就会在合适的场景下自动按这套手册来工作。这套机制还有一个隐藏优势——可迁移性。你用 Claude 调好的 Skill换个支持同样协议的客户端一样能用你在团队里写了一个符合公司规范的周报 Skill分发出去所有人都在用同一套 AI 工作标准。这正是开源社区里 Skill 类项目增长迅猛的核心原因写一次处处运行。2. 整理笔记类 Skill把碎片信息变成结构化知识不是玄学2.1 我选的是哪个开源项目解决什么问题笔记整理是碎片化最严重也最值得用 Skill 去规范化的场景。我平时会从网页、PDF、微信聊天里攒一堆零散内容放在 Obsidian 的 Inbox 文件夹里过两周去看全成了僵尸笔记。试了好几个开源的笔记整理 Skill最后长期留在工作流里的是一个叫AI Note Taker开源地址在 GitHub 上搜索 obsidian skill 能找到多个类似实现的思路框架。这类 Skill 的核心思路只有一条不是让 AI 帮你写笔记而是让 AI 帮你完成从收集到归档的完整加工流水线。加载这个 Skill 后你可以直接把一段原文、一张截图或一篇网页链接丢给它它会按照预设规则完成四步处理清洗去除广告、重复段落、无意义的口水话把核心信息抽出来。结构化根据内容类型选择合适的模板——是文献笔记、会议记录还是想法碎片不同的模板有不同的字段要求。链接自动找出与已有笔记的关联补上双向链接。这一步对 Obsidian 用户来说极为实用等于给你的知识网络自动织网。落盘把整理好的笔记写入指定目录按照既定命名规则比如YYYY-MM-DD-主题.md保存。2.2 SKILL.md 里的关键指令设计这类开源 Skill 的SKILL.md写得非常有讲究。它不会让 AI 自由发挥而是用类似这样的指令来约束行为## 处理流程 1. 先识别输入内容的类型可能为以下四种网页转载、会议记录、阅读摘录、随想碎片。 2. 根据类型选择对应模板模板字段见 templates/ 目录。 3. 对全文进行信息密度评估删除重复与无效内容保留原始语气和关键数据。 4. 检查知识库中是否有相关主题的已有笔记如有生成关联建议并补上链接。 5. 输出处理报告识别类型、删减比例、归档路径、关联笔记列表。这套设计的精妙之处在于强制 AI 遵守顺序和输出规范。没有 Skill 时你问 AI整理一下这些内容它给的答案时好时坏有了这套指令AI 每次都会按固定的流水线走稳定得像一个训练有素的助理。我还见过一些更强的变体它们会配合本地脚本使用。比如用 Python 脚本来实现标签自动补全、文件名规范化或者自动执行 Git 提交。Skill 负责思考判断类型、提炼结构脚本负责执行移动文件、更新时间戳两者配合得严丝合缝。2.3 我实测的配置流程与效果对比以 Obsidian 为例我用的这个 Skill 是通过社区插件Obsidian Copilot来加载的。配置并不复杂在 GitHub 上找到该 Skill 的仓库把整个文件夹 clone 到本地某个目录比如你的库/.obsidian/plugins/copilot/skills/下。在 Copilot 插件的设置里找到 Skills 分类点击扫描目录确认 Skill 已被识别。新建一篇笔记粘贴一段之前收集的资料然后告诉 AI用笔记整理技能处理这篇文档。第一次跑完的效果对比非常直观。不用 Skill 时AI 给的是三段式总结内容虽对但结构松散和我的知识库没有任何关联。用了 Skill 之后输出直接是一篇带有 frontmatter元数据、标签、关联链接的正式笔记文件名也自动生成了我只需要做最终确认。有一点要特别提醒Skill 不是万能的清洗机。它内部依赖的模型能力决定了整理上限——如果你用的小模型本身阅读理解能力不足那再好的指令也救不回来。我的经验是这类整理类 Skill 至少需要 GPT-4 级别或 Claude Sonnet 以上才够用小模型在需要精确判断哪些内容是核心时往往力不从心。3. 客户会议准备类 Skill把临时抱佛脚变成一套可复现流程3.1 这个 Skill 的完整工作链条开会前 10 分钟翻客户资料、临时想议题、脑子里一团浆糊——这是很多销售和客户成功岗位的日常。我接触到的一个会议准备开源 Skill在 GitHub 上搜索 client meeting prep skill 能找到类似项目就是为了根治这个问题设计的。它的工作链条非常清晰第一步收集背景信息。你只需要提供给 AI 客户公司的官网地址、对接人的 LinkedIn 链接或历史会议纪要和邮件往来Skill 会先启动一个信息检索的流程。这里通常是调用搜索或网页抓取工具把客户公司最近的动态新闻、产品发布、管理层变动、招聘信息抓取回来作为情报基础。第二步历史关系复盘。Skill 会要求 AI 从你提供的过往会议记录中抽取几个关键维度上一次会谈确认了哪些事项、哪些承诺还没兑现、客户对哪些话题表现出明显的兴趣或反感。这些信息会被整理成一张关系温度计让你对双方的合作现状有清晰认知。第三步生成会议策略。基于前面两步的内容Skill 会输出一套完整的会议准备包通常包含这样几个板块会议目标建议根据客户当前所处阶段了解期、方案评估期、决策期推荐本次会议应该达成的最小目标。三类问题清单破冰问题围绕客户近期的公开动态、挖需问题引导客户说出痛点、确认问题验证你理解的准确性。可能遇到的异议与应答口径根据客户业务特点预判对方可能提出的价格、周期、兼容性等方面的异议并给出参考应答。推荐议程表以 30 分钟会议为例什么时间段聊什么内容、各自占比是多少。3.2 为什么说它是最值得复制的销售类 AI 实践我在多家公司见过销售团队做客户准备绝大多数人的做法是翻一翻客户官网、看看上次的会议纪要然后硬着头皮上会。真正能稳定产出高质量准备材料的往往是极少数有方法论沉淀的资深销售。而这个 Skill 做的恰恰是把那套资深销售脑子里的方法论外化成可复制的文本指令。我没记错的话这个项目在设计上有一个非常聪明的点它不试图生成一份百科全书式的客户分析大报告而是把重心放在可执行的会议动作上。比如它不会写建议深入了解客户技术架构而是直接给出三个具体的提问句式让你在会议上照着念就能自然引出话题。这种把知识转化为行动的设计思路比单纯输出一堆分析要有价值得多。从技术实现来看这个 Skill 的指令文件里写明了必须区分事实与推测。比如AI 从官网获得的信息会被标记为已证实而从社交动态推断出的结论会被标记为待验证。这个细节我要给满分——因为在客户沟通中最忌讳的就是把 AI 的推测当成事实去和客户确认那会显得你非常不专业。3.3 血缘最近的上游从会议记录到客户画像的全闭环我实际用下来的感受是这个 Skill 要发挥最大威力最好是和笔记整理 Skill 搭配使用。具体做法是每次开完会先用笔记整理 Skill 把会议纪要结构化归档等下次会议前再调客户会议准备 Skill 读取这批已归档的纪要和关联资料。这样一来AI 对客户关系的理解就会一茬接一茬地累积而不是每次会议都从零开始。我团队里一位同事在连续用了三周之后反馈最大的变化不是省了多少时间而是上会前的焦虑感明显降低了。哪怕只提前 10 分钟调用 Skill 生成准备包也能带着至少三条有质量的问题进会议室这和以前脑子一片空白完全两个状态。如果你所在的团队经常面对客户沟通类工作这个 Skill 值得马上纳进你的标准工具集。4. 数据查询类 Skill让外行也能精准地问数据4.1 数据分析场景里需求很容易变成帮我看看数据有什么问题没过多久我就发现了一个极其普遍的现象很多非数据分析岗位的人在面对一堆数据时根本问不出好问题。他们只会说帮我分析一下这个月的销售数据然后 AI 往往会返回一份泛泛而谈的报告——环比增长多少、哪个产品线领先、哪些区域波动大。这些信息确实是分析但离解决问题还差了一个太平洋。GitHub 上一个叫Data Analyst Skill指代这类开源项目的思路我认为是真正理解了普通用户痛点之后的设计。它的核心机制是把一句含糊的需求逐步分解为一组明确的分析子任务让 AI 主动询问缺失的信息而不是闷头开跑。加载这个 Skill 后当你提出数据分析需求它会自动进入一个结构化流程明确业务目标先问三个固定问题——你需要用这个分析支持什么决策目标受众是什么背景可以接受的分析精度是多大锁定分析的业务上下文。字段字典对齐要求你提供或确认数据集的字段含义。很多时候用户自己对字段的理解是模糊的这一步能提前暴露问题。分析方案拆解把需求拆成结构化的问题清单比如先看整体趋势再看产品线分化然后验证某一类客户的留存情况。这个方案会明明白白地写出来让用户确认之后再往下走。分步输出结果每一步分析单独呈现带图表和文字解读并且附上数据局限性说明把样本量太小、字段缺失等对结论的影响交代清楚。4.2 它的提问模板里藏着最值得抄的设计这个 Skill 的SKILL.md写得非常细几乎每一步都预留了具体的提问模板。比如在明确业务目标环节它要求 AI 必须使用这样的句式在开始分析之前我需要先确认几件事情。以下三个问题将帮助我把目标转化为分析框架 1. 这项数据要支撑的核心决策是什么例如是否继续投入某个渠道 2. 分析结果的主要阅读者是谁例如只有你能看到还是要给管理层汇报 3. 如果数据不完美你更倾向于保守的解释还是大胆的洞察为什么说这套设计值得抄因为在传统的数据分析流程里需求澄清这个环节严重依赖分析师个人经验。新人数据分析师可能默认要求就往下跑资深分析师则会多问两句。Skills 把这套经验变成了强制步骤等于把一个金牌分析师的工作习惯内化成了流程。我的亲身体会有一次我拿一份活动报名数据给这个 Skill 分析它追问了我目标受众是谁我这才意识到我的需求原话有歧义——我说的分析效果是指拉新效果而数据里能看出来的主要是老用户激活。如果没被追问我大概率会拿到一份偏题的结论。就是这个细节让我对这类追问型Skill 的价值有了重新评估。4.3 技术底层如何在本地安全地跑数据查询大部分开源的数据类 Skill 会提供一个可选的本地执行环境。你可以把数据文件放在一个指定目录Skill 会在沙箱里运行 SQL 或 Python 脚本完成任务而不是把数据上传到第三方模型 API。这在处理敏感数据时尤为重要。我实测过的一个项目是直接在本地起一个 SQLite 引擎AI 生成查询脚本后自动执行并把结果以表格形式返回。整个过程中数据不出内网模型只看到表结构和查询结果。如果你所在的行业对数据安全有合规要求比如金融、医疗这套本地化设计几乎是你使用数据类 Skill 的前提条件。当然代价是你得给 AI 模型能够读取表结构及样例数据的权限这需要你在安全策略上做权衡。5. 演示文稿类 Skill从大纲到成稿把PPT 恐惧症治好5.1 我劝你别再让 AI 一键生成完整 PPT 了让 AI 做 PPT 的功能很早就有但市面上绝大多数方案效果都一言难尽。原因很简单——PPT 的本质不是排版是叙事结构。AI 直接生成全套幻灯片往往会在结构设计上栽跟头逻辑跳跃、字太多、重点不突出。开源社区里真正好用的 PPT Skill 有一个共同特点它们只做前半程结构设计和内容撰写把后半程视觉美化交给专业的工具或人来完成。我使用的一个项目就是按这个思路设计的。它的执行流程分为三段第一步结构设计。AI 先根据你的主题和目标受众生成一份详细的叙事弧线——开场吸引点、背景铺垫、核心论点展开、数据佐证、风险提示、行动号召。这一阶段输出的不是幻灯片内容而是一份大纲级别的结构图。第二步分页文案。按照上面的大纲逐页生成标题和核心文案。这里有一个关键设计——每页的内容量被严格限制AI 被明确告知标题不超过 12 个字、正文不超过 30 个字逼着它提炼最核心的表达。第三步视觉提示。每一页旁边附上一段给设计工具的绘画提示词注明配图风格、配色建议、构图参考。如果你想做一页数据不错但不够亮眼的封面它会建议你用深色背景配高对比大字号数字而不是让你自己在图库里苦找。5.2 和传统一键生成 PPT的本质差异传统方案是把你当下的想法交给 AIAI 吐给一整套幻灯片你的角色变成了被动的修改者。而这个 Skill 试图把你变成主动的决策者——AI 输出结构后你要先行确认确认后再出内容内容确认后再进入视觉环节。每一步都有人的参与看起来效率似乎低了但最终成品的质量反而高得多。我做测试时用了一个真实场景给公司一款新产品做融资路演初稿。传统方案生成的幻灯片受限于模板风格读起来像把商业计划书的关键词塞进了统一的壳里完全没有层次感。而这个 Skill 生成的大纲先给了我一个惊喜——它把用户痛点放在市场规模前面理由是投资人对市场规模的耐受度越来越低而对真实痛点的记忆度更强。这个判断对不对另说但至少说明它真的理解叙事优先级而不是按部就班地套公式。我特别喜欢这个 Skill 的一个小细节它在输出大纲时会用 TRLTop-down Rule of Three自上而下三原则检查每一页的核心信息是否唯一。如果一页里塞了三个论点它会在旁边标注提醒逼着你在设计阶段就做减法。这个操作在传统 PPT 工作流里叫单页信息聚焦通常是资深咨询顾问才养成的习惯如今被写成了一条可执行的指令。5.3 推荐的落地路径只用它做大纲和讲稿我现在的使用习惯是让这个 Skill 生成完整的大纲、每页标题和关键词、以及配套的演讲者备注然后我把这套内容导入熟悉的设计排版工具里面去做视觉呈现。这样分工的好处是——AI 负责它擅长的内容架构人负责机器做不好的审美呈现。有人可能会问能不能连视觉一起做了能但效果通常不太好。开源项目里有一些接了图片生成模型的 Skill可以直接给每页画配图但生成结果的风格一致性很难控制。如果你所在的团队没有专业设计人员我的建议是让 AI 把每页的视觉意图写清楚比如用城市天际线剪影表达未来感然后去图库网站按这个描述找图效率比让 AI 直接生图可靠得多。6. 配图类 Skill为文章和演示找到对味的视觉语言6.1 从关键词到构图指令开源配图 Skill 的思路写博客、做公众号、做演示配图始终是个绕不开的环节。很多人的方案是去图库搜商务科技合作这类关键词搜出来的千篇一律放进文章里毫无辨识度。开源社区里配图类 Skill 的思路和传统图库搜索完全不同。它不帮你找图而是帮你把抽象概念转化为具体的视觉描述再驱动 AI 绘图模型或专业设计师来完成。它的核心能力是把我想要一张表现数据安全的图这样的模糊需求一步一步转化为绘图模型能理解的高质量提示词。以我实际用过的一个配图 Skill 为例它的处理流程是这样的概念拆解先分析需求里的抽象概念。比如数据安全它会拆成几个可视觉化的子概念锁、盾牌、网络节点、加密信道。风格匹配根据文章的调性选择合适的视觉风格。技术教程类默认走扁平插画风品牌故事类走摄影风或 3D 渲染风。这个选择不是随机的Skill 里内置了一套内容类型与视觉风格映射表。构图设计生成完整的构图描述包含主体位置、前景背景关系、色彩倾向、光线方向。比如一个巨大的盾牌处于画面中央偏左背景为深蓝色城市夜景鸟瞰盾牌表面有微光流动的电路纹理整体色调冷色为主暗示防护与冷静。多版本输出一次生成 3 个不同的视觉方案并附上每个方案的使用建议比如方案 1 适合封面图方案 3 适合文内配图。6.2 一个让出图质量产生质变的提示技巧我见过很多配图类 Skill 只做概念拆解输出的提示词依然是一只站在电路板上的猫头鹰象征智慧这种水平绘图模型生成的结果基本靠抽卡。而好的开源 Skill 会在提示词结构上做文章这里我分享一个观察到的核心技巧——把被摄主体和视觉环境彻底分开描述。有些 Skill 输出的提示词遵循一个固定模板[主体描述]一只由电路纹理构成的猫头鹰站在纯黑底板上。 [环境描述]背景是淡蓝色的二进制数据流营造科技感但不过分抢主体。 [氛围与风格]扁平化插画高对比度主色调蓝橙互补类似现代科技杂志封面风格。这个模板看似简单实际作用非常大。因为主流 AI 绘图模型对主体的执行力和对背景的执行力往往是分开的——如果你在一个句子里面纠缠不清模型很容易把主体元素变成背景装饰。把两者拆开等于给了模型清晰的图层意识出图稳定度能提升一个量级。配图 Skill 还常常带有一个容易被忽略的模块——版权自检。它会提醒你确认生成内容是否涉及真人肖像、品牌 Logo、商标元素输出前强制要求你确认图中不包含可识别的真实人物面部和受版权保护的品牌标识。这对商业用途的项目来说比较重要值得在选型时留意。6.3 我实际跑通的一条配图产出链路现在的配图工作流对我来说已经相当顺滑了。我写完一段内容后先把文本交给配图 Skill 分析得到 3 个候选视觉方案选定一个后我会根据 Skill 提供的提示词在绘图模型里生成最终图如果生成结果不满意我会局部修改提示词再抽几次。这套流程跑下来整体质量要比我去图库搜索高不少图文的匹配度也好了很多。以前写一篇带 5 张配图的文章光找图就要花半小时以上还不一定找得到契合的。现在从构思到出图大约 10 分钟且图片和内容的关联度是我能控制的——因为方案里的每一个视觉元素都有明确的来源理由我可以逐一审视和调整而不是从海量图库里矮子里拔将军。7. 把这些 Skill 组合起来一套完整的个人 AI 工作流参考单点用 Skill 的能力是有限的但如果把它们串成一条链路产生的价值会明显大于各部分之和。我目前日常跑的这套组合工作流给大家做个参考以准备一次客户研讨会为场景。我会用会议准备 Skill 生成客户背景分析和议程草案然后把草案中的关键观点丢给数据分析 Skill让它查证我们的历史业务数据是否支撑这些论点接着用 PPT Skill 把整场研讨会的内容大纲搭出来最后用配图 Skill 为大纲里每一页生成视觉方向建议。四个 Skill 各司其职中间不需要我重复交代背景因为每个 Skill 的产出都会作为下一个 Skill 的输入上下文。这套流程跑顺有一个前提条件——你的客户端支持多 Skill 联动并且有足够的上下文窗口。如果你用的模型上下文只有 32K 或 64K在几个 Skill 之间传递长文档很容易爆上下文。我的建议是尽量选择支持长上下文128K 以上的模型或者拆成更小的处理单元分段流转。关于 Skill 的路径和配置管理我再多啰嗦一句开源 Skill 项目更新频率很高很多 Skill 会通过 Git 仓库持续迭代。我的习惯是把所有第三方 Skill 统一放在一个目录下用 Git 管理每次更新前先看看 changelog避免静默升级导致行为变化。这个习惯帮我避免过好几次为什么输出突然变样了的困惑。8. 选型与使用的避坑建议这些弯路我已经替你走过了8.1 三个容易踩的坑先说说我在折腾这些开源 Skills 过程中踩过的一些坑希望你能绕过。第一个坑是不读 SKILL.md 就盲目启用。很多 Skill 仓库看着功能很强大但内部的指令设计和你的使用习惯可能冲突。比如某些整理笔记的 Skill 会强制把笔记写入特定文件夹如果你没提前改配置AI 会把你的文件整理到莫名其妙的地方。我的做法是任何新 Skill 启用后先用一条简单测试数据跑一遍确认行为符合预期后再接入正式工作流。第二个坑是同时启用多个功能重叠的 Skill 导致冲突。曾有段时间我同时启用了两个做数据可视化的 Skill结果 AI 一会儿按 A 的逻辑出图表一会儿按 B 的逻辑出图表输出极不稳定。目前我的原则是同一类任务最多保留一个 Skill干掉多余的保持配置精简。第三个坑是忽略 Skill 内部依赖的外部服务。不少开源 Skill 默认配置好了一套 API 调用但实际上它调用的服务要么需要你自己申请 key要么已经变更了地址。启用前仔细看一遍 README 里的依赖说明把这些 key 和服务的可用性先验证一遍再推进后续配置。不要等到真用时才发现调用 401。8.2 如何判断一个开源 Skill 的质量看一个开源 Skill 是否值得用我一般从三个维度来判断。第一是看SKILL.md 里是否包含明确的检查清单或输出规范——好的 Skill 会定义什么时候算完成而不是模糊地说高质量输出。第二是看它的示例输出如果仓库里贴了真实的使用案例和输出截图可信度远高于只有花哨的功能说明。第三是看社区活跃度这个项目的 issue 区是否有人在讨论使用问题、作者是否积极回复这决定了你踩坑时能不能获得帮助。8.3 用 SKILL.md 做自己专属技能的最小模板最后给你一套我自己总结的最小模板方便你快速上手写一个自己的 Skill。虽然功能简单的 Skill 不需要很复杂但这个结构足以应付大多数场景--- name: 技能名称 description: 在什么场景下使用、解决什么问题 --- # 技能名称 ## 适用场景与边界 - 适用于明确说明该技能可以处理的输入类型。 - 不适用于给出无法处理的边界防止 AI 错误套用。 ## 执行步骤 1. 第一步说明需要进行的初始检查或信息收集。 2. 第二步核心处理流程尽量用必须禁止来约束行为。 3. 第三步输出规范定义结构要求和格式要求。 ## 输出格式 - 必须输出的字段字段一、字段二、字段三。 - 输出文件命名规则xxx-日期.md。按这个模板写出来的 SKILL.md 也许不算惊艳但至少不会让 AI 跑偏。等跑通了再加细节逐步把它打磨成一个真正贴合你工作习惯的技能。写在最后的一点体会把这 5 个开源 Skill 用顺手之后我对AI 提效这件事有了新的理解。以前总觉得大模型的能力边界决定工作流的天花板现在发现其实如何给 AI 定义清晰的执行路径往往比模型本身更能影响最终产出质量。一个好的 Skill 就是一份可复用的最佳实践让你不用每次从零开始教 AI 该怎么干活。开源社区里还有大量针对各种场景的 Skills法律文书审查、代码评审、学习计划制定、跨境物流查询几乎你能想到的高频任务都能找到对应的项目。这篇文章里提到的五个只是我在日常工作中验证过、确实提升了效率的代表。工具迭代很快但把经验沉淀为可复用指令这件事的价值不会变——这大概就是 Skills 机制最迷人的地方。如果你也折腾出了好用的工作流欢迎在评论区分享互相抄作业总是比自己闷头探索来得快。