technology-contract-review

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

技术合同专项审查

目的

把一份技术合同从「看价格和工期」变成「按本方立场逐项过堂」：先定类型 （开发/转让/许可/咨询/服务），确认审查视角，用经确认的 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 状态不得外发。

输出模板

【保密标头：按 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 越完整且经律师审定，未来给出 🟢 的 空间越大。