专利申请文件质量审核工具（全量指标版）

功能概述

本工具（patent-quality-review-pro）是专利申请文件质量审核的全量指标版本：

• 全量评审模式 ：对所有评价指标统一评审，无重点/非重点分档

• 复审无效决定要点集成 ：结合 DP1–DP20 及 DP-C1~C3 辅助判断权利稳定性和撰写质量

• 领域权重自动切换 ：支持化学/机械/电学/通用四领域 AHP 权重方案

• 官方技能边界对齐 ：新颖性使用 Patsnap/智慧芽 novelty-check（ zhihuiya_novelty_lite MCP）并遵守单参考对比逻辑，创造性使用 non-obviousness-check 多参考组合逻辑

• 默认 HTML 输出 ：生成标准格式《专利申请文件质量评价表》，含主表+附表1，按需含附表2/附表3；用户明确要求 Word 时再额外生成 .docx

运行环境要求 ：默认 HTML 输出仅需 Python 标准库；仅在按需生成 Word 或二次局部编辑 .docx 时需要 python-docx 库。运行 Word 路径前必须确认当前 Python 环境已安装 python-docx，或使用 Codex bundled Python/manifest runtime 提供的依赖。

MCP 使用边界

• 本技能涉及公开专利文献、法律状态、无效/复审信息和证据链检索时，统一使用 Patsnap MCP（manifest 中 mcp_dependencies: ["patsnap"]）。

• 不再配置或调用其他专利检索类 MCP；若 Patsnap MCP 暂不可用，应降级为同目录附件和用户提供材料的有限评审，并在 evidence_mode、 legal_status_evidence 或最终回复中说明限制。

• 权利稳定性评审涉及复审无效信息时，应优先查询智慧芽高级专利数据的复审无效能力（ advanced-patent-data/re-examination-and-invalidation），以目标申请号、公开号、公告号、专利名称和案号交叉检索；查到案件后必须读取决定书内容，并抽取"案由、证据清单、证据认定、新颖性/创造性/公开充分评述、决定结果、受影响权利要求、决定日期和案号"。

• novelty-check 在本技能中由 Patsnap/智慧芽 zhihuiya_novelty_lite MCP 承担，用于权利稳定性中新颖性快速自查、候选 D1/D2/D3 检索和特征比对； non-obviousness-check 是创造性多参考组合判断子流程。

• 凭证安全：禁止将用户提供的 MCP URL、apikey、token、Authorization header、 sk- 密钥或任何认证凭证写入 SKILL.md、manifest、V2 JSON、HTML/Word 报告、附表、日志说明或最终回复；skill 只记录 MCP 能力名称、工具函数、调用顺序和查询结果，凭证必须由运行环境/连接器管理。

技术领域与 AHP 权重方案

收到专利文件后，必须先快速阅读摘要和独立权利要求，判断技术领域倾向，再向用户确认 AHP 权重方案。用户确认前不得进入完整评审。四套权重如下， scores 指标名称中的百分比和加权分必须随用户确认的领域同步变化。

评审标准（三档）

复审无效实践决定要点库（DP编号）

评审报告的问题描述中应明确援引 DP 编号，不得仅泛泛描述。DP 编号以本说明为准，禁止自行改写编号含义。

新颖性决定要点（DP1–DP4）｜归属：③权利稳定性

创造性决定要点（DP5–DP8）｜归属：③权利稳定性

充分公开决定要点（DP9–DP12）｜双重归属：③权利稳定性 + ⑦说明书充分公开情况

权利要求撰写决定要点（DP13–DP17）｜归属：①②③④⑧多指标共用

撰写质量对权利稳定性的综合影响（DP18–DP20）｜归属：②③⑤多指标共用

保护客体决定要点（DP-C1~C3）｜归属：②保护范围规划

评审维度与指标清单（全量8项）

本技能采用全量 8 项指标统一评审。除常规"权利要求是否获得说明书支持"的正向检查外，必须增加"说明书公开内容是否均已被权利要求保护"的反向检查，避免有价值技术方案因未写入权利要求而形成捐献风险。

一、权利要求书质量

1. 技术方案表述

   • [重要] 独立权利要求技术方案完整，能够解决说明书所述技术问题（援引 DP13）。

   • [重要] 独立权利要求各技术特征之间存在有机结合关系，而非简单罗列（援引 DP13）。

   • [重要] 权利要求书中各技术特征表述清晰，无歧义、无矛盾（援引 DP14）。

   • [一般] 使用准确技术术语，与说明书术语一致（援引 DP16）。

   • [一般] 独立权利要求中未使用含义不确定的相对性语言（援引 DP14）。

2. 保护范围规划

   • [重要] 独立权利要求包含解决技术问题所必需的全部必要技术特征（援引 DP13）。

   • [重要] 保护范围适当，不含非必要技术特征，范围既不过宽也不过窄（援引 DP18/DP19）。

   • [重要] 反向保护检查：逐项核对说明书发明内容、具体实施方式、附图对应结构、优选/进一步方案、替代连接方式、参数范围、运动过程和效果实现路径，确认有价值技术点是否进入独立权利要求或从属权利要求；未覆盖时识别捐献风险（援引 DP18）。

   • [一般] 未引入多余的技术方案限制，保护范围留有合理空间。

   • [机械重点→重要] 独立权利要求无纯功能性限定，以结构特征为主。

   • [电学专属][重要] 方法/装置/系统/存储介质等保护客体区分清楚（援引 DP-C1/DP-C3）。

3. 权利稳定性（须执行 A→B 两步子流程）

   • [重要] 独立权利要求具备新颖性（援引 DP1/DP2/DP3/DP4）。

   • [重要] 独立权利要求具备创造性，不易被现有技术组合否定（援引 DP5/DP6/DP7/DP8）。

   • [重要] 权利要求覆盖范围与说明书公开内容匹配，无超范围风险（援引 DP11）。

   • [重要] 功能性限定特征有足够实施例支撑，整个保护范围均能实现（援引 DP10）。

   • [重要] 必须结合公开文献、无效决定、复审无效程序、法律状态和同目录附件进行稳定性判断（援引 DP18/DP19）。

   • [化学重点→重要] 参数发明提供了具体实现手段及可重现的测量方法（援引 DP12）。

   • [一般] 权利要求中不存在不清楚的相对性语言导致保护范围模糊（援引 DP14）。

4. 权利要求布局

   • [重要] 根据应用场景布局了相应方法/装置/系统权利要求。

   • [重要] 至少有一个独立权利要求能构成直接侵权。

   • [重要] 从属权利要求充分保护核心实施例，形成梯次保护。

   • [重要] 反向布局检查：说明书多个实施例、替代方案、优选范围、关键协同组合和效果实现路径，应有对应从属权利要求兜底；仅依赖独权宽泛概括而无退守从权时应扣分（援引 DP18/DP19）。

   • [电学专属][重要] 系统/方法/装置/存储介质四角度布局完整。

   • [一般] 独立权利要求数量适当，无不必要重复。

   • [一般] 从属权利要求引用关系正确，无多项引多项情形（CN实践）（援引 DP17）。

二、说明书质量

1. 背景技术论述

   • [重要] 背景技术引用了最接近的现有技术文献。

   • [重要] 背景技术清楚揭示了现有技术存在的缺陷和不足。

   • [一般] 背景技术论述不过度承认现有技术内容（援引 DP20）。

   • [一般] 引用文献格式规范，来源可查。

