pps-report — 专利全景报告层（环节 4/4）

自报家门： 我是环节 4/4（环节4）。上游是环节 2/4 pps-stats（环节2 统计 + 价值信号）、环节 3/4 pps-tag（环节3 标引体系 + 推荐包），以及环节 3.5 客户 SaaS 全量标引回流的 tagged_pool.csv。我是流水线的终点,产出交付给客户。

目的

环节4 将结构化专利分析转化为业务可读的报告。

它回答：

• 与决策相关的核心发现是什么？

• 哪些趋势、玩家、分支和专利包最重要？

• 技术随时间如何演进，哪些专利族标志着每次转向？ （技术演进路线）

• 可防御的护城河在哪里——哪些分支集中了承载价值的信号？ （护城河 / 价值交叉）

• 每个判断由什么证据支撑？

• 哪些内容仍不确定或需要专家复核？

环节4 是报告与综合层，不应替代法律审查。

适用场景

在以下条件满足后使用 /pps-report：

• /pps-search 和 /pps-stats 已产出经验证的检索范围、统计结果、核心候选、价值信号和图表数据。

• /pps-tag 已产出 tech_breakdown.json、 key_questions.json 和 patent_packages.csv，或模式 A 中已有足够支撑报告的 SaaS 回流 tagged_pool.csv。

• 用户已确认报告目标和受众。

tagged_pool.csv（环节 3.5 客户 SaaS 全量标引回流）若已就位则报告完整；缺席时 环节4 降级为「仅基于推荐专利包 + 统计」的报告。

适用于：

• 单文件 HTML 报告。

• 报告大纲。

• 证据登记表。

• 推荐专利包摘要。

• 局限与下一步说明。

不要用于正式 FTO、侵权、SEP 必要性、有效性、新颖性或创造性意见。

输入

契约输入（ARCHITECTURE.md 第2节 环节2 / 环节3 / 环节 3.5 → 环节4）。

运行模式 A vs B（标引后默认 A）

环节 3.5 客户 SaaS 标引回流 tagged_pool.csv 后，环节4 有两种跑法。 默认走 A （标引池信息已足够丰富，可直接产报告，省去补造上游 环节3 推荐包的迭代）：

模式 A 的字段替代关系 （ tagged_pool.csv 列 → 环节4 用途；列名随 SaaS 导出，执行前先 head -1 核对）：

模式 A 三条口径（已与用户确认）：

1. 层级兼容、二级优先： 报告方案兼容 2 层 / 3 层；本批数据只到 Level 2， 优先做好二级展示 ，二级即最细分支；保留三级钩子，将来 tagged_pool.csv 出现 Level 3 列能自动下钻。

2. 允许多标签重复计数： 一件专利的技术分类列可能含多个值（换行分隔，Level 1 / Level 2 同理）。§5 技术矩阵按这些标签展开计数，一件可计多次，报告 显著标注「分类计数 ≥ 专利数」 。这是正常情况，不去重为单值。

3. 族级去重用 简单同族编号： 计数前先按 family_id 去重（公开号级 → 族级）。本批每件各自成族，去重后数量不变，但 schema 上仍按族级处理。

模式 A 下 §6 / §10 的降级：

• §6 演进路线：缺 环节3 key_questions 时， 用一级分类作为演进分支 。取族口径（已在大模型联盟 run 验证，避免明星专利劫持不相关分支）：① 先拆多标签——Level 1 / Level 2 单元格可能含换行多值，按 \n 拆开并 strip('"') 清残留引号；② 每个一级分支圈定其 主导 Level 2 子分支集 （对齐 §5 矩阵 Top 2–3），代表族必须 Level 1 命中该分支 且 Level 2 落在该子分支集内（用 (Level 1, Level 2) 配对，不能只看 Level 2，因 Level 2 词表跨一级共享）；③ 按公开年分早（≤2024）/ 成型（2025）/ 前沿（2026）三段， 段内取被引最高 ， 三段间用全局 used 集禁止同族复用 ，并 软轮换主导玩家 （优先选本路线尚未出现的申请人，让中小玩家在其被引占优段露出；实在没有再放开）；④ turning_point{type,note} 与 phase_caption 取自该代表族自身的「技术问题 / 技术手段」标引字段 ，不脑补：首段= 关键专利出现，玩家变更段= 玩家入场，玩家延续段= 性能跃迁。仍配 evolution_overview + route_summary + phase_caption，不虚构空段。⚠️ 软轮换会让中小玩家偏向露在其被引占优的时段， evolution_overview 须注明这是取样算法效果、非真实布局时点。

