企业部署AI后，经常发现真正难管理的不是模型，而是散落在代码、文档和聊天记录里的提示词与Skill。Mistral Studio提出把它们当作生产资产，集中记录版本、负责人和变更历史。这个思路适用于任何技术栈：只要一段指令会影响客户回答、审批建议或业务动作，它就不应继续作为某个人电脑里的临时文本存在。
一、为什么提示词也是生产代码
提示词决定语气、业务规则、拒绝边界和工具选择，一个词的变化就可能改变结果。它虽然不像传统代码那样编译，却同样需要版本、测试、审批和回滚。如果客服提示词被直接覆盖，团队很难解释昨天和今天回答为何不同。把每次发布固定为不可变版本，才能让线上结果对应到当时真实运行的指令。
二、Prompt与Skill要分开管理
Prompt主要保存可复用文本和角色要求，Skill则包含何时使用某种方法、具体步骤以及模板或参考文件。简单的语气模板适合Prompt，复杂的合同审查流程更适合Skill。区分后，业务人员可以修改表达，流程负责人维护步骤，开发人员管理工具权限，避免所有逻辑挤在一个巨大的系统提示中。
三、为每项资产指定负责人
负责人不是最初创建者，而是能够判断业务规则是否正确并承担维护责任的人。资产记录中应包括用途、适用场景、所有者、审核人、依赖数据、风险等级和停用条件。人员变化时必须完成交接。没有负责人、长期无人使用或无法解释来源的提示词，不应继续进入生产环境。
四、版本与环境怎么设计
开发版本允许快速试验，测试版本用于固定评估，生产版本必须经过批准。生产版本发布后不能原地修改，只能创建新版本；发现问题时回滚到已知稳定版本。可以使用staging和production标签指向具体版本，但标签变化要记录操作者与时间。这样应用调用稳定标签，管理平台负责控制标签指向。
五、发布前必须有评估集
为每个Prompt或Skill准备真实案例，覆盖正常请求、模糊请求、越权请求和已知失败场景。评估既包括自动指标，也包括业务人员判断。客服场景可以测事实正确、政策一致、敏感信息泄露和语气；数据分析可以测公式、字段完整和异常解释。没有测试结果的改动，不能因为“看起来更好”就直接上线。
六、观察结果并追溯到版本
生产日志应能回答：哪个用户请求触发了哪个Skill，使用了哪个Prompt版本，调用了哪些工具，最后结果如何。出现投诉时，可以从输出追溯到资产版本，再比较前后差异。日志需要脱敏和访问控制，不能为了可观察性保存全部敏感原文。重点是建立可定位链路，而不是无边界收集数据。
七、业务人员与开发人员如何协作
业务人员最了解政策和措辞，开发人员负责接口、权限与发布管道。好的平台让业务人员能在隔离环境中编辑和测试，但生产推广仍触发既有审批和持续集成流程。这样既避免每次文字调整都排队等开发，也防止未经测试的规则直接影响客户。双方共同维护验收标准，而不是互相传递一段无法验证的提示词。
八、从十条提示词开始治理
小团队不必一次建立庞大平台。先找出十条最常用、最接近客户或最可能产生风险的提示词，为它们补负责人、版本号、测试问题和回滚副本。每次变更留下说明，每月淘汰无效资产。随着数量增加，再接入集中注册表和自动评估。治理的目标不是增加流程，而是让AI行为可以重复、解释和恢复。
资料来源：官方资料。本文依据官方信息独立整理与扩展，结合实际使用场景进行说明。