2. 技术问题与技术效果论述

   • [重要] 发明内容部分清楚说明了本发明解决的技术问题（援引 DP5/DP6）。

   • [重要] 技术效果表述客观，有说明书实施例/数据支撑（援引 DP6）。

   • [一般] 发明内容覆盖了所有独立权利要求对应的技术效果。

   • [一般] 技术问题与技术效果论述逻辑清晰，因果关系明确。

3. 说明书充分公开情况

   • [重要] 说明书详细描述了实现发明的最优实施方式，本领域技术人员无需创造性劳动即可实现（援引 DP9）。

   • [重要] 功能性限定特征在说明书中有足够实施方式说明，支撑整个保护范围（援引 DP10）。

   • [重要] 说明书实施例覆盖权利要求保护范围，无超出公开范围的保护（援引 DP11）。

   • [重要] 附图数量充足，清楚表达了技术方案的核心结构/流程。

   • [化学重点→重要] 参数发明在说明书中给出了可重现的具体实现手段及测量方法（援引 DP12）。

   • [一般] 说明书发明内容部分与权利要求书保持一致，未简单复制。

   • [一般] 摘要准确概括了技术方案的核心内容。

   • 反向保护检查中发现的"说明书提到但公开不足"的内容，不应直接建议纳入权利要求；应先指出公开不足，再判断是否适合补强为保护方案。

三、其他

1. 形式问题

   • [重要] 权利要求书格式规范，独立权利要求和从属权利要求格式正确。

   • [一般] 附图标记与说明书中的标号说明一致（援引 DP16）。

   • [一般] 非中文技术名词在首次使用时有中文注释。

   • [一般] 每项权利要求不含多个句号。

   • [一般] 全文用词前后一致。

   • 仅检查专利申请文件本身的形式质量；不评价本技能生成的评价表、评分字段、问题清单或输出结构，这些属于交付校验，不计入本指标。

权利稳定性③ — novelty-check 两步子流程

Step A：权利要求拆解

将独立权利要求拆解为特征元素清单 E1, E2, E3...，并对每个特征标注：

Step B：新颖性/创造性快速自查 → B3 三态结论

执行要求 ：

• 权利稳定性③可与其他指标并行评审，但必须最后汇总计入总分。

• 若 evidence_mode=full，新颖性须使用 novelty-check（Patsnap/智慧芽 zhihuiya_novelty_lite MCP）形成快速查新、候选文献和特征比对依据；最终新颖性判断仍遵守单参考对比原则。创造性使用 non-obviousness-check 多参考组合逻辑，并按证据链校验要求写入官方产物。

• novelty-check 推荐调用顺序： novelty_summary 提取技术三要素 → novelty_feature_extract 拆解技术特征 → novelty_keywords_extract 生成检索关键词/IPC → novelty_lite_search 检索相似专利 → novelty_feature_comparison 做特征比对 → novelty_lite_report_generate 生成新颖性/创造性快速评述。

• novelty-check 结果应写入或支撑： fetched_references、 artifact_paths、 d1_selection_rationale、 novelty_conclusion、 scores[2] 和 issues；但不得把快速评述机械等同为最终法律结论，仍需结合 DP1-DP4、法律状态、无效/复审记录、同目录附件和人工判断。

• 进入 novelty-check 之前，必须先查询复审无效信息：优先使用智慧芽高级专利数据复审无效能力（ advanced-patent-data/re-examination-and-invalidation）检索目标申请号/公开号/公告号/专利名称/案号；若命中无效或复审案件，先读取决定书内容并建立 legal_status_evidence，再决定是否仍需 novelty-check 和 non-obviousness-check 补充证据链。

• 若读取到无效决定、行政诉讼或同目录附件中的稳定性证据，应优先纳入 Step B 结论。

• 每发现一个 [重要] 级子项不满足，通常扣 10–15 分；每发现一个 [一般] 级子项不满足，通常扣 3–5 分。

默认输出格式（V2）

• 默认交付格式为 HTML。完成评审后必须先将 V2 JSON 写入文件，再调用 scripts/generate_html.py --data <V2 JSON路径> --output <目标HTML路径>；该脚本会先复用 review_validation.py 执行证据链与评分一致性校验，校验失败时不得交付报告。

• 仅当用户明确要求 Word、 .docx、可编辑 Word 文档、或需要对既有 Word 报告做局部编辑时，才调用 scripts/generate_word.py 或使用 python-docx 处理 .docx。

• HTML 与 Word 必须使用同一份 V2 JSON 数据；不得为不同格式分别构造两套评价数据。

• 默认最终回复返回 HTML 文件路径；若用户同时要求 Word，则同时返回 .html 和 .docx 路径。

HTML 输出格式规格（V2，默认）

• HTML 输出应与 Word 主表结构一致，使用同一份 V2 JSON 数据，不得另造旧版 indicators 数据结构。

• 内容格式框架硬性要求 ：正式 HTML 的内容框架必须严格沿用本技能 V2 主表+附表结构，禁止改成摘要报告、段落式分析、卡片式页面、旧版 indicators 表、只列总分不列8项指标、或把权重单独拆成另一张表。主表必须先展示基本信息，再展示评分表和总分/结论；评分表必须按"评价指标 / 得分 / 加权得分 / 主要问题描述"四列呈现；附表1必须按"序号 / 严重程度 / 问题名称 / 涉及位置 / 问题描述 / 修改建议"六列呈现；若存在 fetched_references 必须输出附表2，若存在 dp_cited 必须输出附表3。

• 评价指标与权重呈现硬性要求 ：评分表中的8项评价指标必须逐项显示为 ①技术方案表述（X%）、 ②保护范围规划（X%）、 ③权利稳定性（X%）、 ④权利要求布局（X%）、 ⑤背景技术论述（X%）、 ⑥技术问题与技术效果论述（X%）、 ⑦说明书充分公开情况（X%）、 ⑧形式问题（X%）。括号内百分比必须来自用户确认的 AHP 领域权重，禁止省略、写成小数、写成"权重X%"单独列、或继续使用通用版权重占位。

• 分组呈现硬性要求 ：8项评分必须按固定三组输出： 一、权利要求书质量 包含 scores[0-3]； 二、说明书质量 包含 scores[4-6]； 三、其他 包含 scores[7]。不得调换顺序、合并指标、删除指标或增加第9项指标。

• 加权分呈现硬性要求 ：每项加权分必须等于 原始分 × 用户确认的对应领域权重，保留到可核验的数字精度； total_score 必须等于8项加权分之和。权重不得在技能中固化为某一领域默认值，必须随用户确认的 AHP 方案动态呈现：用户选 A 则呈现化学权重，选 B 则呈现机械权重，选 C 则呈现电学权重，选 D 则呈现通用权重。

• 页面视觉：使用 A4 页面容器（ 210mm × 297mm）， @page { size: A4; margin: 20mm; }，页面内边距 20mm。

• 字体与颜色：宋体优先，正文 10.5pt，大标题 14pt，加粗居中；全文黑色，禁止彩色字体和链接色。

• 表格：全表无底色，黑色细实线边框， border-collapse: collapse，文字自动换行；数字/分数列居中，文字内容列左对齐。

• 结构：第1个页面区块为主表；第2个页面区块为附表1；若报告含 D1/D2/D3 或引用 DP 编号，应继续输出附表2、附表3。

• 命名：HTML 文件名使用固定前缀和加号分隔，输入 CN120270198A.pdf → @session/output/专利申请文件质量评价表+CN120270198A.html。

• 生成命令： scripts/generate_html.py --data <V2 JSON路径> --output <目标HTML路径>；格式调试样例可临时加 --skip-validation，正式评审报告禁止跳过校验。