• §10 推荐专利包：缺 环节3 patent_packages.csv 时， 从 tagged_pool 自动精选 ——每个二级分支取「被引最高 + 同族最宽」2–3 件，按 §10 给 use_case / purpose_tag / answers_question + package_summary；明确标注为自动精选、非人工 rubric 评审（脚注层标 L4）。

• 报告头部声明：「模式 A · 标引池直驱；§6/§10 部分为标引池字段的自动派生，非 环节3 人工评审」。

输出

契约输出（ARCHITECTURE.md 第2节 环节4 输出契约）。

可选输出：

• evidence_register.json — 关键发现背后的证据条目（也可内嵌进 report_manifest.json）

• report_limitations.md — 局限说明

• recommended_patent_package.csv — 推荐专利包的可读副本

与 环节2 panorama_stats_report.html 的区别： 环节2 出的是 统计快照（数据视图） ——只可视化「数到了什么、聚合了什么」；环节4 出的 report.html 是 洞察报告（分析视图） ——演进路线、护城河解读、布局建议。两者共用同一套样式契约（见下），但定位不同,不可混淆。

报告结构（默认模块；随数据完整度调整）

默认模块可根据数据完整度和交付目的合并、改名或压缩。v0.2 样例使用 10 个章节：执行摘要 / 范围方法 / 格局 / 技术矩阵 / 演进路线 / 功效分布 / 问题场景 / 护城河 / 推荐包 / 附录边界。

节序决策（已确认）： 演进路线紧跟技术矩阵之后（§6） ——先看静态结构再看动态走向； 护城河紧接在推荐专利包之前（§9） ——先讲清价值在哪集中,再给出可落地的推荐包。

§6 技术演进路线（新增模块）

从 key_questions.json 的关键技术问题出发,为每条问题织一条时间轴。 演进路线不只是把专利族排成时间轴——必须配"看了之后所以呢"的总结 ,所以采用自顶向下三层总结结构:

三层总结结构（自顶向下）：

取族与排序：

• 种子： 每个 key_question 的 seed_node_ids[] → 落到 tech_breakdown.json 的三级节点。

• 取族： 在 tagged_pool.csv（或缺席时 patent_index.core.*）里按这些三级分类取代表专利族, 每条演进路线 ≥3 族 ,沿公开日 / 优先权日排序成「早期 → 当前 → 前沿」三段。

• 每族标注： publication_number、normalized_assignee、公开年、所属三级节点、 结构化转折点 (见下)。

转折点要说清"为什么是转折"： 每族的 turning_point 从一句模糊感想改为带类型枚举:

turning_point:
  type: 路线分叉 | 关键专利出现 | 玩家入场 | 性能跃迁 | 场景迁移
  note: 一句话说明,点出转折转的是什么

• 不虚构时间点： 没有族落在某时间段就如实留空, route_summary 不脑补「过渡技术」或不存在的过渡阶段。

• 可视化： 用 HTML/CSS/SVG 或内联 JS 绘制横向时间轴，每条一级分支一行； route_summary 显示在该行时间轴上方， phase_caption 显示在三段分隔处， evolution_overview 显示在章节开头。禁止外部 D3/CDN 依赖。

§7 技术功效分布（新增模块）

调用 /3fd502 technology_effect_distribution,出「技术手段 × 功效改进」矩阵:

• 数据源： 对候选池检索式跑一次 technology_effect_distribution,结果落进 chart_data.json。

• 可视化： 用 HTML/CSS/SVG 或内联 JS 绘制气泡 / 热力矩阵，横轴功效维度、纵轴技术手段、气泡大小=族数。禁止外部 D3/CDN 依赖。

• 标注： 标 /3fd502 信号,非验证后结论;空白格如实标「该手段-功效组合在本数据集下无显著族」。

§9 护城河 / 价值交叉（新增模块）

把 value_signals.json 的 候选级 分数聚合成 分支级护城河主题 （环节2 显式不做此聚合,留给 环节4）:

