# Technology Contract Review

> 技术合同专项审查技能，由 contract-review 路由器按合同类型路由加载，不直接面向 用户调用。覆盖场景：技术开发合同（委托开发/合作开发）、技术转让合同 （专利权/专利申请权/技术秘密转让）、技术许可合同（专利实施许可/技术 秘密使用许可）、技术咨询与技术服务合同、含里程碑验收的研发合作文本。 同义场景词：技术开发合同审查、技术转让审查、技术许可审查、研发合作 协议审查、技术合同把关。执行与 nda-review 同构的全链路：matter 上下文 与产物去向检查、委托方/受托方（让与方/受让方、许可方/被许可方）立场 判定、技术合同立场 playbook 加载或现场补齐、Scope check（开发/转让/ 许可/咨询/服务的类型先定与藏条款）、七类分类检查（技术目标与里程碑 验收、成果归属与后续改进、技术资料交付与保密、知识产权侵权担保与 责任、价款与提成、违约与解除、管辖与争议解决）、按 playbook 三色 分桶、输出统一 triage memo；涉外技术进出口管制因素触发升级。

- Skill: `minimax-ai/technology-contract-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add minimax-ai/technology-contract-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/minimax-ai/technology-contract-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: MiniMax AI (https://skillmd.com/u/minimax-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/minimax-ai/technology-contract-review

---


# 技术合同专项审查

## 目的

把一份技术合同从「看价格和工期」变成「按本方立场逐项过堂」：先定类型
（开发/转让/许可/咨询/服务），确认审查视角，用经确认的 playbook 立场
逐项比对，把结果分成 🟢🟡🔴 三桶，产出一份可直接行动（改、谈、签、
停）的 triage memo。

本技能的核心纪律有三条：

1. **类型先于条款**：技术合同是民法典合同编的一整章，开发、转让、
   许可、咨询、服务的成果归属与法定默认规则各不相同；类型定错，
   整条成果归属检查的口径就错了；
2. **结论依附立场**：同一条成果归属条款对委托方是投资保障、对受托
   方是研发积累被抽走，不先定立场就无权下结论；
3. **🟢 不出自默认值**：🟢 只能基于律师审定的 playbook 立场；画像
   里还是默认模板时，单份合同最高 🟡（docs/scenes/contract-review-cn.md B3）。

本技能遵守 legal-core Shared guardrails（G1–G12）与docs/scenes/contract-review-cn.md；冲突时以 legal-core 为准。

## 前置检查

1. 已由 `contract-review` 路由器完成画像检查与路由确认；未经路由器直接进来
   的先补齐。
2. 文本完整可读；技术规格书、需求文档、里程碑计划、报价单等附件不
   齐的，在 reviewer note 的「已读」行如实写明。
3. 用户角色已识别，决定 G4 标头档位与 G5 后果门口径。
4. 金额初判与升级初判：合同金额超画像审批阈值、或成果归属安排复杂
   （合作开发、背景与前景知识产权交织）、或含涉外因素的，触发 B5
   升级，memo 照出但明示「须升级人工」。

## 操作规程

### 第 0 步：Matter context 与 Destination check

- Matter context：查 `matters/_log.yaml`；已有相关事项则挂入（memo
  存 drafts/，notes.md 追加进展）；长期研发合作的，建议经
  `matter-workspace` 建档（提示即可，不强制）。
- Destination check：产物去向在保密圈外的 flag 并可提供内外双版本；
  memo 含本方技术家底、成果归属底线等信息，外泄直接损害谈判地位。
  去向不明按仅内部处理。

### 第 1 步：立场判定（委托方 / 受托方等）

按合同类型确定本方角色：

- **技术开发**：委托方 / 受托方（合作开发的为合作各方）。委托方视角
  重点：成果归属与交付完整性、里程碑验收的抓手、失败风险分担；受托
  方视角重点：需求变更机制、验收标准客观化、背景 IP 不被裹挟转让。
- **技术转让**：让与方 / 受让方。受让方视角重点：权利无瑕疵担保、
  技术资料与培训交付、后续技术支持；让与方视角重点：价款保障、自己
  保留的使用权范围。
- **技术许可**：许可方 / 被许可方。额外核查许可类型（独占/排他/普通）、
  范围（地域、期限、可否转许可）与提成交付的对账机制。
- **技术咨询/服务**：委托方 / 受托方。重点在成果形式（报告/方案）的
  验收与责任边界。
- 文本角色与业务实质不一致的（如名为技术服务实为委托开发、名为许可
  实为转让），以业务实质为准，在 memo 中说明，并评估是否需向用户
  提出类型重路由。

### 第 2 步：加载 playbook（技术合同立场）

- 读取画像中的技术合同立场节；经律师审定的直接使用，默认模板最高
  🟡。涉及知识产权归属复杂安排的，对照画像升级矩阵处理。
- 未填的，现场询问关键立场并**经 `customize` 技能写回画像**（标
  [已确认—日期]、「未经律师审定」）：
  1. 成果归属底线（委托方视角：是否必须取得全部成果；受托方视角：
     哪些背景 IP 绝不转让）；
  2. 后续改进成果的归属与使用立场；
  3. 价款结构偏好（一次总算 / 入门费+提成 / 纯提成）；
  4. 可接受的保密期限与违约责任结构；
  5. 管辖偏好（与 B9 首选管辖对齐）。
- 用户答不出：不编造，相关项整体 🟡，理由「立场未确认」。

### 第 3 步：Scope check（类型先定与藏条款，无条件执行）

通读全文，完成两件事：

**（a）类型先定**：民法典第八百五十一条至第八百六十一条为技术开发
合同一节 [模型知识—待核实，引用前经 statute-verify 核验]，引用该节
条文保持 [CITE:__] 占位；技术转让与技术许可、技术咨询与技术服务各有
其节 [模型知识—待核实，引用前经 statute-verify 核验]。按主要权利义务把合同归入其中一类；混合型的（开发+许可、
转让+服务）写明主从结构，各部分分别适用对应检查口径。

**（b）藏条款识别**：命中以下任一情形，**无条件 auto-🟡** 并在执行
摘要第一行明示「本合同名为 XX 合同，实际含有 XX 安排」：

1. **名为服务/咨询实为委托开发**：约定形成可交付的技术成果（软件、
   配方、工艺），成果归属规则完全不同。
2. **名为许可实为转让**：一次性对价 + 永久 + 全部权利，实为权利
   转让。
3. **夹带人员绑定**：限制受托方关键人员流动、约定竞业限制——实为
   对人身与经营自由的限制条款。
4. **夹带排他合作**：约定同类技术只能与对方合作。
5. **涉外技术进出口因素**：技术跨境转让/许可的，涉及技术进出口
   管理（禁止/限制/自由进出口的分类管理）[模型知识—待核实，引用
   前经 statute-verify 核验]——命中即触发 B5 升级并按 G3 处理法域
   问题，本技能不就进出口合规下结论。

处理方式：藏条款部分按真实法律关系另列标记项（起点 🟡）；命中画像
红线条款的按画像红线纪律（出现即提示，严重度下限 🟠，G9）。

### 第 4 步：分类检查清单（七类，调用 risk-clause-database）

逐类检查。**不设硬编码数值阈值**——里程碑数量、提成比例、保密期限
一律比对画像/playbook 立场；立场未覆盖的标 🟡 写「超出 playbook」。
通用条款风险形态调用 `risk-clause-database` 取统一口径，本节只列
技术合同专项要点：

1. **技术目标与里程碑验收**：技术指标是否客观可检验（参数、性能、
   文档清单附件化）；里程碑划分与对应付款节点的挂钩；验收标准、
   程序与期限；「逾期未提异议视为验收合格」的默示验收；验收不过
   的返工次数上限与最终失败的处理（退款、风险分担）——委托开发
   失败的风险负担规则 [模型知识—待核实，引用前经 statute-verify
   核验]。
2. **成果归属与后续改进成果**：开发成果的归属约定（委托开发无约定
   时的法定归属、合作开发的共有规则 [模型知识—待核实，引用前经
   statute-verify 核验]）；**背景 IP 与前景 IP 是否分开约定**——
   「为履约产生的一切成果归甲方」会把受托方背景 IP 裹挟进去，受托
   方视角高危；后续改进成果的归属与相互使用安排（无约定时的处理
   [模型知识—待核实]）；署名权等人身性权利的处理。
3. **技术资料交付与保密**：交付物清单（源文件/图纸/文档/培训）是否
   穷尽；交付节点与验收的衔接；技术秘密的保密义务、期限与例外；
   人员更替与分包下的保密传递；泄密救济。
4. **知识产权侵权担保与责任**：让与方/许可方/受托方对成果合法性与
   不侵权的保证；被控侵权时的处理（应诉、替换、退款）与费用承担；
   担保的例外（按委托方提供的技术资料实施导致的侵权）；责任上限
   是否对等（对照民法典第五百七十七条 [CITE:__] 与画像赔偿上限
   立场）。
5. **价款与提成**：价款结构——一次总算、提成支付、或入门费加提成
   [模型知识—待核实]；提成的计算基数（销售额/利润，口径是否定义）、
   提成期限、对账与审计权；入门费与里程碑付款的挂钩；税费与发票。
6. **违约与解除**：违约情形是否覆盖技术合同特有形态（交付不合格、
   进度迟延、泄密、权属瑕疵）；解除后果——已交付资料的处理、已
   付款项的结算、已产生成果的归属与继续使用；合同解除或终止后
   保密义务与成果使用限制的存续。
7. **管辖与争议解决**：法院或仲裁、地点，对照画像首选管辖；技术
   合同纠纷的管辖特点 [模型知识—待核实]；涉外因素的准据法（按
   G3 处理）；主合同与技术附件、保密附件的一致性。

红线扫描：全量对照docs/scenes/contract-review-cn.md A8.1 的 blocks 与画像红线。技术
合同场景的高发区：借技术合作外观转移职务成果、规避技术进出口管制、
以虚假技术指标订立合同。命中即停止并明示。

### 第 5 步：分桶 🟢🟡🔴

- **🟢 可推进**：七类全部落在经律师审定的 playbook 立场内；默认
  模板立场最高 🟡。
- **🟡 需修订或需人判断**：偏离 playbook 但可修；playbook 未覆盖；
  命中 Scope check 藏条款；成果归属复杂需升级。
- **🔴 不得推进**：命中 blocks 红线或画像审批底线；或条款组合构成
  重大不利且不可经修改补救（如受托方视角下「背景 IP 被裹挟 + 无
  限侵权担保 + 无上限赔偿 + 验收标准主观化」的组合）。
- **双轴标注**：每项同时按 G9 给法律风险轴（🔴🟠🟡🟢）与商业摩擦轴
  （阻碍/拖慢/费解/无感）。分桶时先看组合、再看单项。

### 第 6 步：输出 memo

使用统一 triage memo 模板（见下方）。执行摘要只放机械性一行修改；
凡是需要起草新语言的（重写成果归属条款、补验收程序），建议栏只写
「**建议转法务起草**」，不在 memo 里代拟。

### 第 7 步：后果门与收尾

- 结论含 🔴：memo 首页明示「**本合同不提交签署流程、不向相对方作出
  任何承诺**」，按 G5 生成「带给律师的一页 brief」，非律师用户到此
  停止。
- 结论 🟢 且用户为非律师：进入签署流程前按 G5 动作闸门——显式确认
  知悉后果并获得明确指令，同时生成律师 brief；含糊回应不放行。
- 结论 🟡：逐条建议，改完复审。
- 含里程碑日期、许可期限、保密期限、提成对账周期的：提示并经用户
  同意后调用 `renewal-tracker` 登记 contracts/renewal-register.yaml。
- 全部条文引用过 `citation-audit`（G10）；未核验的保持 [CITE:__]
  占位，FAIL 状态不得外发。

## 输出模板

```markdown
【保密标头：按 G4 二选一——律师「保密·内部法律分析」/ 非律师
「研究备忘——不构成法律意见，使用前请经执业律师复核」】

