共计 1820 个字符，预计需要花费 5 分钟才能阅读完成。
概念定义：控制论视角下的本质差异
从控制论角度看，prompt（提示词）相当于即时指令，而 skill（技能）则是固化能力。打个比方，prompt 像临时教朋友做菜的口头指导，而 skill 则是他经过反复练习后掌握的烹饪技能。
核心指标对比表
| 维度 | Prompt | Skill |
|---|---|---|
| 输入响应延迟 | 高（需实时解析） | 低（预编译逻辑） |
| 上下文记忆能力 | 依赖外部存储 | 内置状态管理 |
| 训练成本 | 低（即时调整） | 高（需开发周期） |
| 可复用性 | 差（场景绑定） | 强（模块化） |
| 维护复杂度 | 线性增长 | 对数增长 |
工程痛点：错误使用的代价
典型案例：对话系统雪崩
某电商客服机器人将商品推荐逻辑全部用 prompt 实现，导致：
– 用户每句话都触发完整 API 调用
– 高峰期响应时间从 200ms 飙升到 2s
– 当月云服务费用超预算 300%
成本量化公式
# 错误方案成本计算示例
def calc_prompt_cost(requests_per_second, avg_prompt_tokens):
api_cost_per_token = 0.00002 # 美元 / 千 token
return requests_per_second * 3600 * avg_prompt_tokens * api_cost_per_token / 1000解决方案：明智的技术选型
决策流程图
graph TD
A[需求分析] --> B{是否需要长期记忆?}
B -->| 是 | C[开发 Skill]
B -->| 否 | D{是否高频调用?}
D -->| 是 | C
D -->| 否 | E[使用 Prompt]Skill 模块化示例
from enum import Enum, auto
from typing import Optional
class OrderStatus(Enum):
PENDING = auto()
SHIPPED = auto()
DELIVERED = auto()
class OrderTrackingSkill:
"""订单追踪技能模块（包含状态机）"""
def __init__(self):
self._state: Optional[OrderStatus] = None
def handle_query(self, order_id: str) -> dict:
try:
status = self._fetch_status(order_id) # 调用内部 API
self._state = OrderStatus[status.upper()]
return {
'status': self._state.name,
'message': self._generate_response()}
except Exception as e:
return {'error': f"Skill error: {str(e)}"}
def _generate_response(self) -> str:
"""状态驱动的响应生成"""
if self._state == OrderStatus.PENDING:
return "您的订单正在备货中"
elif self._state == OrderStatus.SHIPPED:
return "包裹已发出，物流信息已更新"
else:
return "订单已完成，期待再次光临"生产级考量
性能测试数据（相同商品查询功能）
| 并发用户数 | Prompt 方案(QPS) | Skill 方案(QPS) |
|---|---|---|
| 50 | 120 | 850 |
| 100 | 80 | 820 |
| 200 | 40 | 800 |
安全防护方案
- 输入消毒：对所有 skill 入口参数进行正则过滤
- 权限隔离：skill 运行在沙箱环境中
- 审计日志：记录完整的执行上下文
避坑指南
反模式警示
- ❌ 在 skill 中硬编码如
"请用不超过 20 字回答：{user_input}"的 prompt 模板 - ❌ 用 prompt 拼接实现业务流程跳转
调试技巧
使用 LLMtrace 工具时：
- 安装调试包
pip install lllmtrace - 添加追踪点
from lllmtrace import set_trace def skill_entry(...): set_trace(context=locals())
实践思考题
- 如何设计 skill 的版本兼容机制，确保升级时不影响现存对话？
- 对于需要频繁调整的业务规则，如何平衡 prompt 的灵活性和 skill 的稳定性？
- 在多租户场景下，如何实现 skill 实例的资源隔离？
通过本文的对比分析，我们可以看到 prompt 和 skill 各有其适用场景。当业务逻辑需要稳定性、高性能时，skill 是更优选择；而对于快速原型验证或一次性任务，prompt 则能提供更敏捷的实现。关键在于根据具体需求做出合理的技术选型。
正文完
