Skills 和 大模型

如果是同一个skill，那么采用不同的模型跑，会有区别吗？比如后端用deepseek，或用GLM，这2个后端模型的能力是有差别的，但skill是同一个，跑出的结果会有差别吗？

其实，Skill 是“剧本”，模型是“演员”。 同一个剧本，不同水平的演员演出来的效果自然不同。Skill 本质上是一段包含多个步骤、约束条件、输入输出格式的复杂提示词。

• 强模型：能准确理解 Skill 的每一步，比如“先提取实体，再调用 API，最后按 JSON 格式输出，如果缺字段就输出 null”。执行稳定，很少跑偏。
• 弱模型：可能跳过某个步骤、误解条件（把“如果……则……”当成直接执行）、忘记输出格式，甚至把 Skill 里的示例当成了必须输出的内容。

其他方面都会存在差距，比如工具调用（Function Calling / Tool Use）、多步推理与状态保持、鲁棒性（对人写的 Skill 缺陷的容忍度）、风格与“个性”等。那么，Skills到底是什么，和之前流行的提示词工程有何进步？

• 共用提示词提炼 比如你写了一个“法律合同审查”的超长提示词（包含角色、步骤、输出格式），以前每次要复制粘贴。现在把它包装成一个 Skill，一键加载。

• 行业专用提示词
  医疗、金融、编程等领域的专家提示词，可以做成 Skill 分享。

更进一步的，传统提示词工程只是一段文本，而 Skill 通常是一个小结构：

演进路线图

提示词工程 (Prompt Engineering)
    │
    ├── 写一段好的指令
    │
    ↓
结构化提示词 (如 LangChain Prompt Template)
    │
    ├── 变量、示例、部分格式化
    │
    ↓
Agent + Tool
    │
    ├── 模型 + 工具调用
    │
    ↓
Skill (高级封装)
    │
    ├── 提示词 + 工具 + 流程 + 状态管理
    │
    ↓
（未来）AI 应用 / 插件市场

所以，如果你现在有写得很好的提示词，包装成一个 Skill 会更好用，尤其当你需要反复使用、分享给别人、或者加入简单的外部动作时。最后说一下 Skill 里的流程。

很多Skill不需要写一行代码，流程靠提示词里的自然语言描述，由模型自己理解和执行。例子：

名称：合同审查助手
流程：
1. 首先，让用户上传合同文本
2. 然后，提取合同中的甲乙方、金额、有效期
3. 接着，检查是否存在以下风险条款：[列出5条]
4. 最后，按以下格式输出报告：...

你把这个提示词放进Skill框架，模型读懂了就会按顺序执行。这里没有if、for、函数调用，全是自然语言。

但当你需要确定性逻辑（比如必须调用API、必须做数据校验、必须按严格顺序执行），就要用编程语言写流程。常见平台的做法：

实际产品中，Skill往往是提示词描述高层流程 + 编程实现关键步骤。例子： 一个“写邮件草稿”Skill

【提示词部分】（给模型看的）
流程：
1. 理解用户想要表达的核心意思
2. 生成邮件草稿
3. 调用"自动检查语气"工具，如果工具返回"太生硬"，则修改后再输出

【编程部分】（平台执行的）
- "自动检查语气"工具：用Python调用一个情感分析API
- 条件判断"太生硬"：代码里写`if result.tone == 'harsh'`

• 模型负责理解、生成、柔性逻辑（步骤1-2）
• 代码负责确定性操作、API调用、硬条件判断（步骤3的条件分支）