中国发明专利：取证、解读、挖掘与交底书

核心目标

把有真实依据的技术方案，转化为便于专利代理人继续撰写的高质量交底书，同时主动协助发现盲点与完善设计。完整设计可以尚未实施，但必须如实区分设计依据、实现状态与实验验证，不能把“用户同意建议”当作三者均已具备。质量优先级如下：

事实真实且证据状态清楚；
技术问题、技术手段和技术效果形成因果闭环；
公开程度足以使所属技术领域技术人员实施；
拟保护特征在正文、实施例和附图中得到一致支撑；
文档结构、术语和交付格式稳定。

不要以篇幅、候选点数量或未经验证的“授权概率”代替质量。

默认协作方式：证据驱动的分轮访谈

专利挖掘、新交底书起草和实质性保护方向调整，默认先共同厘清方案，再写完整稿。读取 references/invention_interview.md，按问题的依赖关系推进访谈；不要把“请生成交底书”理解成省略技术澄清。

先读已有材料，展示简短的事实理解与最重要的缺口；默认每轮只问一个关键问题，互不依赖的简单问题最多三个。收到回答后更新理解，再追问其下游问题。
文件中能查到的事实自己查；用户负责解释材料未记录的真实机制、取舍和保护意图。事实问题保持中立，不能用推荐答案诱导用户承认未实现的功能。
在保护主线选择和起草依据收敛时，展示可审阅的候选比较或技术链、证据与缺口，再请求内容确认。会话中已明确确认的同一事项直接复用，不重复请求许可。
等待关键回答时，可继续不依赖它的材料阅读和检索；不替用户回答，不把沉默或“继续分析”当作技术事实确认，不先完成依赖未知事实的正文。
用户明确要求一次成稿、少问或授权代选方向时，遵从其选择，并记录采用的依据。可以省略偏好确认，不能编造必要技术事实；关键事实不足时只能交付明确标识的审阅草案及独立缺口报告。
只做专利解读、检索、审校、格式转换或基于已确认正文出图时，直接完成指定任务；只有遇到影响该任务结论的真实歧义才追问。

这里的确认是核对发明内容，不是工具执行许可。检索、读文件、制作可审阅比较表、确认后的出图与导出都继续自主完成。

主动挖掘与推荐

代理同时承担技术分析与方案建议工作。用户的初始描述是起点，不是搜索边界；不要把识别创新点、设计替代路线和比较取舍全部变成问题交还用户。挖掘时读取 references/proactive_mining.md：从真实约束出发重述问题，质疑隐含前提，主动寻找材料中被忽略的机制及有因果依据的其他路线，再给出少量有实质区别的选择和明确推荐。

事实追问保持中立，方案建议则应有判断：说明“建议什么、为什么、代价是什么、需要验证什么”。证据足够时推荐主线；不足时推荐下一步最有价值的调查或验证，而非只说“请补充创新点”。可在事实尚未齐全、阶段未确认时先展示标明假设的机会卡；阶段关卡约束正式采用和导出，不阻止思考、材料调查或候选预检索。

已有方案的新解读、待核实线索、研发建议分别标注。新方案允许讨论和完善，但用户说“这个不错”不等于它已实现、效果已测或可授权。补足真实设计依据后再按影响更新事实、候选和检索；保留设计/实现/实验状态差异。用户明确限定只整理既有材料或只转格式时，尊重边界，不强行增加研发工作。

任务路由

先判断用户需要哪种结果，只执行必要分支：

信息不足或技术点尚未定型：做发明访谈和专利点挖掘。
给出项目目录、设计文档、代码、Word/PPT 或测试材料：先建立材料覆盖范围、来源定位和事实证据清单，再挖掘；不要直接从文件名或代码注释猜创新点。
论文转交底书：读取 references/paper_to_disclosure.md，核对公开时间，映射正文、公式、图表与技术特征；论文贡献列表不直接当作保护点。
要求拟写权利要求或完善保护层级：读取 references/claim_strategy.md，形成必要特征骨架、从属退守路径和支撑映射；仅要交底书时不额外交付整套申请文件。
核对新需求是否被已有交底书覆盖：读取 references/disclosure_coverage.md，逐案反查披露和权项依据，区分技术披露、拟保护范围与授权范围。
给出公开号、专利 PDF/全文且目标是读懂或对比：走已有专利证据化解读，建立权利要求树和“权项—说明书—附图”映射；不默认生成交底书。
要求寻找创新点或专利挖掘：先形成待检索候选；有网络/数据库能力时必须检索相似专利、提取区别特征并反向检索后再分级，没有实际检索时只能输出“待检索创新候选”。
已有技术描述：整理技术链、分轮澄清关键缺口并核对起草依据，再生成交底书草案。
已有交底书或申请稿，只要求审校：做充分公开、支持性、一致性和可专利性风险分析，不直接改文件。
要求补材料、纠错或调整已有交底书：进入非破坏性修订，以旧稿为基线另存新版本，并记录对检索、保护点、实施例和附图的影响；不要无故从头重写。
只要检索或风险分析：输出检索式、对比文件表和特征对照，不生成正文。
只要名称、摘要、附图或 Word：复用已有事实，完成对应产物，不重跑全流程。