• 交付抽检：用 HTML 解析或字符串检查确认 section.page、 table 数量、主表标题、附表1标题、评分项和问题行存在；同时确认无 apikey、 sk-、 Authorization、 http:// 或 https:// 等凭证/链接残留。

• 评分框架抽检硬性要求 ：生成 HTML 后必须抽检8个指标名称及权重百分比是否逐项存在，且顺序与 scores 一致；必须抽检分组标题 一、权利要求书质量、 二、说明书质量、 三、其他 存在；必须抽检列名 评价指标、 得分、 加权得分、 主要问题描述 存在。任一项缺失或权重与用户确认领域不一致时，禁止交付，应先修正 V2 JSON 或生成脚本后重出 HTML。

Word 输出格式规格（V2，按需）

• 页面：A4（21×29.7 cm），四边距均 2.0 cm。

• 字体：宋体，全文统一（含东亚字体属性，确保中文正确渲染）。

• 字色：全文纯黑色 RGBColor(0,0,0)，禁止任何彩色字体。

• 字号：正文 10.5pt（五号），大标题 14pt 加粗居中，表标题 10.5pt 加粗居中。

• 加粗规则：表头行加粗，数据单元格不加粗。

• 对齐规则：数字/分数列居中，文字内容列左对齐。

• 底色：全表无底色，禁止灰色/彩色底色。

• 边框：黑色细实线（ sz=4）。

• 分页：第1页主表（基本信息+评分情况整合一张表），第2页附表1主要问题与修改建议；若按需追加 D1/D2/D3 或 DP 编号说明，继续输出附表2、附表3。

• 主表列宽： 5.0 / 2.5 / 2.5 / 7.0 cm。

• 附表1列宽： 1.0 / 2.0 / 3.0 / 2.5 / 4.25 / 4.25 cm。

数据结构规格（V2）

• basic： { patent_name, tech_field, agency, agent, agent_tel }。

• scores：8 项四元组列表，顺序固定： [指标名（含领域权重%）, 原始分0-100, 加权分, 主要问题描述]。

• total_score：数字，0–100。

• conclusion： 质量良好，可提交 / 可提交，建议修改后再提交 / 存在重大缺陷，建议修改后再提交。

• issues：六元组列表： [序号, 严重程度, 问题名称, 涉及位置, 问题描述, 修改建议]，严重程度填写 重要 或 一般。

• review_date、 reviewer_name、 domain、 stability_risk、 novelty_conclusion、 dp_cited。

• 证据链字段按需补充： evidence_mode、 loaded_skills、 fetched_references、 artifact_paths、 d1_selection_rationale、 legal_status_evidence、 reverse_claim_coverage。

scores 分组规则：

• scores[0-3] → 一、权利要求书质量。

• scores[4-6] → 二、说明书质量。

• scores[7] → 三、其他。

AI 执行操作流程

1. 读取文件全文 ：抽取 PDF/Word 正文；扫描版 PDF 必要时转 OCR；抽查首页著录项目、摘要、独立权利要求、发明内容和具体实施方式。

2. 关联文件与法律状态排查 ：扫描同目录关联文件；优先使用智慧芽高级专利数据复审无效能力检索申请号、公开号、公告号、专利名称和案号，再补充法律状态检索；若发现无效/复审决定，必须读取决定书内容，优先抽取"案由、证据清单、证据认定、创造性/新颖性/公开充分评述、决定结果、受影响权利要求、决定日期和案号"。

3. 确定技术领域 ：按标准问卷向用户确认 A/B/C/D 权重方案，未确认前不得完整评审。

4. 逐项评审 8 个指标 ：结合 DP 要点、领域差异化规则、反向保护检查和权利稳定性 A→B 子流程；权利稳定性须最后汇总。

5. 计算加权总分 ：加权分 = 原始分 × 对应领域权重；总分 = 8 项加权分之和；按三档标准给出结论。

6. 生成默认 HTML 文件 ：必须先将 V2 JSON 写入文件，再调用 scripts/generate_html.py --data <V2 JSON路径> --output <目标HTML路径>；脚本会先执行 pre_html 证据链校验。禁止用环境变量传递中文 JSON 字符串，禁止手工复制 Word 文本拼接 HTML。

7. 按需生成 Word 文件 ：仅当用户明确要求 Word、 .docx 或可编辑文档时，再调用 scripts/generate_word.py --data <V2 JSON路径> --output <目标DOCX路径>；Word 必须与 HTML 使用同一份 V2 JSON。

8. 结构抽检并返回路径 ：默认读取生成后的 .html 结构，确认主表、评分项、附表1问题行非空；若同时生成 .docx，也抽检 Word 结构。这是交付校验，不计入形式问题评分。

运行问题与解决方案

问题1：HTML/Word 文件内容空白

根本原因 ：环境变量传递中文 JSON 时字符丢失。 解决方案 ：先用 files.write 将完整 JSON 写入文件，再通过 --data 参数传路径。

问题2：字体出现彩色

解决方案 ： set_run_font() 中强制设置 run.font.color.rgb = RGBColor(0, 0, 0)。

问题3：python-docx 依赖包未预装

解决方案 ：默认 HTML 输出不需要 python-docx。只有用户要求 Word 或需要编辑 .docx 时，先确认当前 Python 可 import docx；若系统 Python 缺失该库，应改用 Codex bundled Python/manifest runtime，或先在受控运行环境安装 python-docx。

问题4：生成后没有自动打开输出目录

根本原因 ：使用了 @session/... 这类 Eureka handle 执行系统打开命令，系统命令无法解析该 handle。 解决方案 ：默认 HTML 输出不自动打开目录，最终回复直接返回 HTML 绝对路径。若按需生成 Word 且需要打开目录，使用 word_output_manifest.json 中的 output_dir_path 或 word_path 绝对路径打开；Word 脚本内置跨平台打开目录：Windows 用 os.startfile，macOS 用 open，Linux/其他桌面环境用 xdg-open。

问题5：AHP领域确认问卷格式（先问后评）

根本原因 ：AI在未向用户确认领域的情况下直接开始评审，导致权重方案选择不透明。 解决方案 ：收到专利文件后，先快速阅读摘要和独立权利要求，判断技术领域倾向，然后 必须 按以下标准格式向用户提问，等用户确认后再执行评审：

标准问卷格式：

本专利涉及[简述技术领域，如：机械传动/电机控制/化学合成等]，
IPC分类号为[XXX]，主要技术特征为[简述核心特征]，
初步判断属于[领域名称]领域。
请选择权重方案：
A. 化学领域（含材料、生物、医药）
B. 机械领域（含机电一体化）← 【AI推荐】
C. 电学领域（含软件、通信、计算机）
D. 使用通用权重

执行要求：

• 必须给出 AI 推荐选项（在对应选项后标注 ← 【AI推荐】）及简短理由

• 必须等用户回复确认后，才能继续执行 Step 3 及后续评审流程

• 禁止在用户未确认领域的情况下自行默认选择并直接开始评审

问题6：输出文件命名不规范

根本原因 ：AI调用 generate_html.py 或按需调用 generate_word.py 时， --output 参数未严格遵守命名规范，使用了缩写前缀（如 质量评价表_）和错误分隔符（如下划线 _）。 解决方案 ：默认 HTML 的 --output 参数必须严格按以下格式构造：

@session/output/专利申请文件质量评价表+{输入文件名去扩展名}.html

正确示例：

• 输入文件 CN120243995A.pdf → @session/output/专利申请文件质量评价表+CN120243995A.html

