2026年08月25日 · 博客

中欧企业联合研发：从PoC到量产，签约前必须写清的7件事

Joint R&D不是“大家一起做研发”：目标、投入、IP、验收、技术访问和商业化必须从第一天分开定义

数据截至2026年8月

中国企业与欧洲公司谈联合研发时，最容易听到一句话：

我们可以一起开发。

真正的问题是：

一起开发什么？谁投入什么？失败以后谁承担成本？新技术归谁？项目成功以后谁可以卖？

如果这些问题没有答案，

项目叫：

Joint R&D、Co-development、Strategic Technology Partnership

都没有太大区别。

一份真正可执行的联合研发合同，至少要先解决下面7件事。

1. 不要先写“共同开发”，先写什么叫“成功”

例如目标是：

开发新一代工业视觉检测系统。

这几乎无法验收。

更有用的是：

在指定测试条件下，缺陷识别准确率≥98%；
单件检测时间≤300ms；
可以部署在现有生产线；
单套目标成本不超过€X。

也就是说，合同需要同时写：

应用场景；
技术指标；
测试条件；
验收方法；
成本目标；
Deadline。

否则双方很可能都认为：

自己完成了工作，

但对“项目是否成功”有完全不同的理解。

2. 双方投入什么，要做成一张表

联合研发最容易模糊的一句话是：

双方共同投入资源。

必须把它量化。

中国企业	欧洲合作方
€X研发预算	X名研发人员
样品和材料	测试设备
中国生产线	现有算法/技术
工程师X人天	工程师X人天
测试数据	欧洲试点环境
供应链资源	认证/工程化资源

尤其要区分：

Cash Contribution

和：

In-kind Contribution

否则项目做到一半很容易出现：

“我们已经投入很多了，为什么还要继续付款？”

但合同里根本没有定义双方所谓的“投入”。

3. IP不要只问“归谁”，要拆成三层

背景知识产权（Background IP）

双方合作以前已经拥有的：

专利；
软件；
数据；
算法；
配方；
工艺；
Know-how。

最好在项目开始时：

列成附件。

否则项目结束以后最难回答的问题就是：

这项技术本来就有，还是项目中开发出来的？

项目成果（Results）

项目中新产生的：

专利；
软件；
模型；
工艺；
原型；
测试方法；
技术文件。

这里尤其不要默认：

联合研发 = 联合所有。

在EU协同研发体系中，Joint Ownership只是可能的结果，并不是必须采用的结构；相关方也可以约定把成果集中到一个所有者，再向其他方授予明确的使用权。European IP Helpdesk也明确指出，联合所有并非强制选择。(IP Helpdesk)

对企业来说，很多情况下反而更容易管理的是：

一方拥有 + 另一方获得明确许可。

例如：

欧洲企业拥有核心算法；
中国企业获得中国工业视觉领域的独占商业许可。

比一句：

双方50/50共同拥有

更容易实际执行。

使用权（Access Rights / Licence）

还必须回答：

谁可以使用？
用在哪里？
哪个行业？
哪些国家？
是否独占？
能否转授权？
项目结束以后还能否继续使用？

拥有IP和能够商业使用IP不是同一个问题。

4. “交付技术”到底意味着交什么？

这是软件、AI、材料和工艺合作最容易发生争议的地方。

例如写：

交付AI模型。

到底意味着：

可执行版本？
API？
Model Weights？
Source Code？
Training Data？
Training Pipeline？
Documentation？

完全不同。

所以合同应该直接列：

Deliverables。

例如：

Prototype；
Test Report；
BOM；
Source Code；
Model；
API Documentation；
Process Parameters；
Training Materials。

同时可以采用：

分阶段技术开放。

PoC阶段只开放完成PoC必要的信息；

达到下一Milestone以后，

再开放更深层的技术资料。

这样比：

NDA签完以后立即交换全部核心技术

安全得多。

5. 有些技术和软件不能因为是“共同研发”就自由传到中国

如果欧洲合作方需要向中国团队提供某些：

软件；
技术文件；
源代码；
高端设备技术；
半导体技术；
传感器；
加密技术；
其他军民两用技术，

必须先检查欧盟出口管制。

