ARIS invention-structuring 技能详解：把原始发明想法结构化为专利交底书-平芜编程栈

ARIS invention-structuring 技能详解：把原始发明想法结构化为专利交底书

【免费下载链接】Auto-claude-code-research-in-sleepARIS ⚔️ (Auto-Research-In-Sleep) — Lightweight Markdown-only skills for autonomous ML research: cross-model review loops, idea discovery, and experiment automation. No framework, no lock-in — works with Claude Code, Codex, OpenClaw, or any LLM agent.项目地址: https://gitcode.com/gh_mirrors/au/Auto-claude-code-research-in-sleep

导读

本文围绕 ARIS（Auto-Research-In-Sleep）开源仓库中的 invention-structuring 技能展开，完整讲解如何将一个零散的原始发明想法，通过"技术问题—技术方案—有益效果"框架、三层发明分解、可专利主题识别、附图规划、权利要求依赖映射与跨模型验证等步骤，最终结构化输出为一份可直接进入权利要求撰写阶段的patent/INVENTION_DISCLOSURE.md专利交底书。读完本文，你将掌握该技能的全部操作流程、每一步背后的专利法理依据（新颖性、创造性、充分公开、单一性等），以及它如何在 patent-pipeline 完整专利流水线中与查新、权利要求撰写、说明书撰写、审查与格式编译等环节衔接配合。

一、技能定位：专利流水线的"结构设计"环节

invention-structuring是 ARIS 专利流水线中的承上启下环节。从 patent-pipeline 的流水线定义可以看到完整的链条：

/prior-art-search → /patent-novelty-check → /invention-structuring → /claims-drafting → /specification-writing → /patent-review → /jurisdiction-format (查新) (可专利性验证) (发明结构化) (权利要求) (说明书) (审查) (格式编译) ├── /figure-description └── /embodiment-description

其上游是 prior-art-search 生成的patent/PRIOR_ART_REPORT.md与 patent-novelty-check 生成的patent/NOVELTY_ASSESSMENT.md；其下游则是 claims-drafting——技能的描述明确指出其"Adapted from the refinement pattern in /research-refine for patent invention decomposition"，即借鉴了 research-refine 的迭代精炼思路，但服务于专利发明拆解这一特定目标。

技能本身通过两个常量控制运行行为：

常量	值	含义
`REVIEWER_MODEL`	`gpt-6-astra`	通过`mcp__codex__codex`调用的外部验证模型，用于对发明拆解结果做审查
`MAX_REFINEMENT_ROUNDS`	`3`	最大结构迭代轮次，防止无限精修

其中MAX_REFINEMENT_ROUNDS = 3与 claims-drafting 的MAX_CLAIM_REVISION_ROUNDS = 3、patent-pipeline 的MAX_REVIEW_ROUNDS = 2一起构成了整个流水线中"有限迭代、逐环收敛"的质量控制机制。

技能输入

技能运行前需要准备以下输入（全部位于patent/目录，为运行产物而非仓库内文件）：

$ARGUMENTS中携带的发明描述（用户直接描述，或引用一个简报文件路径，如invention-structuring "patent/INVENTION_BRIEF.md"）；
patent/INVENTION_BRIEF.md（若存在）——由用户在模板基础上填写，或在 patent-pipeline Phase 0 中从对话式描述解析生成；
patent/PRIOR_ART_REPORT.md——现有技术全景；
patent/NOVELTY_ASSESSMENT.md——新颖性与创造性分析结论。

若尚未有发明简报，用户可参照仓库中的 INVENTION_BRIEF_TEMPLATE.md 先行填写，或在专利流水线入口直接描述发明，由 pipeline 的 Phase 0 自动解析成简报。

二、Step 1：技术问题—技术方案—有益效果框架

专利交底书的第一性要求，是把"发明说了什么"转化为法律可审查的"三段式"。技能要求严格遵循 Problem-Solution-Advantage（问题—方案—效果）通用专利框架，这一框架同时是 specification-writing 中"发明内容"部分、以及中国、美国、欧洲各法域审查实践的共同母题。

技术问题（Technical Problem）

必须来源于现有技术的缺陷，即NOVELTY_ASSESSMENT.md中指出的 prior art deficiencies，而不是商业或社会需求；
必须是具体的技术问题，不是商业问题或社会问题；
陈述格式固定为："The technical problem to be solved is how to [具体技术目标] given [具体技术约束]."

这与 specification-writing 中"背景技术不是文献综述，而是直接引出问题"的规则一脉相承：说明书background.md描述的现有技术缺陷，正是这里技术问题的源头；中国专利格式中对应"本发明要解决的技术问题是……"（见 patent-format-cn）。

技术方案（Technical Solution）

