中文发明专利撰写

目标

把技术事实转换为层次清楚、术语一致、获得说明书支持的中文发明专利草案。优先保护可验证的技术手段及其协同关系，不以功能口号、商业目标或界面外观替代技术特征。

工作原则

• 区分发明人已经实现、明确计划实现和仅由模型建议的内容。不得把建议伪装成既有事实。
• 在缺少决定性技术事实时列出“待确认事项”，不得凭空补写尺寸、材料、算法参数或实验效果。
• 把相关专利视为边界证据，不复制其表达，不以标题或摘要代替权利要求比对。
• 先确定独立权利要求的最小必要技术特征，再写说明书；不要从完整实施例机械压缩独立权利要求。
• 保持装置、系统、方法、介质等主题之间的技术特征对应。仅在资料支持且有保护价值时增加并列主题。
• 明确提示草案需由专利代理师结合正式检索结果与申请策略复核。

输入分流

1. 读取用户提供的技术交底、既有专利、附图和检索清单。
2. 对 DOC/DOCX 使用文档处理能力提取正文；对 PDF 使用 PDF 读取能力核对图文；只在版式影响理解时渲染页面。
3. 判断任务属于以下哪一种：
   • 从零起草完整申请文件；
   • 只起草或修改权利要求；
   • 根据已有专利设计改进专利；
   • 审查现有草稿；
   • 形成技术交底书。
4. 若用户要求查新或法律状态核验，先使用可用的专利检索来源并记录公开号、文本版本、检索日期和不确定性。

标准流程

1. 建立事实底稿

输出并确认以下内容：技术领域、应用场景、现有流程、客观技术问题、组成部分、连接关系、数据或能量流、控制逻辑、替代方案、技术效果、附图和术语表。

把每项事实标记为“资料明确”“合理推导”或“待确认”。若合理推导会改变保护范围，先向用户确认。

2. 提炼发明点

读取 prior-art-and-invention-point.md，建立“现有技术特征—本方案特征—区别特征—解决问题—产生效果—证据位置”矩阵。

至少形成一个主发明构思和可选的次级构思。若多个构思缺少单一总的发明构思，建议拆分申请，不要强行拼接。

3. 设计权利要求

读取 claims-drafting.md。先写独立权利要求的特征骨架并验证每个特征均有说明书依据，再写完整句式和从属权利要求。

对软件或数据处理主题，写清数据来源、处理对象、关键处理步骤、步骤间关系以及产生的可验证技术效果。避免只写“分析、判断、展示、控制”。

4. 撰写说明书与摘要

读取 specification-drafting.md，按 assets/application-outline.md 的顺序成稿。让背景技术只陈述与本发明相关的缺陷，不贬损、不虚构、不提前泄露完整解决方案。

为每个权利要求特征提供至少一个实施依据；为关键上位概念提供下位例和可替换方案。摘要保持单段、客观、无宣传性语言，不写未在说明书支持的内容。

5. 审查与交付

读取 quality-review.md，逐项检查：

• 新颖性风险与最接近现有技术；
• 独立权利要求是否包含全部必要技术特征；
• 从属关系、引用基础和主题一致性；
• 说明书支持、公开充分、术语和附图标记一致性；
• 技术问题、技术手段和技术效果是否形成因果链；
• 是否混入未经确认的技术事实。

对 Markdown 或纯文本草稿运行：

python scripts/patent_lint.py <draft.md>

把脚本结果作为机械检查线索；人工复核其无法判断的保护范围、支持性和创造性问题。

交付格式

根据用户要求交付以下一项或多项：

• 发明点与现有技术对比.md
• 待确认问题.md
• 权利要求书.md 或 .docx
• 说明书.md 或 .docx
• 说明书摘要.md 或 .docx
• 附图说明与附图标记表.md
• 一致性审查报告.md

需要 Word 文件时，使用文档创建能力排版并进行渲染检查；不要只改变文件扩展名。保留可编辑源文件，并在交付说明中列出仍需代理师确认的风险。

停止条件

出现以下情况时先停在分析或问题清单阶段：

• 缺少能够区分现有技术的具体技术手段；
• 用户只能描述目标效果，无法说明输入、处理、输出或结构关系；
• 关键术语在不同材料中含义冲突；
• 用户要求隐瞒发明人、伪造实验、编造实施数据或照抄他人权利要求。