• 输入文件 某专利申请.docx → @session/output/专利申请文件质量评价表+某专利申请.html

若用户明确要求 Word，同前缀同目录，仅扩展名改为 .docx。

禁止写法：

• ❌ 质量评价表_CN120243995A.html（前缀缩写 + 下划线分隔）

• ❌ 专利质量评价表+CN120243995A.html（前缀不完整）

• ❌ 专利申请文件质量评价表_CN120243995A.html（分隔符错误）

• ❌ 发明专利申请文件质量评价表_CN120243995A.html（前缀多余"发明"二字 + 下划线分隔）

• ❌ @session/outputs/专利申请文件质量评价表+CN120243995A.html（目录为 outputs 而非 output）

问题7：JSON字段名错误（basic.title → basic.patent_name）

根本原因 ：AI构造 review_data JSON 时，将专利名称字段写为 basic.title，但 generate_html.py 和 generate_word.py 脚本期望的字段名为 basic.patent_name，导致评价表中专利名称一栏为空。 解决方案 ：构造 basic 对象时，专利名称字段必须使用 patent_name 而非 title。

正确写法：

"basic": {
  "patent_name": "一种转子车削装置",
  "tech_field": "机械",
  "agency": "",
  "agent": "",
  "agent_tel": ""
}

禁止写法：

• ❌ "basic": { "title": "一种转子车削装置" }（字段名错误）

问题8：scores字段格式错误（字典格式 → 列表4元组格式）

根本原因 ：AI构造 review_data JSON 时，将 scores 写为字典格式（ {"指标名": 分数}），但 generate_html.py 和 generate_word.py 脚本期望的是列表格式，每项为包含4个元素的数组 [指标名, 原始分, 加权分, 问题描述]，导致脚本解析失败或表格数据错误。 解决方案 ： scores 字段必须使用列表格式，每个元素为包含4个元素的数组。 以下仅为 通用版权重示例 ；实际评审时必须根据用户确认的化学/机械/电学/通用权重方案，替换指标名中的百分比并重新计算加权分。正式 HTML 必须直接读取这些指标名作为评分表第一列，呈现为"评价指标（权重%）"，不得在 HTML 中另行改名、删去百分比、把权重拆到脚注或另表中。

B 机械领域呈现示例（仅当用户确认选择 B 时使用这组百分比；不是默认固化权重）：

"scores": [
  ["①技术方案表述（12%）", 82, 9.84, "问题描述文本"],
  ["②保护范围规划（12%）", 76, 9.12, "问题描述文本"],
  ["③权利稳定性（10%）", 66, 6.60, "问题描述文本"],
  ["④权利要求布局（18%）", 78, 14.04, "问题描述文本"],
  ["⑤背景技术论述（10%）", 62, 6.20, "问题描述文本"],
  ["⑥技术问题与技术效果论述（8%）", 73, 5.84, "问题描述文本"],
  ["⑦说明书充分公开情况（18%）", 78, 14.04, "问题描述文本"],
  ["⑧形式问题（12%）", 84, 10.08, "问题描述文本"]
]

该示例体现的是内容格式框架，不要求沿用示例分数，也不得把机械权重作为所有案件的固定默认值；但指标顺序、指标名称、序号、括号中的"用户确认领域对应权重"和四元组结构必须保持一致。

正确写法：

"scores": [
  ["①技术方案表述（10%）", 85, 8.50, "问题描述文本"],
  ["②保护范围规划（10%）", 78, 7.80, "问题描述文本"],
  ["③权利稳定性（10%）", 72, 7.20, "问题描述文本"],
  ["④权利要求布局（20%）", 75, 15.00, "问题描述文本"],
  ["⑤背景技术论述（10%）", 82, 8.20, "问题描述文本"],
  ["⑥技术问题与技术效果论述（10%）", 80, 8.00, "问题描述文本"],
  ["⑦说明书充分公开情况（20%）", 75, 15.00, "问题描述文本"],
  ["⑧形式问题（10%）", 80, 8.00, "问题描述文本"]
]

禁止写法：

• ❌ "scores": { "①技术方案表述": 85, ... }（字典格式，脚本无法解析）

• ❌ "scores": [ {"name": "①技术方案表述", "score": 85} ]（对象列表格式，非4元组）

问题9：issues字段格式错误（字典格式 → 6元组列表格式）

根本原因 ：AI构造 review_data JSON 时，将 issues 每项写为字典格式（ {"no":1, "level":"重要", ...}），但 HTML/Word 生成脚本均按位置读取六元组，字典格式会导致附表1问题行内容为空或字段错位。 解决方案 ： issues 字段每项必须使用6元组列表格式，按位置顺序填写： [序号, 严重程度, 问题名称, 涉及位置, 问题描述, 修改建议]。

正确写法：

"issues": [
  [1, "重要", "必要技术特征完整性", "权利要求1", "独立权利要求缺少XXX必要技术特征，导致技术方案不完整（援引DP13）", "建议在独立权利要求中补充XXX特征"],
  [2, "重要", "功能性限定充分公开", "权利要求1、说明书实施例", "功能性限定特征XXX在说明书中仅有单一实施例支撑，未覆盖整个保护范围（援引DP10）", "建议补充至少一种替代实施方式"],
  [3, "一般", "相对性语言明确性", "权利要求1", "权利要求1中XXX表述含义不确定（援引DP14）", "建议改为具体数值或结构限定"]
]

禁止写法：

• ❌ "issues": [{"no":1, "level":"重要", "name":"...", "loc":"...", "desc":"...", "sug":"..."}]（字典格式，无法按位置解包，附表1全部为空）

• ❌ "issues": [[1, "重要", "问题名", "位置", "描述"]]（只有5个元素，缺少第6项「修改建议」，解包失败）

问题10：main.py 输出格式与 V2 生成脚本期望格式脱节

根本原因 ： main.py 生成 review_data.json 时采用 旧版 indicators 数组格式 （顶层含 patent_no、 indicators、 overall_assessment），而 generate_html.py 和 generate_word.py 已升级为期望 V2格式 （顶层含 basic、 scores、 issues、 total_score、 conclusion），两者数据契约完全脱节，导致脚本访问 DATA["basic"] 时取不到数据，评价表基本信息、评分表和附表1可能为空。

具体差异：

解决方案 ：AI执行评审后， 必须直接构造 V2格式 JSON （而非依赖 main.py 输出），再调用 generate_html.py；用户要求 Word 时再用同一份 V2 JSON 调用 generate_word.py。V2格式构造规则详见问题7、8、9。禁止将 main.py 的 indicators 格式输出文件直接传给任一 V2 生成脚本。

问题11：传入了错误的数据文件（review_data.json 而非 review_data_v2.json）

根本原因 ：工作区中同时存在 review_data.json（旧格式）和 review_data_v2.json（V2格式）两个文件，AI调用 generate_html.py 或 generate_word.py 时误传了旧格式文件 review_data.json，导致评价表内容为空。 解决方案 ：

• 调用 generate_html.py 或 generate_word.py 时， --data 参数必须明确指定 V2格式数据文件 （即 AI 本次评审后直接写出的 review_data_v2.json）。

• 禁止使用 review_data.json（ main.py 的旧格式输出）作为 --data 参数传入任一 V2 生成脚本。

• 最佳实践：AI每次评审结束后，直接将 V2格式 JSON 写入 @skill_workspace/review_data_v2.json，调用脚本时固定使用该文件，不再使用 review_data.json。

问题12：扫描版/图片型 PDF 无法直接抽取文字

