nature-paper-to-patent

从论文到中国专利

将此文件用作专利撰写工作流的路由器。不要直接从论文摘要或贡献列表撰写申请文件。

1. 加载工作流

阅读 manifest.yaml，然后阅读 always_load 下的每个文件。

从用户的文件和请求中检测以下维度：

• source_format：可选 PDF、扫描 PDF、粘贴文本或混合项目；
• task_mode：完整撰写、权利要求集、公开内容分析、技术交底、交底迭代或论文专利审计；
• invention_type：算法/软件、装置/系统、工艺/材料或混合。

用一行简短文字说明检测到的值。仅加载 manifest 中声明的匹配片段。仅当详细参考的适用条件满足时才加载它们。

2. 保持来源依据

在撰写前创建稳定的来源 ID：

• P001... 用于论文文本块；
• E001... 用于公式；
• F001... 用于来源附图；
• C001... 用于源代码或补充证据。

正式权利要求中的每项实质性特征必须映射到一个或多个来源 ID。支持状态仅使用 explicit、inherent、needs-confirmation 或 unsupported。将 unsupported 特征排除在正式权利要求之外。

永远不要推断发明人身份、所有权、未公开的实现细节、公开日期、现有技术结论或法律充分性。当事实缺失时，在正式权利要求之外使用 [TO CONFIRM: specific question]。

3. 通过阶段门禁进行撰写

对于 full-draft、claim-set、disclosure-analysis 和 paper-patent-audit，按顺序完成 static/core/workflow.md 中的各阶段。持久保存其中指定的中间产物。在来源映射、术语台账、清单、证据台账和发明构思通过各自门禁之前，不要进入正式权利要求。

对于 technical-disclosure，遵循 static/fragments/task/technical-disclosure.md 中按顺序排列的提示词参考。对于 disclosure-iteration，遵循 static/fragments/task/disclosure-iteration.md，并保留先前草稿，而不是重新启动正式申请工作流。

对于完整申请，先撰写权利要求，然后使说明书、附图、实施例和摘要与权利要求术语及步骤顺序保持一致。

4. 产出中文正式文件

面向 Agent 的分析可以使用用户偏好的语言。当任务是正式申请包时，以中文产出正式中文专利交付物：

• 权利要求书；
• 说明书；
• 说明书摘要；
• 摘要附图；
• 附图标记和说明。

对于 technical-disclosure 和 disclosure-iteration，产出带时间戳的 Markdown 格式中文技术交底书（技术交底书）以及匹配的 DOCX，并通过 scripts/disclosure/ 渲染 Mermaid 系统/流程图。

对于算法类发明，保留有来源支持的核心公式，定义每个符号，解释每个公式的技术操作，并在 DOCX 中将公式渲染为原生可编辑的 Office Math。不要使用纯 LaTeX 字符串作为可见公式。

根据主方法权利要求的有序步骤生成主流程图。其最终节点必须命名具体的领域输出，例如缺陷检测结果、目标位姿、状态估计或控制指令。将同一主图复用为摘要附图和说明书附图。

5. 交付前验证

对于正式申请包，填写 references/draft-schema.md 中描述的结构化草稿，然后运行：

python scripts/validate_patent_draft.py draft.json
python scripts/build_patent_package.py draft.json --output-dir outputs --prefix patent

解决所有验证 ERROR 问题。对照来源审查每一条 WARNING。当未达到 static/core/output-contract.md 中要求的质量阈值时，将结果标记为 incomplete draft。

对于技术披露，运行 references/disclosure/disclosure_self_check.md 中的内部检查，使用 scripts/disclosure/mermaid_render.py 渲染 Mermaid/Word 输出，并在交付前解决公式、参数、现有技术 URL 和章节一致性问题。

生成的包是供发明人和专利专业人员审查的起草辅助工具，不是专利性意见、侵权意见或申请保证。