描述发明的具体技术贡献；
聚焦机制（mechanism）而非结果——这也是 patent-writing-principles 中"result-to-be-achieved language"禁令的直接体现（例如"实现99%图像分类精度"不可，"包含至少三个残差块的卷积神经网络提取特征"可）；
描述粒度须与计划的权利要求保护范围匹配；
必须区分哪些特征是**已知（known）的、哪些是发明（inventive）**的——这一区分是后续 claims-drafting 中"前序部分/特征部分"（CN/EP 两部式）划分的基础。

有益效果（Advantages）

必须是相对现有技术可度量或可量化的改进；
必须由发明特征本身产生，而非"良好工程实践"的附带结果；
在已知具体技术效果时可写入（如"处理时间减少 40%"）。

需要特别注意的是，这里的有益效果定位在交底书层面，而进入正式说明书时，specification-writing 与 patent-format-cn 都要求：说明书"发明内容"与"具体实施方式"中不得写入实验数据/精度百分比，有益效果须用结构性推理表述（"由于采用了……结构，因此具有……效果"）。交底书中标注可量化的技术效果，正是为了在后续审查阶段（而非说明书正文）作为争辩材料使用。

三、Step 2：三层发明分解（核心发明构思/支撑性特征/可选特征）

技能要求把发明拆解为三个层次，这一分层直接决定了后续权利要求金字塔的形态：

层级	定义	对应权利要求	判定测试
核心发明构思（Core Inventive Concept）	使发明具备可专利性的最小特征集合	独立权利要求范围	测试：删掉该特征，发明不再新颖
支撑性特征（Supporting Features）	使发明在实践中良好运转的特征	从属权利要求素材	每个支撑特征应具备独立技术价值
可选特征（Optional Features）	实现细节、优选参数、替代方案	实施例素材	支持更宽的权利要求解释

三层分解的"最小集测试"与 patent-writing-principles 中"独立权利要求应是在现有技术之上最宽的可辩护范围——不更宽也不更窄"的原则精确对应：核心构思多了会把竞争对手挡在保护范围外，少了则会被现有技术破坏新颖性。

支撑性特征"各自独立有价值"的规则也相当关键——它确保了每个从属权利要求作为**独立的后备位置（fallback position）**都能单独存活：当独立权利要求被驳回时，窄化的从属权利要求可以逐级承接。这正是 claims-drafting 中"每个从属权利要求都必须增加至少一个有意义限定、不得只是复述母权利要求"的依据。

四、Step 3：可专利主题识别

针对核心发明构思，技能要求判定应当撰写哪些类别的权利要求：

类别	适用条件	内容
方法/流程（Method/process）	发明包含步骤	流程、算法、工作流
系统/设备（System/apparatus）	发明包含组件	硬件结构、模块、连接关系
产品（Product）	发明是物理装置	形状、结构、组成
计算机可读介质（Computer-readable medium）	软件类发明（美国）	存储的指令、非暂态介质
产品-方法限定（Product-by-process）	结构难以界定	以制造方式定义的产品

多类别权利要求的法律价值在于：同一发明撰写方法+系统+介质等多类权利要求，等于在同一申请内"复制"了多重保护面，无需另案申请。这一点在 patent-writing-principles 中有明确论述，且是中美欧审查实践的共同策略。

不过类别选择受法域与专利类型约束，claims-drafting 给出了精确边界：

中国实用新型（utility model）仅限装置/设备权利要求，禁止方法权利要求，且只需 1 条独立装置权利要求；
美国软件发明可单独撰写non-transitory computer-readable storage medium权利要求（见 patent-format-us 的示例格式）；
EP 的独立权利要求强制两部式（two-part form），涉及新化合物本身、产品-方法限定等例外情形可不采用（见 patent-format-ep）。

因此，本步骤的输出应当是"按目标法域可落地的类别清单"，而非漫无边际的类别罗列。

五、Step 4：附图规划（Drawing Plan）

说明书与权利要求需要附图支撑以实现"充分公开"（enablement）。技能提供了一个最小附图规划模板：

图号	类型	展示内容	支撑的权利要求要素
FIG. 1	框图（Block diagram）	系统架构	系统权利要求的组件
FIG. 2	流程图（Flowchart）	方法步骤	方法权利要求的步骤
FIG. 3	时序图（Sequence diagram）	组件间交互	具体实现细节

处理规则：若用户已提供附图则直接引用；若缺少附图则记录缺口（"note what is needed"）。

附图规划在 patent-format-us 与 patent-format-ep 中有更细的合规要求，可在规划时同步对照：

附图必须展示权利要求中限定的每一个特征；
附图标记须与说明书完全一致（FIG. 1 用 100 系列、FIG. 2 用 200 系列），格式统一为 "FIG. 1"；
图中除附图标记与必要标签外不得出现文字；
中国专利还要求提供"摘要附图"——从申请附图中选取最能代表发明的一幅（见 patent-format-cn）。

