企业官网建设流程全解析

patent-disclosure-skill案例脱敏入库实战：redact脱敏与ingest_case流程一步到位

【免费下载链接】patent-disclosure-skill中国专利.skill：专利点挖掘与交底书（发明/实用/外观）编写，通俗解读专利，嗅探政策动向，辅助审查答复。项目地址: https://gitcode.com/GitHub_Trending/pa/patent-disclosure-skill

如果你收到审查意见通知书，却不知道如何安全地把历史答复案例沉淀成自己的知识库，patent-disclosure-skill 的「模式 D · 审查答复辅助」正是为此而生：它用redact.py自动抹掉公司名称、申请号、电话、邮箱、身份证号等敏感信息，再用ingest_case.py一条命令把案例脱敏入库，最终在 Obsidian 里形成可检索、可关联的专利案例库。

为什么专利案例入库前必须先脱敏？

审查答复（Office Action，简称 OA）的核心思路是"用历史赢案指导当前案件"：审查员质疑创造性时，你希望秒速找到"同样是 22 条 3 款、同样靠修改权利要求拿下授权"的旧案例。

但案例里天然包含三类危险信息：

• 主体信息：申请人公司名、发明人姓名
• 案件信息：申请号（9~13 位数字）、对比文件号
• 联系方式：电话、邮箱、身份证号

这些内容一旦提交到 git 或分享给同事，就是合规事故。因此本项目的护栏（见 prompts/oa/guardrails.md）明确要求：未脱敏原文禁止入库。

redact 脱敏：5 类敏感信息自动识别

脱敏逻辑集中在 tools/oa/redact.py，是纯规则的轻量实现，逐条正则替换：

两个实用细节：

• 通过--extra-name "客户名"可追加自定义脱敏实体，把特定人名替换为【脱敏姓名】
• 每次脱敏都会返回变更摘要（redact_notes），自动写进案例 frontmatter，入库后可以审计"到底改了哪里"

规则型脱敏不是万能的，所以官方流程规定：脱敏后仍需人审确认，才能执行入库。

ingest_case 入库流程：从 PDF 到案例笔记

完整脚本是 tools/oa/ingest_case.py，官方提示词见 prompts/oa/ingest_case.md。整个流程分三步：

第一步：PDF 自动抽取，生成案例草稿

直接喂通知书 PDF，脚本会抽取文本并生成带 frontmatter 的 md 草稿（--draft-only表示只出草稿、不入库）：

python tools/oa/ingest_case.py --pdf path/to/notice.pdf \ --reply-pdf path/to/reply.pdf \ --case-id my-case-slug --title "脱敏标题" --draft-only

生成的草稿结构见模板 prompts/oa/case_note_template.md，包含「通知书要点 / 策略 / 陈述要点 / 修改摘要 / 结果」五个板块——这正是答复一份 OA 所需的全部要素。

第二步：人审补全标签

草稿的statutes（法条）、defect_types（缺陷类型）、outcome（结果）等字段需要人工补齐，字段规范定义在 references/schemas/oa_case.schema.yaml。标签质量决定检索质量：入库时defect_types和statutes会自动转成oa/inventiveness、法条/专利法第22条第3款这类标签，成为后续检索的过滤条件。

第三步：脱敏 + 入库一条命令

python tools/oa/ingest_case.py -i path/to/case.md --extra-name "客户名" --dry-run

建议先--dry-run预览将要写入的元数据，确认无误后去掉该参数正式执行。脚本会依次完成：正文脱敏 → 写入 Obsidian 笔记 → （status 为 history 时）写入 sqlite 向量库 → 自动刷新_OA索引/ Canvas / Bases。

练手样例：不碰真实案件也能跑通

仓库内置了一套虚构、已脱敏的演练材料，目录结构见 examples/example_oa_response/README.md：

• 历史案（已答复）：hist-inventiveness-clamp.md、hist-clarity-connector.md
• 待答复通知书：oa_notice_pending.md

以历史案为例，其 frontmatter 长这样，redacted: true即表示已脱敏：

case_id: hist-inventiveness-clamp statutes: [专利法第22条第3款] defect_types: [inventiveness] outcome: amended_then_granted strategy: [amend_claims, argue_only]

对照场景很直观：审查员认为"限位凸起属于常规结构替换"，答复策略是把「限位凸起 + 导向斜面」组合特征并入权利要求1，最终修改后授权。入库后，当新的通知书同样以 22 条 3 款质疑卡扣类结构时，tools/oa/search_cases.py 按--defect inventiveness --statute "专利法第22条第3款"就能优先命中这类旧案。

可选配置：向量检索要不要开？

向量不是必须的。标签检索（法条 + 缺陷类型过滤）始终可用；向量检索只是锦上添花，让"语义相似"的案件也能被捞出来。

• 跳过向量：python tools/oa/config.py skip-vector
• 启用向量（推荐智谱 embedding-3）：python tools/oa/config.py set --preset zhipu --api-key "sk-..."
• 配置模板：docs/oa/embedding.config.yaml，密钥单独存放在embedding.secrets.yaml（勿提交）

向量调用失败或超时会自动回退到标签检索，并在结果中标注retrieval_mode，不会阻塞答复流程。

数据最终落在哪：Obsidian 案例库三目录

入库后按status分流，结构与 tools/oa/README.md 一致：

同时自动维护_OA索引.md、_OA看板.base（看板视图）、_OA关联.canvas（关联画布），在 Obsidian 里案例之间形成网状关联，检索、看板、图谱三种视角随时切换：

只刷新 Obsidian 结构而不重新入库时，单独执行python tools/oa/refresh_vault.py即可。

安全护栏清单：入库前逐项确认

对照 SKILL.md 中模式 D 的检查清单，提交入库前确认：

1. ☑ 已向用户列出将脱敏的项目，并获得"可入库"确认
2. ☑redact_notes摘要完整，无漏网的敏感词
3. ☑禁止把未脱敏原文提交到 git
4. ☑ 需要重建向量时，已获人工确认（rebuild_vectors.py --confirm）
5. ☑ 检索结果展示的retrieval_mode与 diff 已向用户说明

小结

patent-disclosure-skill 把"OA 案例沉淀"这件原本靠自觉和手工的事，收敛成了redact → 人审 → ingest_case一条流水线：规则脱敏保证合规，frontmatter 标签保证可检索，Obsidian 三目录结构保证可持续积累。历史案越多，答复草稿的起点就越高——这大概就是"案例库"对专利代理工作最大的复利。

【免费下载链接】patent-disclosure-skill中国专利.skill：专利点挖掘与交底书（发明/实用/外观）编写，通俗解读专利，嗅探政策动向，辅助审查答复。项目地址: https://gitcode.com/GitHub_Trending/pa/patent-disclosure-skill