• 聚合方式： 按 branch_id 汇总该分支下候选的 citation_signal / family_signal / legal_signal / competitor_concentration_signal / portfolio_value_signal / most_asserted_signal,得到分支级护城河强度。

• 解读： 哪些分支同时高被引 + 大同族 + 高竞品集中 → 高护城河;哪些分支信号稀薄 → 蓝海或未成熟。

• 诚实标注： 默认采信路径下 citation/family/legal 为 recall 信号代理,标 recall_proxy;只有 verified 记录用真实值。聚合分是 信号 ,不是估值,不构成法律结论（L5）。

• 可视化： 分支级护城河雷达 / 堆叠条形,signals_fired 透明展示。

§10 推荐专利包（用户视角重构）

核心原则：推荐理由必须是「用户视角」,不是「分析师视角」。 环节3 patent_packages.csv 的 recommendation_reason 是六项技术属性 rubric( disruptive_technology / novel_function …),回答的是「我们为什么从数据里挑中它」;客户真正要的是「我拿到它能干嘛」。 环节4 在渲染时做一层翻译,不改 环节3 schema。

双层呈现： 主层用客户语言,数据信号下沉脚注(见「双层渲染规则」)。

环节4 翻译产出的三个用户视角字段：

rubric + value_signal → purpose_tag 映射规则：

映射是 启发式推断 ,标 L4(recommendation),环节3 原始 rubric 保留在脚注层可追溯。映射不命中时 purpose_tag 留「待人工判定」,不硬塞。

整包加「这个包是干嘛的」： 每个 sub_domain 包顶部加 package_summary(一句话):这一包集中解决什么 + 推荐优先看哪 1–2 件。

最终推荐卡片结构(双层)：

【主层 · 客户语言】
  ▸ use_case:         "建议用于 监控竞品 —— 覆盖 XX 技术,是 [竞品] 的核心卡位"
  ▸ purpose_tag:      [监控竞品]   ← 彩色 chip,可按标签筛选推荐包
  ▸ answers_question: "回答关键问题 Q3:如何降低端侧推理时延"
【脚注层 · 可展开 ⓘ 角标】
  ▸ rubric:           major_performance_gain（环节3 原始推荐依据）
  ▸ evidence:         同族 18 国 · 被引 42(recall_proxy) · 法律有效 · refered_rank top
  ▸ 免责:             信号仅供参考,不构成 FTO / 许可建议（L5）

证据级别

一致使用以下级别：

报告中的每个重要判断都应映射到一个或多个证据条目。

证据登记

evidence_register.json 应使用如下条目：

{
  "evidence_id": "E-001",
  "level": "环节1 data fact",
  "claim": "在标引池中，Agent workflow 专利是最大的标引组。",
  "source_file": "tagged_pool.csv",
  "source_field": "tech_level_2",
  "counting_method": "记录级单值标签（由脚本聚合，不逐行读入上下文）",
  "limitations": "标签是由 SaaS 工具应用的环节3分类标签，不是法律结论。"
}

推荐专利包

用户视角优先(见 §10 设计段)。 每件推荐专利的主层呈现 use_case + purpose_tag + answers_question(客户语言:能干嘛、归哪类用途、回答哪个关键问题);每个 sub_domain 包顶部有 package_summary。

下列筛选/排序标准是 分析师视角的选取依据 ,作为脚注层的可追溯证据,不作为主文案:

• 与优先分支的相关性。

• 技术问题和解决方案的清晰度。

• 同族宽度或地域信号。

• 法律状态信号。

• 有意义时的引用信号。

• 可用时的官方 refered_rank、 famn_rank、 most_cited 或 portfolio_value 信号。

• 申请人的代表性。

• 是否已进行权利要求/说明书审阅。

未经专家审查，不要建议收购、许可、维权或 FTO 行动。

HTML 报告规则

• 保持报告自包含。

• 说明数据来源、日期、地域和计数方法。

• 区分官方全景统计、本地规则命中近似值和环节3验证标签。

• 将规则命中数量标记为近似值。

• 将标引分布标记为环节3标签，而不是法律结论。

• 除非已通过底层专利记录验证，否则将 /3fd502 的价值、诉讼、引用和功效输出标记为信号。

• 在相关分析附近写明局限，不只放在文末。

