提示词和skill的区别

你大概遇到过这种场面：同一个流程在聊天窗口里跑得挺好，一接进 Agent 就散架，或者每次都要把一大段提示词复制来复制去。问题往往不在提示词写得差，而在于你把「描述一次性意图」和「封装一项稳定能力」混成了一件事。这篇按能力封装的视角把两者的边界、选型和不适用场景讲清楚，附一份可直接照着走的判断清单。

你大概遇到过这种场面：同一个流程在聊天窗口里跑得挺好，一接进 Agent 就散架，或者每次都要把一大段提示词复制来复制去。问题往往不在提示词写得差，而在于你把「描述一次性意图」和「封装一项稳定能力」混成了一件事。

这篇按能力封装的视角，把两者的边界、选型和不适用场景讲清楚。出发点很简单：不是问哪个更高级，而是问这段交代到底是「这轮用完就算」还是「以后每次都得有」。答案不同，做法就完全不同。

先把两样东西各自的定位说准

提示词

运行时输入。一次调用里描述角色、约束、输出格式，用完即弃，改动成本几乎为零。

Skill

事先打包的资产。把可复用的指令、脚本、外部接口调用和参考资料固化下来，被调用时才加载。

判断标准看的是「重置成本」。每次都要重新交代一遍的，是提示词的活；交代过一次就该沉淀下来的，才是 Skill 的活。这个角度比「谁更正式」有用得多，因为它直接对应你每天要花多少时间重复劳动。

两者在同一个 Agent 里并不互斥：Skill 内部照样要写提示词，提示词也可以显式点名调用某个 Skill。把二者当成上下游而不是替代关系，很多纠结会自然消失。

能力边界怎么划：四问定归属

下面四问不用全中，三问以上落在 Skill 一侧，就别再硬撑。每一问都对应一个可观察的事实，不用凭感觉。

第三问值得多说一句：如果输出必须字段齐全、能被程序直接解析，那就把模板与校验交给 Skill 承载，提示词只负责填内容。反过来，只要允许人工再看一眼，就没必要为了这点确定性提前上封装。

封装程度与代价：别一次封太满

封装粒度从轻到重大致是：一段系统提示词、带参数模板、带说明文件的 Skill、带脚本和外部依赖的 Skill。每往下一层，复用性上升，调试难度和失效面也跟着上升。

1. 先跑通再抽让流程以提示词形态跑 5 到 10 次，用日志或聊天记录把每次的输入记下来。
2. 找出不变量对比这几轮，哪些句子每次都不变，哪些每次都要改；不变的句子才是值得固化的部分。
3. 留逃生口Skill 里留出输入参数和「本轮特殊要求」的覆盖入口，否则遇到例外只能改源码。
4. 上线后观察记录触发次数、失败率、平均耗时，跑一两周回看是否值得继续维护。

交付前跑一遍的验收清单

• 同一需求用三种说法各跑一次，看 Skill 触发是否稳定；触发不了说明它的描述没写到点子上，不是用户不会说话。
• 故意传一个不完整或矛盾的输入，看返回的是明确的缺参数提示，还是一段看起来合理实则跑偏的结果。
• 核对成本口径：Skill 里若带了检索、脚本或多次模型调用，单次触发实际消耗的不止一轮对话，用自己的输入量估算一遍再决定哪些步骤该留在里面。
• 确认授权与数据边界：读写的文件和调用的外部服务是否在允许范围内，涉及第三方能力的先对一遍合规要求再接入。
• 留观测：长期不触发的 Skill 就该合并或下线，别让它挂在目录里吃维护成本。

成本这一项最容易被忽略。同一个 Skill 触发一次，背后可能是好几轮模型调用加一次检索，账面和对话轮数不是一回事。要算清楚，到 模型成本计算器（/tools/model-cost-calculator） 用你自己的输入量对一遍当时的数字。

授权与数据边界同理，涉及第三方能力时先到 安全与合规（/safety） 对一遍要求，再决定这个 Skill 该不该接、接到什么程度。