Skip to main content Skills Marketplace Descubra e explore skills de IA criadas pela comunidade.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Mostrar detalhes do prompt Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
npx skills add https://github.com/materialofair/oh-my-codex --skill patent-workflowO comando permanece em uma só linha. Role horizontalmente para revisá-lo antes de copiar.
Prefere uma cópia local? Baixe os arquivos disponíveis atualmente no SkillsMP.
Baixar Zip Baixando... Analyze raw prompts, identify intent and gaps, inventory the current oh-my-codex skill catalog across local/upstream sources, choose the best-fit skill chain, and output a ready-to-paste optimized prompt for Codex. Advisory role only — never executes the task itself. TRIGGER when: user says "optimize prompt", "improve my prompt", "how to write a prompt for", "help me prompt", "rewrite this prompt", or explicitly asks to enhance prompt quality. Also triggers on Chinese equivalents: "优化prompt", "改进prompt", "怎么写prompt", "帮我优化这个指令". DO NOT TRIGGER when: user wants the task executed directly, or says "just do it" / "直接做". DO NOT TRIGGER when user says "优化代码", "优化性能", "optimize performance", "optimize this code" — those are refactoring/performance tasks, not prompt optimization.
Review software architecture using repository evidence, with focused design, change, and system modes. Use when evaluating an architecture proposal before implementation, verifying a completed feature or refactor for boundary and dependency regressions, or performing a milestone/periodic architecture health review. Focus on layering, dependency direction, module boundaries, cohesion, coupling, extensibility, information hiding, testability, change amplification, migration risk, and architecture drift. Trigger for architecture review requests such as 架构审查, 架构评审, 分层检查, 解耦分析, 扩展性审查, or 架构健康检查. Do not use for ordinary line-level code review or for creating a new architecture from scratch.
Explorador de arquivos
6 arquivos IMPLEMENTATION_SUMMARY.md 19.1 KB Ocupações relacionadas SOC
Baseado na classificação ocupacional SOC
name patent-workflow description 三阶段专利撰写workflow（Research → Plan → Implement），借鉴AutoPatent架构，通过 Codex CLI 原生 spawn_agent 派发 explorer/reviewer child agent 协作，确保专利质量和授权率；也用于整理或优化已有 DOCX 专利交底书、保留图片和版式资源并生成新版 Word 文档 auto_invoke true tags ["patent","workflow","multi-agent","quality-gate","omc-agents"] version 0.2.0 source fork updated_at 2026-05-29T03:50:00.000Z layer domain checksum 917cd56131d6d9db6b2431ba2b2612053881fe48be843576d7199c4a99a80f1e
Patent Workflow Skill - 专利三阶段撰写工作流
核心架构
灵感来源 : AutoPatent多Agent框架 + InstructPatentGPT权利要求优化
三阶段workflow :
Research阶段 (Planner) → Plan阶段 (Planner) → Implement阶段 (Writer + Examiner)
↓ ↓ ↓
专利检索 专利大纲生成 分段撰写 + 质量审查
术语收集 PGTree结构 IRR检查 + 术语一致性
发明分析(explorer) 权利要求审查(reviewer) explorer+reviewer 并行复审
质量门禁 :
Gate 1: Research → Plan (检索完整性 ≥80%)
Gate 2: Plan → Implement (大纲完整性 ≥85%)
Gate 3: Implement → Delivery (质量综合评分 ≥90%)
交付约束 :
最终交付物必须是 Word .docx 文件；聊天回复只给文件路径、简短摘要、质量评估和风险说明。
如果用户提供已有 .docx 交底书并要求优化，默认进入 DOCX 保真优化模式，先保留原文档容器资源，再修改正文。
不把完整专利正文作为最终交付直接贴在聊天里；如果当前环境无法生成 .docx，先说明阻塞并要求启用 Documents/Word 处理能力或提供可用 DOCX 生成工具。
Native Subagent Protocol (Codex)
Codex CLI 支持原生 child agent。本 skill 在三个阶段都通过 spawn_agent 派发只读 subagent，主线 Codex 负责撰写与综合。最小编排：
spawn_agent -> (send_input 可选) -> wait_agent -> close_agent
派发到哪个 agent_type （对应 .codex/agents/*.toml 已有定义）：
角色 agent_type TOML 默认 用于 发明架构分析 explorermedium effort, read-only Phase 1.3 拆解发明结构、对比 prior-art 权利要求对抗审查 reviewerhigh effort, read-only Phase 2.3 / 3.3 多视角 claims 复审 文献核验（可选） docs-researchermedium effort, read-only Phase 1.2 校验 prior-art 引用真实性
Message framing （Codex 把 message 视作 user-level 输入，按官方建议加 XML 标签）：
Your task is to perform the following. Follow the instructions below exactly.
<agent-instructions>
[本 SKILL 中各 Step 给出的 prompt 内容]
</agent-instructions>
Execute this now. Output ONLY the structured response specified above.
当 child agent 不可用时的 fallback （参考 ultrapilot 约定）：在单条响应里用 [EXPLORER] / [REVIEWER] /
[SYNTHESIS]
可选强化 ：如需更强专利领域偏置，可在 .codex/agents/ 新增 patent-analyst.toml（基于 explorer）和 patent-claims-reviewer.toml（基于 reviewer），把 developer_instructions 换成专利特定指令；本 skill 不要求，但能进一步降低发散。
适用场景
用户说："写专利"、"申请专利"、"专利workflow"
用户说："三阶段专利撰写"、"专利质量优化"
用户提到："专利检索"、"权利要求优化"、"专利授权率"
用户上传 .docx 专利交底书并要求："优化交底书"、"生成新版 Word"、"保留图片/附图/题注/格式"
与现有cn-patent-application的区别 :
cn-patent-application: 单阶段文档模板填充，适合快速生成交底书patent-workflow: 三阶段系统化workflow，适合高质量专利申请（目标：提高授权率）
Word / DOCX 处理协议 本 skill 生成或优化专利材料时，默认以 .docx 作为最终交付格式。优先使用可用的 Documents skill、结构化 DOCX API、python-docx、OpenXML 解包编辑或等价工具；选择工具时以“保真”和“可校验”为第一目标。
A. 新建专利申请 DOCX 适用于用户没有提供原始 Word 交底书，或明确要求生成全新专利申请文本。
先完成 ResearchPack、ImplementationPlan 和 Gate 3 审查，再生成 .docx。
文档至少包含：技术领域、背景技术、发明内容、附图说明、具体实施方式、权利要求书、摘要、质量评估报告。
如有附图，先确认图片来源和图号，再插入 Word；不要只在正文写“见图1”却没有实际图片或附件路径。
文件名建议使用 [发明名称]-专利申请交付包.docx，并在最终回复中提供绝对路径。
B. 已上传 DOCX 保真优化模式 适用于用户提供 .docx 专利交底书并要求优化、改写、完善、补强权利要求或生成新版 Word。默认启用本模式，除非用户明确要求重新排版。
保留原 DOCX 容器资源，而不是从抽取出的纯文本重新生成空白文档。
纯文本抽取只能用于理解内容，不能作为最终生成 Word 的唯一来源。
优先修改原文档解包后的 word/document.xml 及确需修改的页眉、页脚、脚注、尾注或批注 XML。
不删除或重命名 word/media/*；不移除仍被正文引用的 word/_rels/document.xml.rels 图片关系；不破坏 [Content_Types].xml 中的图片类型声明。
尽量保留图片、附图题注、图号、编号、表格、样式、页眉页脚、脚注、批注和修订痕迹。
识别输入文档：记录原始 .docx 路径、输出路径、用户指定的优化目标和必须保留的资源。
建立资源清单：统计 word/media/* 图片数量、文件名和可行时的哈希；统计图片 relationship 数量和 target；记录题注、图号和图片附近段落。
执行保真编辑：只改需要优化的正文、权利要求、摘要、质量报告等文字；如需新增章节，把新内容插入原文档结构，不覆盖整份文档。
重打包输出：基于修改后的原 DOCX 目录生成新版 .docx。
交付前校验：比对优化前后图片数量、文件名、哈希和 relationship；发现图片丢失、关系断裂或题注错位时先修复，不交付缺图文档。
C. 允许重排版的例外 只有满足以下任一条件，才允许创建全新 .docx 替代保真编辑：
用户明确要求“重新排版”“不要保留原版式”。
原 DOCX 损坏、无法解包、无法编辑或不是真正的 Word 文档。
原文档只是参考资料，用户明确要求生成全新的专利申请文本。
即便重排版，也要优先提取原图片并重新插入新版 Word；如果无法保留图片，必须在质量评估报告和最终回复中标注图片/版式风险。
Phase 1: Research阶段 - 专利检索与技术分析 角色 : Planner Agent
目标 : 检索相关专利、收集术语、分析技术布局
时间 : 15-20分钟
Step 1.1: 技术信息收集（5分钟） 向用户提问收集（Codex CLI 直接以问答方式获取）:
发明概述:
Q: "请简要描述你的发明（1-2句话）"
示例: "一种基于联邦学习的用户建模方法，保护数据隐私"
技术领域:
Q: "涉及哪些技术领域？（用于检索相关专利）"
示例: "联邦学习、隐私计算、机器学习、用户画像"
核心创新点:
Q: "与现有技术相比，你的核心创新是什么？"
示例: "使用第三方鉴权节点进行ID对齐，避免数据外泄"
Word文档输入:
Q: "是否已有 DOCX 交底书需要优化？如果有，是否必须保留图片、题注、表格、页眉页脚、批注或修订痕迹？"
默认: "已有 DOCX 时启用保真优化模式；无 DOCX 时生成全新专利申请 Word"
Step 1.2: 专利检索（10分钟） 工具链:
1 . exa-code检索 (优先):
query: "[技术领域] patent prior art analysis"
tokensNum: 5000
目的: 获取高质量专利文献和技术术语
2 . WebSearch / WebFetch (备选):
query: "[发明关键词] 专利 现有技术"
目的: 补充中文专利信息（CNIPA、知网等）
3 . Context7检索 (可选):
libraryID: 专利领域相关库
topic: "patent drafting best practices"
目的: 获取撰写标准和术语规范
检索内容:
现有专利布局:
- 相关专利数量和趋势
- 主要专利权人
- 技术演进路径
技术术语库:
- 标准技术术语
- 权利要求常用表述
- 避免的模糊词汇
现有技术方案:
- 主流解决方案（2-3个）
- 技术缺陷和局限性
- 技术发展方向
Step 1.3: 派发 explorer subagent 做发明架构分析（5分钟） spawn_agent(agent_type="explorer", message=<下方框架>)，主线 wait_agent 取回结果后 close_agent。
Message 框架 （已套上 Codex 推荐的 XML 包装）：
Your task is to perform the following. Follow the instructions below exactly.
<agent-instructions>
You are doing pre-drafting analysis for a patent application. Read-only.
Do not propose claim text. Cite sources by URL or by patent number.
Inputs:
- Invention summary: [发明概述]
- Technical domain: [技术领域]
- Core innovation claim: [核心创新点]
- Prior art shortlist (from Step 1.2): [代表性专利号 + URL 列表]
- Terminology pool (from Step 1.2): [术语列表]
Deliver a markdown report with these sections:
1. 架构层次拆解（模块 / 数据流 / 控制流）
2. 核心创新点 vs 次要创新点（每条附 prior-art 对比证据）
3. 与现有专利技术路线的差异面（表格：本发明 / 代表性 prior art / 差异）
4. 专利保护策略建议:
- 推荐独立权利要求宽度: 宽 / 中 / 窄（附理由）
- 建议保留的可选技术特征（供从属权利要求使用）
5. 不确定性 / 信息缺口（供 Quality Gate 1 判断是否需要补检）
</agent-instructions>
Execute this now. Output ONLY the structured markdown report.
为什么选 explorer 而不是 reviewer ：
explorer.toml 的 developer_instructions 是 "Stay in exploration mode. Trace the real execution path, cite, avoid proposing fixes" —— 恰好匹配 Research 阶段"只分析、不出权利要求"。reviewer 留给 Plan / Implement 阶段做对抗式 claims 评审，避免角色重叠。若发明本质是某个仓库的代码改造，可追加一个 spawn_agent(agent_type="explorer", ...) 单独跑代码路径调研，不替换本次。
Fallback（child agent 不可用时） ：主线 Codex 在单条响应中以 [EXPLORER] 块自演同样的 prompt，紧跟主线综合。
Step 1.4: Research阶段输出 # 📋 Patent ResearchPack: [发明名称]
## 技术概述
- 发明名称: [标准格式名称]
- 技术领域: [主领域、次领域]
- 核心创新: [1-2句话]
- 技术成熟度: [概念/原型/产品]
## 现有专利布局
### 相关专利统计
- 检索到相关专利: [数量]
- 主要专利权人: [公司/机构列表]
- 技术演进趋势: [分析]
### 代表性专利
1. [专利号] - [专利名称]
- 技术方案: [简述]
- 技术缺陷: [分析]
- 与本发明的区别: [对比]
来源: [URL]
2. [专利号] - [专利名称]
...
## 技术术语库
### 标准术语（从专利文献提取）
- [术语1]: [定义] (来源: [专利号])
- [术语2]: [定义]
...
### 权利要求常用表述
- [表述1]: [示例]
- [表述2]: [示例]
...
### 避免使用的模糊词汇
- ❌ "等"、"或类似"、"大约"
- ❌ "优化"、"改进"（需具体说明如何优化）
- ❌ 主观判断词汇（"优秀"、"高效"）
## Explorer Subagent 技术分析结果
[explorer subagent 输出的架构分析、prior-art 差异、保护策略建议]
## 保护策略建议
### 独立权利要求策略
- 建议范围: [宽/中/窄]
- 核心技术特征: [列表]
- 可选技术特征: [列表]
### 从属权利要求策略
- 优选实施例: [列表]
- 可替代方案: [列表]
## Quality Gate 1检查
- ✅ 检索到≥3个相关专利
- ✅ 技术术语库≥10个术语
- ✅ 现有技术方案分析完整
- ✅ Explorer subagent 分析完成（含保护策略与不确定性清单）
- 综合评分: [X/100] (≥80通过)
## Sources
1. [来源1 URL]
2. [来源2 URL]
...
检索完整性 ≥80分 → 进入Plan阶段
<80分 → 补充检索或询问用户提供更多信息
Phase 2: Plan阶段 - 专利大纲生成（PGTree模式） 角色 : Planner Agent
目标 : 生成结构化专利大纲，设计权利要求层次
时间 : 15-20分钟
Step 2.1: PGTree大纲规划（10分钟） PGTree (Planning Graph Tree) 结构 :
专利文档树形结构:
根节点: 发明名称
第一层: 主要章节
- 技术领域
- 背景技术
- 发明内容
- 附图说明
- 具体实施方式
第二层: 章节细分
发明内容:
- 发明目的
- 技术方案
- 有益效果
具体实施方式:
- 实施例1（主要实施例）
- 实施例2（变形方案）
- 实施例3（其他应用场景）
第三层: 段落规划
技术方案:
- 总体技术方案（3-5段）
- 关键技术特征（2-3段）
- 可选技术特征（1-2段）
大纲生成策略:
1 . 从ResearchPack提取核心创新点
2 . 参考相关专利的章节结构
3 . 使用标准专利术语
4 . 设计3个层次的权利要求
Step 2.2: 权利要求层次设计（5分钟） 独立权利要求:
范围设计:
- 宽权利要求: 保护核心思路（易被规避，但覆盖广）
- 中权利要求: 保护关键技术特征（平衡）
- 窄权利要求: 保护具体实施方式（授权率高）
策略选择:
高创新度 → 宽权利要求 + 多个从属权利要求
中创新度 → 中权利要求 + 梯度保护
低创新度 → 窄权利要求 + 详细实施例
从属权利要求:
层次1: 进一步限定核心特征
层次2: 具体实施参数和配置
层次3: 优选方案和最佳模式
权利要求数量建议:
独立权利要求: 1 -3 个（方法、系统、装置）
从属权利要求: 8 -15 个（覆盖主要变形）
Step 2.3: 派发 reviewer subagent 做权利要求对抗审查（5分钟） spawn_agent(agent_type="reviewer", message=<下方框架>)，wait_agent 取回 → close_agent。
为什么选 reviewer ：.codex/agents/reviewer.toml 默认 model_reasoning_effort = "high" + sandbox_mode = "read-only" + "Review like an owner, lead with concrete findings" —— 与权利要求需要承受审查员/规避者/诉讼三方压力测试的特性高度匹配。
Your task is to perform the following. Follow the instructions below exactly.
<agent-instructions>
You are reviewing a *draft* patent claims structure (claims not yet finalized).
Read-only. Do not rewrite claims wholesale. Produce concrete findings only.
Inputs:
- ResearchPack (Phase 1 输出, 含 prior art + 术语库)
- 草拟权利要求层次:
独立权利要求: [列表]
从属权利要求: [列表]
- 选定的保护范围档位: 宽 / 中 / 窄
请用四视角对抗方式输出 findings (每条标注视角):
[审查员视角] 哪些特征会被判"非显而易见性不足"或"权利要求过宽"
[规避者视角] 哪些措辞最容易被竞争对手设计绕过（给反例）
[诉讼律师视角] 哪些表述在维权时举证困难
[代理人视角] 是否符合《专利审查指南》标准范式 / 术语规范
最终结构化输出:
1. 高风险条款清单（按风险等级排序，每条附"哪个视角发现 / 为什么 / 建议改法"）
2. 建议补充的限制性术语 / 功能性表述（给出具体替换文本）
3. 推荐的层级再编排（如有）
4. 术语一致性问题列表（对照 ResearchPack 术语库）
5. 总判: 建议返工 Plan / 直接进入 Implement
</agent-instructions>
Execute this now. Output ONLY the five structured sections above.
Fallback ：主线 Codex 在单条响应中用 [REVIEWER] 块自演四视角，输出同样 5 个 section。
Step 2.4: Plan阶段输出 # 📝 Patent ImplementationPlan: [发明名称]
## 专利大纲（PGTree结构）
### 1. 技术领域
段落1: 本发明涉及[一级领域]，特别涉及[二级领域]
关键术语: [术语列表]
### 2. 背景技术
段落1: 行业现状和技术发展
段落2: 现有技术方案1描述
段落3: 现有技术方案2描述
段落4: 现有技术缺陷总结
关键术语: [术语列表]
### 3. 发明内容
#### 3.1 发明目的
段落1: 本发明要解决的技术问题
关键术语: [术语列表]
#### 3.2 技术方案
段落1: 总体技术方案概述
段落2: 核心技术特征1
段落3: 核心技术特征2
段落4: 可选技术特征
段落5: 技术方案工作流程
关键术语: [术语列表]
#### 3.3 有益效果
段落1: 技术效果1（量化数据）
段落2: 技术效果2（对比优势）
段落3: 技术效果3（附加价值）
关键术语: [术语列表]
### 4. 附图说明
图1: [总体架构图]
图2: [流程图]
图3: [数据流图]
### 5. 具体实施方式
#### 实施例1（主要实施例）
段落1-3: 详细技术方案描述
段落4-5: 关键参数和配置
段落6: 技术效果验证
关键术语: [术语列表]
#### 实施例2（变形方案1）
段落1-2: 变形方案描述
段落3: 与实施例1的区别
关键术语: [术语列表]
#### 实施例3（变形方案2）
段落1-2: 变形方案描述
段落3: 应用场景扩展
关键术语: [术语列表]
---
## 权利要求书结构
### 独立权利要求1（方法）
一种[发明名称]，其特征在于，包括以下步骤：
S1: [步骤1描述，使用标准术语]
S2: [步骤2描述]
S3: [步骤3描述]
...
### 从属权利要求2-5（进一步限定）
2. 根据权利要求1所述的方法，其特征在于，所述[技术特征]包括...
3. 根据权利要求1所述的方法，其特征在于，所述[技术特征]进一步包括...
...
### 独立权利要求6（系统）
一种[发明名称]系统，其特征在于，包括：
模块1: 用于[功能描述]
模块2: 用于[功能描述]
...
### 从属权利要求7-10（系统细化）
...
---
## Reviewer Subagent 审查建议
[reviewer subagent 的四视角对抗审查结果与可执行修改建议]
---
## 实施清单
### 文件准备
- [ ] 创建专利申请书文档
- [ ] 准备附图（流程图、架构图）
- [ ] 准备实验数据（技术效果证明）
### 撰写顺序
1. 先写具体实施方式（最详细）
2. 再写发明内容（提炼核心）
3. 最后写背景技术（对比铺垫）
4. 权利要求书（基于说明书提炼）
### 术语一致性检查
- [ ] 全文使用统一术语（从术语库选择）
- [ ] 避免模糊词汇
- [ ] 技术特征描述完整
---
## Quality Gate 2检查
- ✅ 大纲完整（5个主要章节）
- ✅ 权利要求层次清晰（独立+从属）
- ✅ 段落规划详细（每段有关键术语）
- ✅ Reviewer subagent 审查建议已整合（高风险条款已处理）
- 综合评分: [X/100] (≥85通过)
---
## 回滚策略
如果Plan阶段发现问题：
- 技术方案不够详细 → 回到Research阶段补充检索
- 权利要求范围不合理 → 重新设计权利要求策略
- 术语不规范 → 补充术语库
大纲完整性 ≥85分 → 进入Implement阶段
<85分 → 补充大纲或重新规划
Phase 3: Implement阶段 - 分段撰写与质量审查 角色 : Writer Agent + Examiner Agent
目标 : 按大纲撰写专利文档，多层次质量审查
时间 : 40-60分钟
Step 3.1: Writer Agent分段撰写（30分钟） 顺序执行:
1 . 具体实施方式 (20分钟):
- 实施例1（主要实施例，最详细）
- 实施例2-3（变形方案）
- 使用ResearchPack的技术术语
- 参考ImplementationPlan的段落规划
2 . 发明内容 (5分钟):
- 从实施方式中提炼核心技术方案
- 量化技术效果（从用户提供的数据）
3 . 背景技术 (3分钟):
- 使用ResearchPack的现有技术分析
- 突出现有技术缺陷
4 . 权利要求书 (2分钟):
- 基于ImplementationPlan的权利要求结构
- 使用标准专利术语
每段撰写完成后:
✓ 检查术语一致性
✓ 确保技术方案可实施
✓ 避免模糊表述
Step 3.2: Examiner Agent质量审查（10分钟）
Layer 1: IRR重复率检查（AutoPatent借鉴）
def calculate_irr (document ):
"""
检测专利文档中的句子重复
IRR = 1 - (重复句子数 / 总句子数)
目标: IRR ≥ 0.85 (重复率 ≤ 15%)
"""
sentences = extract_sentences(document)
unique_sentences = set (sentences)
irr = len (unique_sentences) / len (sentences)
if irr < 0.85 :
report_repetitive_sections()
return irr
Layer 2: 术语一致性验证 检查内容:
术语使用:
✓ 全文使用统一术语（不得混用同义词）
✓ 技术术语与ResearchPack的术语库一致
✓ 权利要求书与说明书术语一致
避免问题:
❌ 同一概念使用不同术语
❌ 模糊词汇（"等"、"约"、"大致"）
❌ 主观判断（"优秀"、"高效"、"先进"）
自动检查:
1 . 提取全文技术术语
2 . 对比ResearchPack术语库
3 . 标记不一致或非标准术语
4 . 建议修正
Layer 3: 法律合规性检查 检查清单:
新颖性:
✓ 技术方案与现有专利有明显区别
✓ 创新点清晰可辨
创造性:
✓ 技术方案非显而易见
✓ 技术效果有显著提升
实用性:
✓ 技术方案可实施
✓ 本领域技术人员能够实现
✓ 关键步骤和参数完整
完整性:
✓ 所有章节齐全
✓ 权利要求书与说明书对应
✓ 附图引用正确
Step 3.3: 并行派发两个 subagent 复审已撰写文档（10分钟） 编排模式 ：在同一条响应中发两次 spawn_agent（一个 explorer、一个 reviewer），各自带独立 message，主线 wait_agent 收集两份报告后做综合修订，最后 close_agent。
派发 1 — explorer subagent（技术完整性审计） :
Your task is to perform the following. Follow the instructions below exactly.
<agent-instructions>
Audit the *written* patent draft for technical completeness. Read-only.
Input: 完整专利文档（说明书 + 权利要求 + 附图说明）
检查项:
1. 实施例覆盖度: 是否覆盖了 Plan 阶段约定的全部变形方案
2. 可实施性: 关键步骤 / 参数是否齐全，本领域技术人员能否复现
3. 技术效果可验证性: 是否有量化指标 / 对比数据
4. 与 ResearchPack 中 prior art 的差异是否在"背景技术"与"发明内容"显式体现
5. 附图编号 / 数据流与文字描述的一致性
输出: 缺漏清单（每条标 P0/P1/P2 优先级 + 具体补写建议 + 应插入的章节位置）
</agent-instructions>
Execute this now. Output ONLY the gap list.
派发 2 — reviewer subagent（权利要求授权率复审） :
Your task is to perform the following. Follow the instructions below exactly.
<agent-instructions>
Adversarial review of *written* claims for authorization-rate optimization. Read-only.
Input: 权利要求书全文 + ResearchPack 中已授权 prior art 的 claim 范式样本
四视角复审:
[审查员] 新颖性 / 创造性 / 实用性 三性挑战 (逐条标注)
[规避者] 给出可绕过的反例 (counter-examples)
[诉讼律师] 哪些表述维权时举证困难
[代理人] 是否符合最新《专利审查指南》范式
输出:
- 必改条款列表
- 每条给出 diff 形式的建议改稿文本
- 预估授权率影响 (相对当前稿)
</agent-instructions>
Execute this now. Output ONLY the structured diff list.
主线综合修订 （两个 wait_agent 都返回后）:
收齐两份 markdown 报告
冲突仲裁：explorer "要补" vs reviewer "要删" 冲突时，按 "先满足三性，再满足完整性" 排序
主线 Codex 落盘修订专利文档
进入 Quality Gate 3 打分
评分 <90 时可选再跑一次 santa-method（两个独立 reviewer 必须同 pass 才放行）
Fallback（child agent 不可用） ：主线 Codex 在单条响应中依次输出 [EXPLORER]、[REVIEWER]、[SYNTHESIS] 三块，再落盘修订。
Step 3.4: Implement阶段输出 # 📄 Patent Application: [发明名称]
## 文档信息
- 发明名称: [标准格式]
- 申请类型: 发明专利
- 申请人: [企业/机构]
- 发明人: [姓名列表]
- 文档版本: V1.0
- 生成日期: [日期]
---
## 技术领域
[按ImplementationPlan撰写，使用标准术语]
---
## 背景技术
[现有技术分析，引用ResearchPack]
---
## 发明内容
### 发明目的
[要解决的技术问题]
### 技术方案
[总体方案 + 核心特征 + 可选特征]
### 有益效果
[量化技术效果，对比数据]
---
## 附图说明
图1: [说明]
图2: [说明]
...
---
## 具体实施方式
### 实施例1
[详细技术方案，可实施]
### 实施例2
[变形方案1]
### 实施例3
[变形方案2]
---
## 权利要求书
1. 一种[发明名称]，其特征在于...
[独立权利要求]
2. 根据权利要求1所述的...
[从属权利要求]
...
---
## Quality Gate 3评估报告
### IRR重复率检查
- IRR分数: [X.XX] (目标≥0.85)
- 重复段落: [如有]
- 改进建议: [如需要]
### 术语一致性验证
- 术语库使用率: [X%]
- 发现的不一致术语: [列表]
- 修正建议: [具体建议]
### 法律合规性检查
- 新颖性: ✅ 通过
- 创造性: ✅ 通过
- 实用性: ✅ 通过
- 完整性: ✅ 通过
### Codex Subagent 审查建议
#### Explorer subagent 技术完整性审查:
[explorer 的技术方案完整性 + 实施例覆盖度建议（P0/P1/P2 清单）]
#### Reviewer subagent 权利要求审查:
[reviewer 的四视角复审 + 授权率优化建议（diff 形式）]
### 综合质量评分
- IRR检查: [分数]/25
- 术语一致性: [分数]/25
- 法律合规性: [分数]/25
- 双 Subagent 审查: [分数]/25
- **总分** : [X]/100 (≥90通过)
---
## 后续优化建议
[基于质量评估的具体改进建议]
---
## 交付文件
1. 专利申请 Word 文档: [绝对文件路径]/[发明名称]-专利申请交付包.docx
2. 附图或原始图片资源: [文件路径，如单独导出]
3. 质量评估报告: [文件路径或 Word 文档内章节]
4. DOCX 保真结果: [新建文档 / 已基于原交底书保留图片与资源 / 存在需人工确认的图片或版式风险]
综合质量评分 ≥90分 → 交付成果
<90分 → 根据建议优化后重新审查
输入为已有 DOCX 时，原图片文件数、图片 relationship 和仍被引用的题注/图号不得无说明地减少或断裂
无法自动校验 DOCX 资源时，必须在质量评估报告列出验证限制和人工复核点
🤖 完整 Workflow 执行总览
完整Workflow执行 Step 0: Trigger Detection
检测到触发词 → 自动加载patent-workflow skill
询问用户:
Q: "你希望使用三阶段系统化workflow撰写高质量专利吗？"
"这个流程需要40-60分钟，但能显著提高专利授权率。"
选项: [是，使用三阶段workflow ] / [否，使用快速模板（cn-patent-application） ]
---
Phase 1: Research (15-20分钟)
├─ Step 1.1: 收集技术信息 (主动向用户问询)
├─ Step 1.2: 专利检索 (exa-code + WebSearch；可选 docs-researcher 校验)
├─ Step 1.3: spawn_agent(explorer) 做发明架构分析
├─ Step 1.4: 生成ResearchPack
└─ Quality Gate 1: 检索完整性 ≥80% → Pass
---
Phase 2: Plan (15-20分钟)
├─ Step 2.1: PGTree大纲规划
├─ Step 2.2: 权利要求层次设计
├─ Step 2.3: spawn_agent(reviewer) 做四视角对抗审查
├─ Step 2.4: 生成ImplementationPlan
└─ Quality Gate 2: 大纲完整性 ≥85% → Pass
---
Phase 3: Implement (40-60分钟)
├─ Step 3.1: Writer 分段撰写
│ ├─ 具体实施方式 (20分钟)
│ ├─ 发明内容 (5分钟)
│ ├─ 背景技术 (3分钟)
│ └─ 权利要求书 (2分钟)
│
├─ Step 3.2: Examiner 本地质量审查 (Python 工具)
│ ├─ IRR 重复率检查
│ ├─ 术语一致性验证
│ └─ 法律合规性人工 checklist
│
├─ Step 3.3: 并行 spawn_agent 双复审
│ ├─ explorer: 技术完整性审查
│ ├─ reviewer: 权利要求四视角复审
│ └─ 主线综合修订 (可选 santa-method 对抗收敛)
│
├─ Step 3.4: 生成最终 Word .docx
│ ├─ 无原始 DOCX: 新建专利申请交付包
│ └─ 有原始 DOCX: 保真编辑、重打包、校验 media/rels/content types
└─ Quality Gate 3: 综合质量 ≥90% → Deliver
---
Step Final: Delivery
✅ 专利申请 Word .docx
✅ 权利要求书、摘要、质量评估报告（写入 Word 或作为同包文件）
✅ 附图（如需要；已有 DOCX 时保留原图片和关系）
✅ DOCX 保真检查结果
✅ 后续优化建议
📊 性能指标与预期效果
时间效率 传统人工撰写:
专利检索: 2 -4 小时
大纲规划: 1 -2 小时
文档撰写: 4 -8 小时
质量审查: 2 -3 小时
总计: 9 -17 小时
三阶段workflow:
Research阶段: 15 -20 分钟
Plan阶段: 15 -20 分钟
Implement阶段: 40 -60 分钟
总计: 70 -100 分钟
效率提升: 6 -10 倍
质量保障 质量维度:
技术方案完整性: AutoPatent的PGTree确保结构完整
权利要求优化: InstructPatentGPT的RLHF策略提高授权率
术语一致性: 全流程术语库管理
重复率控制: IRR指标≥0.85
预期效果:
专利授权率: 提升15-25%（基于InstructPatentGPT论文数据）
审查周期: 缩短10-20%（文档质量高，减少补正）
保护范围: 扩大20-30%（多实施例设计）
Codex Subagent 协作价值 explorer subagent 贡献 (.codex/agents/explorer.toml):
- Research 阶段: 发明架构拆解 + prior-art 差异分析 + 保护策略建议
- Implement 阶段: 文档技术完整性审查（实施例覆盖度、可实施性、技术效果）
- sandbox_mode = "read-only" ，保证分析独立性，不污染主线撰写
- "Trace, cite, don't propose fixes" 默认指令与"先分析再起草"语义一致
reviewer subagent 贡献 (.codex/agents/reviewer.toml):
- Plan 阶段: 四视角对抗审查权利要求结构（审查员 / 规避者 / 诉讼 / 代理人）
- Implement 阶段: 权利要求成稿的授权率优化与可规避点排查（diff 形式建议）
- model_reasoning_effort = "high" ，对应"严苛 reviewer"角色
- sandbox_mode = "read-only" ，绝对不直接改稿
docs-researcher subagent (可选, .codex/agents/docs-researcher.toml):
- Phase 1.2 校验 prior-art 引用真实性（链接 / 专利号 / 摘要）
- 防止幻觉 prior-art 进入 ResearchPack
- "Verify against primary documentation, do not invent" 默认指令直接复用
主线 Codex 角色:
- 编排者: 在三个阶段的关键节点 spawn_agent -> wait_agent -> close_agent
- 撰写者: 唯一可写实体（三个 subagent 全 read-only）
- 仲裁者: explorer "要补" 与 reviewer "要删" 冲突时按"三性优先 > 完整性"收敛
- 可选 escalation: 评分仍 <90 时调用 santa-method skill 走双独立 reviewer 对抗收敛
为什么放弃 legacy MCP 路线:
- 原方案强依赖单一外部 MCP server（已淘汰），故障即整条 workflow 阻塞
- 改用 Codex 原生 child agent (spawn_agent) ，是 codex CLI 一等公民协议，
跟 ultrapilot / research / subagent-driven-development 等 skill 互通
- 必要时仍可由用户显式要求外部顾问模型参与，但不作为默认依赖
🚨 重要注意事项
何时使用三阶段workflow vs 快速模板 使用三阶段workflow (patent-workflow):
✅ 核心技术专利（高价值发明）
✅ 需要高授权率（竞争激烈领域）
✅ 复杂技术方案（多模块、多实施例）
✅ 有时间进行系统化撰写（70-100分钟）
使用快速模板 (cn-patent-application):
✅ 防御性专利（快速占位）
✅ 简单技术方案（单一实施方式）
✅ 时间紧急（需要35-50分钟完成）
✅ 技术交底书阶段（后续由代理人完善）
质量门禁强制执行 重要原则:
⚠️ 质量门禁不通过，禁止进入下一阶段
⚠️ 发现问题，立即回滚到上一阶段修正
⚠️ 不能为了速度牺牲质量
门禁标准:
Gate 1: 研究完整性 ≥80%
- 检索到≥3个相关专利
- 术语库≥10个标准术语
- explorer subagent 技术分析完成
Gate 2: 大纲完整性 ≥85%
- 5 个主要章节齐全
- 权利要求层次清晰（独立+从属）
- reviewer subagent 四视角审查通过
Gate 3: 综合质量 ≥90%
- IRR ≥ 0.85
- 术语一致性检查通过
- 法律合规性检查通过
- 双 subagent (explorer + reviewer) 审查建议已整合
💡 最佳实践与技巧
专利检索技巧 检索策略:
关键词组合:
- 技术领域 + 核心方法 + 应用场景
- 示例: "federated learning + privacy preserving + user modeling"
时间范围:
- 优先检索近3-5年专利（最新技术）
- 补充检索早期专利（基础技术）
专利分类号:
- 使用IPC分类号精准检索
- 示例: G06N 20 /00 (机器学习)
术语提取:
- 从授权专利提取（而非申请中专利）
- 关注权利要求书的措辞
- 建立项目专属术语库
权利要求撰写技巧 独立权利要求:
开头格式:
"一种[技术方案类型]，其特征在于，包括..."
技术特征描述:
✅ 使用"包括"而非"由...组成"（保护范围更广）
✅ 避免绝对词汇（"完全"、"必须"）
✅ 使用功能性描述（"用于..."、"配置为..."）
保护范围控制:
- 宽权利要求: 只写核心必要特征（3-5个）
- 窄权利要求: 增加限制性特征（6-10个）
从属权利要求:
层次设计:
第1层: 引用独立权利要求，补充1个特征
第2层: 引用第1层从属权利要求，再补充1个
第3层: 详细参数和优选值
避免问题:
❌ 从属权利要求引用链过长（≤3层）
❌ 从属权利要求过于简单（无实质限定）
IRR优化技巧 降低重复率策略:
1 . 变换表述方式:
- 同一技术特征用不同角度描述
- 示例1: "数据加密传输"
- 示例2: "采用加密算法对数据进行加密后传输"
2 . 增加技术细节:
- 不同实施例补充不同参数
- 不同场景描述不同应用
3 . 避免模板化表述:
- 减少"包括但不限于"等套话
- 每段有新的技术信息
目标IRR值:
优秀: IRR ≥ 0.90 (重复率 ≤ 10 %)
良好: IRR ≥ 0.85 (重复率 ≤ 15 %)
及格: IRR ≥ 0.80 (重复率 ≤ 20 %)
不合格: IRR < 0.80
📚 参考资源
AutoPatent项目
InstructPatentGPT项目
Codex CLI 系统集成
Research阶段: 使用 exa-code、WebSearch；spawn_agent(explorer) 做架构分析；可选 spawn_agent(docs-researcher) 校验 prior-art
Plan阶段: PGTree 大纲方法论 + spawn_agent(reviewer) 做四视角对抗审查
Implement阶段: Writer 撰写 + Examiner（Python 工具做 IRR/术语/合规）+ 并行 spawn_agent(explorer) / spawn_agent(reviewer) 双复审
可选 escalation: 评分顽固 <90 时调用 santa-method skill 走双独立 reviewer 对抗收敛
专利法律法规
《中华人民共和国专利法》（2020年修订）
《专利审查指南》（2024年版）
🎯 使用示例
示例1: 联邦学习专利（完整三阶段） 用户: "我想申请一个高质量专利，关于企业间联邦学习的方法，需要高授权率"
Codex:
✅ 加载patent-workflow skill
✅ 询问使用三阶段workflow（用户同意）
Phase 1 - Research (18分钟):
- 收集技术信息（联邦学习、隐私计算）
- exa-code检索到12个相关专利
- spawn_agent(explorer) 分析技术架构 + 给出保护策略
- 生成ResearchPack（术语库15个）
- Gate 1: 85分通过 ✅
Phase 2 - Plan (17分钟):
- PGTree大纲规划（5章节、3实施例）
- 权利要求设计（1独立 + 9从属）
- spawn_agent(reviewer) 四视角审查（建议补充2个限制性术语）
- 生成ImplementationPlan
- Gate 2: 88分通过 ✅
Phase 3 - Implement (55分钟):
- Writer撰写（3个实施例、详细技术方案）
- Examiner审查（IRR=0.88、术语一致性98%）
- 并行 spawn_agent: explorer(技术完整性) + reviewer(授权率)
- 主线综合修订
- Gate 3: 93分通过 ✅
交付:
✅ 专利申请说明书（17,500字）
✅ 权利要求书（1独立 + 9从属）
✅ 流程图和架构图
✅ 质量评估报告
✅ 授权率预估: +20%
总耗时: 90分钟（vs 传统12小时）
示例2: 快速防御性专利（使用快速模板） 用户: "我需要快速申请一个防御性专利，占位用，30分钟内完成"
Codex:
✅ 检测到"快速" 和"防御性" 关键词
✅ 建议使用cn-patent-application skill（快速模板）
执行:
- 使用cn-patent-application skill
- 35分钟完成技术交底书
- 质量评分: 78分（及格）
说明:
"已使用快速模板完成，适合防御性占位。
如果后续需要提高授权率，可以使用patent-workflow进行深度优化。"
🚀 快速启动
一键启动三阶段workflow 用户: "使用patent-workflow撰写[技术名称]的高质量专利"
Codex:
立即启动三阶段workflow
→ Research → Plan → Implement
→ 70-100分钟后交付高质量专利文档
与现有系统的协同 与Agent-KB集成:
- 记录专利撰写经验
- 查询专利领域最佳实践
- 学习成功的权利要求策略
与Git Memory集成:
- 记录专利版本演进
- 追踪技术方案变更
- 协作修订历史
与quality-check集成:
- CodeDNA维度扩展到专利质量
- 6 维度评分（新颖性、创造性、实用性、完整性、术语规范、IRR）
✅ 借鉴AutoPatent : PGTree结构 + IRR质量指标 + 多Agent框架
✅ 借鉴InstructPatentGPT : 权利要求优化 + 授权率提升策略
✅ 集成Codex原生 child agent : explorer（架构/技术完整性）+ reviewer（权利要求对抗审查）+ docs-researcher（prior-art 校验，可选）+ 三阶段质量门禁
✅ 完全零成本 : 使用 Codex CLI 内置 spawn_agent 协议 + 仓库自带的 .codex/agents/*.toml，无需训练新模型，无外部 MCP 依赖
✅ 显著提升 : 授权率+15-25%，效率提升6-10倍