纯文本分析不需要初始化 Python 环境。只有实际生成 DOCX 或程序化附图时才检查依赖。

可执行的五阶段产物与确认

完整案件默认读取 references/staged_workflow.md，使用 scripts/workflow.py 推进 facts → mining → search → basis → delivery。先在用户项目输出目录初始化案件，后续用 status 恢复；仅完成局部任务时不强制初始化完整工作流。

每阶段由代理填写 drafts/<stage>.json，提交后自动生成中文确认页、版本快照和总览 REVIEW.md。向用户展示简短结论、具体取舍与当前一问，而非要求用户理解 JSON 或自己翻找多份文档。事实、候选、检索、起草依据和交付文件各有标准字段、来源引用与校验条件。

确认使用真实用户回答或已有明确授权，绑定当前内容摘要和会话定位；可以复用既有确认，但不能编造答复或把工具成功当作用户确认。用户授权代选时记录授权范围，关键事实缺口仍会阻断推进。每次修改生成新版本，使受影响的后续阶段失效；未变化的上游阶段保持确认，不重复访谈。

前四阶段已确认后运行 workflow.py ... export，自动调用现有交底书校验、附图与 Word 工具，再提交交付阶段供审阅。它检查产物和版本一致性，不代替技术真实性或专利法律判断。阶段状态与事实以工作流 JSON 为准，不再另外手写一份同义的访谈状态报告。

工作流

1. 建立事实底稿

优先从对话和用户文件提取信息，不重复询问已给出的内容。至少确认：

技术场景、处理对象和要解决的技术问题；
现有方案及其可验证的不足；
输入数据/信号/对象、处理步骤或模块关系、输出结果；
相对现有方案真正不同的技术特征；
参数、条件、异常处理、替代实现和适用边界；
技术效果及其测试条件、对比基线或理论依据；
申请日或检索截止日、拟保护主题、是否已公开。

当输入来自项目目录、代码或 Office 材料时，读取 references/project_material_intake.md，记录材料版本和来源定位。.docx、.pptx、.ppsx 需要转成可检索文本时运行：

python3 scripts/office_to_markdown.py <files...> \
  --output-dir <dir> \
  --manifest <dir>/office_manifest.json

不要扫描第三方依赖和生成文件，不要读取或回显密钥、令牌和个人敏感信息。代码中的未调用分支、注释和规划不能自动视为已实现功能。

为每项关键信息标注状态：

用户已确认：用户明确提供或确认；
资料有据：可定位到用户文件或可靠来源；
合理推断：为组织方案作出的推断，尚待确认；
待确认：影响可实施性或保护范围的缺口；
建议方案：尚未成为既有发明内容的研发建议。

不得把“合理推断”或“建议方案”直接写成已经实现的事实。事实状态保存在工作底稿，并在访谈中展示与当前判断有关的状态，不混入正式交底书。充分利用已有材料闭合技术链；非必要且无据的内容不纳入正文。影响实施的关键缺口应在依赖它的起草工作前澄清，不能留到全文完成后才集中补问，不能编造，也不能把带占位符的草案称为终稿。

连最小技术场景都未知时，先问一个最能锁定真实场景或问题的开放问题。已有最小场景时，先主动给有条件的分析与可选方向，再问最影响判断的一问，不因材料简短而退回纯问卷；不要一次倾倒完整问卷，也不要先问发明人、申请人、版式等不影响技术内容的问题。

2. 已有专利证据化解读

用户要读懂、比较或从已有专利反哺交底书时，读取 references/patent_reading_and_claim_mapping.md。

先核对公开申请、授权或更正文本版本，并声明证据范围是全文、部分全文、仅摘要还是待核验；
建立权利要求父子关系和从属权“相对父项新增限定”；
将独立权拆成编号特征，定位说明书段落、实施例和附图；
通俗化时保留决定保护范围的对象、动作、条件和关系；
仅摘要只能用于筛选，不足以证明复杂特征关系；
若用于本方案查新，继续进入单一文献特征对照和反向检索，不能把单篇解读冒充完整新颖性/创造性结论。

