infometa 合同 · 场景识别与意图路由
这是合同专家的第一道工序。每次接到用户的合同类需求，都必须先用本 skill 完成"识别意图 → 命中场景 → 锁定输出标准与工作流 → 判断是否需要交互采集"，再进入后续工序。不要跳过本步骤直接起草/审查。
本 skill 解决什么
把用户一句自然语言的需求，转化为一份明确的「合同任务单」，包含：
- 命中的合同场景（来自 C1–C9 场景决策表）
- 该场景的核心应用目的、输出标准、典型工作流
- 是否需要交互采集：合同工作高度依赖交易细节，绝大多数场景需先采集；判断是否进入
contract-intake - 输出档位与交付形态：写明【输出档位】【交付物形态】【下一步技能】
- 是否有需向用户澄清的关键缺口
工作步骤
第一步：识别基础意图（六大基础意图）
先把用户需求归入以下一类，决定工作的"形状"：
| 基础意图 | 特征 | 主导工序 |
|---|---|---|
| 体系搭建 | 建管理架构、管理制度、模板库 | 生命周期顾问 / 起草引擎 |
| 合同生成 | 起草具体合同、补充协议 | 起草引擎 |
| 合同审查 | 审合同、评估签约背景与风险 | 审查引擎 |
| 谈判支持 | 制定谈判策略、要价让步 | 生命周期顾问 |
| 履行处置 | 履行中违约/纠纷的非诉应对 | 生命周期顾问 |
| 简易咨询 | 单点确认性合同问题 | 直接回答或轻量检索 |
第二步：命中具体场景（查决策表）
打开 references/contract-scenario-table.md，用「场景快速判别索引」把需求精确命中到某个三级场景（C1–C9）。命中后，锁定该场景的四件事：
- 核心应用目的（要达到什么）
- 输出标准（最终成果长什么样）
- 典型工作流（按什么步骤做）
- 输出档位与交付形态：按决策表写入【输出档位】【交付物形态】【下一步技能】
第三步：判断是否需要交互采集（关键）
合同工作几乎都依赖具体交易事实。按下表判断是否先进入 contract-intake：
| 场景 | 是否强制交互采集 | 必须先收集的关键事实 |
|---|---|---|
| C1 合同管理架构 | 是 | 组织架构图、核心业务线、各部门岗位职责 |
| C2 合同管理制度 | 是 | 现状（有无系统）、管理目标、痛点、合同类型分布 |
| C3 合同模板库建设 | 是 | 核心业务场景、需建模板的合同类型 |
| C4 具体合同起草 | 是 | 商业目的、资金流向、各方权责、商业预期与底线 |
| C5 合同背景评估 | 是 | 交易主体、交易类型、标的、金额、行业、特殊背景 |
| C6 合同条款审查 | 是 | 待审合同文本、本方立场口径、合同背景/特殊需求 |
| C7 合同谈判支持 | 是 | 本方交易地位、核心诉求与底线、冲突点 |
| C8 合同纠纷应急处置 | 是 | 案情时间线、已签合同与证据材料、对方反应 |
| C9 合同变更增删 | 是 | 原合同文本、要变更的条款与诉求 |
原则：信息不足先采集，绝不臆造。但能用互斥假设覆盖的（如"按已书面约定/仅口头约定"两分支），可在任务单中标注由后续工序并行假设，不必每次都停下追问。
第三·二步：判断是否需要接入用户标准（起草/审查类）
命中**起草类（C3/C4/C9）或审查类（C5/C6）**场景时，在任务单中标注是否走 contract-standards-ingest：
- 用户已附/已提及自有模板、范本、惯用条款、规则库、审查 Playbook、过往审查意见 → 标注【接入用户标准：是】，转化为条款库/审查 Playbook 后优先采用。
- 用户未提供 → 标注【接入用户标准：待告知】，在 intake 阶段或开工前主动一句话告知此能力可用，由用户选择是否提供；不提供则用通用标准，不强制。
第四步：输出合同任务单
以如下结构小结，交给下一工序。任务单不是最终成果；输出后必须按【下一步技能】逐个交接：
【命中场景】C4 具体合同起草
【基础意图】合同生成
【核心目的】为既有模板无法匹配的特殊合作量身起草完整合同
【输出标准】完整合同文本 + 特殊条款 + 风险批注
【是否交互采集】是 —— 需收集：商业目的/资金流向/各方权责/商业预期与底线
【输出档位】重量：完整合同文本（交付物）
【交付物形态】合同文本（含风险批注）
【下一步技能】contract-intake → contract-legal-research → contract-drafting-engine → contract-output-formatter
【关键缺口】交易频率与复杂度未知 → intake 中确认以选择合同结构套餐
输出档位与交付形态
档位按交付目的与成果分量判断，不按单个样例硬编码：
| 输出档位 | 典型交付形态 | 是否需交互采集 |
|---|---|---|
| 轻量 | 单点合同知识咨询、条款含义解释 | 通常否 |
| 中量 | 合同背景评估意见、谈判要点、补充协议、单类模板 | 是 |
| 重量 | 完整合同文本、合同审查意见书/风险清单、管理制度、模板库体系、纠纷非诉处置方案 | 是 |
重量级场景任务单必须写明完整技能链，并经交互采集补齐关键事实后再进入实质工序。
关键约束
- 场景识别只做判断与规划，不做实质起草/审查。
- 不确定命中哪个场景时，宁可向用户确认一句，也不要错判导致输出标准跑偏。
- 用户一个需求可能横跨多个场景（如"先评估这个合作要点、再帮我起草"= C5 + C4），允许命中多个场景并在任务单中按先后列出。
- 合同工作几乎都要交互采集；除非是单点知识咨询，否则不要在信息不全时直接产出合同/审查结论。
References
references/contract-scenario-table.md— 合同场景决策表（C1–C9：场景分类/二级/三级场景 × 核心目的/输出标准/典型工作流/提问示例 + 快速判别索引 + 档位规则）