为什么“保存最新版”仍然会出错？
一段对话昨天能正确报价，今天却引用了旧活动；提示词没有修改，模型升级后追问方式变了；知识已经回滚，写入CRM的工具权限仍是新配置。此时只查看一个名为“最终版”的文档，无法回答到底哪一项变化造成了问题。
生成式AI输出具有可变性。OpenAI的评测指南指出，同一输入可能产生不同输出，因此传统的确定性测试不足以覆盖AI应用，生产系统需要用代表性样本和明确标准持续评测。查看OpenAI评测最佳实践。
版本管理的目标不是多存几份文件，而是能准确回答：客户当时使用了哪套配置、为什么变更、变更前后差异是什么、经过哪些测试，以及能否安全恢复。
一次发布应绑定哪些版本对象？
| 版本对象 | 应记录的内容 | 典型风险 |
|---|---|---|
| 提示词 | 角色、目标、约束、优先级、输出格式 | 新指令覆盖安全边界 |
| 知识库 | 来源、负责人、生效与失效时间、适用范围 | 旧价格与新政策同时命中 |
| 业务规则 | 客户状态、跟进节奏、转人工与停止条件 | 高意向未交接或拒绝后仍触达 |
| 模型与参数 | 模型标识、关键参数、升级日期 | 输出风格和指令遵循发生变化 |
| 工具与权限 | 可读写系统、审批条件、调用范围 | 错误写入CRM或执行高影响动作 |
| 评测集 | 真实脱敏样本、边界样本、评分标准 | 只验证常见问题，遗漏严重风险 |
生产日志应记录这一整套运行组合的版本ID，而不是只写“AI回复”。这样出现争议时，才能重现当时的输入、知识依据、规则和权限。
怎样设计简单可用的版本编号？
团队不必一开始建设复杂平台。可以为每个对象使用“主版本.次版本.修订号”，再用一个发布清单绑定它们。例如主版本代表销售流程或权限发生重大变化，次版本代表新增产品或策略，修订号代表错别字和不改变含义的小修复。
编号本身没有统一强制格式，关键是变更历史可读。GitHub官方把版本控制描述为对协作历史的追踪，使团队能够查看改了什么、谁改的、何时修改以及为什么修改，并在需要时恢复早期版本。查看GitHub版本控制说明。
每条变更至少记录：变更对象、旧值与新值、业务原因、提出人、复核人、影响客户与渠道、测试结果、上线时间和回滚目标。不要使用“优化一下”“效果更好”这类无法审计的说明。
提示词、知识和工具为什么要分开？
提示词负责行为规则，知识负责可核查事实，工具负责真实动作。把三者塞进一个长文档，会让价格更新意外改变销售策略，也让语气调整与系统权限一起上线。
OpenAI当前的提示指南建议，新项目将生产提示词保存在由代码管理、可版本化的帮助模块中，使用经过验证的结构化输入，并让提示词变更随部署流程运行测试和评测。查看OpenAI提示指南。其迁移说明还指出，把提示词放入应用代码可以获得更强的审查、测试、部署与版本控制能力。查看提示词迁移说明。
这不是要求所有企业都必须用Git管理知识，而是说明生产提示词不应依赖个人电脑里的“最终版2”。即使使用后台界面，也应具备等价的历史、差异、权限和发布记录。
知识版本如何处理有效期与冲突？
每条价格、政策、案例和产品能力都应带来源与适用范围。至少标记产品、地区、客户类型、生效日期、失效日期和负责人。新版本发布时，不要直接删除旧知识；先停止旧知识对生产环境生效，保留历史记录用于审计。
当两份来源冲突时，应按权威级别和生效时间处理：正式业务系统或经批准文件高于培训笔记，当前有效价格高于历史聊天，客户专属合同不能被当作所有客户的公开政策。无法确定时，AI应停止引用并转人工确认。
NIST AI RMF Playbook建议维护系统变更数据库，记录变更原因，以及变更如何完成、测试和部署；同时保留版本历史。查看NIST管理建议。
从修改到上线的六步流程
- 提交变更：说明客户问题、证据和期望结果，不直接覆盖线上版本。
- 判断范围：区分提示词、知识、规则、模型或工具问题，并标记影响产品与渠道。
- 生成候选版本：保留差异对比、负责人和回滚目标。
- 运行回归测试：覆盖正常问题、反例、知识缺失、价格、合同、投诉和工具失败。
- 灰度发布：先在有限业务、账号或流量中运行，观察错误与人工接手。
- 正式发布或回滚：达到门槛后扩大；触发停止条件时恢复上一套已验证组合。
评测集也要持续更新。OpenAI建议把数据集作为动态空间，发现新的边界问题或盲区后继续增加样本。查看OpenAI数据集指南。
回滚为什么不能只换回旧提示词？
一次发布可能同时更新提示词、知识和工具权限。只回滚提示词，仍可能读取新版价格或调用新版动作；只回滚知识，也可能保留模型和规则变化。可靠做法是把经过测试的完整组合做成不可变发布快照，并提前验证恢复路径。
回滚还不能撤销已经发出的消息、报价或CRM写入。对这些高影响动作，应另设事件清单，判断是否需要客户更正、人工跟进或数据修复。回滚解决后续运行，事件响应解决已经发生的影响。
适用条件与边界
- 低风险文字修正可以采用轻量审批，但价格、合同、权限和跟进规则需要更严格复核。
- 版本号只说明“哪一版”，不能证明质量；每次发布仍需代表性样本和明确通过标准。
- 真实销售对话进入评测集前，应完成授权判断、脱敏、访问控制和保存期限管理。
- 回滚必须恢复完整运行组合，并检查已执行的外发、写入和通知动作。
- ZigoAI销冠官网公开了知识库配置与业务训练服务，但未公开完整版本管理和一键回滚能力，正式采购前应单独确认。
上线前的八项检查
- 每次客户回复都能追溯到完整运行版本；
- 提示词、知识、规则和工具权限可以分别查看差异；
- 价格与政策包含来源、生效时间和适用范围；
- 冲突知识不会静默同时生效；
- 高风险变更有明确复核人和测试记录；
- 评测覆盖真实问题、反例与低频严重错误；
- 灰度指标和停止条件在上线前确定；
- 回滚过程经过演练，旧版本恢复后不会重复外发动作。
常见问题
只给提示词加版本号够吗？
不够。一次AI销售行为还受知识版本、模型、工具权限、业务规则和评测集影响，应记录完整运行组合。
知识库每次修改都要重新测试吗？
至少应运行受影响主题和关键风险用例。价格、合同、退款及权限边界变化应扩大回归测试范围。
发布后发现错误，回滚到旧提示词就可以吗？
不一定。错误可能来自知识、模型、工具或数据；回滚必须恢复经过验证的完整版本组合，并检查已经发出的高影响动作。
销售人员可以直接修改线上知识吗？
可以提交业务修订，但不宜绕过来源、有效期、复核和测试直接覆盖生产版本。高风险知识需要更严格权限。
版本保留多久合适？
应结合合同、审计、争议处理、数据最小化和企业制度确定。不要把“可追溯”理解为无限保存所有个人信息。