# Aj Patent Disclosure Cn > 从项目文档、代码、Word/PPT、访谈或已有专利中提取证据，生成、审校和非破坏性修订中国发明专利技术交底书，重点覆盖软件、互联网、人工智能、大数据、区块链、物联网和网络安全方案。用于项目扫描、发明访谈、专利点挖掘、已有专利通俗解读与权利要求树、联网查找相似专利、单一文献特征对比、区别特征反向检索、创新点筛选、充分公开与支持性检查、脱敏、附图、Markdown/Word 交付及版本留痕；当用户提到专利交底书、发明专利稿、读专利、专利解读、查重、相似专利、专利挖掘、寻找创新点、新颖性或创造性、权利要求支撑、说明书补强、修改已有交底书、专利附图时，即使只要求其中一个环节也应使用。 - Skill: `zuoa/aj-patent-disclosure-cn` (Agent Skill, multi-file: 32 files) - Install (CLI): `npx skillmds add zuoa/aj-patent-disclosure-cn` - Raw SKILL.md: https://api.skillmd.com/api/skills/zuoa/aj-patent-disclosure-cn/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: zuoa (https://skillmd.com/u/zuoa) - Updated: 2026-09-09 - Page: https://skillmd.com/skills/zuoa/aj-patent-disclosure-cn --- # 中国发明专利：取证、解读、挖掘与交底书 ## 核心目标 把已真实完成或可验证的技术方案，转化为便于专利代理人继续撰写的高质量交底书。质量优先级如下： 1. 事实真实且证据状态清楚； 2. 技术问题、技术手段和技术效果形成因果闭环； 3. 公开程度足以使所属技术领域技术人员实施； 4. 拟保护特征在正文、实施例和附图中得到一致支撑； 5. 文档结构、术语和交付格式稳定。 不要以篇幅、候选点数量或未经验证的“授权概率”代替质量。 ## 任务路由 先判断用户需要哪种结果，只执行必要分支： - **信息不足或技术点尚未定型**：做发明访谈和专利点挖掘。 - **给出项目目录、设计文档、代码、Word/PPT 或测试材料**：先建立材料覆盖范围、来源定位和事实证据清单，再挖掘；不要直接从文件名或代码注释猜创新点。 - **给出公开号、专利 PDF/全文且目标是读懂或对比**：走已有专利证据化解读，建立权利要求树和“权项—说明书—附图”映射；不默认生成交底书。 - **要求寻找创新点或专利挖掘**：先形成待检索候选；有网络/数据库能力时必须检索相似专利、提取区别特征并反向检索后再分级，没有实际检索时只能输出“待检索创新候选”。 - **已有技术描述**：整理技术链、识别披露缺口并生成交底书草案。 - **已有交底书或申请稿，只要求审校**：做充分公开、支持性、一致性和可专利性风险分析，不直接改文件。 - **要求补材料、纠错或调整已有交底书**：进入非破坏性修订，以旧稿为基线另存新版本，并记录对检索、保护点、实施例和附图的影响；不要无故从头重写。 - **只要检索或风险分析**：输出检索式、对比文件表和特征对照，不生成正文。 - **只要名称、摘要、附图或 Word**：复用已有事实，完成对应产物，不重跑全流程。 纯文本分析不需要初始化 Python 环境。只有实际生成 DOCX 或程序化附图时才检查依赖。 ## 工作流 ### 1. 建立事实底稿 优先从对话和用户文件提取信息，不重复询问已给出的内容。至少确认： - 技术场景、处理对象和要解决的技术问题； - 现有方案及其可验证的不足； - 输入数据/信号/对象、处理步骤或模块关系、输出结果； - 相对现有方案真正不同的技术特征； - 参数、条件、异常处理、替代实现和适用边界； - 技术效果及其测试条件、对比基线或理论依据； - 申请日或检索截止日、拟保护主题、是否已公开。 当输入来自项目目录、代码或 Office 材料时，读取 [templates/project_material_intake.md](templates/project_material_intake.md)，记录材料版本和来源定位。`.docx`、`.pptx`、`.ppsx` 需要转成可检索文本时运行： ```bash python3 scripts/office_to_markdown.py \ --output-dir \ --manifest /office_manifest.json ``` 不要扫描第三方依赖和生成文件，不要读取或回显密钥、令牌和个人敏感信息。代码中的未调用分支、注释和规划不能自动视为已实现功能。 为每项关键信息标注状态： - `用户已确认`：用户明确提供或确认； - `资料有据`：可定位到用户文件或可靠来源； - `合理推断`：为组织方案作出的推断，尚待确认； - `待确认`：影响可实施性或保护范围的缺口； - `建议方案`：尚未成为既有发明内容的研发建议。 不得把“合理推断”或“建议方案”直接写成已经实现的事实。用户要求一次成稿时，可继续写草案，但要保留 `【待确认：…】`，不要偷偷补造细节。 输入过短时，只问最影响技术链和保护范围的 3–5 个组合问题；不要先问发明人、申请人、版式等不影响技术内容的问题。 ### 2. 已有专利证据化解读 用户要读懂、比较或从已有专利反哺交底书时，读取 [templates/patent_reading_and_claim_mapping.md](templates/patent_reading_and_claim_mapping.md)。 - 先核对公开申请、授权或更正文本版本，并声明证据范围是全文、部分全文、仅摘要还是待核验； - 建立权利要求父子关系和从属权“相对父项新增限定”； - 将独立权拆成编号特征，定位说明书段落、实施例和附图； - 通俗化时保留决定保护范围的对象、动作、条件和关系； - 仅摘要只能用于筛选，不足以证明复杂特征关系； - 若用于本方案查新，继续进入单一文献特征对照和反向检索，不能把单篇解读冒充完整新颖性/创造性结论。 ### 3. 形成技术链和专利点 需要挖掘时读取 [templates/patent_mining_strategy.md](templates/patent_mining_strategy.md)。需要识别领域披露重点时读取 [templates/tech_field_config.md](templates/tech_field_config.md)。 先写一条最小可实施技术链： `技术问题 → 输入/触发条件 → 核心处理或模块协作 → 输出 → 可归因的技术效果` 再区分，并把尚未完成现有技术对比的内容标为“待检索候选”： - 独立构思候选：能够形成完整技术闭环的必要技术特征组合； - 从属限定候选：参数、数据结构、模型细节、异常分支、部署方式等进一步限定； - 组合/分案候选：具有独立技术问题和效果、可能不宜塞入同一构思的方案； - 研发建议：当前材料没有披露，必须由用户确认后才能并入交底书。 A/B/C/D 仅表示布局优先级和披露成熟度，不等于新颖性、创造性或授权结论。不要依据文字相似度百分比判定法律意义上的相同或显而易见。 当独立构思存在实质分叉时，展示“必要特征 + 拟解决问题 + 预期效果 + 主要取舍”，请求一次确认；细枝末节可继续以待确认项推进。 ### 4. 联网检索、特征对比并筛选创新点 需要检索时读取 [templates/search_and_evidence.md](templates/search_and_evidence.md)。 当用户要求“寻找创新点”“专利挖掘”“查相似专利”或评价新颖性/创造性时，有可用网络或专利数据库能力就实际执行外部检索，不得只凭模型记忆给出结论。检索和挖掘采用迭代闭环： 1. 把待检索候选拆成必要技术特征，记录每个特征的功能、关系和预期效果； 2. 宽检并找到最接近的现有专利，阅读全文中的独立权利要求、相关段落和附图； 3. 制作“本方案—单一文献”特征对照，提取未被直接、明确公开的区别特征组合； 4. 围绕“区别特征 + 功能关系 + 技术效果”再次检索，排查其他专利是否已经公开该组合或给出明确技术启示； 5. 根据反向检索结果收缩、重组或淘汰候选，再对剩余候选复检，直到能说明其证据边界。 区别特征不自动等于创新点。只有同时满足以下条件时，才可列为“初步创新点候选”： - 来自用户已确认或资料有据的技术方案，不是为绕开文献临时编造； - 是具有功能联系的特征组合，而非场景替换、业务规则、孤立参数或常规模块并列； - 相对最接近现有技术存在可定位的区别； - 能通过作用机理产生可归因的技术效果； - 反向检索尚未发现直接公开该组合的单一文献，并已评估其他文献是否给出组合启示。 为每个候选记录：最接近现有技术、区别特征组合、效果与机理、正文支撑、反向检索式及命中、风险、证据置信度和建议定位。若没有筛出强创新点，要如实说明，并把可能的改进放入“研发建议”，不能包装成既有发明。 - 先确定检索截止日，不把“最近 10 年”当成法定范围；较早文献仍可能是关键现有技术。 - 以中国专利为重点，同时检索必要的外国专利和非专利文献。 - 先按技术问题、核心手段和关键关系宽检，再按 IPC/CPC、申请人、引证和同族精筛。 - 对高相关文件核对公开文本、公开日/优先权日、权利要求和相关段落；记录可访问链接。 - 用“特征—单一文献”检查新颖性；用“最接近现有技术—区别特征—实际技术问题—技术启示—效果”分析创造性。 绝不编造公开号、申请人、日期、引文或检索结果。没有数据库/网络能力或没有实际完成检索时，明确写“未执行外部检索”，仅提供检索策略，不输出虚假的高相关专利清单。 ### 5. 起草交底书 起草前读取 [templates/drafting_quality_standard.md](templates/drafting_quality_standard.md)。正文采用以下默认结构，并根据发明性质增减内部小节： 1. 发明名称 2. 技术领域 3. 背景技术 4. 发明内容 - 要解决的技术问题 - 技术方案 - 有益效果 5. 附图说明 6. 具体实施方式 7. 内部附录（不作为正式说明书正文）：术语表、拟保护主题、权利要求支撑矩阵、待确认项、检索记录 撰写技术方案时： - 按执行顺序说明每一步的输入、处理、输出，以及步骤间的数据或控制关系； - 系统/装置方案说明模块职责、连接或交互关系，不只罗列模块名称； - 至少提供一个端到端可实施例，并用替代实现、参数范围或异常分支支撑合理概括； - 说明每个关键区别特征如何产生所述技术效果； - 量化效果只有在存在测试条件、样本、基线或来源时才能写成确定事实，否则改为定性表述并列为待验证项； - 背景技术客观描述，不虚构对比文件，不使用贬损或宣传语言； - 术语首次出现时定义，全文、附图和拟保护主题保持同名同义。 材料较多或方向存在分叉时，先给出“技术问题—必要特征—区别特征—效果—主要风险”的短预览；用户明确要求一次成稿或方向已经清楚时直接继续，不把预览变成阻塞步骤。 需要脱敏时读取 [templates/revision_and_redaction.md](templates/revision_and_redaction.md)。移除客户、产品、内部代号和个人信息，但保留实现必要的字段、关系、条件、参数依据和部署约束；不要用“预设”“适当”“智能”掩盖应充分公开的细节。 涉及 AI/算法时，重点写清模型/算法与具体技术场景的结合关系。模型构建或训练通常需要披露必要模块、层级/连接关系、训练步骤和关键参数；具体应用通常需要披露输入、输出及其内在技术关联。仅替换应用对象而没有针对对象作出算法或模型实质调整，通常不能作为高质量创造性论证。 ### 6. 规划附图 先从已确认技术链生成附图清单和图元—术语映射，再出图。默认优先使用可编辑、可复现的程序化框图或流程图；生成式图片容易引入错误连接和伪文字，只在用户明确需要概念图且逐项核对后使用。 常见附图： - 系统/网络架构图； - 方法主流程图； - 数据结构或消息结构图； - 模型结构或训练/推理流程图； - 关键时序图或状态转换图。 图号连续，同一部件标记一致；正文提到的附图标记必须出现在图中，图中的标记也必须在正文得到说明。把已确认图元写入结构化输入的 `figure_plan` 后，运行 `python3 scripts/generate_figures.py --input-json --output-dir `。脚本必须接收真实输入；不得把 `--demo` 生成的通用示意图用于交付。失败时保留 Mermaid/PlantUML 源文件和明确错误，不伪称已生成 PNG。 ### 7. 非破坏性修订 用户要求修改已有交底书时，读取 [templates/revision_and_redaction.md](templates/revision_and_redaction.md)： 1. 记录基线文件、哈希、新材料和本轮修订类型； 2. 区分补充、纠错、保护策略调整和纯格式修改； 3. 把变化传播到技术问题、必要特征、效果、正文、实施例、支撑矩阵、附图和检索结论； 4. 默认另存带版本和时间戳的新文件，不覆盖旧稿； 5. 交付后用 `scripts/revision_log.py` 追加 Markdown 与 JSONL 修订记录。 如果增量改变核心区别特征或技术效果，补做相应检索；如果只是格式或不影响技术实质的措辞，不重跑无关流程。 ### 8. 验证并交付 交付前逐项通过以下质量门： - **真实性门**：没有把推断、建议、未检索结果写成事实；引用均可追溯。 - **技术性门**：技术问题、手段、效果完整，算法/业务规则与技术特征存在具体相互作用。 - **充分公开门**：关键步骤、关系、参数选择依据、异常处理和至少一个实施例足以实施。 - **支持性门**：拟保护的每个必要特征都能定位到正文和实施例；概括范围有替代方案支撑。 - **创新点门**：拟作为核心的创新点已完成相似专利对比和区别特征反向检索，或者明确标为“未执行外部检索/待检索候选”。 - **一致性门**：名称、术语、步骤编号、附图标记和数据流一致。 - **材料追溯门**：项目材料中的关键事实有路径、页码、行号、版本或测试记录定位；未调用代码和规划未被当作已实现事实。 - **修订门**：已有稿修改已保留基线和旧版本，变化已传播到受影响章节，核心变化已评估是否需要补检索。 - **脱敏门**：身份和商业信息已去除，但未删除实现必要的技术细节；对外稿不含密钥、个人敏感信息或内部路径。 - **文本门**：语言客观、清楚、无营销词，无未经解释的占位符或矛盾数字。 需要结构化校验或 DOCX 时，从 skill 根目录执行： ```bash python3 scripts/validate_disclosure.py --input python3 scripts/validate_disclosure.py --input --final python3 scripts/generate_docx.py --input --output --with-markdown ``` 若依赖缺失，再运行 `bash scripts/setup_env.sh`，随后用 `./.venv/bin/python` 执行。不要每次调用 skill 都重建环境。正式导出前先通过 `--final`；同一输入重复导出由哈希侧车文件避免重复生成，内容变化时使用新版本文件名或显式 `--overwrite`。 结构化输入参考 [examples/disclosure_input.sample.json](examples/disclosure_input.sample.json)。 ## 输出契约 按任务范围交付，不强制制造无关文件。完整项目的推荐产物为： ```text outputs/ ├── disclosure_input.json ├── 交底书_[发明名称]_v1.0.md ├── 交底书_[发明名称]_v1.0.docx ├── 交底书_[发明名称]_v1.0.docx.sha256 ├── source_manifest.json ├── figures/ │ ├── fig1_architecture.png │ └── figure_sources/ └── reports/ ├── invention_points.md ├── patent_reading.md ├── prior_art_search.md ├── feature_comparison.md ├── disclosure_gap.md ├── quality_report.json ├── revision_history.md └── revision_history.jsonl ``` 首次草案至少同时给出： - 一句话发明构思； - 已确认事实与待确认项； - 拟保护主题及必要技术特征； - 初步创新点候选、对应区别特征及检索状态； - 交底书正文； - 检索状态和风险边界； - 下一轮最值得确认的问题。 ## 风险说明 产物是技术交底书或申请文件草案，不是法律意见，也不保证授权。申请前注意保密，由专利代理师结合完整检索、申请策略和最新规则复核。涉及个人信息、敏感数据、自动决策或歧视性规则时，额外检查数据来源、处理合法性、社会公德和公共利益风险。