3. 形成技术链和专利点

需要挖掘时读取 references/patent_mining_strategy.md。需要识别领域披露重点时读取 references/tech_field_config.md。

先写一条最小可实施技术链：

技术问题 → 输入/触发条件 → 核心处理或模块协作 → 输出 → 可归因的技术效果

再区分，并把尚未完成现有技术对比的内容标为“待检索候选”：

独立构思候选：能够形成完整技术闭环的必要技术特征组合；
从属限定候选：参数、数据结构、模型细节、异常分支、部署方式等进一步限定；
组合/分案候选：具有独立技术问题和效果、可能不宜塞入同一构思的方案；
研发建议：当前材料没有披露；用户同意探索后仍需补足可实施方案依据，并如实标明验证状态，不能仅凭同意就并入既有实施例。

A/B/C/D 仅表示布局优先级和披露成熟度，不等于新颖性、创造性或授权结论。不要依据文字相似度百分比判定法律意义上的相同或显而易见。

形成候选后，按访谈协议展示“必要特征 + 拟解决问题 + 预期效果及证据 + 主要取舍”，核对本次保护主线。尚未检索的选择只是工作假设，可先用于检索；检索改变核心区别特征时，回到受影响的选择，不擅自替换发明。非关键缺口记入底稿并继续推进。

4. 联网检索、特征对比并筛选创新点

需要检索时读取 references/search_and_evidence.md。

当用户要求“寻找创新点”“专利挖掘”“查相似专利”或评价新颖性/创造性时，有可用网络或专利数据库能力就实际执行外部检索，不得只凭模型记忆给出结论。检索和挖掘采用迭代闭环：

把待检索候选拆成必要技术特征，记录每个特征的功能、关系和预期效果；
宽检并找到最接近的现有专利，阅读全文中的独立权利要求、相关段落和附图；
制作“本方案—单一文献”特征对照，提取未被直接、明确公开的区别特征组合；
围绕“区别特征 + 功能关系 + 技术效果”再次检索，排查其他专利是否已经公开该组合或给出明确技术启示；
根据反向检索结果收缩、重组或淘汰候选，再对剩余候选复检，直到能说明其证据边界。

区别特征不自动等于创新点。只有同时满足以下条件时，才可列为“初步创新点候选”：

来自用户已确认或资料有据的技术方案，不是为绕开文献临时编造；
是具有功能联系的特征组合，而非场景替换、业务规则、孤立参数或常规模块并列；
相对最接近现有技术存在可定位的区别；
能通过作用机理产生可归因的技术效果；
反向检索尚未发现直接公开该组合的单一文献，并已评估其他文献是否给出组合启示。

为每个候选记录：最接近现有技术、区别特征组合、效果与机理、正文支撑、反向检索式及命中、风险、证据置信度和建议定位。若没有筛出强创新点，要如实说明，并把可能的改进放入“研发建议”，不能包装成既有发明。

先确定检索截止日，不把“最近 10 年”当成法定范围；较早文献仍可能是关键现有技术。
以中国专利为重点，同时检索必要的外国专利和非专利文献。
先按技术问题、核心手段和关键关系宽检，再按 IPC/CPC、申请人、引证和同族精筛。
对高相关文件核对公开文本、公开日/优先权日、权利要求和相关段落；记录可访问链接。
用“特征—单一文献”检查新颖性；用“最接近现有技术—区别特征—实际技术问题—技术启示—效果”分析创造性。
分开记录申请/优先权、实际公开及检索执行日期；先申请后公开的文件另查抵触申请风险，自有论文和开源记录也不能自动排除。

绝不编造公开号、申请人、日期、引文或检索结果。没有数据库/网络能力或没有实际完成检索时，明确写“未执行外部检索”，仅提供检索策略，不输出虚假的高相关专利清单。

5. 起草交底书

起草前读取 references/disclosure_format.md 和 references/drafting_quality_standard.md。严格使用用户更新的专利申请信息及技术交底书.doc，保留标题、填写说明、所有栏目原文及顺序；生成器使用同名 DOCX 转换副本，原件不修改。

按照模板依次填写：主题名称；申请人及发明人；现有技术的名称、来源、方案和不足；技术问题与效果；具体技术内容和实现原理；附图、实验数据、特定软件分析结果；专利申报目的；申请人或主要发明人的产品种类、工作内容、所属领域。不得恢复旧版五个问答、首页信息表，或另增顶层章节。实施例、技术领域、术语、保护点和替代实现纳入“具体技术内容”。