• 在附录中链接或列出所有数据资产。

HTML 骨架与样式契约

样式事实来源： skill/patent-panorama-insights/references/report-visual-style.md。 report.html 与 环节2 的 panorama_stats_report.html 共用同一套 CSS 变量、字体、组件与图表表达原则 ，避免两套色板漂移。当前视觉证明为 examples/大模型联盟专利洞察/outputs/report.html。

• 自包含： 单文件、CSS/数据全内联、无外部 CDN/D3、离线可双击打开。数据从落盘 JSON/CSV 预聚合后写入 HTML，不读外部文件、不逐行读 tagged_pool.csv（按脚本预聚合后只注入聚合结果）。如确需交互，JS 必须内联且可降级。

• CSS :root 变量（逐字照抄现有报告）： --bg:#ffffff; --bg-soft:#f7f9fc; --bg-mid:#eef2f8; --accent:#1d4ed8; --accent2:#0891b2; --accent3:#059669; --gold:#d97706; --red:#dc2626; --text-primary:#111827; --text-secondary:#374151; --text-muted:#6b7280; --border:#e5e7eb; --card-bg:#ffffff; --card-bg2:#f9fafb; --tier2-bg:rgba(29,78,216,0.05); --tier3-bg:rgba(217,119,6,0.05);

• 字体： 'Segoe UI', -apple-system, BlinkMacSystemFont, 'PingFang SC', 'Microsoft YaHei', sans-serif； html font-size 13px。

• 组件： .report-header（双语标题 + tag-line + meta-row,border-bottom 2px solid var(--accent)）、 .kpi-strip / .kpi-card、 .section / .section-header（双语 section 标题）、tier chip（tier1=accent / tier2=accent2 / tier3=gold）、证据级别 badge（环节1–L5）、 purpose-tag chip（5 色,对应 5 个用途标签:监控竞品 / 规避设计参考 / 许可备选 / 自研借鉴 / 布局卡位,可点击筛选推荐包）、 evidence-footnote 折叠组件（ⓘ 角标展开,承载下沉的证据级别 + 数据信号 + 免责） 。

• 双层渲染规则（§6 / §9 / §10 必须遵守）： 业务结论用主文案呈现(client-readable 语言: 是什么、所以呢、能干嘛 );环节1–L5 证据级别 badge、数据信号(被引数 / 同族宽度 / recall_proxy / refered_rank / rubric)、免责声明统一收进 可展开的 ⓘ 角标 / evidence-footnote 折叠脚注 ,不在主文案行平铺。让客户先读懂结论,需要深究再点开证据,避免信号过载淹没结论。

• 图表： 优先 HTML/CSS/SVG 静态表达，必要时用内联 JS；禁止外部 D3/CDN。覆盖趋势 + 地域、竞品卡片、技术矩阵、演进时间轴、技术功效矩阵、护城河/价值信号、推荐包表。

• 头部声明： report-header 注明定位「洞察报告（分析视图）」+ scope/日期口径/族级口径/数据截止日/MCP 出处;若 tagged_pool.csv 缺席,头部显著标注「标引数据未回流,报告降级为仅基于推荐专利包 + 统计」。

输出

落盘后在对话里只留一行 report.html written (N sections, N charts) + report_manifest.json, 不回贴 HTML 内容 。

边界

不要输出：

• 正式 FTO 意见。

• 侵权意见。

• 有效性意见。

• SEP 必要性意见。

• 新颖性或创造性法律意见。

• 没有证据支持的业务判断。

在适当位置使用 “patent signals suggest”、“under this dataset” 和 “requires legal review” 等措辞。

下一步

我是环节 4/4(环节4),流水线终点。 report.html + report_manifest.json 落盘后,把交付物清单交回编排层 patent-panorama-insights,由其向用户汇报全景分析完成。

使用前配置

本 Skill 依赖智慧芽开放平台 MCP 服务：

• 完成安装、初次使用时需进行自检，参见 README.md

• 用户需完成账号授权，并确保 Agent 环境已启用对应 MCP 工具

• 若未完成配置，本 Skill 只能提供分析框架，无法检索实时数据或生成基于数据库的结论

• 缺少MCP配置时，引导用户参照 README.md 在 [ open.zhihuiya.com ]( https://open.zhihuiya.com/ ) 获取MCP。