infometa 知产 · 场景识别与意图路由
这是知产专家的第一道工序。每次接到用户的知识产权类需求，都必须先用本 skill 完成"识别意图 → 命中场景 → 锁定输出标准与工作流 → 映射专业数据库 → 判断是否需要交互采集"，再进入后续工序。不要跳过本步骤直接检索/分析/起草。
本 skill 解决什么
把用户一句自然语言的需求，转化为一份明确的「知产任务单」，包含：
- 命中的知产场景（来自 IP-A~IP-F 场景决策表）
- 该场景的核心应用目的、输出标准、典型工作流
- 专业数据库映射：本场景要用到哪些专业知产库（DB 编号），哪些可自动化、哪些需用户手动查询
- 是否需要交互采集：知产工作高度依赖具体标的与事实，绝大多数场景需先采集
- 输出档位与交付形态：写明【输出档位】【交付物形态】【下一步技能】【核验工作台】
- 是否有需向用户澄清的关键缺口
工作步骤
第一步：识别基础意图（六大基础意图）
先把用户需求归入以下一类，决定工作的"形状"：
| 基础意图 | 特征 | 主导工序 |
|---|---|---|
| 检索查询 | 查专利/商标/作品状态、布局全景、近似排查 | research + analysis-engine |
| 确权判断 | 是否构成作品/商业秘密、权属归谁、可注册性、三性 | analysis-engine |
| 侵权/FTO 研判 | 是否侵权、FTO、混淆可能性、无效理由 | analysis-engine（技术特征/近似/要件比对） |
| 策略与方案 | 申请/布局/许可/维权/抗辩/无效/管辖/战略 | drafting-engine |
| 申请与文书 | 专利申请文件、答复文书、登记材料 | drafting-engine |
| 简易咨询 | 单点确认性 IP 知识问题 | 直接回答或轻量检索 |
第二步：命中具体场景（查决策表）
打开 references/ip-scenario-table.md，用「场景快速判别索引」把需求精确命中到某个三级场景（IP-A~IP-F）。命中后，锁定该场景的五件事：
- 核心应用目的（要达到什么）
- 输出标准（最终成果长什么样）
- 典型工作流（按什么步骤做）
- 专业数据库映射（该场景末尾【专业库】字段，去哪些库、查什么）
- 输出档位与交付形态：按决策表写入【输出档位】【交付物形态】【下一步技能】
第三步：判断是否需要交互采集（关键）
知产工作几乎都依赖具体标的与事实。按决策表每个场景的「是否交互采集」判断是否先进入 ip-intake：
原则：信息不足先采集，绝不臆造权利事实（专利号/商标号/软著登记号/作品/当事人）。但能用互斥假设覆盖的（如"按已书面约定/仅口头约定"两分支、"权利人立场/被控方立场"两视角），可在任务单中标注由后续工序并行假设，不必每次都停下追问。
第三·二步：确认立场口径（侵权/维权/抗辩类必做）
命中侵权认定、维权、抗辩、异议应对、无效等对抗性场景时，必须在任务单中标注本方立场：权利人（维权） 还是 被控侵权方/被申请人（抗辩）。立场不同，分析方向和结论可能完全相反。
第三·三步：标注专业数据库落地方式
按命中场景的【专业库】映射，在任务单标注每个库的落地方式：
- 可自动化（有 MCP/Skill/公开可抓取网页）→ 标注【自动检索】，由
ip-legal-research直接调用。 - 需登录/验证码/付费/仅人工可查（如中国商标网、专利业务办理平台、版权登记系统等官方权属库多数需登录）→ 标注【手动查询指引】，由
ip-legal-research生成面向用户的查询步骤（网址+入口+检索字段+操作），让用户自查后回填，绝不谎称已查询。
第四步：输出知产任务单
以如下结构小结，交给下一工序。任务单不是最终成果；输出后必须按【下一步技能】逐个交接：
【命中场景】IP-B10 专利侵权认定分析（FTO）
【基础意图】侵权/FTO 研判
【立场口径】被控侵权方（抗辩）
【核心目的】判断被控产品是否落入涉案专利保护范围，排查抗辩事由，给出应对策略
【输出标准】侵权定性结论 + 权利要求比对分析表 + 适用判定原则 + 抗辩事由排查 + 应对建议 + 律师复核提示
【是否交互采集】是 —— 需收集：涉案专利号/权利要求、被控产品或方法技术特征、收到的起诉状/侵权主张
【专业库】DB8 专利检索与分析系统【自动检索】、DB5 审查信息【手动查询指引】、DB13/DB14 现有技术【自动检索】
【输出档位】重量
【交付物形态】专利侵权认定法律意见书（+核验工作台 HTML）
【核验工作台】必用
【下一步技能】ip-intake → ip-legal-research → ip-analysis-engine → ip-drafting-engine → ip-output-formatter → ip-verification-workbench
【关键缺口】被控产品的完整技术特征未知 → intake 中逐项收集以做权利要求比对
输出档位与交付形态
档位按交付目的与成果分量判断，不按单个样例硬编码：
| 输出档位 | 典型交付形态 | 是否需交互采集 | 核验工作台 |
|---|---|---|---|
| 轻量 | 单点 IP 知识咨询、概念解释 | 通常否 | 不启用 |
| 中量 | 检索比对报告、注册可行性评估、年费/续展建议、管辖建议 | 是 | 一般不启用（除非用户要正式报告） |
| 重量 | 侵权/FTO 分析意见、无效策略、维权方案、申请文件撰写、战略规划、尽调报告、体系建设方案 | 是 | 必用 |
重量级场景任务单必须写明完整技能链，经交互采集补齐关键事实后再进入实质工序。
关键约束
- 场景识别只做判断与规划，不做实质检索/分析/起草。
- 不确定命中哪个场景时，宁可向用户确认一句，也不要错判导致输出标准跑偏。
- 用户一个需求可能横跨多个场景（如"先评估商标注册可行性、再帮我做布局"= IP-C3 + IP-C2；"先判断是否侵权、再定维权"= IP-C8 + IP-C9），允许命中多个场景并在任务单中按先后列出。
- 知产工作几乎都要交互采集；除非是单点知识咨询，否则不要在信息不全时直接产出结论。
- 对抗性场景务必先定立场口径。
- 专业库映射务必区分自动检索与手动查询指引，为下游
ip-legal-research的数据库落地做好准备。
References
references/ip-scenario-table.md— 知识产权场景决策表（IP-A~IP-F 六大板块共 44 个三级场景 × 核心目的/输出标准/典型工作流/提问示例/专业库映射 + 快速判别索引 + 档位规则）