欧盟Regulation (EU) 2021/821的“export”不仅包括把实体产品运出欧盟，也明确包括通过电子邮件或其他电子方式向欧盟外传输受管制的软件或技术，甚至包括在特定情况下通过语音传递技术。(Eur-Lex)

所以正确顺序是：

技术分类 → 最终用户/最终用途 → 是否需要许可 → 再决定技术访问范围。

不是：

Joint R&D合同签了，所以双方当然可以共享。

同时还要检查第三方权利。

如果项目使用：

Open-source Software；
商业软件库；
第三方数据；
已许可专利；

必须确认：

新产品能不能按计划商业化。

否则双方可能共同开发出一个技术上成功、法律上不能卖的产品。

6. 付款要绑定Milestone，而不是绑定“研发时间”

联合研发不建议只写：

每月支付€X。

更实用的是：

M1 — Feasibility

交付：

技术路线 + 初始测试数据。

M2 — PoC

达到：

明确性能指标。

M3 — Prototype

完成：

可测试样机或软件版本。

M4 — Pilot

在：

真实客户或生产环境验证。

每一步设置：

Go / No-Go。

如果M2已经证明技术路线不成立，

企业应该能够：

停止项目，

而不是因为最初签了18个月合同，

继续为一个已经失败的路线支付一年费用。

7. 商业化不能等研发结束以后再谈

很多Joint R&D项目技术做出来以后才第一次讨论：

谁负责销售？

这已经太晚。

项目开始前至少确认：

谁负责产品化？
谁负责制造？
谁承担认证或合格评定？
谁负责欧洲客户？
谁负责中国客户？
谁决定最终价格？
谁承担Warranty？
谁维护软件或技术？
收入怎么分？

尤其如果双方都可以销售，

必须提前确定：

Territory + Field of Use + Customer Ownership。

例如：

中国企业：中国与东南亚市场；

欧洲伙伴：EU市场；

或者：

中国企业负责制造，欧洲伙伴负责欧洲系统集成。

否则第一个真正客户出现以后，

双方才会发现：

研发伙伴同时变成了商业竞争对手。

最后还需要一个退出机制

联合研发不是所有项目都会成功。

合同应该提前回答：

项目中途停止以后怎么办？

至少包括：

已付款是否退还；
已完成成果归谁；
已取得的Licence是否继续；
未完成样机怎么办；
Confidential Information何时删除或返还；
双方能否继续独立开发；
已申请专利由谁继续维护；
第一个客户项目谁继续服务。

真正好的Exit条款不是为了：

结束合作。

而是为了让双方敢于：

开始合作。

签Joint R&D之前，看这一张表就够了

必须写清	核心问题
目标	什么数据证明研发成功？
投入	双方分别投入多少钱、人、设备和技术？
Background IP	哪些技术原本就属于各自？
Results	新成果归谁？
Licence	谁可以在哪些市场商业使用？
Deliverables	最终到底交什么？
Milestones	什么时候付款，什么时候可以停止？
Compliance	技术、软件和数据能否合法跨境共享？
Commercialisation	谁生产、谁销售、谁服务客户？
Exit	项目失败以后双方还拥有什么权利？

结语

中欧企业联合研发真正困难的地方，不是：

双方技术够不够强。

而是：

双方投入不同、已有IP不同、商业目标不同，却要共同创造一个新成果。

因此Joint R&D真正需要解决的不是：

“我们愿不愿意合作？”

而是：

成功怎么定义？

技术归谁？

谁可以商业使用？

什么时候可以停止？

成功以后谁把它卖出去？

第一次合作也没有必要直接成立：

共同实验室。

更合理的路径通常是：

Feasibility → Paid PoC → Prototype/Pilot → Joint R&D扩大 → 商业化。

先证明技术可以合作，

再扩大组织和资金投入。

联合研发真正成功的标志不是签了一份合作协议，而是技术成果最终能够进入产品、生产线或真实客户项目。

本文提供一般联合研发、知识产权与项目治理信息，不构成法律、知识产权、出口管制或投资意见。具体IP归属、技术许可、数据访问、出口管制及商业化安排应根据技术类型、参与方所在国家和具体项目结构确认。