另外，specification-writing 会在说明书阶段调用/figure-description子技能处理用户提供的附图，并产出patent/figures/numeral_index.md附图标记索引供审查阶段核对。

六、Step 5：依赖映射（Dependency Mapping）

技能以 ASCII 树形图规划权利要求层级：

Independent Claim 1 (method, broadest scope) ├── Core inventive feature A ├── Core inventive feature B └── Known feature C (for context) Dependent Claim 2 → narrows feature A with specific implementation Dependent Claim 3 → narrows feature B with specific parameters Dependent Claim 4 → depends on 2, adds optional feature D Dependent Claim 5 → alternative implementation of feature A

这份依赖映射的价值在于把"三层分解"翻译为可起草的权利要求清单：核心构思 → 独立权利要求；支撑特征 → 从属权利要求；可选特征 → 更外围的从属/实施例。

在起草阶段，claims-drafting 会进一步落实这里的映射：

连续编号（CN 格式硬性要求）：独立权利要求与从属权利要求交错连续编号（1, 2, 3, …），即使层级上独立权利要求是 1/4/7，最终编号也必须连续无缺；
从属权利要求规则：必须引用在先权利要求编号、必须增加有意义的限定、不得复述母权利要求、不得仅为其他从属权利要求的简单叠加（即"权利要求区分原则"claim differentiation）；
美国多引权利要求只能以 "or" 连接（"claim 1 or claim 2"），"and" 非法；
EP 允许多引（"any one of claims 1 to 3"），但不允许多引权利要求再被多引。

依赖映射还应当与权利要求数量目标对齐：MAX_TOTAL_CLAIMS = 20（USPTO 基础官费包含 20 条）与MIN_INDEPENDENT_CLAIMS = 2（典型为方法+系统）是 claims-drafting 的默认常量，交底书阶段的映射若超出该规模，需在起草时做取舍。

七、Step 6：跨模型验证（Cross-Model Validation）

结构设计完成后，技能要求通过mcp__codex__codex调用REVIEWER_MODEL = gpt-6-astra，以xhigh推理强度进行外部验证。调用载荷格式如下：

mcp__codex__codex: model: gpt-6-astra config: {"model_reasoning_effort": "xhigh"} prompt: | You are a patent attorney reviewing an invention disclosure. Evaluate the structuring choices: INVENTION: [Problem-Solution-Advantage summary] DECOMPOSITION: [Core/Supporting/Optional features] CLAIM PLAN: [intended claim categories and hierarchy] Please assess: 1. Is the Problem-Solution-Advantage framework correctly applied? 2. Is the core inventive concept correctly identified? Are there features that should be core but are listed as supporting (or vice versa)? 3. Are the planned claim categories sufficient to protect the invention? 4. Is the drawing plan adequate for enablement? 5. Are there any claimable aspects being missed?

这五条审查维度分别对应：框架正确性、核心构思识别、类别充分性、附图对充分公开的支撑、可专利点遗漏。这是 ARIS 特有的"交叉模型审查"方法论在专利领域的延伸——与 patent-novelty-check 中的专利审查员验证、claims-drafting 中的权利要求质量审查（含清晰性 112(b)/Art 84、书面描述 112(a)/Art 83、预期 102/Art 54、非显而易见性 103/Art 56、先行基础 antecedent basis、不确定术语等八个维度）、以及 patent-review 中的正式审查意见书（office action）审查形成三级验证体系。

降级与容错规则：如果mcp__codex__codex不可用（例如未配置 OpenAI API 密钥），技能要求跳过跨模型验证并在输出中注明——流水线不得因缺少审查器而失败。同样的降级策略在 patent-pipeline、patent-novelty-check、claims-drafting、specification-writing 中均有一致约定，构成整个专利流水线的通用容错契约。

环境前提：调用mcp__codex__codex需要先配置 Codex MCP Server。仓库中的 patent-review 给出了参考配置命令：
claude mcp add codex -s user -- python3 "$HOME/aris_repo/mcp-servers/codex-exec/server.py"
其中mcp-servers/codex-exec/server.py即本仓库中 codex-exec MCP 服务端的实现路径，可按你的 ARIS 克隆实际位置替换。

八、Step 7：输出发明交底书

技能最终输出patent/INVENTION_DISCLOSURE.md，模板如下（原文完整继承）：

## Invention Disclosure ### Title [invention title] ### Technical Problem [formal problem statement] ### Technical Solution [formal solution description] ### Advantages [measurable advantages] ### Feature Decomposition #### Core Inventive Concept [features that define independent claim scope] #### Supporting Features [features for dependent claims] #### Optional Features [features for embodiments] ### Claimable Subject Matter [method, system, product, medium claims planned] ### Drawing Plan [figures needed, what each shows] ### Dependency Map [claim hierarchy plan] ### Inventor Information [names, contributions] ### Target Jurisdiction [CN/US/EP/ALL]

