patent-application-creator

专利申请创建技能

开展完整的专利申请活动：基于用户现有的任何材料——代码库、发明披露材料、零散笔记——要么产出可直接提交的临时申请文件包，要么给出有理有据、有证据支撑的解释，说明为何不能申请。

此工作流经过实际运行检验并加以强化（2026 年 7 月，在生产代码库上开展了一次完整的申请活动）。以下每个阶段的存在，都源于那次活动中跳过相关步骤所付出的代价。

约定

• 诚实的结果就是交付成果。“这里没有任何内容达到新颖性门槛，以下是足以否定每个候选方案的现有技术”是成功，不是失败。“这项发明可以申请专利，但不值得你花钱——不申请，或者采取防御性公开”也是如此。绝不夸大薄弱的候选方案。
• **申请活动保护的是用户的钱，而不只是用户的申请。**本工具服务的人群，负担不起为商业价值微不足道的专利准备技术上完美的申请文件包。在进入昂贵阶段之前就要判断是否值得申请，每当权利要求范围缩小时都要重新判断——如果到最后才发现只能构筑“小围栏”，那么这场申请活动早已花掉用户的预算，却回答了错误的问题。
• **机器检查把关，人类核验。**所有标记为低置信度的自动化发现都要人工核验；每份确认无异常的报告都要列出已运行的检查以及跳过的检查。
• **日期很重要。**现有技术持续不断地公开；在检索过程中发现的时效性风险要记录下来，并在申请文件包中说明。对于临时申请，尽早提交胜过花更长时间打磨。
• **AI 绝不是发明人。**用户才是。AI 负责挖掘、检索、起草和核验；受到保护的是用户的创作。

阶段 0 — 资料收集（任何原始材料）

接受用户提供的粗略需求，不要要求其先整理。如果材料是代码库，不要要求提供发明披露材料——挖掘是阶段 1 的任务。只询问无法从材料中推导的信息：发明人姓名，以及其中是否有任何内容已公开披露或出售（法定截止日期）。然后审查发明人自己的公开足迹——已发布的产品、演示、公开代码仓库、营销页面——并记录首次披露日期：发明人自己的披露会启动美国宽限期的计时，也可能立即导致外国权利丧失。要在起草之前完成此项工作，而不是之后。

阶段 1 — 发明挖掘

寻找具体的技术机制，而不是功能特性。对于代码库，安排多个阅读者并行检查（每个子系统一位），并采用以下标准：候选方案必须 (a) 具体且已实现，(b) 解决技术问题，(c) 可以合理认为非常规——绝不能是教科书式的身份验证、增删改查或缓存。对于每个候选方案，记录：机制（怎么实现，而非是什么）、证据位置、解决的问题、胜过的常规替代方案，以及差异为何不显而易见。

然后使用以下标准进行筛选（淘汰／继续）：

• 第 101 条筛选：无论构思多巧妙，计费、商业活动和组织人类活动等主题都会招致 Alice 案相关驳回——降低优先级。
• 拥挤领域筛选：线程池、重试、分布式同步、测试方法——除非有不寻常的创新，否则淘汰。
• 统一性筛选：寻找一个由多个候选方案体现的原则；包含多个实施例的系统权利要求，优于零散的小型权利要求。

Phase 1-H — 历史挖掘（当材料是 git 仓库时）

当前代码展示了现存内容；历史则展示了它取代了什么、实现难度有多大，以及发生时间——其中还保存着 HEAD 的读者永远无法发现的机制，因为它们已在被放弃的分支中消亡。对于经常重建的发明者而言，被放弃的分支中藏着最纯净的素材：从未合并的机制从未部署，因此没有开始运行的披露期限，外国权利也完整无损。 只要原始材料有 git 历史，就应在 Phase 1 代码挖掘的同时执行此流程。

漏斗（已在一个拥有 808 次提交、9 个分支和 92 个 PR 引用的真实仓库中验证：约 250 万个 Agent token，耗时数分钟）：

