专利核稿搭子

这份技能是干什么的

给你一份已经写好的专利申请文件（.docx / .md / .txt，权利要求书 + 说明书 + 摘要 + 附图说明），
在提交前做一遍质检，产出一份能直接拿去改的分级核稿意见单。

核稿的难点从来不是看不出问题，是人眼一定会漏。漏掉的往往不是需要专业判断的东西，
是枯燥的东西：从属权项引用了在后的权项、同一部件在权项里叫 基板 在说明书里叫 基片、
附图标记漏了一个、摘要悄悄超了 300 字。这些不需要判断力，只需要耐心——
而赶工期的时候，耐心最先消失。

所以这个技能的顺序是反的：先把标准定下来，再让机器扫掉全部枯燥项，最后才动人眼。

与相邻技能的分工

撰写技能写完之后交到这里，是自然的衔接。核稿不做实质检索——新颖性、创造性要检索并逐篇读对比文件，
那是 iprdb-patent-intel / patent-stability-analysis 的活。

铁律（六条，不可让步）

1. 不代改实质内容。 核稿人绝不替发明人补技术内容——核稿时补的东西一旦成为后续修改的基础，
   就是修改超范围（《专利法》第 33 条）。发现实施例撑不住权项，退回补料，不自己写两段。
2. 每一条意见都要带三样：法条或指南依据、具体改法、保护范围影响标注（限缩 / 扩大 / 不动）。
   缺第三样的意见，撰写人无法决策，等于没提。
3. 分级不许模糊。 只有 A 硬伤 / B 建议 / C 待确认三级。
   "仅供参考""建议关注"这类说法一律不许出现——那等于把判断推回给对方。
4. 机器报告不润色。 脚本输出原样附在意见单里，人工判断另起一节。
   复盘时要能分清"哪条是脚本抓的、哪条是人看出来的"。
5. 不承诺授权、不替代代理人责任、不做实质检索。 三条写进意见单末尾。
   这不是免责，是让客户知道这次核稿覆盖了什么、没覆盖什么。
6. 引用条号必须先确认版本。 本技能依据 2023 年修订《专利法实施细则》（2024-01-20 施行）：
   说明书第 20 条、附图第 21 条、权利要求书第 22 条、独权从权第 23～25 条、摘要第 26 条。
   网上大量转载仍是旧条号（说明书第 17 条、权利要求书第 21 条等），引用前务必核对。

工作流（先选深度，再走流程）

开始前先问用户一句话：这次是快速体检，还是完整核稿？

• 快速体检（日常默认）：只确认申请类型（发明/实用新型），然后直接跑第 1 阶段的两个脚本，
  把结果念给用户、标出哪几条是 A 级级别的硬伤，收尾。适合「帮我看一眼能不能交」的场景，
  十分钟出结果。快速体检只覆盖形式与结构，意见单末尾必须注明"本次为快速体检，
  未做权项支撑核对与实质核稿"。
• 完整核稿（正式交付）：走完下面第 0～6 阶段，逐阶段与用户确认。适合代理所内审、
  企业 IPR 审来稿这类要留痕、出正式意见单的场合。

第 0 阶段 · 定标（完整核稿必做；跳过这一步整场核稿就废了）

向用户确认五件事，然后停下来等确认：

1. 申请类型：发明 / 实用新型——实用新型要额外核"必须有附图"和"明显不具备新颖性"两项；
2. 核稿场景：撰写人自检 / 组内互检 / 企业 IPR 审代理所稿——三种场景的重点完全不同（见 references/01-review-setup.md）；
3. 稿件来源：自家撰写 / 外所来稿（外所来稿保持其体例，不按自己习惯大改格式）；
4. 有无交底书：没有交底书就明确声明"本次仅做形式与内在一致性核稿，不核是否写偏发明人意图"；
5. 核稿深度：只做形式+一致性 / 还是加做权项与说明书的实质支撑核对。

同时把 A/B/C 三级定义写死，告诉用户这次核稿按哪一级为交付底线。

第 1 阶段 · 机器扫描

# 权利要求书结构扫描（--type utility 时额外查方法/用途主题，实用新型建议加）
python scripts/check_claims.py 稿件.docx --type utility -o 输出目录/claims_report.md

# 全文一致性与形式扫描
python scripts/check_consistency.py 稿件.docx -o 输出目录/consistency_report.md

输入直接支持 .docx——不需要用户先转 Markdown，脚本在本地解包读取（纯标准库，不上传）。
老式 .doc（二进制）不支持，让用户在 Word/WPS 里另存为 .docx 即可。

两份报告出来后，把结果念给用户（错误/警告/提示各几条、分别是什么），
再确认是否继续深入。脚本报的误报要当场说明——前向引用那一节是自动判定，允许人工推翻。

第 2 阶段 · 权利要求书实质核稿

按 references/02-claims-review.md 走，顺序是先看保护范围，再看清楚性，最后才是引用关系。
核心动作是独权必要技术特征的删减测试：逐个删掉权 1 里的特征，问"技术问题还解决得了吗"。

完成后可以给用户一份"独权特征删减测试表"，这是这个阶段唯一的产出物。

第 3 阶段 · 说明书核稿

按 references/03-spec-review.md 走，逐条填 assets/claims-review-matrix.csv：
每个权项特征 → 说明书对应段落 → 有无实施例。填不满的表就是核稿意见的主体。

重点两处：背景技术里有没有把本申请的区别技术特征写进去（自认风险）；
每个特征的实施例支撑够不够（上位概念至少两个下位实例）。

第 4 阶段 · 一致性与形式

按 references/04-consistency-and-formal.md 走，对着 assets/formal-checklist.md 逐条打勾。
这一层的修改是能径行改的，改完在意见单里列出改了哪里。

第 5 阶段 · 出核稿意见单

用 assets/review-sheet-template.md 的七节结构填。
出草稿后给用户看一遍再定稿——尤其是 A 级的判定和 C 级该转给谁问。

第 6 阶段 · 交付与留痕

交五样：意见单、两份机器报告、填好的核稿矩阵、术语表（如本次有定案）。
用文件呈现工具交给用户。

三个附件怎么用

常见事故与预防

交付形式

• 核稿意见单（Markdown，可按需转 docx）
• 权利要求书结构扫描报告（脚本原始输出）
• 全文一致性与形式扫描报告（脚本原始输出）
• 权项核稿矩阵（填写后的 CSV，可用表格工具打开）
• 术语表（本次有定案时）

用途与边界

用途：代理所内部质量把关、企业 IPR 审代理所来稿、撰写人交稿前自检。

边界：

• 输出是核稿意见，不是修改后的申请文件。修改由撰写人或代理人完成；
• 不承诺授权。授权取决于审查员对现有技术的判断；
• 不做实质检索，不判断新颖性、创造性；
• 不替代专利代理人的执业责任；
• 所有脚本本地运行、不联网、不上传稿件内容——稿件是未公开技术方案，不要送去任何在线服务。

参考文件

故障速查