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

> 合同不写明提示词、评测和连接器，所有权之争只会推迟到交付那天。

原文: https://fdetimes.net/zh/guides/who-owns-prompts-evals-client-work/

设想你在一家物流客户那里驻场到了第六周。代码仓库里已经有一套由真实工单构建的评测集，共 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 是销售和法务的事。条款由他们起草，但只有写代码的人才知道仓库里到底有什么。物流客户的团队负责人在第六周提出的问题，你本该在第一天就问自己，而答案应该早已躺在一张四行的表格里。

**本周动手试试:**

- 打开当前项目的代码仓库，列出每一项产出物，给每一行标上背景、前景或混合型。
- 在现有的工作说明书（SOW）或合同中搜索“prompt”“eval”和“connector”这几个词；缺哪个，就向法务发一个问题。
- 阅读模型服务商商业条款中 Input/Output 和反馈的部分，再核实项目 API 账户上的“Customer”是谁。

## 信源

- [IP Assignment Clauses for UK AI Automation Agencies](https://sprintlaw.co.uk/articles/ip-assignment-clauses-for-uk-ai-automation-agencies/)

- [Understanding Background IP: Key Legal Insights](https://www.upcounsel.com/background-intellectual-property)

- [Pre Existing IP Meaning: Key Insights for Agreements](https://www.upcounsel.com/pre-existing-intellectual-property-rights)

- [17 U.S. Code § 101 - Definitions](https://www.law.cornell.edu/uscode/text/17/101)

- [Commercial Terms of Service](https://www.anthropic.com/legal/commercial-terms)