根本原因 ：部分专利 PDF 由页面图片组成， pdftotext、 strings 或常规 PDF 文本库无法读取权利要求、说明书正文；只看封面或附图会导致评审依据不足。 解决方案 ：

• 先判断 PDF 是否为图片型：若 strings 只能看到压缩流、图片对象或少量元数据，且常规文本抽取为空，应转入 OCR。

• macOS 环境可优先尝试 Quick Look 生成封面预览读取著录项目；若需要全文，可使用 PDFKit 渲染页面并调用 Vision OCR。Vision OCR 在沙箱内可能因模型加载失败返回 nilError，此时应请求用户批准在沙箱外运行本地 OCR 脚本，输出到工作区文本文件。

• OCR 后必须抽查至少：首页著录项目、摘要、独立权利要求、说明书发明内容和具体实施方式关键段。不要只依据附图或摘要评分。

• 若 OCR 仍不可用，应明确告知用户只能做有限评审，不能生成完整权利稳定性结论。

问题13：evidence_mode=full 缺少 D1 选择理由

根本原因 ： validate_review_data.py 会校验 d1_selection_rationale。仅提供 fetched_references、 novelty_report.md 等产物仍会被拦截。 解决方案 ：V2 JSON 中必须加入 d1_selection_rationale 对象，字段至少包括：

"d1_selection_rationale": {
  "selected_d1": "EP2048040B1",
  "source": "检索来源和检索方式说明",
  "reason": "为什么该文献是最接近单篇参考",
  "date_check": "YYYY-MM-DD",
  "fetch_path": "/absolute/path/to/D1.txt",
  "alternatives_considered": ["备选D1及未选原因"],
  "limitations": ["检索限制或结论适用边界"]
}

其中 fetch_path 必须指向真实存在且非空的 D1 原文/摘要读取文件，并与 fetched_references 中 role=D1 的路径一致。

问题14：D1/D2/D3 参考文献附表需要写入评价表，但默认不放链接

根本原因 ：用户需要知道 D1、D2、D3 分别是谁，但正式评价表中直接放长 URL 会影响版面，也不符合本项目输出偏好。 解决方案 ：

• 默认 HTML 报告若存在 fetched_references，应输出分页附表，标题固定为 附表2 权利稳定性参考文献说明。当用户要求"把 D1/D2/D3 放入 Word"或"作为 Word 附表/附录信息"时，在现有 Word 评价表末尾追加同名分页附表。

• 附录表默认 4 列： 编号、 公开文本、 标题、 在本次评审中的作用。

• 若执行了海外补充检索，可在同一附表2中追加 OS1/OS2/OS3... 或 US1/EP1/WO1... 行，表示海外补充参考；这些行不得替代 D1/D2/D3 的角色，除非经单篇最接近现有技术比较后确认为新的 D1/D2/D3。

• 默认不要加入链接列，也不要在单元格中写 URL ；只有用户明确要求链接时才加入。

• 对 HTML 默认报告，生成后用字符串或 HTML 解析抽检附表2标题、D1/D2/D3 内容存在且没有 URL 残留。

• 若报告正文、评分描述或问题清单提到海外补充文献，抽检时还必须确认附表2中存在相应海外公开文本编号，且没有 URL 残留。

• 对既有 DOCX 追加附录属于局部编辑，应保留原主表和附表1结构，不重新生成整份文档；追加后用 python-docx 结构抽检，确认附表2标题、D1/D2/D3 内容存在且没有 URL 残留；若此前已存在旧标题 附录：权利稳定性参考文献说明，应替换为 附表2 权利稳定性参考文献说明，并确认旧标题不再存在。

问题15：Word 生成后需要二次局部编辑时的处理方式

根本原因 ：评审后用户可能继续要求增删附录、调整 D1/D2/D3 表述、去掉链接等。如果重新跑 generate_word.py，可能覆盖用户刚刚确认过的人工/二次编辑内容。 解决方案 ：

• 对已生成的评价表做小范围修改时，优先使用 python-docx 直接编辑现有 .docx，不要重新构造 V2 JSON 再全量生成，除非用户要求重新评分或重出报告。

• 修改后至少做结构抽检：读取表格行数、目标表头、目标行文本，确认没有空表、重复附录或残留错误字段。

• 若用户仅要求调整附表2标题、D1/D2/D3 表述、去掉链接或增删一行参考文献，必须按局部编辑处理；完成后抽检新文本存在、旧文本不存在、表格数量合理且主表/附表1未被覆盖。

• 若使用 Documents 技能渲染检查，但本机缺少 LibreOffice/ soffice，可以交付结构抽检通过的 DOCX，并在最终回复中说明视觉渲染 QA 未完成。

问题15A：报告引用 DP 编号但未解释编号含义

根本原因 ：评价表的问题描述和评分描述会引用 DP13、 DP14 等决定要点编号，但读者若未阅读本技能说明，无法理解编号对应含义。 解决方案 ：

• 当正式评价表正文、主表或附表1中引用 DP 编号时，默认 HTML 应输出分页附表；若是既有 Word 评价表，应在末尾追加分页附表。标题固定为 附表3 本报告实际引用决定要点编号说明。

• 附表3默认 3 列： 编号、 要点名称、 核心内容。

• 只列本报告实际引用到的 DP 编号，不必复制未引用编号；编号含义必须与本技能"复审无效实践决定要点库（DP编号）"一致，不得自行改写。

• HTML 生成后用字符串或 HTML 解析抽检，确认附表3标题、实际引用 DP 编号和对应说明存在。

• 既有 DOCX 追加附表3属于局部编辑，应保留主表、附表1和附表2结构，不重新生成整份文档；追加或改标题后用 python-docx 结构抽检，确认附表3标题、实际引用 DP 编号和对应说明存在，旧标题不存在，且表格数量合理。

问题16：权利稳定性评审漏查同目录附件、无效决定和关键证据链

根本原因 ：AI仅按用户指定的专利公开文本（如 PDF 授权公告文本）进行文本质量评审和有限现有技术检索，没有把同目录下的关联案卷文件、无效宣告请求审查决定书、请求人证据清单、合议组认定的证据组合纳入稳定性判断。这样会把"已经存在官方无效决定/关键公开专利证据链"的事实误判为普通创造性压力，导致权利稳定性评分虚高。

典型表现 ：

• 同目录存在 4W...、 无效宣告请求审查决定、 决定书、 复审无效、 口审、 审查决定 等文件名或内容，但未读取。

• 只使用授权文本扉页列明的审查阶段对比文件，未使用无效决定中真正采纳的证据组合。

• 仅检索最接近单篇 D1，未用专利号/申请号/授权公告号/无效案号倒查无效程序和证据链。

• 评价表中仍写"新颖性倾向保留、创造性中等偏弱"，但实际已有无效决定宣告全部或部分无效。

解决方案：权利稳定性评审前必须执行法律状态与附件排查

1. 扫描同目录关联文件

   • 在读取用户指定文件后，必须检查其所在目录是否存在与同一申请号/公开号/授权公告号/案号相关的 .docx、 .pdf、 .txt 文件。

   • 重点识别文件名或正文包含： 无效、 复审、 决定书、 审查决定、 口头审理、 4W、 5W、 案件编号、 请求人、 证据1、 证据2、 宣告专利权全部无效、 宣告专利权部分无效、 维持专利权有效。

   • 若发现疑似无效/复审决定文件，必须先抽取并阅读"案由、证据清单、证据认定、创造性/新颖性评述、决定"段落，再给权利稳定性评分。