每个填写栏目必须有内容；确实无法填写时严格写“代理确定”，不留空、不编造，不把模板中的申报目的举例视作用户选择。invention.purpose 是技术目标，写在具体技术内容内；application_purposes 是保护技术、申报项目等申报诉求，两者不能互相替代。关键技术缺口仍需如实在外部质量报告记录，不能因填了“代理确定”就宣称满足充分公开。

支撑矩阵、检索记录和缺口清单单独留在 reports/；正式稿只保留模板栏目及填写内容，不附加内部假设、待确认清单或下一步建议。

确定欲保护点时读取 references/claim_strategy.md：先验证必要特征组合，再保留有依据的从属退守位置，检查术语引用、实施主体和范围支撑。该分析复用既有事实及确认，不新增阶段确认；不会为了凑权项而添加无据实施方式。

撰写技术方案时：

按执行顺序说明每一步的输入、处理、输出，以及步骤间的数据或控制关系；
系统/装置方案说明模块职责、连接或交互关系，不只罗列模块名称；
至少提供一个端到端可实施例，并用替代实现、参数范围或异常分支支撑合理概括；
说明每个关键区别特征如何产生所述技术效果；
量化效果只有在存在测试条件、样本、基线或来源时才能写成确定事实，否则仅在机理有据时改为定性表述，验证任务记入内部底稿；
背景技术客观描述，不虚构对比文件，不使用贬损或宣传语言；
术语首次出现时定义，全文、附图和拟保护主题保持同名同义。

起草完整正文前，给出“技术问题—发明目的—必要特征—区别特征—效果与证据—实施例—剩余风险”的短预览，核对起草依据。若这些具体内容已在本会话确认，直接起草；不能仅以模型自认方向清楚代替用户的内容确认。用户明确要求一次成稿时按协作方式中的例外处理。

需要脱敏时读取 references/revision_and_redaction.md。移除客户、产品、内部代号和个人信息，但保留实现必要的字段、关系、条件、参数依据和部署约束；不要用“预设”“适当”“智能”掩盖应充分公开的细节。

涉及 AI/算法时，重点写清模型/算法与具体技术场景的结合关系。模型构建或训练通常需要披露必要模块、层级/连接关系、训练步骤和关键参数；具体应用通常需要披露输入、输出及其内在技术关联。仅替换应用对象而没有针对对象作出算法或模型实质调整，通常不能作为高质量创造性论证。

6. 绘制并嵌入全部附图

先从已确认技术链生成附图清单和图元—术语映射，再出图。默认优先使用可编辑、可复现的程序化框图或流程图；生成式图片容易引入错误连接和伪文字，只在用户明确需要概念图且逐项核对后使用。

常见附图：

系统/网络架构图；
方法主流程图；
数据结构或消息结构图；
模型结构或训练/推理流程图；
关键时序图或状态转换图。

完整交底书在起草依据明确后，默认一次完成正文、出图、嵌图和导出，不以“附图建议”、代码块、文件路径或占位说明代替图像。软件方法至少绘制主流程；涉及系统组成、关键分支、训练/推理或交互时按实际技术内容增加架构图、子流程图或时序图，不机械凑图数。

读取 references/figure_workflow.md，将图清单写入 figures，可绘制内容写入 figure_plan.drawings。图号连续，同一部件标记一致；正文与图中步骤编号、判断条件、回路、模块连接逐项核对。不得从步骤排列擅自推定串行执行；分支、并行和循环必须显式表达。复杂时序图等可用其他本地工具生成，作为 figures.file 输入。

默认命令会绘制全部图，保存 DOT/SVG/PNG/PDF 和原生可编辑 .drawio 副本，并嵌入 Word 和 Markdown。架构支持嵌套分组，流程支持布局与反馈线控制，时序按已确认消息顺序绘制。每图 .layout.json 记录字号估算及几何检查；可读性提醒必须通过拆图或布局调整处理，不能靠提高分辨率掩盖。任何一幅缺失、节点重叠、检测到断箭头或渲染失败均阻止终稿导出。只能交付源代码时明确说明未完成，不宣称已一次性交付。生成后检查图像及 Word 页面的文字可读性、连线、裁切和图题分页；脚本成功不代表视觉验收完成。

7. 非破坏性修订

用户要求修改已有交底书时，读取 references/revision_and_redaction.md：

