--- title: "把 Skill 改成你自己的" wiki: skills category: "构建指南" slug: M03-把Skill改成你自己的 url: https://learnagent.wiki/skills/cards/M03-把Skill改成你自己的 tags: ["Skill 改造", "定制", "个性化", "实战"] last_updated: 2026-04-11 reading_time: 35 --- > > 模块3：把Skill改成你自己的 | 用时：约30分钟 | 目标：掌握description触发机制、正文三要素、自由度设计、触发测试方法 # Skill 从小白到高手系列课 > 模块3：把Skill改成你自己的 | 用时：约30分钟 | 目标：掌握description触发机制、正文三要素、自由度设计、触发测试方法 --- 上节课咱们搞懂了 Skill 的底层原理——渐进式披露、和 MCP 的区别、为什么装 50 个也不卡。 但搞懂原理和真正用得顺手，中间还隔着十万八千里。 这节课我带你怎么把一个"能用"的 Skill，调成"好用"的 Skill。 说实话，我前两三个月写 Skill 的时候，真的崩溃过好多次。明明 Skill 写好了，AI 就是不用。或者用了，输出的东西跟我想要的差了十万八千里。后来我才慢慢摸索出来：**改 Skill 其实就两个地方要动——description 控制"什么时候触发"，正文控制"输出什么质量"。** 这两个东西搞明白了，你的 Skill 就从"凑合能用"变成"顺手好用"。 --- ## 先讲一个真实的调试故事 还记得模块 1 里咱们做的那个 Skill 吗？无论是周报、小红书还是 commit message，当时写完都觉得挺顺的。 但我后来做其他 Skill 的时候，真的崩溃过好多次。明明 description 写得挺好的，AI 就是不用。或者用了，出来的东西跟我想要的差了十万八千里。 比如我做过一个短视频脚本 Skill，description 写的是"生成短视频脚本"，结果测试的时候： - "帮我写个抖音文案"——没触发 - "想拍个产品测评视频，怎么写"——也没触发 - "来个视频脚本"——终于触发了，但输出的是电影剧本那种格式，完全不对 我心想：这不对啊，我明明写了格式要求的。 后来我折腾了好几天才搞明白——**description 写得不对，AI 就不触发；正文写得不对，触发了输出也烂。** 这节课就是手把手教你改这两个东西。我用三个不同类型的真实案例——**公众号文章、短视频脚本、电商详情页**——给你演示不同场景的调试方法。你照着走一遍，能省不少弯路。 --- ## 一、description 触发机制——AI 是怎么决定用不用你的 Skill 的 ### AI 的语义匹配是怎么工作的 当你输入一句话，AI 会做一件事：**把你的话和所有 Skill 的 description 做语义相似度比较**。哪个 description 和你的话最"像"，就触发哪个 Skill。 我打个比方。description 就像一本书的书名和简介。你去图书馆找书，不会翻开每一本看内容，而是扫一眼书脊上的标题。如果你的 Skill 叫"文案助手"，用户说"帮我写个小红书种草文"，AI 扫一眼——"文案"和"种草"语义上有交集，但不算强匹配，可能触发，也可能不触发。 这就是为什么 description 写得好不好，直接决定你的 Skill 能不能被用上。**你在 description 上的投入，回报率是最高的。** ### 两种致命的触发问题 我把触发问题分成两类：**Under-trigger（该触发没触发）** 和 **Over-trigger（不该触发也触发了）**。两种都很烦，但原因和修复方法完全不同。 #### Under-trigger：你的 Skill 在"睡觉" Under-trigger 就是用户明明在说你的 Skill 相关的事，但 AI 没有匹配上。 举个我自己踩过的真实例子。我做了一个架构图生成 Skill，description 写的是： ``` "生成精美软件架构图。当用户需要画架构图时使用。" ``` 我当时觉得写得挺好的。然后测试了一下： - "帮我画个架构图" — 触发了 ✓ - "画一个系统设计图" — 没触发 ✗ - "帮我梳理一下微服务之间的调用关系" — 没触发 ✗ - "我需要一个技术方案的可视化" — 没触发 ✗ 四个测试只过了一个。问题出在哪？ **description 里只有"架构图"三个字，但用户不会每次都说"架构图"。**他们会说"系统设计"、"调用关系"、"技术方案"、"模块图"、"组件图"，说法五花八门。 我的 description 太窄了。说白了就像一个只认识一个名字的门卫，用户换个说法就进不来了。 #### Over-trigger：你的 Skill 在"到处乱跑" Over-trigger 是反过来的——你的 Skill 太热情了，什么事都想揽。 我做过一个"社交回复助手"，description 写的是： ``` "帮你写回复。当用户需要回复消息时使用。" ``` 结果呢？这些全部误触发了： - "帮我回复一下这个 GitHub Issue" — 本来应该走代码助手 - "回复客户邮件" — 本来应该走邮件助手 - "回复一下领导的工作安排" — 本来应该走职场沟通助手 "回复"这个词太泛了，什么场景都有"回复"。我的 Skill 就像一个到处抢活干的同事，什么活都接，结果干的都不是自己的事。 ### 一个差的 description 怎么一步步改成好的 我把一个真实案例的完整改写过程展示出来。假设我要做一个"电商详情页生成"Skill。 **第一版（最原始）：** ``` "写详情页。" ``` 就这么三个字。我测试了一下，只有用户说"写详情页"的时候才触发。说"帮我做个产品页"就不触发。**基本等于没用。** **第二版（加了触发场景）：** ``` "生成电商详情页。当用户需要写产品描述时使用。" ``` 比第一版好了一点点，但问题依旧——"淘宝文案"、"商品介绍"这些说法还是触发不了。而且 AI 不知道输出什么格式，触发了也没用。 **第三版（加更多触发词）：** ``` "生成电商详情页。当用户需要写详情页、产品描述、淘宝文案时使用。输出包含主图卖点、痛点场景、解决方案、信任背书、行动号召。" ``` 好多了。覆盖了"详情页"、"产品描述"、"淘宝文案"三种说法。但我测试的时候发现，用户说"帮我写个产品介绍页"还是不触发。**"介绍页"太口语化了，我的 description 里没有这种说法。** **第四版（最终版）：** ``` "生成高转化率电商详情页。当用户需要写详情页、产品描述、淘宝文案、商品介绍、产品页文案，或者想生成卖点文案、做产品介绍、写种草文案时使用。输出结构：主图卖点（3-5个核心卖点）→痛点场景（用户痛点描述）→解决方案（产品如何解决）→信任背书（证书/评价/销量）→行动号召（购买引导）。适用于淘宝、京东、拼多多等电商平台。" ``` 这一版我加了口语化的触发场景"卖点文案"、"种草文案"、"产品介绍"，还加了"商品介绍"、"产品页文案"等同义词。同时把输出结构也说清楚了（主图卖点→痛点场景→解决方案→信任背书→行动号召），还限定了"电商平台场景"。 **测试结果：10 个相关提问触发了 9 个，5 个不相关提问只误触发了 1 个。能用。** 你看，一个好的 description 不是一拍脑袋就能写出来的，它是**改出来的**。每一版你都能发现新的触发盲区，然后补上。好在这部分工作也可让AI代劳。 ### 两种 description 策略：精准狙击 vs 触发词轰炸 我总结出两种写 description 的策略，适用不同的场景。 #### 专用型 Skill——用"精准狙击" 如果你的 Skill 是专门解决一个特定问题的，比如"生成 Docker Compose 配置文件"，那就用精准狙击。 **特点：** 触发范围窄，只对特定领域生效，不容易误触发。 **写法要点是"说清楚做什么 + 限定场景"。** ``` "生成 Docker Compose 配置文件。仅在用户需要编写或修改 docker-compose.yml 时使用。支持多服务编排、网络配置、卷挂载。不适用于 Dockerfile 编写或容器运维操作。" ``` 注意最后那句"不适用于 Dockerfile 编写或容器运维操作"。**这是精准狙击的精髓——主动告诉 AI 你的 Skill 不干什么，把边界画清楚。** 还有个例子： ``` "生成 GitHub Actions CI/CD 工作流。仅在用户需要创建或修改 .github/workflows 下的 YAML 配置时使用。支持 Node.js、Python、Java 项目。不适用于 Jenkins、GitLab CI 等其他 CI 工具。" ``` 同样是"做什么"加上"不做什么"，边界非常清晰。**你把它想象成给 AI 画了一个圈——圈内的归我管，圈外的别来烦我。** #### 通用型 Skill——用"触发词轰炸" 如果你的 Skill 适用范围广，比如"写作助手"、"翻译助手"，那就用触发词轰炸。 **特点：** 触发范围宽，把用户可能说的各种说法都写进去，确保不遗漏。 ``` "帮助用户进行各类文案写作。当用户需要写文章、写作、写文案、写稿、写推文、写笔记、写帖子、写内容、写宣传语、写广告语、写软文、写种草文、写分享文时使用。支持小红书、微信公众号、微博、知乎等平台风格。" ``` 看到没？光"写"这个动作我就列了十几种说法。用户不管说"帮我写个帖子"还是"来篇种草文"还是"写个推广文案"，全都能命中。 再给一个例子： ``` "帮助用户翻译文本。当用户需要翻译、中翻英、英翻中、中译英、英译中、把中文翻译成英文、把英文翻译成中文、translate、查看翻译、对比翻译时使用。支持中英、中日、中韩互译。" ``` 这里连"中翻英"和"中译英"都分开写了。因为 AI 做语义匹配的时候，"翻"和"译"是不同的词，分开了命中率更高。 **我的经验是：通用型 Skill 的 description 宁可多写不能少写。**你有 1024 个字符的额度，不用白不用。我自己的通用型 Skill，description 基本都写满了。 --- ## 二、正文指令写作——让 AI 输出你想要的东西 description 决定了 Skill 会不会被触发，**正文决定了触发之后输出什么。** 正文写不好，就会出现上面那种情况——触发了，但输出一坨糊糊。 ### 正文三要素 我把正文拆成三个要素：**操作步骤、输出格式、反模式**。三个都写到位了，输出质量才有保障。 #### 要素一：操作步骤——告诉 AI 先干什么后干什么 操作步骤就是给 AI 一个明确的执行顺序。没有步骤，AI 就会"想到哪写到哪"。 我见过很多人写正文的时候，就把要求堆在一起，没有先后顺序。比如： ```markdown ## 写作要求 - 写一篇小红书笔记 - 用 emoji 开头 - 口语化风格 - 300-500 字 - 加 3-5 个标签 ``` 这种写法不是不能用，但 AI 有可能先写标签再写正文，或者把 emoji 放在结尾。加了步骤顺序就不一样了： ```markdown ## 操作步骤 1. 先根据用户给的主题，构思一个有吸引力的标题 2. 然后写正文，遵循下面的写作风格 3. 最后添加标签和互动引导语 ``` 就这么简单——"先、然后、最后"。AI 有了顺序，输出就会稳定很多。 我再给一个非写作类的例子。假设你在做一个"代码审查"Skill： ```markdown ## 操作步骤 1. 先阅读用户提交的代码，理解这段代码在做什么 2. 逐项检查：命名规范、逻辑错误、性能问题、安全隐患 3. 按严重程度分级输出问题列表（严重 → 警告 → 建议） 4. 对每个问题给出修改建议和示例代码 5. 最后给出整体评价和改进方向 ``` 五步走，清清楚楚。AI 不会跳步，不会漏项。 #### 要素二：输出格式——给 AI 一个模板 输出格式就是告诉 AI "我要的东西长什么样"。不给格式，AI 就用自己的默认格式，而 AI 的默认格式通常不是你想要的。 我举个 PRD 的例子。如果只写了"生成 PRD"，没有规定格式，AI 就输出了一整篇不带分段的纯文本。后来在正文里加了格式模板： ```markdown ## 输出格式 ### 需求背景 2-3 句话说清楚为什么要做这个功能。 ### 目标用户 一段话描述这个功能是给谁用的。 ### 用户故事 按以下格式写 3-5 条： - As a [角色], I want [功能], so that [价值] ### 功能需求 用表格列出：功能点 | 优先级 | 描述 ### 验收标准 用表格列出：验收条件 | 预期结果 ``` 加了这模板之后，输出立刻从"一坨文字"变成了结构清晰的文档。**AI 不是不会写结构化文档，是你要告诉它你要什么结构。** 再给一个详情页的格式模板： ```markdown ## 输出格式 ### 主图卖点（必填） - [ ] 卖点一：核心卖点一句话（突出差异化） - [ ] 卖点二：功能卖点一句话 - [ ] 卖点三：情感卖点一句话 ### 痛点场景（必填） - [ ] 场景一：描述用户遇到的痛点 - [ ] 场景二：痛点带来的困扰 ### 解决方案（必填） - [ ] 方案描述：产品如何解决上述痛点 - [ ] 核心功能：1-2个核心功能点 ### 信任背书（选填） - 证书/检测报告/用户评价/销量数据 ### 行动号召（必填） 一句话购买引导，带紧迫感。 ``` 方括号让格式一目了然，AI 照着填就行。 #### 要素三：反模式——告诉 AI 不要做什么 **反模式是三个要素里被忽视最多的，但它可能是提升输出质量最快的方法。** 为什么反模式这么重要？因为 AI 有很强的"默认行为"。你让它写文章，它默认写书面语。你不明确告诉它"不要做"，它就会按默认来。 我举个例子。我做一个"朋友圈文案"Skill，正文里写了"口语化、轻松、自然"。结果 AI 输出： ``` 今天心情非常愉悦，和大家分享一下我最近的生活。 首先，我要说的是，这家餐厅真的非常好吃... ``` "非常愉悦"、"首先，我要说的是"——这还是书面语啊。我加了反模式之后： ```markdown ## 反模式 | 不要这样做 | 症状 | 怎么改 | |-----------|------|--------| | 结构词堆砌 | "首先""其次""最后" | 直接说事，不要过渡 | | 程度副词滥用 | "非常""十分""极其" | 删掉，或用"挺""蛮" | | 书面语腔调 | "笔者认为""综上所述" | 换成"我觉得""说白了" | | 华丽修辞 | 排比句、对仗句 | 短句，一行一个意思 | | 长段落 | 超过 3 行 | 强制换行，留空白 | ``` 再测试，AI 的输出变成了： ``` 昨晚被朋友拉去吃了一家泰料，绝了 🤤 冬阴功汤酸到上头，咖喱鸡浓到可以拌两碗饭 地址放评论区了，冲！ ``` 区别非常大。**写"做什么"是描述一个无限大的可行域，写"不做什么"是在可行域上画边界。**反模式就是帮 AI 打破它的默认行为。 ### 三个不同领域的正文改写实例 光说原理不够，我拿三个不同领域的例子完整展示一遍怎么改正文。 #### 实例一：技术文档——API 接口文档生成 Skill **改之前：** ```markdown 生成 API 接口文档。 ``` 三个字。输出可想而知——AI 自己发挥，格式不统一，该有的字段没有，不该写的写了一堆。 **改之后：** ```markdown ## 操作步骤 1. 根据用户提供的接口信息，确定请求方法和路径 2. 按照标准 RESTful 格式生成文档 3. 对每个字段标注类型、是否必填、默认值 4. 提供请求和响应示例 ## 输出格式 ### [方法] [路径] **描述**：一句话说明这个接口做什么。 **请求参数**： | 参数名 | 类型 | 必填 | 默认值 | 说明 | |--------|------|------|--------|------| **响应示例**： ```json { "code": 200, "data": {}, "message": "success" } ``` **错误码**： | 错误码 | 说明 | |--------|------| ## 反模式 - 不要省略请求参数的默认值和类型 - 不要用段落描述接口，必须用表格 - 不要忘记写错误码 - 不要生成没有实际意义的示例数据（如 "string"、"xxx"） ``` 改完之后，每次输出的接口文档格式统一、字段齐全，直接能用。 #### 实例二：中自由度案例——电商详情页生成 Skill **改之前：** ```markdown 生成电商详情页文案。 ``` AI 输出的文案要么卖点不清晰，要么结构混乱，要么没有转化引导，看完不知道怎么用。 **改之后：** ```markdown ## 操作步骤 1. 分析用户提供的产品信息，提炼3-5个核心卖点（差异化优先） 2. 根据产品类型，构建对应的痛点场景（2-3个用户痛点） 3. 撰写解决方案部分，突出产品如何解决问题 4. 添加信任背书（证书、评价、销量等） 5. 最后写行动号召，带紧迫感 ## 输出格式 ### [产品名] 详情页文案 **主图卖点** - 卖点1：[核心卖点] — [一句话解释] - 卖点2：[功能卖点] — [一句话解释] - 卖点3：[情感卖点] — [一句话解释] **痛点场景** - 场景1：[用户痛点描述] - 场景2：[痛点带来的困扰] **解决方案** [产品如何解决痛点，2-3句话] **信任背书** [证书/评价/销量数据，1-2点] **行动号召** [带紧迫感的购买引导，1句话] ## 反模式 - 不要堆砌功能参数，要突出用户收益 - 不要写"质量很好"这种空话，要具体 - 不要忽略行动号召部分 - 不要输出超过500字 ``` 改完之后，详情页有了清晰结构，卖点突出，转化路径完整。直接能用。 #### 实例三：职场——面试问题生成 Skill **改之前：** ```markdown 生成面试问题。 ``` AI 输出的问题要么太简单（"你的优点是什么"），要么太泛（"说说你的项目经历"），完全不能用。 **改之后：** ```markdown ## 操作步骤 1. 确认岗位类型和级别（根据用户输入判断） 2. 按以下维度各生成 2 个问题：技术能力、项目经验、沟通协作、问题解决、文化匹配 3. 每个问题附带考察点和评分标准 4. 标注问题难度（初级/中级/高级） ## 输出格式 ### [岗位名称] 面试题库 #### 技术能力 **Q1：[问题]** - 难度：[级别] - 考察点：[具体考察什么] - 好的回答包含：[要点 1、要点 2、要点 3] - 差的回答特征：[什么表现说明不行] #### 项目经验 （同上格式） ## 反模式 - 不要出"你的优缺点是什么"这种烂大街的问题 - 不要出纯理论题，必须是场景化问题 - 不要一次生成超过 15 个问题 - 不要忘记标注考察点 ``` 改完之后，每个问题都有明确的考察目的，面试官拿来就能用。 --- ## 三、自由度设计——什么时候该严什么时候该松 不是所有 Skill 都该写得一样详细。有些任务你得把步骤写死，有些反而应该给 AI 留发挥空间。 Extra08 提出了一个**自由度光谱**的概念： ``` 任务越脆弱（容易出错） → 自由度越低 → 用脚本锁死 任务越灵活（多种方案都对） → 自由度越高 → 用文字引导 ``` | 自由度 | 实现方式 | 适用任务 | 示例 | |--------|----------|----------|------| | **高** | 文字指令 | 多种方法都可行，依赖上下文 | 写作风格、创意生成 | | **中** | 模板+参数 | 有最佳实践但允许变通 | 报告生成、代码审查 | | **低** | 具体脚本 | 操作脆弱容易出错，必须精确 | 部署脚本、数据处理 | ### 低风险任务——高自由度（写作、创意类） 做错了最多文案不好看，不会出大事。 ```markdown ## 写作风格 - 口语化，像跟朋友聊天 - 短句为主，每段不超过 3 行 - 卖点突出，避免参数堆砌 ``` 不给具体步骤，只给风格和原则。AI 在框架内自由发挥，输出更自然。 ### 中风险任务——中自由度（详情页、报告类） 大多数 Skill 属于这一类。核心步骤固定，细节让 AI 自己决定。详情页就是典型例子——有固定的5步结构（主图卖点→痛点场景→解决方案→信任背书→行动号召），但每个部分的内容可以根据产品灵活调整。 ```markdown ## 操作步骤 1. 先分析用户提供的产品信息（固定） 2. 按照5步结构生成详情页（固定框架，具体内容 AI 自行判断） 3. 确保每个部分都有转化引导（固定要求） 4. 根据产品类型调整语言风格（具体风格 AI 自行判断） ``` 步骤 1 和 3 是死的，步骤 2 和 4 是活的。 ### 高风险任务——低自由度（部署、数据类） 做错了后果严重，比如部署脚本、删除数据。 ```markdown ## 数据库迁移操作步骤（严格按顺序执行） 1. 先执行数据备份命令 2. 确认备份文件存在且大小 > 0，否则停止操作 3. 在测试环境执行迁移脚本 4. 检查测试环境数据完整性 5. 以上四步全部通过后，在生产环境执行迁移 ## 安全限制 - 任何时候都不要跳过备份步骤 - 不要使用 DROP、TRUNCATE 等危险语句 ``` 每一步都是确定性的，AI 没有发挥空间。**多写 10 行指令，比数据库被删了强一万倍。** ### 判断标准 1. **做错了需要花超过 30 分钟修复** → 高风险，步骤写死 2. **输出只需要"方向对就行"** → 低风险，给原则就行 3. **拿不准** → 先写详细一点，后续再放松 --- ## 四、触发测试方法论——怎么验证你的 Skill 真的能用 写完 Skill 不能拍拍屁股走人。**你得测试。不测试就上线，等于不试穿就买鞋。** ### 怎么设计测试用例 我设计测试用例的方法很简单：**5 个该触发的 + 5 个不该触发的。** 10 个用例，不多不少，够用了。 #### 该触发的 5 个问题——要覆盖不同说法 这 5 个问题不能都是同一种问法。我一般这么设计： - 1 个"标准问法"——直接说出 Skill 的名字，比如"帮我写个产品详情页" - 1 个"口语问法"——大白话，比如"帮我做个产品介绍的文案" - 1 个"平台问法"——带平台名称，比如"来个淘宝文案" - 1 个"场景描述"——描述场景但不提具体动作，比如"我这个产品怎么写卖点" - 1 个"简短问法"——只说两三个字，比如"详情页" 五种问法覆盖了用户真实使用时的各种可能。如果一个 Skill 这五种都能触发，基本就稳了。 #### 不该触发的 5 个问题——要覆盖容易混淆的场景 这 5 个问题的设计思路是"挑那些和你的 Skill 容易混淆的场景"。 比如你的 Skill 是"电商详情页生成"，那容易混淆的就是： - "帮我写一篇产品评测文章"——也是写产品，但是长文章不是详情页 - "写一份品牌宣传文案"——也是文案，但是品牌宣传不是电商转化 - "帮我写个使用说明书"——也是产品介绍，但是说明书不是营销文案 - "写一份活动策划方案"——也是文案，但是策划场景 - "帮我设计一个产品海报"——也是产品展示，但是海报不是详情页 如果你发现这 5 个不该触发的问题中有 2 个以上误触发了，说明你的 description 太宽了，需要加限制条件。 ### 怎么分析测试结果 测试完 10 个问题之后，我按这个思路分析： **如果该触发的 5 个问题里，有 2 个以上没触发。** 这说明 Under-trigger 了。回去看 description，把没触发的那些问法的关键词补进去。比如"帮我推荐个平价面膜"没触发，就在 description 里加"推荐"、"种草"、"平价好物"这些词。 **如果不该触发的 5 个问题里，有 2 个以上误触发了。** 这说明 Over-trigger 了。在 description 里加排除条件。比如"帮写商务邮件"误触发了，就加一句"不适用于商务邮件、正式信函等职场写作场景"。 **如果触发了但输出不对。** 这说明 description 没问题，正文有问题。回去改正文，加格式要求或反模式。 **如果有时触发有时不触发。** 这通常是 description 里的措辞不稳定。同一个意思，"写笔记"和"写一篇笔记"匹配度可能不一样。我的做法是把所有同义词都写进去，不依赖单一措辞。 ### 怎么调——我的迭代流程 我一般调三轮。不是因为我闲，是因为两轮经常不够。 **第一轮：粗调。** 把 description 和正文写好，跑 10 个测试用例。记录哪些通过、哪些失败。 **第二轮：根据结果修补。** 第一轮没通过的用例，针对性修改 description 或正文。改完之后再跑一遍全部 10 个用例。注意，这里有个坑——改了一个地方可能会影响其他用例，所以要全跑一遍，不是只跑失败的。 **第三轮：边界测试。** 找几个"模棱两可"的问题测试。比如你的 Skill 是"电商详情页生成"，试试"帮我写个产品测评发网上"——这到底该不该触发？如果触发了，输出质量行不行？ 这种边界问题没有标准答案，但你需要知道你的 Skill 在边界情况下的表现，才能决定要不要进一步调整。 ### 一个完整的测试案例 我把"电商详情页生成"的完整测试过程写出来，你看一遍就懂了。 **初始 description：** ``` "生成电商详情页。当用户需要写产品描述时使用。" ``` **第一轮测试结果：** 该触发的 5 个： 1. "帮我写个产品详情页" — 触发 2. "来个淘宝文案" — 未触发 3. "这个产品怎么写卖点" — 未触发 4. "帮我写个产品介绍" — 未触发 5. "详情页文案" — 未触发 不该触发的 5 个： 1. "帮我写个产品评测" — 误触发 2. "写一份品牌宣传文案" — 误触发 3. "写个使用说明书" — 误触发 4. "写一份活动策划方案" — 误触发 5. "帮我设计一个海报" — 未触发 5/5 该触发的只过了 1 个，5/5 不该触发的误触发了 4 个。**惨不忍睹。** **问题分析：** "产品描述"这个词太泛了，什么场景都在用。我需要把范围缩窄到电商转化场景，同时把各种口语化的说法加进去。 **修改后的 description：** ``` "生成高转化率电商详情页文案。当用户需要写详情页、淘宝文案、产品页、种草文案、卖点文案，或者想生成产品介绍、电商文案、转化文案时使用。输出包含主图卖点、痛点场景、解决方案、信任背书、行动号召。不适用于产品评测、使用说明、品牌宣传、活动策划等场景。" ``` **第二轮测试结果：** 该触发的 5 个全部触发了。不该触发的 5 个里面，"写一份品牌宣传文案"还是误触发了——因为"文案"这个词在我的触发词里没有明确排除。 **再次修改：** 在"不适用于"后面加了"纯品牌宣传、非转化类文案"。 **第三轮测试：全部通过。** 这个案例说明一件事：**一轮改好是运气，三轮通过才是质量。** --- ## 五、什么时候该用 scripts/ 和 references/ —— Skill 超越提示词的关键 这是 Skill 和提示词**最本质的区别**。提示词只能描述，Skill 可以封装资源。 ### 三层资源各司其职 | 目录 | 内容 | AI 怎么用它 | 典型场景 | |------|------|------------|---------| | `scripts/` | 可执行代码（Python/Shell） | 调用执行，读取输出 | 精确计算、数据处理、API 调用 | | `references/` | 参考文档（Markdown/txt） | 按需读取，指导输出 | 长文档拆分、多平台规范、schema 定义 | | `assets/` | 模板文件（Excel/PPT/图片） | 复制修改，直接使用 | 报告模板、品牌素材、配置文件 | ### scripts/：把"做不好的"交给脚本 AI 擅长理解和组织信息，但**不擅长精确计算和格式控制**。 **什么时候必须用脚本**： - 同样的代码每次都要重写，或者需要确定性的可靠输出 - 涉及精确格式/长度约束（如生成 YAML 配置文件） - 需要校验规则匹配（如验证数据格式） - 复杂的数据处理（如 CSV 分析、PDF 解析） **示例**：PDF 旋转任务 ``` SKILL.md 只写：调用 scripts/rotate_pdf.py input.pdf 90 scripts/rotate_pdf.py：实际的 PDF 处理代码 ``` AI 不需要理解 PDF 旋转算法，只需要知道"什么时候调用这个脚本"。 ### references/：拆分长内容，按需加载 当你的 SKILL.md 正文超过 5000 tokens，就该考虑拆分。 **三种拆分模式**： **模式 1：高层指南 + 参考文件** ```markdown ## 高级功能 - 表单填写：详见 [FORMS.md](references/FORMS.md) - API 参考：详见 [API.md](references/API.md) ``` **模式 2：按领域组织** ``` references/ ├── finance.md # 财务指标 ├── sales.md # 销售数据 └── product.md # 产品分析 ``` 用户问销售问题时，AI 只读 `sales.md`。 **模式 3：多平台内容** ```markdown ## 平台选择 - 微信公众号：加载 [wechat-style.md](references/wechat-style.md) - 小红书：加载 [xhs-style.md](references/xhs-style.md) ``` ### assets/：直接使用的模板 AI 不需要"读懂"这些文件，只需要知道"什么时候放进去"。 **典型用途**： - `assets/report-template.xlsx` → 生成报告时复制，填入数据 - `assets/product-image-template.psd` → 生成详情页时参考产品图排版 - `assets/prd-template.docx` → 按模板格式输出 PRD ### 一句话总结 提示词只能"说"："请按这个格式写" Skill 可以"做"： - 调用 `scripts/analyze.py` 精确分析 - 查阅 `references/schema.md` 了解表结构 - 复制 `assets/template.xlsx` 生成报告 **这是 Skill 超越提示词的核心能力。** --- ## 六、我总结的一些实用经验 最后分享几条我在改 Skill 过程中总结的经验。这些不是什么高深的理论，就是踩坑踩出来的。 **关于 description：** - 1024 字符的额度，用到 80% 以上。写少了大概率触发不到。 - 触发词宁可重复也不要遗漏。"写推文"和"写个推文"是不同的匹配。 - 通用型 Skill 多写触发词，专用型 Skill 多写排除条件。 - 每次改完 description 都要重新跑测试，不要凭感觉。**感觉是最不靠谱的东西。** **关于正文：** - **反模式是最被低估的工具。**写 3 条"不要做什么"比写 10 条"要做什么"更有效。 - 给 AI 看一个"好的输出"的示例，比写 100 字描述更快。 - 步骤要有顺序——"先、然后、最后"比"同时要注意"好使。 - 输出格式用具体模板（表格、代码块），别用抽象描述（"结构化输出"）。**"结构化输出"对 AI 来说就跟"随便写写"差不多模糊。** **关于调试：** - 先解决触发问题，再解决输出问题。两个同时改，你会分不清是哪个改好的。 - 改了一个地方，全量重测。局部修改可能影响全局。 - 记录每次修改和测试结果。不记录的话，改三轮你就忘了第一轮是什么样了。 - 如果一个 Skill 怎么调都不行，考虑是不是应该拆成两个 Skill。有时候问题不是写得不好，是一个 Skill 试图干两件事。 改 Skill 这件事，本质上就是和 AI 沟通的过程。**你写得越清楚，AI 就越能给你想要的东西。**最开始可能要改好几轮，但改熟练了之后，一次就能写个八九不离十。 --- **下一个模块我们会上一个台阶**——不是改别人做好的 Skill，而是从头设计一个复杂的 Skill。到那时候你会用到这个模块里所有的技巧：精准的 description、完整的正文三要素、合理的自由度设计。这些基本功练扎实了，后面做复杂 Skill 才不会手忙脚乱。 咱们，下节课见。 --- *Source: https://learnagent.wiki/skills/cards/M03-把Skill改成你自己的* *Markdown mirror of https://learnagent.wiki, served as text/markdown for LLM ingestion.*