1. 枚举所有内容。 镜像克隆；也要获取 +refs/pull/*/head。git rev-list --all 列出全集。诚实说明限制：托管平台只提供仍可通过引用访问的提交——被强制推送抹去的历史已不复存在，因此标记应写“托管平台目前仍保留的内容”，绝不能写“曾经存在过的所有内容”。
2. 按 patch-id 合并。 git rev-list --all | git diff-tree --stdin -p -r | git patch-id --stable —— 数百个分支中的 cherry-pick 和 rebase 会合并为各自的一条记录。成本随唯一补丁数量增长，而非随分支数量增长。（不要传入 --no-commit-id；patch-id 需要提交行来归属补丁。）
3. 机械分流至具名类别。 排除噪声主题（依赖项／文档／合并）、仅涉及锁文件或二进制文件的补丁，以及微小差异——每项排除都必须归入一个类别，并记录其主题。覆盖率必须保持可核算：全集 = 已读 + 已排除，且两者可对账。
4. 阅读每个幸存补丁。 分批处理补丁（每个 Agent 约 30 个，每个 diff 上限约 7 KB，并披露此上限），并要求每位读者为每个补丁给出一个判断，且报告阅读的补丁数量——逐批核对数量。区分 MECHANISM 与 ROUTINE，并记录“此 diff 取代了哪种常规做法”。明确要求读者：绝不要降低对已放弃或未完成工作的评价——被放弃的巧妙设计正是目标。
5. 聚类并定位。 多次提交中出现的同一机制应归为一个集群。对每个候选机制：使用 git branch --contains 检查分支，并确认其相对于默认分支的可达性；随后对照已发布代码，确认该机制是否已迁移（桥接分支可能会让“搁置”的提交内容在其他位置继续存在——应检查已部署的源码，而不是分支拓扑）。只有“在所有已发布内容中均不存在”的机制，才可标记为未开始披露期限。
6. 持续进行第二轮对抗性审查，直至没有新发现。 单一视角会有疏漏；使用“第一轮误判了什么？”这一提示词重新审查 ROUTINE 集合，直到某轮没有新发现。

历史还能提供 HEAD 无法提供的信息：diff 会展示被取代的常规替代方案（这是 Phase 1 中最难填写的字段）；突破前一连串失败尝试，是客观证明非显而易见性的证据；提交日期和作者信息则是构思记录。像对待其他候选项一样，将幸存的候选机制送入 Phase 1 的分流筛选（包括 worth-it）。

阶段 2 — 现有技术：逐一检索所有渠道，采取对抗式审查

仅检索专利对软件而言远远不够：真正能否定新颖性的现有技术通常存在于产品、开源项目、标准和论文中。检索以下所有渠道：

1. 专利：search_patents_google（全球全文检索，包括权利要求；必须匹配所有词，因此应优先使用有辨识度的术语；添加 CPC=G06F16/00 之类的术语，以限定在某个分类中），以及 Google Patents 页面（可免费深入阅读）。没有 SerpApi 密钥时的备用方案：search_patents_bigquery 和 search_patents_by_cpc_bigquery，但在那里进行关键词检索会扫描约 341 GiB（约 2 美元，相当于一个免费月份额度的三分之一）。
2. 非专利文献：针对每组权利要求，分别派出对抗式网络研究 Agent，每个 Agent 都要设法否定权利要求：检索产品（现有写作／编码助手究竟能做什么？）、开源项目（阅读代码）、标准组织、arXiv 和工程博客。
3. 要求每个 Agent 对每项资料给出结论：“我们的方案具备而该资料缺少的内容”，或“足以否定新颖性”。汇总为：干净的立足点（写入独立权利要求）、致命风险区（绝不可单独主张）、必须阅读的权利要求资料（提交实用专利申请前，律师必须阅读的参考资料）以及尚未解决的线索（被机器人拦截的页面等——上报给用户，绝不能悄悄略过）。

措辞规范（不可妥协）。 检索结果只支持这样的表述：“截至[日期]，在[已检索渠道]中未发现足以否定新颖性的资料”，并须附有按日期记录、逐项对照的表格。绝不可将“没有人做过”“不存在现有技术”“已彻底检索干净”或“能够经受审查”写成事实——Agent 对代码库的审查只是对不断演进的代码库所做的一次快照，几周后再次审查，结论就可能相互矛盾。还有一条在紧急情况下很容易弄错的日期规则：已公开的第三方现有技术永远无法被抢先。 任何已经公开的内容都是之后任何申请的现有技术，无论是否有宽限期；关于紧急提交申请的理由，只适用于尚未发生的披露。

决策关口：如果没有任何候选方案拥有干净的立足点，就撰写不继续报告（列出候选方案、否定它们的参考资料及逐项理由），然后停止。该报告就是交付成果。随后，按照每个幸存方案检索完成后的实际范围，重新进行是否值得申请的评估：干净的立足点必然比阶段 1 的候选方案更窄，关键问题是：更小的保护范围是否仍会让竞争对手付出代价。若某个幸存方案现在可以通过明显的变体规避，也要将其写入不继续报告——指出具体的规避设计，并说明防御性公开这一替代方案（成本几乎为零、永久有效，并能阻止第三方日后就相同机制取得专利）。

阶段 3 — 以权利要求为先进行撰写

先撰写权利要求，再撰写说明书；干净的现有技术范围决定权利要求内容。

• 每项独立权利要求中承载关键作用的限定，都必须是检索未曾发现的要素。单独发现的要素放入从属权利要求。
• 正确格式：“The method of claim N, wherein ...”——绝不使用简写（分析器的从属关系跟踪和审查员都需要完整格式）。
• 术语保持一致：首次引入时使用 “a/an”，后续引用时使用 “the”，并使用完全相同的名词短语。
• 如果明确排除已知现有技术的成本不高，就明确排除（例如，最接近的现有技术按时间到期来解除抑制，则写明“not by elapsed time”）。
• 跟踪不断缩小的保护范围。 每次明确排除现有技术，以及每次缩小权利要求的修正（此处以及阶段 5 的攻击审查之后），都会让竞争者更容易绕开。攻击审查确定最终权利要求形态后，再对实际保留下来的内容进行最后一次值不值得申请的筛选；在项目包 README 中记录结论（绕开成本、可检测性、建议申请临时专利还是进行防御性公开），以便用户针对实际能够获得的专利做决定，而不是针对自己设想的专利做决定。

然后撰写说明书：技术领域、背景技术（以技术角度表述问题）、发明内容（每项独立权利要求各用一段）、附图简要说明、包含所有实施例并带有附图标记的具体实施方式、实施过程，以及变形方案段落（扩大范围：任意模型、任意相似度度量，阈值仅为示例）。说明书必须逐字包含每个权利要求术语，支持性检查器会进行核验。

经源代码验证的权利要求（强制要求）。 每项权利要求的每个限定都必须根据实现本身进行验证——打开代码查看——不能依据挖掘 Agent 的摘要，也不能依据可能过时的头部注释（某次真实项目中，契约文档描述的是最近匹配项重定位，但其下方的可执行代码却包含歧义拒绝门；根据摘要撰写的权利要求因此有误，并且与说明书相矛盾）。实际实施过程是确定权利要求、说明书和附图必须如何表述的最终依据——三者必须描述相同的算法，或者明确将每种变体列为单独的实施例。绝不能声称实现中不存在的行为（例如，代码从未执行的“有效保存型计划结果”重新分类，是等待被驳回的新事项）。

终止状态完整性。 任何声称具有确定性终止、有限重试次数或保证结果的说明书，都必须列出每一种终止状态和每一次预算转换——包括那些不起眼的情况（机械耗尽、全局超限兜底机制）；附图必须展示每个分支，并为分支边加上标签。

附图：使用 create_block_diagram 绘制系统图（编号组件须与说明书一致）；针对每项独立权利要求，使用带有手写 DOT 的 render_diagram 绘制图示，以便决策分支的连线标注 Yes/No（create_flowchart 不会为连线标注）；每个节点都要带有附图标记。

阶段 4 — 机器验证循环（迭代直至通过）

1. patent-creator config set PATENT_ENABLE_ANTECEDENT_CHECK 1 — 先行基础检查默认关闭；每次专利申请工作都必须运行。
2. 对完整的权利要求集运行 review_patent_claims。修复确实存在的问题（形式、术语漂移）；手动核验每一项剩余的低置信度标记，并记录判定结果——这项人工审查是工作流的一部分，不可省略。
3. 运行 review_specification（权利要求 + 说明书）——持续迭代，直至关键问题为零：每个被标记的权利要求要素都必须逐字融入说明书。
4. 运行 check_formalities（摘要 50-150 个单词、标题限制、章节）。

验证印记带有内容哈希，编辑会使其失效。 每条记录的检查结果都必须注明所检查的确切文档文本的 SHA-256（或等效哈希值）。之后的任何编辑——增加一项权利要求、修改一句话——都会使该文档上的所有印记失效；打包前必须重新运行检查。README 若声称某份文档“已验证”，但该文档在验证后又经过编辑，这是打包内容中危害最大的谎言，因为审查者一旦发现，就会不再信任其他所有内容。（这与该专利申请工作本身针对 AI 扫描所实施的输入指纹纪律相同；请将其应用于自身。）

阶段 5 — 两轮红队审查，而非一轮

5a. 敌意审查员攻击轮（权利要求）。 让对抗性 Agent 扮演 USPTO 审查员，对最终权利要求发起攻击，并提供检索中最接近的对比文件：最有力的新颖性（102）论据、最有力的显而易见性（103）组合论据（逐项权利要求要素映射到对比文件，并说明组合动机），以及 Alice（101）攻击及其技术解决方案反驳。如果攻击得逞，就缩小权利要求范围，或将被驳倒的要素移至从属权利要求——然后针对变更后的权利要求重新运行阶段 4。

5b. 打包红队审查（整个文档包）。 仅攻击权利要求还不够：文档包的权利要求可以无懈可击，却仍不适合提交。首先运行确定性关卡：对组装好的目录运行 check_package。它会重新计算每个内容哈希验证印记（记录检查后发生编辑属于关键失败），将权利要求数量与每处“N 项权利要求”的声明交叉核对，标记与草稿标记并列的就绪状态表述，查找提交文件中的评论，并进行日期合理性检查。先修复所有关键问题，再投入审查者精力。然后将组装好的文档包——每个文件，仅此而已——交给一名对抗性审查者。该审查者不得了解任何申请背景，其任务是找出：README、权利要求、说明书和附图之间的内部矛盾；文档本身与之相矛盾的验证声明；早于编辑时间的印记；日期错误；不得提交的策略评论；对现有技术的宽泛定性；以及缺乏依据的权利要求措辞。文档包通过红队审查之前，任何内容都不得描述为可直接提交。（某次真实申请工作中，权利要求经过攻击并加强后，正是这种全新的审查发现了问题：README 声称“已验证”，旁边却有一个过时的“尚未完成合规检查”标题；一项权利要求是在记录检查后新增的；还有三个文档描述了三种不同的协调算法。权利要求红队审查未发现这些问题，因为它们都与权利要求无关。）

阶段 6 — 打包

工作副本和提交副本是分开的文件，提交副本通过机械方式生成。 提交文件只包含权利要求和披露文本——不含任何方括号括起的策略备注，不含任何审查器评分，不含任何“与现有技术对比”的评论，不含任何后续步骤章节，也不含任何限制策略。背景部分不得对现有技术作出绝对承认（使用“发明人所知”的措辞，而不是“没有系统能做到 X”）。用脚本剥离工作副本，生成提交副本，然后进行差异检查，确认只剩权利要求／披露文本。

提交目录中应包含：说明书和权利要求（提交副本）；附图（转换为符合 Patent Center 要求的 PDF——Letter／A4 纸张、嵌入字体，并在转换后进行目视检查；从浏览器打印 SVG 并非质量控制流程）；SB/16 封面表数据（发明人居住地、通信地址）；如主张微型实体资格，则提供相关认证（注意：以总收入为依据还要求符合小型实体资格、满足计入申请数量限制，并且所有权权益持有人具备相应资格）；以及一份 README，说明 pro-se 临时申请路径和 12 个月实用专利期限，并列出最终律师审查所需的强制审查清单和未解决线索。明确说明该材料包的性质：它是一份旨在加快人工法律审查的临时申请——并非其替代品——并使用内容哈希戳说明其验证状态，绝不可只写“已验证”。

此工作流旨在防止的失败模式

• 发明明明写在代码里，却轻信披露访谈。
• 只检索专利现有技术（致命的对比文件通常是某个产品）。
• 把检索发现的元素写入权利要求（应放入从属权利要求，否则就舍弃）。
• 关键检查项被悄悄关闭，却报告“100% 合规”。
• 在说明书中转述权利要求术语（支持缺口会在审查过程中暴露）。
• 竞争对手即将发布时仍反复润色（日期压力是真实存在的）。
• 明知申请质量薄弱，仍提交，而不是坦诚地决定不推进。
• README 声称材料“已验证”，但材料在检查后又被编辑（没有内容哈希的戳记就是等待被揭穿的谎言）。
• 根据 Agent 的摘要而非源代码起草权利要求，或依据过时的头部注释而非可执行主体起草。
• 权利要求、说明书和附图描述的同一算法竟有三个不同版本。
• 权利要求用语描述了实现中并不存在的行为。
• 声称“确定性终止”，却没有列举所有终止状态。
• 对已经发布的现有技术紧急喊着“赶在 X 前提交”（无法抢在它前面；只有未来的现有技术才可以）。
• 面向专利局的文件中还留有策略评论、审查器评分和绝对化的新颖性断言。
• 只攻击权利要求，却从未检查整套材料。
• 花预算证明某项权利要求具备可专利性，却始终不问最终形成的保护范围是否值得拥有——在分流评估时要问，检索范围缩小时要再问，攻击审查缩小权利要求时还要再问。