# 技术合同审查 memo：<合同名称>

## Reviewer note
- 来源：<文本清单（合同/技术附件/里程碑计划）及来源标注；合同类型
  判定（开发/转让/许可/咨询/服务）；playbook 立场 [已确认—日期，
  是否经律师审定]>
- 已读：<全文 / 指定范围；缺件说明>
- 标记：结论 🔴 不得推进 / 🟡 需修订或需人判断 / 🟢 可推进；
  单项 = 法律风险轴（🔴🟠🟡🟢）× 商业摩擦轴（阻碍/拖慢/费解/无感）
- 时效：<法律状态核查日期；未核验写"未核验">
- 使用前注意：<去向限制；非律师用户注明"本 memo 不是法律意见"；
  超阈值或含涉外因素时注明"已触发升级">

## 执行摘要
<若类型异常或含藏条款，第一行必须是：本合同名为 XX 合同，实际含有
XX 安排 / 实为 XX 合同>
<三句话以内：合同类型与立场、总体结论、最关键的一件事>
<机械性一行修改清单；需起草的只写"建议转法务起草">

## 标记项
| # | 条款位置 | 问题 | 法律风险轴 | 商业摩擦轴 | 建议改法 | 依据 |
| --- | --- | --- | --- | --- | --- | --- |
| 1 | 第 X 条 | <问题> | 🔴/🟠/🟡/🟢 | 阻碍/拖慢/费解/无感 | <一行修改 或 "建议转法务起草"> | [CITE:__] |