2. 用专利号和案号做外部/公开信息倒查

   • 优先查询智慧芽高级专利数据复审无效能力（ advanced-patent-data/re-examination-and-invalidation）；凭证必须来自运行环境或连接器，不得写入任何技能文件、输出文件或日志。

   • 评审 CNxxxxxxxxxA/B/U、申请号或专利号时，必须检索或查找以下关键词组合：

     • {申请号} 无效

     • {授权公告号} 无效

     • {公开号/公告号} 复审 无效

     • {专利名称} {申请人} 无效

     • 若已知案号： {4W/5W案号}、 {决定号}。

   • 若检索到无效决定或第三方引用无效决定，应优先核验决定文本或可靠公开来源；智慧芽复审无效接口返回决定书正文、附件或详情页时，必须读取决定书内容后再评分。

3. 从无效决定反向建立证据链

   • 无效决定书中列明的 证据1/证据2/证据3... 必须作为权利稳定性证据链的首要参考，而不是只采用授权文本扉页对比文件。

   • 对合议组实际采纳的组合（如 证据2 + 证据4 + 公知常识）应在 fetched_references、 d1_selection_rationale、 claim_diff_matrix.md、 inventive_step_report.md 中明确写入。

   • 若官方决定已经认定某些权利要求不具备创造性/新颖性，应在评分和问题描述中直接引用该认定，不能仅写"存在一定不确定性"。

4. 评分规则

   • 若已存在未被撤销的无效决定宣告专利权全部无效，且报告正文、评分描述或问题清单已写明"权利稳定性实质丧失""权利稳定性实质性丧失""专利权全部无效""稳定性实质丧失"等同义结论，则 权利稳定性 原始分必须为 0，加权分必须同步为 0.00；不得以"是否起诉/是否生效尚待核验"为由保留 1~20 的余量分。程序状态不确定只能写入 legal_status_evidence.appeal_window_or_litigation_status、问题描述或限制条件，不得抬高 scores[2] 分数。

   • 若已存在未被撤销的无效决定宣告专利权全部无效，但报告仅能确认决定存在、尚未能判断是否生效或是否被法院撤销，且未写"实质丧失"类结论，可在 0~20 内谨慎评分；此时必须在 scores[2] 明确写明程序状态未知及评分保留原因。

   • 若已存在无效决定宣告部分无效，应按被无效权利要求范围、剩余权利要求商业价值和可执行性评分，通常不应高于 40~60。

   • 若存在尚未作出决定的无效请求，或者决定仍在三个月起诉期/行政诉讼中，应标注程序状态，并将稳定性评分下调到反映现实风险的区间。

   • 一致性硬校验 ：生成 V2 JSON 和正式评价表前必须检查 scores[2]、 total_score、 issues[0] 与 legal_status_evidence.decision_result 是否一致。若 decision_result 为"宣告全部无效"且评分描述/问题清单写明"实质丧失"，但 scores[2][1] 不是 0 或 scores[2][2] 不是 0.00，必须先修正 JSON 并重算总分，禁止生成或交付 HTML/Word。

5. V2 JSON 记录要求

   • 若读取到无效决定，V2 JSON 应新增或补充：

"legal_status_evidence": {
  "status_source": "智慧芽复审无效查询/无效宣告请求审查决定书/公开法律状态检索",
  "case_no": "4Wxxxxxx",
  "decision_no": "第xxxxxx号",
  "decision_date": "YYYY-MM-DD",
  "decision_result": "宣告全部无效/宣告部分无效/维持有效",
  "affected_claims": "权利要求1-9",
  "key_evidence": ["证据2 CNxxxx", "证据4 CNxxxx"],
  "appeal_window_or_litigation_status": "未知/起诉期内/已诉/已生效",
  "source_path": "/absolute/path/to/decision.docx"
}

• scores[2] 的权利稳定性描述必须同步引用该字段中的决定结果和关键证据。

• issues 第一项应优先写"已有无效决定/无效程序证据链影响稳定性"，而不是普通撰写缺陷。

问题16A：未发现延迟暴露的 Patsnap/智慧芽 MCP 就误降级

根本原因 ：部分 Patsnap/智慧芽 MCP 工具不会在初始工具列表中直接暴露，需要先通过 tool_search 发现后才能调用。若 AI 只查看当前可见工具，未执行工具发现，就容易误写"未接入 Patsnap MCP""法律状态检索未完成"，即使实际 MCP 已可用。

解决方案：生成降级结论前必须先做 MCP 发现

• 当评审涉及公开专利检索、法律状态、复审无效或证据链时，若初始工具列表中没有直接可用的 Patsnap/智慧芽工具，必须先调用 tool_search 搜索 Patsnap patent search legal status invalidation 或同义关键词。

• 若发现 zhihuiya_* / Patsnap 相关 MCP，应优先使用：

  • 核心专利库检索目标公开号/申请号，核验著录项目和 patent_id；

  • 智慧芽高级专利数据复审无效能力（ advanced-patent-data/re-examination-and-invalidation）查询目标公开号、公告号、申请号、专利名称和案号，并读取决定书内容；

  • 复审无效未命中时，再用法律状态工具补充查询目标公开号、公告号和申请号；

  • 必要时用专利争议、核心库或高级检索倒查同题名、同申请人、同族/并行申请。

• 只有在 tool_search 未发现可用 Patsnap/智慧芽工具，或工具调用失败且无法恢复时，才可写 evidence_mode=degraded / document_only / limited 等降级说明。

• 禁止在未执行工具发现的情况下写"未接入 Patsnap MCP""Patsnap MCP 不可用""法律状态检索未完成"等表述。

• 若先前报告已经误写该表述，必须局部编辑默认 HTML（或用户要求的 Word）和 V2 JSON，将其修正为实际查询结果，如"已接入 Patsnap/智慧芽基础检索和复审无效查询，未查到本案复审/无效记录"。

问题16B：把目标案或同族/并行申请误当作 D1

根本原因 ：按公开号或题名检索时，Patsnap/智慧芽会首先命中目标申请文本本身，或命中同申请日、同题名、同申请人的实用新型/并行申请。若未排除目标案，会把自我文本误当作最接近现有技术，导致 D1 选择错误。

解决方案：D1 选择前必须排除目标案和不合格同族/并行申请

• CNxxxxxxxxA/B/U 检索命中的目标文本只用于：

  • 核验著录项目、申请号、公开号、申请人、发明人、IPC；

  • 查询法律状态、复审无效、争议记录；

  • 识别同族/并行申请信息。

• 目标案本身不得作为 D1。D1 必须是目标案申请日以前公开、且技术内容最接近独立权利要求的单篇参考文献。

• 与目标案同申请日、同题名、同申请人/发明人的实用新型、分案、同族或并行申请，原则上不得直接作为 D1；除非能证明其公开日早于目标案申请日且构成合法现有技术，并在 d1_selection_rationale.limitations 中说明适用边界。

• d1_selection_rationale 应明确写入目标案排除说明，例如：

"target_exclusion": {
  "target_publication": "CN120270198A",
  "reason": "该文献为本次被评审申请公开文本，仅用于著录项目和法律状态核验，不作为D1。",
  "family_or_parallel_cases": ["CN224013545U：同题名同申请日并行申请，仅记录为同主题信息，不作为D1。"]
}

• 若 novelty_lite_report_generate 自动评述基于目标案自身给出"无新颖性/无创造性"结论，禁止机械采纳该结论；必须在 novelty_report.md 和 d1_selection_rationale.target_exclusion 中写明"目标案自身已人工排除"，并基于排除目标案后的候选文献重新确定 D1、 novelty_conclusion 和 inventive_step_conclusion。

