为客户写的提示词和评测，到底归谁？

设想你在一家物流客户那里驻场到了第六周。代码仓库里已经有一套由真实工单构建的评测集，共 400 个用例，还有 30 个提示词、一个对接工单系统的连接器。这些都跑在你们公司每个项目都用的评测框架库上。

评审会上，客户的团队负责人问了一个再普通不过的问题：合同结束后，这些东西是不是都归他们？你发现自己答不上来。更糟的是，合同可能也答不上来。

到了这一步，这个问题已经晚了六周。你不是律师，也不必成为律师。你要做的是懂得足够多，在项目启动、补救成本还低的时候发现漏洞，然后向法务提出正确的问题。

所有产出物，都装进两个口袋之一

基本框架很简单。按 UpCounsel 的解释，背景知识产权（background IP）是项目开始前已存在的内容，前景知识产权（foreground IP）是项目期间开发出来的内容。你们公司的评测框架库属于背景 IP，为客户构建的 400 个用例属于前景 IP。

背景这只口袋的默认规则相对宽松。英国律所 Sprintlaw 在面向 AI 自动化服务商的文章中建议，合同应写明：既有材料除非明确转让，否则仍归服务商所有。

但保留所有权只是一半。UpCounsel 指出，如果你交付的连接器离不开你们的库才能运行，合同就必须写清客户是否获得该库的使用许可。

前景这只口袋需要一份清单。Sprintlaw 建议精确界定哪些交付物需要转让，并具体点名，比如脚本、工作流和提示词，而不是写一句“服务产生的全部成果”。原因很实际：提示词和评测是新型产出物，照旧模板起草的条款未必考虑到了它们。

在美国还有一个额外的陷阱。根据 17 U.S. Code § 101 的定义，委托创作的作品只有属于法条列举的类别之一，且双方签署书面文件确认，才算“雇佣作品”（work made for hire）。

所以，“客户付了钱，东西就归客户”并不是可靠的默认规则。你需要一条白纸黑字的转让条款。

一个项目，四项产出物

回到那家物流客户。对着代码仓库坐下来，把每一项放进对应的口袋，就能得到这样一张表：

产出物	口袋	向法务提的问题
你们公司的评测框架库	背景	项目结束后客户能否继续使用，许可范围多大？
由真实工单构建的 400 个评测用例	前景，含机密信息	归谁所有？你方能否保留任何版本？
30 个定制提示词和工作流	前景	转让清单里是否点名列出？
对接工单系统的连接器	混合型：共享核心加定制配置	核心与定制部分的界线在哪里？

第二行最难。评测集是你最有价值的产出，因为它定义了这家客户眼中什么才算“正确”。

但它是用客户的数据构建的。Sprintlaw 强调，合同应明确限制对客户机密信息的复用。

如果你想把这套评测集的结构带到下一个项目，就从一开始谈好，别在最后一周自己拍板。

最后一行说明了为什么要尽早拆分代码。如果连接器核心放在独立的包里，客户配置放在单独的模块里，IP 的边界就和仓库里的边界一致。如果全混在一个文件里，什么条款也救不了你的交付。

第三层：模型服务商的条款

合同双方并不是全部。Sprintlaw 提醒，第三方 AI 平台的条款可能限制转让、转售、复制、用于训练或后续商业化。你没有的权利，也给不了客户。

以 Anthropic 的商业条款为例。按这些条款，客户保留对 Input 的全部权利并拥有 Output，Anthropic 不得用服务中的 Customer Content 训练模型。评测集是用真实工单构建的，这一点可以用来让客户的安全团队放心。

但要仔细读“Customer”这个词。条款把 Output 的权利授予 Customer，所以第一步是核实项目所用账户上的 Customer 是谁。如果不是你的客户，就再给法务加一个问题：合同通过什么途径把 Output 的权利交到客户手里？

还要留意反馈条款：Anthropic 声明，它可以使用客户反馈，且对客户不承担任何义务。提交 bug 报告时附上真实的评测用例，按下发送前值得多想一下。

第一周该做什么

先列一份预期产出物清单，在写任何代码之前完成：要带入哪些库、提示词、评测、连接器、运维手册文档。给每一行标上背景、前景或混合型，再标出哪些行涉及客户的机密数据。

接着，核实项目 API 账户上的 Customer 是谁，读一读服务商条款中关于 Input、Output、训练和反馈的部分。最后把表格发给法务，提三个问题：转让清单是否点名列出提示词、评测和连接器；客户是否获得已有工具的使用许可；项目结束后你方可以复用什么。

这项技能在求职时也用得上。当前线部署工程师（FDE）的招聘启事提到“scoping”或“SOW”时，简历上写一句“项目启动时梳理产出物清单，并与法务一起完成 IP 分类”，就能说明你主导过项目，而不只是在项目里写过代码。

常见错误

最常见的错误是把提示词当成无足轻重、没人列入清单的配置。第二是让内部库和客户代码混在一起，结果交付连接器那天，公司的共享工具也得一并交出去。

第三是把整套评测集复制到下一个项目，理由是“反正只是测试”，可其中每个用例都是客户的机密数据。

最后一个更隐蔽：以为 IP 是销售和法务的事。条款由他们起草，但只有写代码的人才知道仓库里到底有什么。物流客户的团队负责人在第六周提出的问题，你本该在第一天就问自己，而答案应该早已躺在一张四行的表格里。