很多企业对 AI Skill 的兴奋停留在 demo 阶段：做一个能回答问题的原型并不难，难的是让它在真实业务场景中稳定、可控、可度量地运行。Skill 工程（Skill Engineering）就是解决这个问题的系统化方法。它把 Skill 的开发过程标准化，确保每个环节都有验收标准和回退机制。
阶段一：需求澄清与边界划定
Skill 工程的第一步不是写代码，而是澄清需求。需要回答三个问题：这个 Skill 解决谁的什么问题？成功标准是什么？哪些情况不在范围内？
边界划定尤其重要。一个「查库存」的 Skill，要不要处理缺货预警？要不要支持跨仓库查询？要不要自动触发补货建议？这些边界如果没有提前明确，后期会不断返工。建议用「用户故事 + 输入输出示例 + 异常清单」三件套来固化需求。
阶段二：接口对接与数据治理
Skill 的价值在于连接业务系统。接口对接阶段需要完成：API 文档梳理、权限设计、数据脱敏、错误码映射、超时与降级策略。很多项目在这个阶段暴露出企业系统的「历史债务」：接口文档不全、字段含义模糊、权限颗粒度太粗。
- 接口文档：至少包含接口地址、请求参数、返回字段、错误码、示例。
- 权限设计： Skill 能访问哪些数据，遵循最小权限原则。
- 错误处理：当接口超时或返回异常时，Skill 应该给出友好提示并记录日志。
数据治理是隐性成本，但往往决定 Skill 能否真正落地。建议在项目早期就安排数据负责人参与。
阶段三：提示工程与输出约束
提示工程是 Skill 工程的核心。一个好的提示词不仅要告诉模型做什么，还要告诉它不能做什么、输出格式是什么、参考知识是什么。
| 提示要素 | 说明 | 示例 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 角色定义 | 让模型知道它扮演的角色 | 你是一名资深销售顾问，熟悉本公司产品线。 | 任务描述 | 清晰描述要完成的具体任务 | 根据客户需求，推荐最合适的产品方案并说明理由。 | 输出格式 | 规定返回结构 | 返回 JSON：{product,reason,price_desc} | 约束条件 | 明确限制 | 不要推荐停产产品；价格只写区间。 | 参考知识 | 接入企业知识 | 参考以下产品资料：{context} |
除了提示词，还需要加一层后校验：检查输出是否符合格式、是否包含敏感信息、是否调用越权接口。校验层是防止大模型「幻觉」的最后一道防线。
阶段四：评测体系建设
Skill 上线前必须有评测体系。评测通常分为三类：功能评测（是否完成了预定任务）、安全评测（是否越权、是否泄露敏感信息）、性能评测（响应时间、并发能力）。
建议建立「测试集 + 自动评测 + 人工抽检」的机制。测试集应覆盖正常 case、边界 case 和异常 case。自动评测可以用规则匹配和模型打分相结合，人工抽检则用于发现自动评测覆盖不到的问题。
阶段五：上线与持续运营
Skill 上线不是终点，而是运营的开始。上线后需要监控调用量、成功率、用户满意度、bad case 分布，并定期把新问题和优质回答沉淀到知识库和提示词中。
优秀的 Skill 团队会把 50% 的精力放在上线后的持续优化上，而不是一次性把功能做完。
常见问题
Skill 工程和传统软件开发有什么不同？
Skill 工程更强调需求边界、提示设计、评测体系和持续运营，因为大模型的输出具有一定的不确定性。
为什么评测体系很重要？
大模型可能产生幻觉或越界输出，评测体系是保障 Skill 稳定、安全、可控的关键防线。
Skill 上线后还需要做什么？
需要监控调用量、成功率、bad case，定期优化提示词和知识库，形成持续改进闭环。