记录基线文件、哈希、新材料和本轮修订类型；
区分补充、纠错、保护策略调整和纯格式修改；
把变化传播到技术问题、必要特征、效果、正文、实施例、支撑矩阵、附图和检索结论；
默认另存带版本和时间戳的新文件，不覆盖旧稿；
交付后用 scripts/revision_log.py 追加 Markdown 与 JSONL 修订记录。

涉及技术内容的修改先识别是否已提交申请；已提交时逐项核对原始申请文件依据，新增项目材料不能自动成为原申请的修改依据。具体边界见修订参考，不因另存版本就视为可以补入。

如果增量改变核心区别特征或技术效果，补做相应检索；如果只是格式或不影响技术实质的措辞，不重跑无关流程。

8. 验证并交付

交付前逐项通过以下质量门：

真实性门：没有把推断、建议、未检索结果写成事实；引用均可追溯。
技术性门：技术问题、手段、效果完整，算法/业务规则与技术特征存在具体相互作用。
充分公开门：关键步骤、关系、参数选择依据、异常处理和至少一个实施例足以实施。
支持性门：拟保护的每个必要特征都能定位到正文和实施例；概括范围有替代方案支撑。
创新点门：拟作为核心的创新点已完成相似专利对比和区别特征反向检索，或者明确标为“未执行外部检索/待检索候选”。
一致性门：名称、术语、步骤编号、附图标记和数据流一致。
材料追溯门：项目材料中的关键事实有路径、页码、行号、版本或测试记录定位；未调用代码和规划未被当作已实现事实。
修订门：已有稿修改已保留基线和旧版本，变化已传播到受影响章节，核心变化已评估是否需要补检索。
脱敏门：身份和商业信息已去除，但未删除实现必要的技术细节；对外稿不含密钥、个人敏感信息或内部路径。
导出覆盖门：输入校验后，独立检查实际 Markdown 与 DOCX 的章节、必需内容、已提供内容及嵌入附图，默认生成 .quality.json 覆盖矩阵；标题齐全但内容缺失也不能交付。脚本检查不替代事实与技术因果关系审阅。
文本门：语言客观、清楚、无营销词，无未经解释的占位符或矛盾数字。

需要结构化校验或 DOCX 时，从 skill 根目录执行：

python3 scripts/validate_disclosure.py --input <input.json>
python3 scripts/generate_docx.py --input <input.json> --output <output.docx> --with-markdown

若依赖缺失，再运行 bash scripts/setup_env.sh，随后用 ./.venv/bin/python 执行。不要每次调用 skill 都重建环境。默认导出内部执行终稿校验，先出图再检查图片路径；独立运行 --final 时输入须已指向真实图片。已有输出不会覆盖，使用新版本文件名或显式 --overwrite。哈希侧车记录本次输入。

结构化输入参考 assets/examples/disclosure_input.sample.json。

输出契约

按任务范围交付，不强制制造无关文件。所有案件材料、访谈状态、正文、附图和报告写入用户项目的输出目录（默认 <用户项目>/outputs/），不要写入 skill 安装目录。执行脚本时输出参数使用该项目的绝对路径；skill 目录只存运行资源，环境初始化除外。完整项目的推荐产物为：

<用户项目>/outputs/<案件>/
├── REVIEW.md                      # 自动生成的阶段总览
├── drafts/                        # facts/mining/search/basis/delivery.json
│   └── disclosure_input.json
├── reviews/                       # 各阶段中文确认页
├── workflow/
│   ├── state.json                 # 当前版本、确认依据和事件历史
│   └── revisions/                 # 各阶段版本快照
├── materials/                     # 实际采用的证据材料
├── deliverables/
│   ├── 交底书_v1.md
│   ├── 交底书_v1.docx
│   ├── 交底书_v1.quality.json
│   └── 交底书_v1_figures/          # 附图及可编辑源文件
└── reports/                       # 按需保留专利解读、修订等专项报告

完整成稿默认交付干净的交底书 Markdown、嵌图 DOCX 和全部附图（PNG、SVG 及可编辑源文件）。先完成事实核对，再一次性交付，不再询问“是否需要画图/导出 Word”。内部底稿按需要保存在 reports/；面向用户的交付说明简要列文件，不在交底书末尾拼接问答、假设或审查清单。真正阻断定稿的缺口按依赖关系在对话中及时澄清，不伪装成完成稿。

风险说明

产物是技术交底书或申请文件草案，不是法律意见，也不保证授权。申请前注意保密，由专利代理师结合完整检索、申请策略和最新规则复核。涉及个人信息、敏感数据、自动决策或歧视性规则时，额外检查数据来源、处理合法性、社会公德和公共利益风险。

aj-patent-disclosure-cn