## 通过项（简表）
<符合 playbook 的条款，一行一条>

## FYI
<偏离市场惯例但合法的记录>

## [需复核] 清单
<全文内联 [需复核] 项的汇总（G8）>

## 下一步
<按第 7 步后果门的决策树展开>
```

## 常见误判与边界提示

1. **把「技术开发」当「软件开发外包」一锅端**：需求变更机制与验收
   客观化是此类合同的第一高发争议；验收标准写「达到甲方满意」的，
   至少 🟡。
2. **背景 IP 一刀切条款**：「为履约产生的一切成果（含已有技术）归
   甲方」会把受托方多年积累裹挟进去——归属条款必须按背景/前景/
   改进三层拆开检查。
3. **职务成果与人员风险**：成果实际由对方员工完成、权属链条（劳动
   关系下的职务成果归属 [模型知识—待核实]）未核的，受让方/委托方
   视角单列标记项。
4. **提成口径不定义**：「按销售额提成」不定义销售额口径（含税与否、
   退货扣减、关联方销售）的，执行期必起争议。
5. **进出口管制漏判**：技术跨境时只审合同条款、不提示进出口管理，
   是漏报——涉外因素一律触发 B5 升级（G12）。
6. **组合判断提示**：单条看不严重的条款组合起来可能构成 🔴——典型
   如委托方视角下「付款前置 + 验收标准主观 + 成果归属约定不明 +
   受托方责任上限极低」的组合。分桶先看组合、再看单项。

## 本技能不做什么

- 不代拟技术合同条款语言——需起草的一律「建议转法务起草」。
- 不凭默认值给 🟢：playbook 未经律师审定时，结论天花板是 🟡。
- 不设硬编码阈值（提成比例多少算高、保密期限多长算长），一切比对
  画像/playbook 立场。
- 不就技术进出口合规、专利有效性下结论——触发升级，交律师与专项
  核查。
- 不替用户做技术路线或交易决策，只标风险与摩擦。
- 不处理 🔴 事项的后续（不出绕行方案，生成律师 brief 后停止）。
- 不做法律意见陈述：对非律师用户的全部输出受 G5 UPL 门控。
- 不直接手改画像：现场取得的立场经 `customize` 写回。

## 收尾与下一步

1. memo 交付后按第 7 步后果门分流：🔴 停止并转律师；🟡 修订后复审；
   🟢 走 G5 显式确认 + 律师 brief。
2. 含里程碑/许可期限/保密期限/对账周期 → `renewal-tracker` 登记
   contracts/renewal-register.yaml。
3. 全部引用过 `citation-audit`；条文原文经 `statute-verify` 核验
   （重点：第八百五十一条起的类型化规则、成果归属法定默认规则）。
4. 需要业务方版本 → `contract-summary`（Quiet mode；上游严重度只作
   下限，降级须声明理由——G9）。
5. 长期研发合作的，提示经 `matter-workspace` 建档，后续变更、补充
   协议挂同一事项 slug。
6. 审查中发现画像技术合同立场缺失或覆盖不全的，提示经 `customize`
   完善 playbook——playbook 越完整且经律师审定，未来给出 🟢 的
   空间越大。