• 若目标案排除后单篇 D1 未覆盖全部特征，应按 DP4 单独对比原则写 novelty_preserved 或 uncertain，不得因为 novelty-lite 原始自动报告包含目标案自身而写 novelty_rejected。

• 附表2 写 D1/D2/D3 时，不应把目标案或同申请日并行申请列为 D1；可在证据限制或法律状态说明中单独记录其存在。

问题16C：缺少海外专利补充检索导致证据链看起来只覆盖中文文献

根本原因 ：网络安全、AI、通信、软件、电学等领域的最接近现有技术经常出现在 US/EP/WO 等海外公开文本中。若只使用中文关键词或只读取 CN 候选，虽然可能已经找到一个合格 D1，但报告会缺少"海外文献是否遗漏"的可审计说明，用户也难以判断 D1 选择是否充分。

典型表现 ：

• fetched_references 只有 CN 文献，未记录 US/EP/WO 检索方向或未命中理由。

• 用户追问"为什么 D1 不是海外专利""是否遗漏海外专利"后，才临时补检并修改报告。

• 海外文献只在最终回复中口头说明，未写入 artifact_paths、 d1_selection_rationale.alternatives_considered、 scores[2]、 issues 或附表2。

• 明明海外文献可增强组合压力，却未进入权利稳定性评分描述和创造性问题清单。

解决方案：权利稳定性证据链必须加入海外补充检索

1. 适用范围

   • 电学、通信、计算机、软件、AI、网络安全、半导体、医疗器械控制、机械自动化等容易存在海外近似公开的案件，默认执行 US/EP/WO 补充检索。

   • 若化学、医药、材料等领域已有全球同族/海外文献检索需求，也应执行海外补检；除非用户明确要求仅做中国文献或仅做文件内有限评审。

2. 推荐检索方式

   • 先用目标案独立权利要求核心技术特征构造英文自然语言语义检索，限定 jurisdiction=["US","EP","WO"]。

   • 再用 2-3 组英文关键词检索，至少覆盖：

     • 技术对象/应用场景；

     • 核心算法或结构；

     • 核心区别特征或效果；

     • 若涉及工控/通信/软件，增加协议字段、网络拓扑、traffic flow、feature grid、graph、attention、CNN/TCN/Transformer 等同义方向。

   • 对海外候选必须检查公开日/优先权日是否早于目标案申请日；晚于申请日的文献只可作为技术背景或趋势参考，不得作为 D1/D2/D3。

3. D1 选择规则

   • 海外文献不因"海外"而优先，也不因"中文案"而排除。D1 仍按最接近单篇现有技术标准选择：申请日前公开、技术领域和技术问题最接近、覆盖独立权利要求核心特征最多、最适合作为三步法起点。

   • 若海外文献比当前 CN D1 更接近，必须替换 D1，并同步更新 d1_selection_rationale.selected_d1、 fetch_path、 fetched_references、 claim_diff_matrix.md、 inventive_step_report.md、 scores[2] 和附表2。

   • 若海外文献不能替代 D1，但能增强组合启示，应作为 OS1/OS2... 或 D2/D3 备选写入 fetched_references，并在 d1_selection_rationale.alternatives_considered 中说明"为何未选为 D1"。

4. V2 JSON 与证据产物记录

   • 建议新增或补充：

"artifact_paths": {
  "overseas_prior_art_check.md": "/absolute/path/to/overseas_prior_art_check.md"
},
"fetched_references": [
  {
    "role": "OS1",
    "publication": "USxxxxxxxxA1",
    "title": "英文标题",
    "path": "/absolute/path/to/overseas_prior_art_check.md",
    "limitation": "海外补充参考：公开XXX，但未公开YYY；因此不替代D1。"
  }
],
"d1_selection_rationale": {
  "alternatives_considered": [
    "USxxxxxxxxA1：公开XXX，但未公开YYY，未比当前D1更接近。"
  ],
  "limitations": [
    "已补充 US/EP/WO 海外专利检索；未发现比当前D1更适合作为最接近单篇D1的海外文献。"
  ]
}

• overseas_prior_art_check.md 至少记录检索范围、检索式/关键词方向、重点海外候选、与本案核心特征的差异、是否替换 D1 的理由。

• 若海外文献增强创造性压力， scores[2] 和 issues 中应同步写入"US/EP/WO 补充文献形成组合压力"或等价表述。

1. 报告与抽检

   • 默认 HTML 报告的附表2应展示海外补充参考行，公开文本列写 US...、 EP...、 WO...，角色列可写 OS1/OS2...；不要写 URL。

   • 生成后抽检：

     • 附表2标题存在；

     • D1/D2/D3 存在；

     • 若执行海外补检， OS1/OS2... 或具体 US/EP/WO 公开号存在；

     • 页面中无 http://、 https://、 apikey、 Authorization、 sk- 残留。

   • 最终回复若用户关心海外文献，应明确说明：海外文献是否检索、是否替换 D1、若未替换则原因是什么。

问题17：缺少权利要求书反向保护检查导致说明书公开内容捐献风险

根本原因 ：AI只做了正向检查（权利要求是否得到说明书支持、是否清楚、是否稳定），没有反向检查说明书中已经公开的有价值技术方案、实施例、替代结构、参数范围和效果实现路径是否进入权利要求保护范围。这样可能导致"说明书写了，但权利要求没要"，在后续侵权比对、无效退守或竞争规避中形成事实上的捐献风险。

典型表现 ：

• 说明书公开多个实施例，但权利要求只覆盖其中一类实施例。

• 说明书写有"优选地""进一步地""一种具体实施例""另一种实施例"等技术方案，但权利要求没有对应从属项。

• 说明书公开替代连接方式、替代材料、替代部件、替代参数范围，权利要求只保护单一方式。

• 说明书把多个部件协同产生技术效果，但权利要求只零散限定单个部件，缺少组合保护。

• 说明书公开运动过程、装配过程、控制过程或锁定/解锁路径，但权利要求只写静态结构。

解决方案：必须增加权利要求书反向保护检查

1. 提取说明书中的可保护技术点

   • 必须系统阅读并提取：发明内容、全部具体实施方式、附图标记对应结构、优选/进一步方案、替代连接关系、参数范围、运动过程、装配方式、锁定/解锁机构、控制逻辑、技术效果对应结构组合。

   • 输出时应形成"说明书技术点清单"，不能只阅读独立权利要求。

2. 建立说明书技术点与权利要求的覆盖映射

   • 对每个技术点判断其属于：

     • 独立权利要求已覆盖；

     • 从属权利要求已覆盖；

     • 仅被宽泛概括覆盖，但没有具体从权兜底；

     • 完全未进入权利要求；

     • 说明书写成可替代/优选方案，但权利要求只保护其中一种。

   • 映射时应同时关注"文字覆盖"和"实际可主张覆盖"：如果权利要求虽有宽泛概括，但竞争对手容易通过替换说明书已公开方案规避，也应提示风险。

3. 识别捐献风险类型

   • 实施例未覆盖 ：说明书公开多个实施例，权利要求只覆盖部分实施例。

   • 替代方案未覆盖 ：说明书公开 A/B/C 可替代结构，权利要求只写 A。

   • 关键参数未覆盖 ：说明书公开优选范围、端点范围或效果较好的范围，权利要求未限定或未形成梯度。

   • 协同特征未覆盖 ：说明书把多个部件组合起来实现技术效果，权利要求缺少该组合。

   • 效果实现路径未覆盖 ：说明书说明某一运动过程、控制过程、装配方式带来效果，权利要求未保护该过程或路径。

