能登录系统，不代表企业已经拿到完整交付
项目验收时，员工可以打开助手、上传文件、生成结果，功能看起来都在。几个月后企业想修改规则，却发现关键提示写在服务商后台，工作流只能在线查看，测试题也没有交付。系统能用，但每次调整都必须重新找原团队。
企业 AI 的价值不只在代码。业务规则怎样被翻译成提示、哪些资料进入知识库、什么结果算合格、异常时怎样转人工，这些配置共同决定系统能不能工作。它们如果不在交付范围里，企业实际拿到的只是一个入口。
先把资产分成五类，再谈谁拥有和谁能使用
第一类是企业原始资料和业务数据；第二类是清洗后的知识条目、数据字典和标签；第三类是提示词、规则和工作流配置；第四类是测试样本、评分标准与人工修改记录；第五类是服务商沉淀的通用框架和公共组件。
前四类通常与企业业务紧密相关，应明确可访问、可导出和可继续使用的范围。通用组件可以由服务商保留，但要说明项目依赖哪些组件、停止合作后是否还能运行，不能只用一句“知识产权归乙方”把所有内容混在一起。
- 企业原始数据和业务事实要有明确归属。
- 项目专用提示、流程和评测资料应写进交付清单。
- 通用组件说明授权范围、期限和替代路径。
导出不是给一堆截图，而是让下一位维护者接得住
有效交接应包含可编辑文件、字段说明、版本信息、依赖接口和导入步骤。提示词最好说明适用任务和已知限制，工作流要标出每个节点的输入、输出、权限与失败处理，评测集则记录样本来源和通过标准。
如果只能导出截图或加密配置，企业仍然无法维护。也不要求服务商暴露所有底层商业秘密，但项目专用部分应以双方约定的格式保存，至少能让另一支团队理解当前系统怎样运行。
归属、维护和责任是三件事，合同里不要混为一谈
企业拥有某份配置，不代表企业有能力独立维护；服务商负责维护，也不等于所有资产都归服务商。合同应分别回答谁拥有、谁可以使用、谁负责更新、出现问题谁响应，以及合作结束后怎样交接。
第三方模型、云平台和开源组件还有自己的许可与限制。项目方案要把这些依赖列出来，避免企业误以为买断了全部技术，也避免服务商把本应交付的业务配置都归入第三方限制。
交付边界越早讲清，后期合作反而越稳定
有些团队担心讨论退出和资产归属会破坏信任。实际相反，客户知道资料能拿回、配置有记录、维护责任清楚，才更愿意把系统放进重要流程。服务商也能避免临近验收时才争论“这个算不算交付”。
企业 AI 定制不是一套黑盒租赁，也不必把所有通用技术都转让给客户。合理做法是把业务专用资产、通用能力和第三方依赖拆开写清，让项目能持续运行，也能在必要时平稳交接。
要点总结
- 应区分项目专用提示与服务商通用模板，具体归属和使用权需要在合同中明确。
- 它记录系统的合格标准和边界样本，是后续升级、换模型和验证修复的重要依据。
- 可以，但应说明授权范围、系统依赖和停止合作后的运行或替代方式。
参考来源说明
本文围绕“企业 AI 定制交付后，提示词、工作流和评测集到底归谁”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。