这个输出结构是"下游即用"的：Feature Decomposition与Dependency Map直接成为 claims-drafting 的输入；Claimable Subject Matter决定权利要求类别清单；Drawing Plan流向/figure-description子技能与附图制作；Target Jurisdiction则最终决定 jurisdiction-format 编译成 CNIPA / USPTO / EPO 哪种申请文件。

在完整流水线中，patent-pipeline 的 Phase 2 会在此处设置检查点（Checkpoint），向用户呈现：

Invention structured: - Core inventive concept: [summary] - Claim categories: [method, system, etc.] - Claims drafted: [X] independent + [Y] dependent = [Z] total - Independent claim 1 (broadest): [first 50 words of claim 1] - Examiner review score: [X]/10

在AUTO_PROCEED = false（默认）时，流水线在此等待用户确认，只有明确回复后才进入权利要求起草阶段——因为专利撰写在每一环节都依赖发明人的判断。

九、关键规则与常见误区

技能末尾列出的关键规则，是区分"专利交底书"与"科研论文/技术报告"的判据，逐条展开如下：

技术问题必须来自现有技术缺陷，而非商业需求——商业动机不是可专利的技术贡献；
技术方案必须描述技术机制，而非结果——"做什么"不足以成立权利要求，"怎么做"才是；
核心发明构思 = 可专利性的最小特征集——这是独立权利要求范围的边界；
支撑特征应各自独立有价值——保证从属权利要求可独立作为后备位置；
禁止虚构实施例——不得编造与真实发明或用户提供材料不对应的实施方式；
跨模型验证不可用则跳过并注明——降级不阻断流程。

结合 patent-writing-principles 中的通用陷阱，交底书/后续权利要求撰写还须规避：

否定式限定（negative limitations）：避免用"不使用数据库"这类"不是什么"定义发明；
结果导向权利要求：禁写"用于达到 99% 精度的方法"，改述机制；
不确定术语："high quality / efficient / optimal"过于含糊（美国会收到 112(b) 驳回），"approximately / about"必须由说明书界定范围；
功能化撰写（means-plus-function）：美国 "means for processing" 会触发 35 USC 112(f)，被限缩到说明书描述的具体结构；更安全写法是 "a processor configured to process"；
术语一致性：同一概念全文同词，不得在 "processor / processing unit / CPU" 间交替；
先行基础："a processor" 首次出现用不定冠词，"the processor" 其后用定冠词，混用会被认为引入了第二个实例。

中国专利还有额外纪律（见 patent-format-cn）：权利要求只写结构特征或方法步骤，禁止写入检测原理、信号特征、测量结果（如"产生负脉冲信号""谐振频率下降"属于说明书内容）；首次引入组件用"一个/一种"，其后统一用"所述"。

十、在完整专利流水线中的位置与入口

invention-structuring不是孤立技能，而是 patent-pipeline 定义的三条研究支线之一（专利线）的中间产物：

┌→ /experiment-bridge → /auto-review-loop → /paper-writing (发表线) /idea-discovery ────┤ ├→ /grant-proposal → [get funded] → ... (基金线) └→ /patent-pipeline → [file patent] (专利线)

专利线可以从多个入口启动，均可汇聚到发明结构化环节：

用户直接描述发明 ──────────────→ /patent-pipeline /idea-discovery 产出 IDEA_REPORT.md ──→ /patent-pipeline (抽取可专利方面) /research-refine 产出 FINAL_PROPOSAL.md ─→ /patent-pipeline (从精炼研究想法出发) /auto-review-loop 产出强结果 ────→ /patent-pipeline (为方法申请专利)

同时，invention-structuring的运行产物patent/INVENTION_DISCLOSURE.md也会被 patent-pipeline 的状态持久化机制跟踪：每个阶段结束时写入patent/PATENT_STATE.json（包含 phase、jurisdiction、patent_type、claims_count、status、timestamp 等字段），中断后可据此恢复，24 小时内的in_progress状态自动续跑，过期则重新开始。

结语

invention-structuring的价值在于在撰写权利要求之前就把法律结构想清楚：用问题—方案—效果框架锁定可专利贡献，用三层分解划定独立/从属/实施例的边界，用主题识别与依赖映射规划权利要求金字塔，再用外部模型以 xhigh 推理强度交叉验证结构的完备性。它产出的INVENTION_DISCLOSURE.md是一份"即插即用"的结构化交底书，可直接驱动下游的权利要求起草、说明书撰写与多法域格式编译。对于希望在 ARIS 中建立从研究想法到专利申请完整链路的用户，可以从 invention-structuring 技能文件入手，配合 patent-pipeline、patent-writing-principles 及 CN/US/EP 三套格式指南，构建完整的专利起草工作台。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考