4. 判断是否需要新增或调整权利要求

   • 对高价值未覆盖点，应给出新增从属权利要求、并入独立权利要求、设置并列独立方案、补充参数梯度或放弃保护的建议。

   • 不能机械地"说明书有就都写进权利要求"；必须结合商业价值、可规避性、稳定性、清楚性和公开充分程度判断。

   • 若某技术点说明书公开不足，应先在"说明书充分公开情况"中提示补强，不宜直接建议写入权利要求。

5. 评分联动规则

   • 高价值说明书技术点未进入权利要求，应在 保护范围规划 中扣分。

   • 缺少从属层级、备选方案、参数梯度或退守权利要求，应在 权利要求布局 中扣分。

   • 反向检查发现缺少有效退守空间，且现有技术/无效证据压力较大时，应同步影响 权利稳定性。

   • 说明书虽提及但公开不足、无法安全纳入权利要求时，应同步影响 说明书充分公开情况。

   • 若 issues 中列出"说明书公开方案未纳入权利要求保护"等反向保护重要问题，必须同步调整相关指标的原始分、加权分和主要问题描述；禁止只在问题清单中描述风险而沿用未考虑反向保护检查时的原始分。

6. V2 JSON 记录要求

   • 建议在 V2 JSON 中新增：

"reverse_claim_coverage": {
  "checked": true,
  "summary": "说明书实施例1-4总体均有权利要求覆盖，但锁定机构、单向转动限位机构和部分第四横杆稳定结构缺少明确从属保护。",
  "items": [
    {
      "spec_location": "说明书[0048]",
      "technical_point": "单向转动限位机构控制左右侧支架只能向内翻转",
      "claim_coverage": "仅概括提及，未形成具体从属权利要求",
      "risk_level": "中",
      "donation_risk": "若竞争对手采用特定限位结构实现相同二次折叠，现有权利要求难以覆盖具体改进点。",
      "recommendation": "增加从属权利要求限定限位件、转轴配合及单向止挡关系。"
    }
  ]
}

• 若存在高风险未覆盖技术点， issues 中必须列出，问题名称建议为 说明书公开方案未纳入权利要求保护。

• 相关问题描述应明确写出：说明书位置、技术点、现有权利要求覆盖状态、可能被竞争对手采用或规避的风险、建议新增或调整的权利要求层级。

问题18：V2 JSON 中 scores 指标名称使用了自定义名称而非 SKILL.md 规定的标准名称

根本原因 ：AI 在构造 review_data_v2.json 时，将8项评价指标写成自定义名称（如"独立权利要求保护范围合理性""从属权利要求覆盖完整性""权利稳定性（新颖性/创造性）""说明书充分公开程度""说明书支撑权利要求程度""技术方案创新高度""权利要求撰写规范性""背景技术与发明内容匹配性"），而非 SKILL.md 规定的含序号和领域权重百分比的标准名称。这导致：

• generate_html.py 直接把 JSON 的 scores[i][0] 渲染到表格第一列，评价表中呈现的是自定义名称而非标准名称；

• 所有指标名均无序号（①②...）和括号权重（X%），读者无法核对领域方案和权重对应关系；

• 分组标题下的指标与"评价指标与指标清单"章节完全对不上，严重影响报告可信度。

解决方案 ：构造 scores 时，每项的第一个元素（ indicator_name）必须严格使用以下格式，且百分比必须来自用户确认的 AHP 领域方案，不得自行替换名称：

禁止写法（以电学C方案为例）：

• ❌ "独立权利要求保护范围合理性" → 正确： "①技术方案表述（12%）"

• ❌ "从属权利要求覆盖完整性" → 正确： "②保护范围规划（10%）"

• ❌ "权利稳定性（新颖性/创造性）" → 正确： "③权利稳定性（10%）"

• ❌ "说明书充分公开程度" → 正确： "⑦说明书充分公开情况（16%）"

• ❌ 任何省略序号（①②...）的名称

• ❌ 任何省略括号权重（X%）的名称

• ❌ 任何与上表不匹配的自创指标名称

自查要求 ：构造 V2 JSON 后，在写入文件前必须逐项核对8个 scores[i][0] 值与上表完全一致，名称、序号、括号权重三者均需匹配用户确认的领域方案。

问题19：用户要求输出HTML时AI绕过 generate_html.py 直接手写HTML

根本原因 ：当用户说"输出html文件""生成html报告"时，AI 没有走规范流程（先写 review_data_v2.json → 再调用 generate_html.py），而是直接用 files.write 将手工拼接的 HTML 字符串写入文件。这导致：

• HTML 内容格式完全由 AI 自由发挥，不符合 SKILL.md 规定的主表+附表结构；

• 评价指标名称、权重百分比、分组标题、列名等均可能与标准不符（参见问题18）；

• generate_html.py 内置的证据链校验（ review_validation.py pre_html 校验）被跳过，交付了未经校验的报告；

• 每次 HTML 输出质量不稳定，依赖 AI 当次生成质量而非脚本保障。

解决方案 ：当用户要求"输出html""生成html报告""重新生成html"时， 必须 严格按以下两步走：

1. 确认 V2 JSON 已写入且内容正确

   • 检查 @skill_workspace/review_data_v2.json 是否存在且为本次评审结果；

   • 若不存在或内容有误（如指标名使用了自定义名称），必须先修正并重写 JSON；

   • 禁止跳过此步骤直接手写 HTML。

2. 调用 generate_html.py 脚本生成 HTML

   • 命令格式： python @skill/scripts/generate_html.py --data <V2 JSON绝对路径> --output <目标HTML绝对路径>

   • 正式报告禁止使用 --skip-validation 参数；

   • 脚本执行失败时，应读取错误信息修正 V2 JSON 后重试，而非改用手写 HTML 方案。

禁止行为 ：

• ❌ 直接使用 files.write / files.begin_write 向 .html 文件写入手工拼接的 HTML 内容

• ❌ 使用 Python 脚本内联生成 HTML 字符串并写文件（绕过 generate_html.py）

• ❌ 以"脚本执行失败"为由退回手写 HTML——应修正 JSON 再重跑脚本

问题20：HTML文件在Eureka对话窗口无法直接点击打开，应自动复制到桌面并用系统浏览器打开

根本原因 ： @session/... 是 Eureka 内部协议路径，当前 Eureka 版本不支持在对话窗口内直接渲染 HTML 文件预览；点击后无法打开任何内容，用户体验极差。

解决方案 ： generate_html.py 执行成功后，AI 应立即执行以下后处理步骤（无需用户额外请求）：

1. 将 HTML 文件复制到桌面

   bash

   cp <HTML绝对路径> ~/Desktop/<文件名>.html

2. 用系统默认浏览器打开

   bash

   open ~/Desktop/<文件名>.html   # macOS
   # Windows: start <文件名>.html
   # Linux:   xdg-open <文件名>.html

3. 最终回复格式 ：同时给出：

   • 会话路径（供文件管理器访问）：如 @session/output/专利申请文件质量评价表+CN118306322B.html

   • 桌面绝对路径：如 ~/Desktop/专利申请文件质量评价表+CN118306322B.html

   • 提示语："文件已自动复制到桌面并在浏览器中打开，如未自动弹出请在桌面双击该文件"

注意 ：

• exec cp 和 exec open 的参数必须使用真实绝对路径，不得使用 @session/... 等 Eureka 内部协议路径；

• 若 exec open 返回错误（如沙箱限制），应在回复中说明，并提示用户手动在桌面双击打开，不要静默忽略错误。

使用前配置

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

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

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

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

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