skill与提示词有什么区别

很多人把 skill 和提示词当成一回事，结果要么把一堆固定流程塞进每次对话的提示词里，越写越长还容易漏；要么明明只是改一句话，却去折腾一整套配置。这篇不做概念考据，只按「这东西放在哪、什么时候生效、改一次影响几次」来对照，帮你判断手上这件事该写成提示词，还是该固化成 skill。

很多人把 skill 和提示词当成一回事，结果要么把一堆固定流程塞进每次对话的提示词里，越写越长还容易漏；要么明明只是改一句话，却去折腾一整套配置。这两种做法都常见，但都不是没法避免的——区别其实就落在三个问题上：这东西放在哪、什么时候生效、改一次影响几次。

这篇不做概念考据，只按上面三个问题来对照。你看完应该能做一件事：把手头这个需求判成提示词还是 skill，并且知道判断完之后第一步该干什么。举个通用场景，一家 5 人小团队里有人负责整理会议记录，如果每次都要重新交代一遍输出格式，那更接近提示词；如果这套格式要被三个人每周复用，那就该考虑固化成 skill。

先把两个词落到具体位置

提示词是你在这一次对话里敲进去的那段话，只在这次请求里起作用，换了会话就没了。skill 更像一份提前放好的说明书，写一次、放在固定的入口里，之后每次调用都按它走。你不写它，它也可能被识别到的任务类型自动带上。

• 判断方法一：这东西是「每次都要重新说一遍」还是「说一次以后一直照做」，前者是提示词，后者是 skill
• 判断方法二：看改动后的影响面，只影响你这一次输出的，放提示词里更安全
• 判断方法三：看有没有人要复用，只有你自己用、用完就走的，多半不值得做成 skill
• 场景不适用：只是随口问一句、结果好坏都无所谓时，不必为它专门做 skill，写清一句提示词就够

三个维度看清分工：触发、范围、维护

光看定义容易含糊，换成触发、范围、维护这三个维度就清楚多了。把 skill 想成团队里贴在工位上的作业规范，提示词是今天临时交代的那几句话——一个是常驻的，一个是即时的。

这张表里最容易踩坑的是「范围」那一行。提示词写错了，顶多这一次输出不对；skill 写错一句，可能让这个入口下所有请求都跟着偏。所以 skill 的改动建议配一个版本记录，改之前先想好怎么退回去。

什么时候写提示词，什么时候该做 skill

判断标准不是「哪个更高级」，而是「这件事会重复吗、需要卡格式吗、要交给别人吗」。三条里中了两条，基本就可以往 skill 方向走；一条都不中，写提示词更省事。

1. 先按提示词跑通别一上来就建 skill。先用提示词把同一类任务跑三五次，观察哪几句是每次都要交代的、哪几句是每次都在变的。
2. 抽出稳定部分把每次重复出现的那几句挑出来，这些是规则，属于 skill 的候选内容；每次都要现场调的那部分，继续留在提示词里。
3. 小范围验证固化成 skill 之后，先在一两个普通例子上跑，确认没把原本能做对的情况弄坏，再推广给其他人用。
4. 留好回滚改 skill 前留一份旧版本，改动后对比新旧输出差异，发现不对能马上退回去。

不适用情况也要说清楚：如果你的任务每次输入结构都不同、几乎没有重复环节，硬做成 skill 反而每次都要绕开它，维护成本比现场写提示词还高。这种情况下提示词才是更合适的形态。

拿不准时的自查顺序

下面这四步按顺序走下来，基本能判出该写哪个。顺序不要跳，尤其第一步，很多纠结其实卡在「没数清楚到底会做几次」上。

• 第一步数次数：同一类活儿一个月会做几次，只有一两次就别急着固化，写成提示词够用
• 第二步看格式：输出要不要卡死结构，要卡死的更适合放进 skill，靠提示词每次叮嘱容易漏项
• 第三步看交接：要给别人复用就倾向 skill，只自己用提示词也扛得住
• 第四步小步验证：改完先在一两个普通例子上跑，确认没把原本能做对的情况弄坏再推广

如果你还在纠结某个具体入口该配哪种参数、或者想看看别人是怎么把流程拆成可复用配置的，站内工具目录里有现成的分类可以参考，对照一下你手上这件事落在哪一类，比空想快得多。至于各家方案的对比数据和当时的实际表现，建议到站内评测和价格追踪页面核对当下的数字，不要凭印象下判断。