共计 1571 个字符,预计需要花费 4 分钟才能阅读完成。
开篇明义
Skill 是预定义的、可复用的能力模块(比如订餐、天气查询),而 Prompt 是即时生成的交互指令(比如让 AI 写一首诗)。前者像工具箱里的扳手,后者像临时手写的使用说明。

痛点分析
- 技能冗余 :把本应 Prompt 实现的闲聊功能硬写成 Skill,导致代码库臃肿
- 上下文丢失 :在 Skill 中强行拼接动态 Prompt,造成对话记忆断裂
- 维护成本 :频繁改动的业务逻辑用 Skill 实现,每次更新都要重新训练模型
技术对比
| 维度 | Skill | Prompt |
|---|---|---|
| 输入输出 | 结构化参数(JSON/YAML) | 自然语言指令 |
| 状态管理 | 内置记忆功能 | 依赖外部会话上下文 |
| 训练成本 | 需标注数据微调模型 | 零样本 / 小样本即可使用 |
| 执行速度 | 毫秒级响应 | 依赖大模型生成延迟 |
| 适用场景 | 标准化高频操作 | 灵活创意型任务 |
graph LR
A[业务需求] -->| 稳定 / 高频 | B(Skill)
A -->| 灵活 / 临时 | C(Prompt)
B --> D[预训练模型 + 微调]
C --> E[上下文注入]
场景化示例
Skill 封装订餐逻辑
class FoodOrderSkill:
def __init__(self):
self.memory = {} # 存储用户历史订单
def execute(self, user_id: str, dish: str, quantity: int) -> dict:
"""
:param user_id: 用户唯一标识
:param dish: 经过校验的菜品 ID
:param quantity: 1-99 之间的整数
:return: 包含订单详情的字典
"""
if not self._validate_dish(dish):
raise ValueError(f"无效菜品: {dish}")
order_id = str(uuid.uuid4())
self.memory.setdefault(user_id, []).append({
"order_id": order_id,
"dish": dish,
"quantity": quantity,
"timestamp": datetime.now()})
return {"status": "success", "order_id": order_id}
def _validate_dish(self, dish: str) -> bool:
return dish in {"pizza", "burger", "salad"} # 简化示例
Prompt 动态推荐
def generate_recommend_prompt(history: list[str]) -> str:
"""根据聊天历史生成推荐 Prompt"""
last_order = history[-1] if history else ""return f"""
用户最近提到:{last_order}
请推荐 3 道互补的菜品,用 emoji 装饰描述,并说明推荐理由(不超过 20 字 / 菜)"""
避坑指南
- 高频稳定操作 Skill 化 :每天使用 100+ 次的登录 / 支付等流程应该封装成 Skill
- 开放域交互 Prompt 化 :用户可能用 100 种方式表达的创意需求(如写诗)适合用 Prompt
- 版本控制分离原则 :Skill 需要严格的 API 版本管理,Prompt 可以通过语义路由动态切换
进阶思考
- 当业务规则每天变化时(如促销活动),如何设计 Skill 的抽象层保持接口稳定?
- 如何评估一个功能应该用 Skill 还是 Prompt?尝试制定量化决策矩阵(如变更频率 / 响应延迟权重)
延伸阅读
最后分享我的踩坑经验:曾经用 Skill 实现菜品推荐,结果菜单每次更新都要重新训练模型。后来改用 Prompt+ 菜品数据库,维护效率提升了 10 倍。关键要像区分「螺丝刀」和「橡皮泥」一样明确两者的边界——一个用来解决确定性问题,一个用来应对不确定性需求。
正文完
