新增 patent skill + REVISIONS.md 修订日志机制

patent skill 写中国发明专利技术交底书,五阶段 workflow (素材摄取 → 挖点 → 检索 → spec → 逐章起草 → 自查渲染),BLOCKING 节奏同 proposal/ppt。复用 markitdown CLI + proposal scripts (render_diagrams/render_docx) + web_search/web_fetch + documents/research skill,零新增脚本;不实现 CNIPA 爬虫(维护成本高)。

REVISIONS.md 作为产物迭代 changelog,覆盖 proposal/patent/ppt 三个产物型 skill — spec = 宪法定调,REVISIONS = 每次卡点累加;单行 bullet 倒序追加,何时记/何时不记按 skill 领域定制(技术路线/区别特征/版式)。

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

PROGRESS.md

@@ -2,7 +2,7 @@
 
 > 配合 `DESIGN.md`。本文件只记 phase 状态、决策偏差、文件量、下一步。每条 1-2 句:做了啥 + 关键判断;细节查 `git log` / `git diff` / `DESIGN §7.9`。
 
-最后更新:2026-05-26(§7.5 沙盒落地清单写入 DESIGN)
+最后更新:2026-05-26(新增 patent skill + REVISIONS.md 修订日志机制覆盖 proposal/patent/ppt 三个产物型 skill)
 
 ---
 
@@ -10,7 +10,7 @@
 
 | Phase | 标题 | 状态 | 备注 |
 |---|---|---|---|
-| 1-3 | 骨架 + Skill + run_python | ✅ | 多 skill(coding/proposal/ppt/research/documents/imagegen/videogen);CoreCoder 唯一匹配 edit;敏感 env 过滤 |
+| 1-3 | 骨架 + Skill + run_python | ✅ | 多 skill(coding/proposal/ppt/research/documents/imagegen/videogen/review/patent);CoreCoder 唯一匹配 edit;敏感 env 过滤 |
 | 4 | 演化性能力 | 🟡 | Model Profile + Probing ✅;版本化 prompt 未做 |
 | 5 | Eval Suite | ⏸ 不做 | dogfooding 替代,probe 覆盖健康检查 |
 | 6 | 长任务工程化 | 🟡 | task + 恢复 ✅;双层记忆 ✅;context 压缩未做 |
@@ -23,6 +23,8 @@
 
 ### 2026-05-26
 
+- **REVISIONS.md 修订日志机制(覆盖 proposal/patent/ppt 三个产物型 skill)**:`<task_dir>/REVISIONS.md` 作为产物迭代过程的紧凑 changelog —— task 对话历史是粗流水(50 条消息找上周改动靠翻),REVISIONS 是用户与 LLM 共同沉淀的实质决策列表(5 行就能复盘"上周这章为啥这么写"),与 spec 定位互补:**spec = 宪法(定调一次),REVISIONS = 实施日志(每次卡点累加)**。三个 SKILL.md 各加 (a) 起草步骤里加一步"用户确认实质改动后追加一行" + (b) "## 修订日志" 独立小节(何时记/何时不记表 + 格式约定 + 实例 + 操作)。三类 skill 的"实质改动"判据按各自领域定制:proposal = 技术路线/考核指标/创新点/课题分解/关键引文/预算结构;patent = 区别技术特征/关键参数/公式/实施例/章节;ppt = 版式/主色/页/图标/文案要点。统一原则:首次起草不记 / 错别字微调不记 / 模型自己改改撤撤不记 — 拿不准倾向不记,避免变流水账。格式选**单行 bullet 倒序追加**(时间在前、文件:章节定位、改了什么 — 为什么),用 edit 在头注释后插入新一行(不 append 到末尾,倒序读秒看最新)。否决:(a) 走 system prompt 软约束 — 对 coding/research/documents/imagegen/videogen 等非产物型 skill 强加无关约束;(b) 新建 `record_revision` tool — 开发期内 LLM 直接 edit 追加足够,加 tool 增加每次小改的调用开销,后期发现 LLM 漏记多再升 tool 化;(c) 按产物拆多文件(`<topic>.revisions.md`)— 单文件好读、跨产物时间线统一。`DESIGN.md` 不动(无架构变化);`RUN.md` 不动(无 CLI/env 变化)。
+- **新增 patent skill(中国发明专利技术交底书)**:`skills/patent/` 完整 6 文件 — `SKILL.md` 主入口(五阶段 workflow:摄取 → 挖点 → 检索 → spec → 逐章起草 → 自查渲染,跟 proposal 同款 BLOCKING 节奏)+ `references/{disclosure_structure,patent_point_taxonomy,prior_art_search,self_check}.md` 4 份指南 + `templates/{spec,disclosure}.md` 2 份模板。**关键复用避免重复造**:① 素材摄取用 `markitdown` CLI(不内置 docx/pptx→md);② mermaid + docx 渲染直接复用 `skills/proposal/scripts/{render_diagrams,render_docx}.py`(参数兼容,patent 不另写);③ 现有技术检索走现成的 `web_search`/`web_fetch`(Bocha)+ `documents` + `research`,不实现 CNIPA Playwright 爬虫(反爬重、维护成本高,正式可作 IDS 提交的检索建议走线下专业渠道);④ 不实现修订日志(zcbot task 对话历史已有)。源 repo `github.com/handsomestWei/patent-disclosure-skill` 的 11 prompts 文件折叠进单份 SKILL.md(跟 proposal/ppt 风格一致)+ 8 Python tools 减到 0(全靠复用)。skill 内特有内容:7 章交底书骨架(技术领域 / 背景 / 发明内容 / 附图 / 实施方式 / 有益效果 / 权利要求建议)+ 三性自检(新颖/创造/实用)+ 9 类客体排除清单 + 6 类自查清单 + 脱敏边界(商业敏感词中性化、技术参数不脱敏)。`SkillRegistry` 自动发现验证通过。`DESIGN.md` 不动(无架构变化,纯新 skill);`RUN.md` 不动(无 CLI/env 变化)。
 - **§7.5 沙盒落地清单 6 条写入 DESIGN(Stage C 实施硬协议)**:Stage C 动手前把"原则 → 具体协议"沉淀,防实施时漏。① 网络 blocklist 硬编码段(`169.254.0.0/16` cloud metadata / loopback / 内网三段 / `100.64.0.0/10` CGNAT,**PG IP 单独再 block 一遍**——Capital One 2019 同款攻击向量);② egress proxy 模型(容器 `HTTP_PROXY` env + iptables DROP except proxy 端口防 SDK 绕 env,宿主侧 proxy 做域名 allowlist + 字节计量 + `network_audit` 审计日志,allowlist 初始集列出 PyPI / GitHub / npm 等);③ 进程组清理协议(`docker exec` 走 `setsid` + `kill -- -PGID`,防 `nohup &` / `disown` 跨 exec 持久化破"同 user 不内隔离"残留风险假设);④ 磁盘配额硬化时点(开外部前必须升 xfs/ext4 project quota 或 zfs dataset quota,否则扫描间隙打满共享 fs 拖死同节点);⑤ Executor 接口走 backend driver + `ZCBOT_SANDBOX_RUNTIME` config 注入(未来切 gVisor/Firecracker/e2b 应用层零改动,避免 Docker API 形状泄漏到接口层);⑥ 工具按信任域二分 dispatch — **host in-process**:`read/write/edit/glob/grep/load_skill/web_search/web_fetch`(原本就在 host 持凭据 / 走 paths.py 校验,塞容器无收益付 200ms × N),**container exec**:`shell/run_python`(执行任意代码必隔离)。同时把 gVisor / Firecracker / 容器内 tool-runner 三档升级触发信号写死,反向兜底"无信号不升级"。否决:(a) 把落地清单同时写进 DESIGN 和 PROGRESS 双 source — 漂移源,PROGRESS 只指针 DESIGN;(b) 在落地清单里写"勾对"验收语气 — DESIGN 写为什么 + 协议形状,验收语气进 PROGRESS 下一步候选 DoD;(c) 立即开始实施 — 设计先沉淀,实施排进下一步候选 #2 单独节奏。`RUN.md` 不动(运行方式无变化,Stage C 还没实施)。
 
 ### 2026-05-25

skills/patent/SKILL.md

@@ -0,0 +1,261 @@
+---
+name: patent
+description: 撰写中国发明专利技术交底书 (供专利代理师转写为申请文件)。当用户要写交底书、挖专利点、做现有技术检索、把项目材料/代码/论文整理成可申报的发明专利材料时使用。
+---
+
+# Patent (交底书)
+
+把项目素材变成可交给专利代理师的**技术交底书** .docx。**先挖专利点 → 检索现有技术 → 八条对齐 spec → 逐章起草 → 验收渲染** —— 不要一口气出全文。
+
+## 资源
+
+下面所有路径都相对 **`<skill_dir>`** —— `load_skill` 返回头里的 `[skill=patent, dir=<绝对路径>]`,用这个绝对路径拼脚本/资源,不要假设 cwd。
+
+- `<skill_dir>/references/disclosure_structure.md` —— 交底书 7 章骨架 + 字数预算 + 必填要素 (always read)
+- `<skill_dir>/references/patent_point_taxonomy.md` —— 专利点分类(方法/装置/系统/介质)+ 三性自检(新颖/创造/实用)+ 客体排除清单
+- `<skill_dir>/references/prior_art_search.md` —— 检索关键词构造 + 数据源优先级 + 区别技术特征写法
+- `<skill_dir>/references/self_check.md` —— 渲染前自查清单(参数/公式一致、逻辑闭环、脱敏、附图)
+- `<skill_dir>/templates/spec.md` —— task 级"宪法"模板(案件名 / 技术领域 / 创新点清单 / 检索结论 / 脱敏边界 / 附图清单)
+- `<skill_dir>/templates/disclosure.md` —— 交底书 7 章 Markdown 模板,阶段四照抄
+- **渲染脚本复用 proposal skill**:`skills/proposal/scripts/render_diagrams.py` + `render_docx.py` —— 跟交底书 md 兼容(同样的 markdown + ```mermaid``` + `%% caption:` 约定),不另写
+
+## 阶段零: 摄取素材 (有 PDF/DOCX/PPTX/XLSX/URL 时才走)
+
+用户给项目文档 / 代码截图 / 论文 PDF / 设计方案 PPT → 用 `markitdown` CLI 统一转 md 落到 `<task_dir>/source/<name>.md`,后续阶段直接 read:
+
+```bash
+markitdown <path>/方案.docx     -o <task_dir>/source/方案.md
+markitdown <path>/汇报.pptx     -o <task_dir>/source/汇报.md
+markitdown <path>/论文.pdf      -o <task_dir>/source/论文.md
+markitdown https://example.com/ -o <task_dir>/source/外部.md
+```
+
+代码仓库 / 单文件代码 → 直接 `read`,关键算法在哪个函数、参数怎么传、跟现有方案差异在哪 —— 边读边记到 spec 草稿里。
+
+## 阶段一: 专利点挖掘与筛选
+
+产物:**候选专利点清单**(写到 spec §3,先粗筛,再细化)。不要直接进章节起草 —— 一份交底书原则上对应 **1 个发明专利**(独立权利要求一项),先把"这次到底要保哪一个"定下来。
+
+1. **读 `<skill_dir>/references/patent_point_taxonomy.md`** —— 先建立分类与三性自检的判断框架
+2. **从素材里抓 candidates**:列 3-8 个"看起来可专利"的技术点,每条按下表填:
+
+   | 候选 | 解决的技术问题 | 关键技术手段 (≥1 个区别于现有的步骤/结构) | 客体类型 (方法/装置/系统/介质) | 三性初判 (新/创/实) |
+   |---|---|---|---|---|
+   | 1 | ... | ... | ... | ... |
+
+3. **合并/淘汰**:语义重复的合并;纯商业方法 / 智力活动规则 / 数学算法本身 / 单纯展示信息 → 按 taxonomy §客体排除清单淘汰
+4. **推荐 1-2 个主推点**,说明理由,⛔ **BLOCKING:等用户选定后才进阶段二**
+
+> **小心 ≠ 创新点不等于专利点**。"用了 LLM 做摘要"不是专利点(已是通用范式);"针对 X 场景设计的 Y 步骤组合 + Z 阈值"才可能是。
+
+## 阶段二: 现有技术检索
+
+产物:**检索报告**(写到 spec §4)。**没有检索就直接写交底书是评审/审查员视角的重大风险** —— 同一发明被检出会导致驳回。
+
+1. **读 `<skill_dir>/references/prior_art_search.md`** —— 拿关键词构造法 + 数据源优先级
+2. **构造检索式**:中文术语 + 英文术语(领域里通行那个)+ 同义/近义词 + 用途词;3-5 组检索式
+3. **执行检索**(优先级从高到低):
+   - **`web_search`** —— 优先搜中国专利文库 / Google Patents / 期刊综述。query 里带 `site:patents.google.com` / `专利` / `CN10` 等限定符可显著提升信号
+   - **`web_fetch`** —— 命中的关键专利/论文页拉全文摘要
+   - **`documents` skill** —— 本地材料学科库(7 个学科共 21W+ 论文)如果命中
+   - **`research` skill** —— OpenAlex 学术文献库,找综述与对比方案
+4. **每条命中归档** (写到 spec §4):
+   - 公开号 / 标题 / 申请人 / 公开日 (专利) 或 DOI / 作者 / 期刊 / 年 (论文)
+   - 一句话概括其技术方案
+   - **与本发明的区别**(这条最关键 —— 写交底书时"区别技术特征"段直接复用)
+5. **判定**:
+   - 命中高度近似 (技术问题 + 关键手段都重合) → ⛔ **BLOCKING 告诉用户"已有 XX 在先,建议改方案 / 换创新点 / 放弃"**,等用户决策
+   - 命中部分相关 → 记录,作为本发明"区别技术特征"对照
+   - 无相关命中 → 检索式可能太窄,再换 1-2 组关键词验证;仍无 → 标记"未检出近似",进阶段三
+6. ⛔ **BLOCKING:把检索结论给用户确认后才进阶段三**
+
+> **不要编公开号 / DOI / 作者**。检不到就说"未检出近似",不要靠训练数据脑补一个 `CN112345678A`。
+
+## 阶段三: 八条对齐 (spec)
+
+产物:**task 级 spec 文件**(交底书"宪法",阶段四每章前都要重读)。文件路径按 system prompt 的《task 级「宪法」文件命名约定》:
+
+    <task_dir>/<today>-<task_short_id>-<task_name>.spec.md
+
+`<today>` / `<task_short_id>` / `<task_name>` 用 system prompt 注入的实际值替换。
+
+**0. 先检测已有 spec**:
+
+```
+glob <task_dir>/*-<task_short_id>-*.spec.md → 按文件名字典序排,取最大者作 current
+```
+
+- 若已有 current → 展示给用户,问「**沿用进阶段四** / **重定调**(以 today 为前缀写新版,旧版保留)」,⛔ BLOCKING 等用户决定
+- 仅有其它 task 的(`*-<别的 short_id>-*.spec.md`)→ 不当 current 用,继续走下面
+- 完全没有 → 直接走下面
+
+1. **复制模板**: `read <skill_dir>/templates/spec.md` → `write <task_dir>/<today>-<task_short_id>-<task_name>.spec.md`
+2. **按字段填**(阶段一二的产物直接抄进去):案件名 / 发明名称 / 技术领域 / 主推专利点 / 检索结论 / 脱敏边界 / 附图清单 / 发明人清单 / TODO
+3. 给用户预览
+4. ⛔ **BLOCKING:用户确认后才进阶段四**
+
+字段清单见 `<skill_dir>/templates/spec.md`。
+
+## 阶段四: 逐章起草
+
+每章两段式:**先列要点 → 用户确认 → 再起草 → 用户确认**。不要直接出正文。
+
+读 `<skill_dir>/references/disclosure_structure.md` 拿 7 章骨架(技术领域 / 背景技术 / 发明内容 / 附图说明 / 具体实施方式 / 有益效果 / 权利要求建议),每章对应字数预算。
+
+**A. 起草前列要点**:
+1. 读 **current spec** 与 `<skill_dir>/references/disclosure_structure.md`
+2. 列 3-6 条要点骨架:本章覆盖的论点 / 关键参数 / 公式 / 附图,每条贴上对齐的检索结论与预估字数
+3. ⛔ **BLOCKING:用户确认要点后才动正文**
+
+**B. 正文起草**:
+4. 从 `<skill_dir>/templates/disclosure.md` 复制对应小节到 `<task_dir>/sections/NN_xxx.md`(章节命名见 §章节骨架速查)
+5. **关键章节一段一卡** —— 背景技术(必须含"现有技术 1/2/3 + 缺陷")/ 发明内容(技术问题 / 技术方案 / 有益效果 三段)/ 具体实施方式(嵌入实施例): 写一段 → 报字数 + **预告下一段** → 等用户确认 → 写下一段
+   普通章节一节一卡: 整节写完再报 + **预告下一节要点**
+6. 报告格式 (每次卡点都按这个出):
+   - **本段 (节)**: 章节名 / 实际字数 / 字数预算 / 与检索结论对齐情况(引用了哪几条现有技术作对比)
+   - **下一段 (节) 预告**: 标题 + 3-5 条要点骨架;若已是本章最后一段,改预告**下一章**首段要点
+   - 提问: "本段可以了吗?下一段要点要改 / 加 / 删什么?"
+7. ⛔ **BLOCKING:停下来等用户明确反馈** ("OK"、"下一段"、"继续") 后才动笔。"看起来不错"、沉默、追问都不算确认 —— 用户对下一段要点没异议也算默认通过,但**关键参数 / 公式 / 区别技术特征异常**时必须主动追问
+8. 用户确认了**实质改动**(改写区别技术特征 / 调关键参数 / 换实施例 / 增删章节)后,追加一行到 `<task_dir>/REVISIONS.md` —— 见 §修订日志
+
+**例外**: 用户**主动且明确**说"别问,直接全做"或"一气呵成" —— 才能一次跑完,跑完必须按阶段五自查。
+
+## 阶段五: 自查 + 渲染
+
+```bash
+# 1. 自查 (按 self_check.md 清单逐条核 — 这一步无脚本,模型逐条对照)
+read <skill_dir>/references/self_check.md
+# 模型按清单 6 类逐项过一遍 sections/*.md, 不过则回头 edit
+
+# 2. mermaid 附图预渲染 (章节有 ```mermaid``` 块就跑)
+python <repo_root>/skills/proposal/scripts/render_diagrams.py <task_dir>/sections/
+
+# 3. 渲染 .docx (复用 proposal skill 的脚本,patent 不另写)
+python <repo_root>/skills/proposal/scripts/render_docx.py <task_dir>/sections/ --fund-type key_rd -o <task_dir>/<案件名>_技术交底书.docx
+```
+
+> `render_docx.py` 的 `--fund-type` 只影响目录页表头文案与封面,不影响章节解析 —— 交底书复用 `key_rd` 排版规范(国标黑体/宋体/1.5 倍行距)。封面页用户拿到后手动改成"技术交底书"标题,或在 sections/00_封面.md 自定义。
+
+`<repo_root>` 取自 `<skill_dir>` 的父级再父级,e.g. `skill_dir = D:/projects/zcbot/skills/patent` → `repo_root = D:/projects/zcbot`。
+
+## 工作目录
+
+`<task_dir>` = system prompt 给的**绝对路径**(`…/workspace/tasks/<task_id>/`)。**所有产物都写到 task_dir 下**,不要写到 cwd / `skills/` / repo 根。
+
+```
+<task_dir>/
+├── source/                                  # markitdown 转出的素材(同 working_dir 多 task 共享)
+├── <today>-<task_short_id>-<task_name>.spec.md  # 阶段三定调,task 级宪法;命名见 system prompt 约定;按 short_id 主锚,重定调时写新日期,旧版保留
+├── sections/                                # 阶段四逐章产物(按章节模板切的小节)
+├── figures/                                 # mermaid 预渲染 PNG (由 render_diagrams.py 生成)
+├── REVISIONS.md                             # 修订日志:每次卡点用户确认的实质改动,见 §修订日志
+└── <案件名>_技术交底书.docx                  # 最终产物 (按案件名命名,不要 output.docx)
+```
+
+## 修订日志 (REVISIONS.md)
+
+`<task_dir>/REVISIONS.md` 是产物迭代过程的紧凑可读 changelog。**spec 是宪法(定调一次),REVISIONS 是实施日志(每次卡点累加)** —— 两份独立但互参,后期 review / 复盘 / 跨周回看"上周这节为啥改成这样"靠这份。
+
+### 何时记 / 何时不记
+
+| 情形 | 记? |
+|---|---|
+| 用户确认改写**关键参数 / 公式 / 区别技术特征** | ✅ 必记 |
+| 用户确认换 / 增 / 删**实施例**或**章节** | ✅ 必记 |
+| 用户对要点骨架的主动修改(改 / 加 / 删) | ✅ 必记 |
+| 自查阶段发现术语 / 参数不一致后的统一改 | ✅ 必记(说明触发自查项,如"自查 2.5") |
+| 章节首次起草(从 0 写出来) | ❌ 不记(初稿不是改动) |
+| 错别字 / 标点 / 纯排版调整 | ❌ 不记 |
+| 模型自己改改撤撤、用户没明确确认 | ❌ 不记 |
+
+> 拿不准 → 倾向不记。`REVISIONS.md` 是"用户与 LLM 共同沉淀的实质决策",不是流水账(那是对话历史的事)。
+
+### 格式
+
+文件首次创建时写头(只写一次):
+
+```markdown
+# 修订日志
+
+> 产物迭代过程中每次用户确认的实质改动,按时间倒序追加(最新在上)。spec 是宪法定调,本文件是实施日志。
+```
+
+每次记一笔追加在头注释之后、最新一笔的顶部(一行 = 一次改动):
+
+```
+- `<YYYY-MM-DD HH:MM>` | <文件:章节/段> | <一句话改了什么> — <为什么>
+```
+
+### 实例
+
+```
+- `2026-05-26 15:08` | sections/06_有益效果.md §2 | 删除"显著提升"改为"准确率 82%→91%、时延 200ms→50ms" — 自查 6.3 拦截不可考核词
+- `2026-05-26 14:32` | sections/03_发明内容.md §技术方案 "其中"段 | 区别技术特征从"采用 Y 算法"细化为"采用 Y + Z 组合,Y 处理粗筛 Z 做精排" — 检索新增 CN98765432A 命中纯 Y 算法,需细化区别
+- `2026-05-26 11:50` | <today>-<short>-<name>.spec.md §7 关键参数 | 学习率 1e-4 → 5e-5 — 发明人提供 8 epoch 收敛实测,原 1e-4 偏大
+```
+
+### 操作
+
+每次卡点用户确认后,用 `edit` 在头注释之后插入新一行(不要 append 到文件末尾 —— 倒序读才能秒看最新)。文件不存在就 `write` 创建带头注释的新文件。
+
+## 章节骨架速查
+
+写每章前在脑子里过一遍这 7 章顺序,sections 文件按 `NN_<名>.md` 命名(NN 影响目录顺序):
+
+| NN | 文件 | 章节 | 字数预算 | 关键 |
+|---|---|---|---|---|
+| 01 | 01_技术领域.md | 一、技术领域 | 50-150 字 | 一句话,IPC 大类(如"本发明涉及自然语言处理领域") |
+| 02 | 02_背景技术.md | 二、背景技术 | 800-1500 字 | **现有技术 1/2/3 + 缺陷**,引检索结论的公开号/DOI |
+| 03 | 03_发明内容.md | 三、发明内容 | 1500-3000 字 | 三段式:**技术问题 → 技术方案 → 有益效果**,技术方案给完整步骤/结构(给代理师写权利要求的种子) |
+| 04 | 04_附图说明.md | 四、附图说明 | 100-300 字 | 图 1/图 2/... 一句话题注,跟 `figures/fig_xxx.png` 对齐 |
+| 05 | 05_具体实施方式.md | 五、具体实施方式 | 2000-5000 字 | ≥1 个实施例,含**关键参数取值**(模型参数 / 阈值 / 时序 / 物理量纲);可多实施例展示变体 |
+| 06 | 06_有益效果.md | 六、有益效果 | 300-800 字 | 量化(精度提升 X%、时延降低 Y ms、成本下降 Z 元),不写"显著提升""效果良好" |
+| 07 | 07_权利要求建议.md | 七、权利要求建议(可选) | 300-1000 字 | 给代理师参考的独权 + 从权草稿,**不是最终权要**(代理师会重写,你提建议) |
+
+边界 (最容易混):
+- 背景技术回答 **WHY 不够** (现有方案 + 它们的缺陷) | 发明内容回答 **WHAT 做了** (技术问题 / 技术方案 / 有益效果) | 具体实施方式回答 **HOW 做的** (实施例 + 参数 + 流程) | 有益效果回答 **HOW MUCH 提升** (量化数据)
+
+## 附图 (流程图 / 结构图 / 时序图)
+
+**所有附图都要落成 png 并在 md 里 `![](...)` 引用**;ASCII 字符画 (`┌─┐│`) Word 里必错位。附图编号 `render_docx.py` 全局自增(图 1 / 图 2 ...),**不要手写"图 2-2"**。
+
+| 图类型 | 工具 | 怎么用 |
+|---|---|---|
+| 流程 / 结构 / 时序 / 模块关系 | **mermaid** | 直接写 ```mermaid 块,**首行必须** `%% caption: <题>`(必填 + 全 task 唯一,既是文件名也是 docx 图题),`render_diagrams.py` 渲成 `figures/fig_<caption>.png` |
+| 数据图表 (实验对比柱/折线) | **matplotlib** | 落到 `<task_dir>/figures/<name>.png`,md 里 `![desc](figures/<name>.png)` |
+| 已有截图 (产品 UI / 实验结果照片) | 直接 | 同上 `![]()` |
+
+附图说明章节(04_附图说明.md)每个图一句题注;实施方式章节(05_具体实施方式.md)正文里通过"如图 N 所示"引用。
+
+## 硬规则速查 (违反即被代理师/审查员退回)
+
+- **客体合规**: 纯商业方法 / 智力活动规则 / 数学算法本身 / 单纯展示信息 / 疾病诊断和治疗方法 / 动植物品种 —— 直接不可专利,见 taxonomy §客体排除清单
+- **技术方案要"能实施"**: 完整步骤 + 关键参数 + 输入输出,代理师按你写的能复现;不要写"基于深度学习方法,根据训练结果输出结果"这种黑盒
+- **关键参数必须给具体值**: "阈值取 0.5"、"窗口 100ms"、"学习率 1e-4";不给值就写 `<TODO 待用户确认>`
+- **公式必须自洽**: 符号定义 → 公式 → 量纲一致;不要凑公式
+- **不可信检索/文献**: 检索式 / 公开号 / DOI / 作者一字不编;不确定就 `<TODO 待检索>`
+- **脱敏边界**: 商业机密(具体客户名 / 内部代号 / 数据源 url)→ 按 spec §脱敏边界中性化("某客户" / "目标数据源");关键技术参数**不脱敏**(脱敏完了代理师没法写)
+- **不堆形容词**: "颠覆性""国际领先""填补空白"一律不用 —— 专利文件靠技术特征区别于现有技术,不靠形容词
+- **量化效果**: "显著提升"❌;"准确率从 82% 提升到 91%,时延从 200ms 降到 50ms"✅
+- **一份交底书一个发明**: 多发明分多份(独权数量 = 发明数量),不要一份塞 5 个发明 —— 代理师拆不清
+
+## 反模式
+
+- 没挖专利点 / 没检索就硬写正文 —— 评审/审查员视角的高风险路径
+- 一次性出全文,跳过"列要点"段段卡
+- 关键章节(背景 / 发明内容 / 实施方式)整章一次出 —— 必须段段卡
+- 自己编公开号 / DOI / 作者(检不到就说"未检出近似")
+- "本发明采用 LLM 方法实现 XXX"这种黑盒写法 —— 必须有可复现步骤 + 参数
+- 把商业代号 / 内部 url / 客户名直接写进去(脱敏边界没过)
+- 把多个发明塞一份交底书(一份 → 1 个独权)
+- 文件名 `output.docx` / `交底书.docx`(按案件名命名)
+- 跳过 self_check.md 直接交付
+
+## 输出
+
+完成后给用户:
+- 文件路径(`<案件名>_技术交底书.docx` + 各章 sections/*.md + figures/*.png)
+- 各章字数 vs 预算
+- 主推专利点摘要(独权种子的 3 句话)
+- 现有技术对照表(本发明 vs 检出的 N 条最近似 —— 区别点清单)
+- `<TODO>` 待补项清单(待用户/发明人补充的参数 / 实验数据 / 附图)

skills/patent/references/disclosure_structure.md

@@ -0,0 +1,238 @@
+# 交底书章节骨架
+
+> 阶段四起草前 always read。7 章 + 字数预算 + 必填要素。各章对应 `sections/NN_<名>.md`,NN 影响 docx 目录顺序。
+
+## 章节总览
+
+| NN | 章节 | 字数预算 | 占比 | 必填要素 |
+|---|---|---|---|---|
+| 01 | 技术领域 | 50-150 | 1% | 一句话 + IPC 大类 |
+| 02 | 背景技术 | 800-1500 | 15% | 现有技术 1/2/3 + 缺陷 + 引证号 |
+| 03 | 发明内容 | 1500-3000 | 25% | 技术问题 / 技术方案 / 有益效果 三段 |
+| 04 | 附图说明 | 100-300 | 2% | 图 1-N 一句话题注 |
+| 05 | 具体实施方式 | 2000-5000 | 45% | ≥1 实施例 + 关键参数取值 + 流程/算法 |
+| 06 | 有益效果 | 300-800 | 8% | 量化数据,不写形容词 |
+| 07 | 权利要求建议 | 300-1000 | 4% | 独权 + 从权草稿(供代理师参考) |
+
+总计约 **5000-11000 字**。开发期默认目标 7000-8000 字(中等复杂度发明)。
+
+---
+
+## §01 技术领域
+
+**结构**(就一句):
+
+> 本发明涉及 **<领域>** 领域,具体涉及一种 **<细分技术方向>** 的 **<方法/装置/系统>**。
+
+**例**:
+> 本发明涉及自然语言处理领域,具体涉及一种基于大语言模型的长文档结构化抽取方法。
+
+**雷区**:写成研究背景介绍。这一章只有一句话定位 IPC 分类用,不要展开。
+
+---
+
+## §02 背景技术
+
+**结构**(段 1 行业背景 + 段 2-4 现有技术 1/2/3 + 段 5 总结缺陷):
+
+```
+段 1 (100-200 字): 行业/技术大背景 — 这事为什么有人做、市场需求或技术痛点
+段 2 (200-400 字): 现有技术 1 — 引用专利/论文,描述其方案,指出 1-2 个缺陷
+段 3 (200-400 字): 现有技术 2 — 同上
+段 4 (200-400 字): 现有技术 3 — 同上 (≥2 条即可,3 条更稳)
+段 5 (100-200 字): 综合总结现有技术的共性缺陷,导出本发明要解决的技术问题
+```
+
+**引证写法**:
+- 专利:`如专利 CN112345678A 公开了一种 XXX 方法,其通过 YYY 实现 ZZZ。但该方法存在 <缺陷 1> 和 <缺陷 2>。`
+- 论文:`Smith 等人在 [文献名, 期刊, 年份] 中提出 XXX,通过 YYY 实现 ZZZ。但该方法 <缺陷>。`
+
+**缺陷怎么写**(对应本发明的"区别技术特征"):
+- 性能:精度低 / 时延高 / 资源占用大 / 鲁棒性差
+- 适用:仅适用于某场景 / 需大量标注数据 / 依赖特定硬件
+- 实现:步骤复杂 / 需人工干预 / 难以并行
+
+**雷区**:
+- 引证号编造 → 审查员一查就驳;不确定就写 `<TODO 待检索补充>`
+- 缺陷写"效果不好""精度不够"→ 太模糊,要具体到"准确率 < 70%"或"无法处理 > 10K 长度文档"
+- 一段就把现有方案带缺陷讲完 → 现有技术分条列,后续做"区别技术特征"时有靶子
+
+---
+
+## §03 发明内容
+
+**三段式硬结构**:
+
+### (一) 技术问题 (100-300 字)
+> 针对上述 <现有技术 N 的缺陷>,本发明所要解决的技术问题是 **<一句话技术问题>**。
+
+**雷区**:写成商业问题。"提升用户体验"不是技术问题;"在长文档场景下结构化抽取准确率低于 70%、且无法稳定支持 50K+ token 输入"是技术问题。
+
+### (二) 技术方案 (1000-2000 字)
+**这一段是交底书的核心。代理师写独权完全靠它。**
+
+```
+本发明的技术方案如下:
+
+一种 <方法/装置/系统>,包括以下步骤 / 包括以下模块:
+
+步骤 S1 / 模块 1: <名称>,<功能描述>,<具体实现 — 输入/处理/输出>;
+步骤 S2 / 模块 2: <名称>,<功能描述>,<具体实现>;
+...
+步骤 Sn / 模块 n: <名称>,<功能描述>,<具体实现>;
+
+其中,<关键创新点的进一步限定 — 通常是 1-2 处区别于现有技术的具体设计>。
+```
+
+**必含**:
+- 完整步骤/模块(代理师按这个写独权)
+- 每步的输入 / 处理 / 输出(可复现性)
+- 关键参数的占位(具体值放 §05 实施方式)
+- "其中"后的"进一步限定"= 区别技术特征,这是 separate from 现有技术的关键
+
+**雷区**:
+- 写"基于深度学习方法,根据训练结果输出结果"—— 黑盒,代理师拒收
+- 步骤里说"使用合适的方法处理"—— 必须说具体方法名
+- 把实施例细节(具体阈值、具体模型名、具体代码)塞这里 —— 这一节是"方案"层级,实施例放 §05
+
+### (三) 有益效果 (200-400 字)
+> 本发明相对于现有技术,具有以下有益效果:
+> 1. <效果 1, 对应技术方案某步骤/某设计>
+> 2. <效果 2, 对应另一步骤/设计>
+> ...
+
+每条效果要**回指**到技术方案里的具体步骤/模块,不要空泛说"提升性能"。
+
+---
+
+## §04 附图说明
+
+**结构**(图 N 一句题注):
+
+```
+图 1 为本发明实施例的整体流程示意图;
+图 2 为本发明实施例的 <模块 X> 结构示意图;
+图 3 为本发明实施例的 <时序 / 数据流向> 示意图;
+图 4 为本发明实施例的 <对比实验结果> 示意图;
+```
+
+**对齐规则**:本节"图 N"编号 = `sections/` 里 `![](figures/fig_xxx.png)` 出现顺序 = `render_docx.py` 全局自增编号。**不要手写图号**,只写题注顺序,渲染时自动对齐。
+
+**附图建议(常见型)**:
+- **必有**:整体流程图(对应技术方案的步骤总览)
+- **建议有**:关键模块结构图、时序图(异步/并发场景)、对比实验图(若 §06 有量化效果)
+
+---
+
+## §05 具体实施方式
+
+**这一章最长(45%)**。代理师按这一章判断"是否充分公开"—— 不充分公开等于无效。
+
+**结构**(实施例 1 必有,可加实施例 2/3 展示变体):
+
+```
+为使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。
+
+## 实施例 1
+
+### 1.1 整体流程
+本实施例提供一种 <名称>,如图 1 所示,包括以下步骤:
+
+#### 步骤 S1: <名称>
+<详细描述: 输入是什么 / 处理逻辑 / 关键参数取值 / 输出是什么>
+<必要时给伪代码 / 公式 / 表格>
+
+例如,采用 <具体方法/模型>,参数设置如下:
+| 参数 | 取值 | 说明 |
+|---|---|---|
+| <参数 1> | <值> | <为什么取这个值> |
+| ... | ... | ... |
+
+#### 步骤 S2: <名称>
+<同上>
+
+...
+
+### 1.2 关键模块详述 (可选)
+针对 <某关键模块>,如图 2 所示,其内部结构 / 算法细节如下:
+<详细说明>
+
+### 1.3 实验/效果验证 (可选,但有数据强烈建议)
+本实施例在 <数据集 / 场景> 上验证,结果如表 X / 图 N 所示:
+<量化结果表 / 对比表>
+
+## 实施例 2 (可选 — 展示变体扩大保护范围)
+<同实施例 1 结构,但替换某关键参数 / 步骤 / 模块,说明本发明的扩展性>
+```
+
+**必含**:
+- ≥1 个完整实施例(端到端,从输入到输出)
+- 所有关键参数的**具体取值**(不能留 `<TODO>` 进交付物)
+- 关键算法的**伪代码或公式**
+- 实验/效果数据(若 §06 给量化效果,这里要有支撑)
+
+**雷区**:
+- "本领域技术人员可以理解 XXX" —— 这话用来兜底某细节简略可以,但不能用来糊弄关键步骤
+- 实施例只描述功能不描述实现 —— 等于没写
+- 多实施例完全重复 —— 没意义,变体要在**关键设计点**上有差异
+
+---
+
+## §06 有益效果
+
+**结构**(每条效果一行,**全部量化**):
+
+```
+本发明实现了以下有益效果:
+
+1. 准确率方面: 在 <数据集/场景> 上,本发明的准确率达到 <X%>,相比现有技术 (Y%) 提升 <Z 个百分点>;
+2. 性能方面: 在 <硬件 / 输入规模> 条件下,本发明的处理时延为 <X ms>,相比现有技术 <Y ms> 降低 <Z%>;
+3. 资源方面: 本发明的内存占用为 <X GB>,相比现有技术 <Y GB> 降低 <Z%>;
+4. 鲁棒性方面: 在 <边界场景, 如长输入/低质量数据> 下,本发明仍能保持 <X% 准确率>,现有技术降至 <Y%>;
+5. 通用性方面: 本发明在 <场景 A / B / C> 上均可应用,扩展性强;
+```
+
+**雷区**:
+- "显著提升性能" / "效果良好" / "用户满意" —— 不可考核词
+- 比例不给绝对值 —— "提升 30%" 不够,要写"从 70% 提升到 91%"
+- 没数据来源 —— §05 实施方式里必须有对应数据支撑;没有就不写这条效果
+
+---
+
+## §07 权利要求建议 (可选)
+
+> 这一章是给**专利代理师**参考的草稿。代理师会重写成最终的权利要求书,但你给的草稿能让代理师抓住保护重点。不写也行,写了价值高。
+
+**结构**:
+
+```
+本发明建议的权利要求如下,供代理师参考:
+
+## 独立权利要求
+
+1. 一种 <名称>,其特征在于,包括以下步骤 / 包括:
+   - 步骤 S1: <对应 §03 技术方案的步骤,简洁化>;
+   - 步骤 S2: <...>;
+   - 步骤 Sn: <...>;
+   其中,<区别技术特征 — §03 "其中" 段的核心内容>。
+
+## 从属权利要求
+
+2. 根据权利要求 1 所述的 <名称>,其特征在于,<进一步限定 — 通常是某参数范围 / 某具体实现方式>。
+3. 根据权利要求 1 所述的 <名称>,其特征在于,<进一步限定>。
+4. ...
+
+## 装置/系统/介质权利要求 (若适用)
+
+5. 一种 <装置/系统>,其特征在于,包括:
+   - 模块 1: 用于执行权利要求 1 所述的步骤 S1;
+   - 模块 2: 用于执行步骤 S2;
+   ...
+
+6. 一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现权利要求 1 所述方法。
+```
+
+**雷区**:
+- 独权写得太窄 —— 把所有实施例细节都堆进去,保护范围被严重压缩;独权只放**必要技术特征**,可选细节进从权
+- 独权写得太宽 —— 没有"其中"段的区别技术特征,等于覆盖了现有技术,会被驳
+- 从权之间互相矛盾 —— 每条从权应该独立可选,不要互相依赖

skills/patent/references/patent_point_taxonomy.md

@@ -0,0 +1,153 @@
+# 专利点分类 + 可专利性自检
+
+> 阶段一(挖专利点)always read。先建立分类与三性框架,再判断每个候选是否值得写交底书。
+
+## 一、客体分类(写交底书前先定型)
+
+| 客体 | 中国专利法用语 | 写在交底书 | 适用场景 |
+|---|---|---|---|
+| **方法** | 方法发明 | "一种 XXX 方法" | 算法 / 流程 / 处理逻辑 / 工艺 |
+| **装置** | 产品发明 (装置) | "一种 XXX 装置" | 物理设备 / 模块化硬件 / 仪器 |
+| **系统** | 产品发明 (系统) | "一种 XXX 系统" | 软硬件协同 / 多模块协作 / 分布式架构 |
+| **介质** | 产品发明 (载体) | "一种计算机可读存储介质" | 程序产品保护(通常作为从权) |
+
+**多客体组合(强烈推荐)**:
+一个发明通常同时申请 **方法 + 装置/系统 + 介质** 三套权利要求,保护范围最大。交底书 §03 技术方案可只写方法,§07 权利要求建议里把装置/系统/介质都列上。
+
+**单方法纯软件的注意**:纯软件 / 算法本身不可专利,必须与"技术手段 + 技术问题 + 技术效果"绑定。写法见 §三 客体排除清单 §3.3。
+
+---
+
+## 二、三性自检(挖点时每个候选都过一遍)
+
+### (一) 新颖性 (Novelty)
+
+**定义**:本发明不属于现有技术(申请日前国内外公开过的任何技术)。
+
+**自检问题**:
+1. 本发明的技术方案,有没有在申请日前的专利 / 论文 / 公开产品 / 公开演示中出现过?
+2. 即使没有完全一样的,有没有现有技术 + 简单参数调整就能推出本发明?
+
+**怎么验**:阶段二做检索,命中 = 新颖性受损。**未检出 ≠ 一定有新颖性**,只能说"已尽职检索未发现",最终由审查员定。
+
+**典型杀手**:
+- 自己公司的论文/产品已经公开(自己"杀"自己的新颖性 —— 6 个月宽限期可能不够)
+- 同事已申请的在审专利(虽未公开但优先权日早)
+- 国外同款方案(国外公开也算)
+
+### (二) 创造性 (Inventive Step)
+
+**定义**:相对于现有技术,本发明具有"突出的实质性特点"和"显著的进步"。
+
+**自检问题**:
+1. 把本发明跟最接近的现有技术对比,**区别技术特征**是什么?(必须能用一两句话说清)
+2. 这个区别技术特征,对本领域技术人员来说是不是"显而易见"?(三步法)
+3. 这个区别技术特征带来了什么**预料不到的技术效果**?(量化)
+
+**三步法(审查员视角)**:
+1. 确定最接近的现有技术
+2. 找出区别技术特征 + 本发明实际解决的技术问题
+3. 判断"现有技术整体上是否给出了把区别特征用于解决该问题的启示"
+
+**典型杀手**:
+- 区别只是"参数取值不同"(如阈值从 0.5 改成 0.6)—— 显而易见,创造性不够
+- 区别只是"换个领域用"(把人脸识别用在动物识别)—— 转用发明,创造性看场景适配难度
+- 区别是已知技术的简单组合(A + B,两者目的相同) —— 显而易见组合
+
+### (三) 实用性 (Industrial Applicability)
+
+**定义**:能制造或使用,能产生积极效果。
+
+**自检**:大多数技术方案都过(只要不是永动机 / 违反自然规律 / 极端理想化的方案)。
+
+**少数雷区**:依赖未实现的硬件(如"基于量子计算机的 XXX")、依赖特殊条件无法重复(如"在零重力环境下 XXX")。
+
+---
+
+## 三、客体排除清单(直接淘汰,不可专利)
+
+### 3.1 智力活动的规则和方法
+**典型**:
+- 游戏规则、抽奖规则
+- 教学方法、心理咨询方法(纯流程,无技术手段)
+- 投资策略、商业计划
+
+**淘汰判断**:整个方案只涉及"人怎么决策""人怎么互动",没有技术设备介入。
+
+### 3.2 单纯的数学方法 / 算法本身
+**典型**:
+- "一种新的排序算法"(纯算法)
+- "一种新的矩阵分解方法"(纯数学)
+
+**怎么救**(纯软件想保护):必须绑定**具体技术场景** + **技术问题** + **技术效果**。
+
+> ❌ 不可专利:"一种基于 XXX 算法的数据分类方法"(无场景)
+> ✅ 可专利:"一种基于 XXX 算法的工业图像缺陷检测方法,用于解决传统方法在 <场景> 下准确率低的问题,通过 <步骤> 实现 <技术效果 — 缺陷检出率从 X% 提升至 Y%>"
+
+### 3.3 计算机程序本身
+**注意**:中国专利法不保护"计算机程序本身"(源代码 / 编译后产物 / 算法逻辑独立存在),但保护"计算机实现的发明"(程序作为技术方案的一部分,解决技术问题,产生技术效果)。
+
+**写法**:
+- 主权利要求写"方法"(强调步骤、技术效果)
+- 从权写"装置"(强调硬件 + 软件协作)
+- 末权写"介质"("一种计算机可读存储介质,存储有程序,程序被执行时实现权利要求 1 的方法")
+
+### 3.4 智力规则 + AI 模型相关
+**典型**:
+- "一种使用 LLM 做 XXX 摘要的方法"(只是调 LLM)
+- "一种基于 ChatGPT API 的 XXX 系统"(只是商业整合)
+
+**怎么救**:
+- 不要保护"用 LLM"本身,保护**针对 LLM 的具体增强**(如 prompt 结构设计 / chunking 策略 / 评分机制 / 多模型协同方式 / 推理加速方法)
+- 区别技术特征落到"我们对 LLM 的什么做了改进,改进带来了什么具体效果"
+
+### 3.5 商业方法、金融方法
+**典型**:
+- "一种 XXX 营销方法"
+- "一种新型信贷审批流程"
+
+**怎么救**:必须有技术手段(数据采集 / 算法处理 / 自动化决策),且解决的是**技术问题**(如时延、准确率),而非商业问题(如转化率、用户留存)。
+
+### 3.6 疾病的诊断和治疗方法
+直接不可专利。可救:
+- "一种用于辅助 XXX 诊断的图像处理方法"(辅助,非诊断本身)
+- "一种 XXX 药物"(物质本身可以)
+- "一种 XXX 医疗器械"(器械可以)
+
+### 3.7 动植物品种
+品种本身不可专利。可救:
+- 培育动植物品种的**非生物学方法**(基因编辑方法、组织培养方法)
+- 微生物本身可以
+
+### 3.8 违反法律 / 公序良俗
+赌博、毒品、武器等。
+
+### 3.9 科学发现 / 自然规律
+"发现"不可专利,"发明利用该发现的方法/产品"可以。
+
+---
+
+## 四、挖点判断流程(每个候选过这个表)
+
+```
+1. 客体类型? (方法/装置/系统/介质 → 三 §一) → 不在表里 → 淘汰
+2. 客体排除? (三 §三) → 命中排除 → 淘汰 (或想救法)
+3. 解决的技术问题是什么? (一句话,要"技术"问题不是商业问题)
+4. 关键技术手段是什么? (≥1 个区别于现有方案的具体步骤/结构/参数设计)
+5. 三性初判:
+   - 新颖性: 印象里有没有人做过? (待阶段二检索验证)
+   - 创造性: 区别技术特征对本领域技术人员显不显而易见?
+   - 实用性: 能不能复现 + 有没有积极效果? (默认通过,除非异常)
+6. 推荐?
+   - 三性都过 + 不在排除清单 → 推荐
+   - 创造性弱(只是参数/简单组合)→ 可保但优先级低,告知用户
+   - 不在排除但纯软件 → 必须按 §3.2 / §3.4 救法包装
+```
+
+## 反模式(挖点常见错误)
+
+- 把"用了某新技术"当专利点 —— 用了 ≠ 改了
+- 把"做了某产品"当专利点 —— 产品 ≠ 技术方案
+- 把"实现了某功能"当专利点 —— 功能 ≠ 创新点;关键是怎么实现的、跟别人怎么实现的有什么不同
+- 一个候选囊括多个发明 —— 拆开,一个交底书 = 一个发明
+- 因为是自己做的 / 花了很多时间 / 老板觉得重要 → 就当可专利 —— 三性是客观的,不看投入只看技术内容

skills/patent/references/prior_art_search.md

@@ -0,0 +1,157 @@
+# 现有技术检索
+
+> 阶段二(检索)always read。**没检索就写交底书 = 高风险**(代理师 / 审查员一查就出问题)。
+
+## 一、检索目的
+
+1. **验证新颖性**:本发明的技术方案,在申请日前有没有公开过?
+2. **找最接近现有技术**:写交底书 §02 背景技术 + §03 区别技术特征 的"靶子"
+3. **避免重大撞车**:命中 = 提前调整方案 / 换创新点 / 放弃,避免代理费 + 申请费 + 时间打水漂
+
+## 二、关键词构造
+
+### 2.1 三层关键词
+
+| 层 | 关键词类型 | 例子(以"基于 LLM 的长文档结构化抽取"为例) |
+|---|---|---|
+| 核心技术 | 本发明的关键技术 + 同义/近义 | "大语言模型" / "LLM" / "large language model" / "GPT" / "Transformer" |
+| 应用对象 | 本发明处理的对象/场景 + 同义 | "长文档" / "长文本" / "long document" / "long context" |
+| 技术效果 | 本发明的关键效果 + 同义 | "结构化抽取" / "信息抽取" / "structured extraction" / "information extraction" |
+
+### 2.2 检索式组合
+
+```
+A ∩ B ∩ C       # 三层都命中 — 最相关
+A ∩ B           # 核心 + 对象 — 相关
+A ∩ C           # 核心 + 效果 — 相关
+A ∩ (B | C)     # 核心 + (对象 | 效果) — 较宽
+```
+
+### 2.3 中英文都要搜
+
+- 中文专利库 / 中文论文 → 中文关键词
+- Google Patents / 英文论文 → **英文关键词**(国际同行用英文,命中率比中文高)
+- **同一概念中英文混着搜 3-5 组**,降低漏检
+
+### 2.4 限定符技巧(配合 `web_search` 用)
+
+| 目的 | query 加 |
+|---|---|
+| 限定专利 | `site:patents.google.com` 或加 `专利 CN` |
+| 限定中国专利 | `site:cnipa.gov.cn` 或 query 加 `公开号 CN` |
+| 限定学术论文 | `site:arxiv.org` / `site:scholar.google.com` |
+| 限定近期 | query 加 `2022..2026` 或英文 `after:2022` |
+| 排除噪音 | query 加 `-广告 -培训` 等(注意有些引擎不支持) |
+
+---
+
+## 三、数据源优先级
+
+| # | 数据源 | 用什么工具 | 何时用 |
+|---|---|---|---|
+| 1 | **中国专利公开** | `web_search` + `site:patents.google.com country:CN` 或 `site:cnipa.gov.cn` | **必查** — 同地区先发的优先权可能挡你的路 |
+| 2 | **国际专利** | `web_search` + `site:patents.google.com` / `site:wipo.int` | **必查** — 国外同款方案也算现有技术 |
+| 3 | **学术论文** | `research` skill (OpenAlex) / `documents` skill (材料库) / `web_search` + `site:arxiv.org` | **强烈推荐** — 论文公开早于专利,常是创造性杀手 |
+| 4 | **行业产品/公开演示** | `web_search` 一般 query | 视情况 — 大厂博客 / 产品文档 / 会议演示 |
+| 5 | **本地文献库** | `documents` skill (材料学科 7 个库) / `research` skill (paper_server) | 涉及材料 / 化学 / 工程领域时优先 |
+
+> 注:CNIPA 官网爬虫本 skill **不实现**(反爬重 + 维护成本高)。如果用户要正式可作为 IDS 提交的检索证据,建议人工跑专利数据库(智慧芽 / Patentics / incoPat / 谷歌 Patents 自己手动检索)。本 skill 出的检索结论定位为"代理师写文件前的尽职检索 + 风险预警",不替代正式律所/代理所检索。
+
+---
+
+## 四、命中归档格式
+
+每条命中按下表记录(写到 spec §4 检索结论):
+
+```markdown
+### [N] <一句话标题>
+
+- **类型**: 专利 / 论文 / 产品 / 其它
+- **标识**:
+  - (专利) 公开号 CN12345678A / 申请人 XX公司 / 公开日 2023-01-01
+  - (论文) DOI 10.xxxx/xxx / 作者 / 期刊 / 年
+  - (产品) 厂商 / 产品名 / 公开日期 / 来源 URL
+- **技术方案** (一段): 它做了什么、怎么做的、解决什么问题
+- **与本发明的区别 (关键)**:
+  - 相同点: A1 / A2 / ...
+  - 不同点 (= 本发明的区别技术特征): B1 / B2 / ...
+- **威胁等级**: 高危 (技术问题 + 关键手段都重合) / 中 (部分重合) / 低 (远缘)
+```
+
+**威胁等级判断**:
+- **高危**:技术问题 + 关键技术手段都重合 → ⛔ **告知用户,建议改方案 / 换创新点 / 放弃**
+- **中**:技术问题相同但手段不同,或手段相似但问题不同 → 作为 §02 背景技术 + §03 区别技术特征 的"靶子"
+- **低**:远缘但相关 → 可不入背景技术,只在 spec §4 留备查
+
+---
+
+## 五、区别技术特征写法
+
+写交底书 §03 "其中,..." 那段 + §07 权利要求建议时,**区别技术特征**是关键。
+
+### 写法模板
+
+> 与最接近现有技术 [N] 相比,本发明的区别在于:
+> 1. **<区别 1>**:本发明 <如何做>,而 [N] <如何做>;该区别带来 <技术效果 X>。
+> 2. **<区别 2>**:...
+
+### 例子
+
+> 与最接近现有技术 CN12345678A 相比,本发明的区别在于:
+> 1. **分块策略不同**:本发明采用基于语义边界的动态分块(滑动窗口 + 句法解析),CN12345678A 采用固定 token 长度分块;本发明使语义完整性保持率从 67% 提升至 94%。
+> 2. **抽取流程不同**:本发明引入两阶段抽取(粗筛 + 精排)并设计了交叉验证机制,CN12345678A 单次抽取;本发明使端到端准确率从 78% 提升至 91%。
+
+### 雷区
+
+- 区别只写"采用了不同的方法"—— 太模糊,要具体到设计点
+- 区别没有量化效果支撑 —— 创造性论证薄弱
+- 区别 4-5 条全部列出 —— 选 1-3 条核心的;太多反而稀释保护强度
+
+---
+
+## 六、检索强度分级(开发期默认)
+
+| 强度 | 投入 | 适用 |
+|---|---|---|
+| **轻量**(默认)| 3-5 组检索式,每组前 10 条命中,2-4 高/中危归档 | 大多数发明的"尽职检索"够用,给代理师参考 |
+| **中等** | 10+ 组检索式,前 20 条/组,跨中英文,5+ 高/中危归档 | 重要发明,准备申请 PCT / 国际布局 |
+| **重度** | 跑正式专利库(智慧芽/Patentics)/ 委托检索机构 | 拟商业化 / 拟诉讼 / 拟无效他人 |
+
+> 本 skill 默认按 **轻量** 跑,够给代理师起手参考。要重度检索建议线下专业渠道。
+
+---
+
+## 七、检索结论模板(供 spec §4 抄)
+
+```markdown
+## 4. 现有技术检索结论
+
+**检索时间**: <YYYY-MM-DD>
+**检索强度**: 轻量 / 中等
+**检索式**:
+- 检索 1: <关键词组合>
+- 检索 2: <...>
+- ...
+
+**命中归档**:
+
+### [1] <标题>
+- 类型 / 标识 / 技术方案 / 区别 / 威胁等级 (见 §四 模板)
+
+### [2] <标题>
+- ...
+
+**结论**:
+- 高危: <列出 + 应对方案>
+- 中危: <列出,作为 §02 背景技术对照>
+- 低危 / 远缘: <列出或仅备查>
+- 漏检风险: <例如 "未跑正式专利库,小规模公司在审专利可能漏检"; 让用户知情>
+```
+
+## 反模式
+
+- 一组关键词搜完就交 —— 至少 3-5 组,中英文都跑
+- 看了 title 就判威胁等级 —— 必须看技术方案描述(`web_fetch` 拉摘要)
+- 编公开号 / DOI / 作者 —— 检不到就说"未检出近似"
+- 把"用了相似技术"当高危 —— 高危看技术问题 + 关键手段是否都重合,只技术相似不算
+- 没归档区别技术特征 —— 检索的核心价值在区别,光列命中不写区别等于白搜

skills/patent/references/self_check.md

@@ -0,0 +1,95 @@
+# 渲染前自查清单
+
+> 阶段五第 1 步:模型按本清单逐条对照 `sections/*.md`,不过的项回头 edit 章节再来。无脚本,纯人工(模型)checklist。
+
+## 自查 6 类(每类都要过)
+
+### 类 1: 完整性
+
+| # | 检查项 | 不过怎么办 |
+|---|---|---|
+| 1.1 | `sections/` 下 01-06 章齐全(07 可选) | 补缺 |
+| 1.2 | 每章字数在预算范围(见 `disclosure_structure.md`) | 偏离 >50% 回头改 |
+| 1.3 | §02 背景技术至少 2 条现有技术(推荐 3 条) | 补 |
+| 1.4 | §03 发明内容三段(技术问题/技术方案/有益效果)齐全 | 补 |
+| 1.5 | §05 具体实施方式至少 1 个完整实施例(端到端) | 补 |
+| 1.6 | §06 有益效果至少 2 条,**全部量化** | 把"显著提升"等改成数字 |
+| 1.7 | 附图 ≥ 1 张(至少 1 张整体流程图) | 补 mermaid 块 |
+
+### 类 2: 一致性
+
+| # | 检查项 | 不过怎么办 |
+|---|---|---|
+| 2.1 | §03 技术方案的步骤数 ≈ §05 实施方式的步骤数(可细化但不能矛盾) | 对齐 |
+| 2.2 | §03 提到的"现有技术 N"对应 §02 里实际有的引证 | 对齐 |
+| 2.3 | §06 有益效果的每条数据,§05 里有对应实施例支撑 | 删无支撑的效果,或在 §05 补数据 |
+| 2.4 | §04 附图说明里的"图 N"对应 §05 正文里"如图 N 所示"的引用 | 对齐顺序 |
+| 2.5 | 同一术语 / 缩写 / 参数符号全文一致(LLM ≠ 大模型 ≠ 大语言模型 选一个用) | 全局替换 |
+| 2.6 | 同一参数的取值全文一致(§03 写阈值 0.5,§05 别写 0.6) | 对齐 |
+| 2.7 | 公式符号 → 公式 → 量纲一致,符号定义不缺漏 | 补符号定义 / 校正公式 |
+
+### 类 3: 充分公开
+
+> 代理师拿到交底书能不能复现?审查员看了相信不相信?
+
+| # | 检查项 | 不过怎么办 |
+|---|---|---|
+| 3.1 | §03 技术方案的每个步骤都有"输入 / 处理 / 输出" | 补,不要黑盒 |
+| 3.2 | §05 实施方式的关键参数**都有具体取值**(不留 `<TODO>`) | 找用户/发明人补;实在没有不写这条参数,但不能空着 |
+| 3.3 | 关键算法有伪代码或公式(不能只描述功能) | 补 |
+| 3.4 | "基于 XX 方法"后面有具体怎么用 XX(不能只甩名字) | 补 |
+| 3.5 | "本领域技术人员可以理解"只用来兜底次要细节,不用来糊弄关键步骤 | 关键步骤展开 |
+
+### 类 4: 区别技术特征
+
+| # | 检查项 | 不过怎么办 |
+|---|---|---|
+| 4.1 | §03 "其中,..."段(或 §07 独权)明确写了区别技术特征 | 补 |
+| 4.2 | 区别技术特征指向 §02 背景技术里某条现有技术(有对照) | 对齐;没对照 = 创造性论证薄弱 |
+| 4.3 | 区别带来的技术效果在 §06 有体现(量化) | 对齐 |
+
+### 类 5: 客体合规
+
+| # | 检查项 | 不过怎么办 |
+|---|---|---|
+| 5.1 | 不是 `patent_point_taxonomy.md §三` 排除清单里的客体 | 命中排除 → 回头按"救法"重新包装,或换创新点 |
+| 5.2 | 纯软件方案有具体技术场景 + 技术问题 + 技术效果绑定 | 补 |
+| 5.3 | 没有"诊断" / "治疗" / "动植物品种"字眼(除非已按救法包装) | 改 |
+
+### 类 6: 脱敏 + 语言
+
+| # | 检查项 | 不过怎么办 |
+|---|---|---|
+| 6.1 | spec §脱敏边界 列出的所有商业敏感词(客户名 / 内部代号 / 数据源 url)在交底书里都被中性化 | 全局替换为"某客户" / "目标数据源" 等 |
+| 6.2 | 关键技术参数 / 算法 **未脱敏**(脱敏完代理师没法写) | 误脱敏 → 加回 |
+| 6.3 | 没有不可考核形容词:"显著""颠覆""国际领先""填补空白""完美""极大"等 | 删 / 改 |
+| 6.4 | 没有营销话术 / 宣传体 | 改 |
+| 6.5 | 章节标题与 `disclosure_structure.md` 规范名称一致 | 对齐 |
+| 6.6 | 一份交底书只对应 **1 个发明**(独立权利要求一项) | 多发明拆分多份 |
+
+## 自查输出
+
+按本清单跑完后,在对话中给用户一个简表:
+
+```markdown
+## 自查报告
+
+| 类 | 通过/总数 | 不过项 |
+|---|---|---|
+| 1 完整性 | 6/7 | 1.3: §02 只有 1 条现有技术,已补 |
+| 2 一致性 | 7/7 | — |
+| 3 充分公开 | 4/5 | 3.2: 阈值取值缺(已补成 0.5);3.4: "基于 BERT" 已补具体用法 |
+| 4 区别技术特征 | 3/3 | — |
+| 5 客体合规 | 3/3 | — |
+| 6 脱敏+语言 | 5/6 | 6.3: 删除 3 处"显著",改成具体数字 |
+
+**结论**: 全部通过,可以渲染。
+**未尽事项 (`<TODO>` 类)**:
+- [ ] 实施例 2 的对比实验数据(用户提供后补 §05.2 表格)
+```
+
+## 反模式
+
+- 没跑自查就直接 `render_docx.py` 输出交付 —— 数据/术语/参数不一致很常见,自查能拦
+- 自查输出"全部通过" 但其实没逐条对照 —— 跑就要认真跑;偷懒等于没跑
+- 不过项不补就交付 —— 不过项要么补、要么明示用户(放进 `<TODO>` 清单)

skills/patent/templates/disclosure.md

@@ -0,0 +1,264 @@
+# 交底书 Markdown 模板
+
+> 阶段四逐章起草时,从本模板复制对应小节到 `<task_dir>/sections/NN_<名>.md`。每章遵循 `references/disclosure_structure.md` 的结构与字数预算。
+
+---
+
+## 01_技术领域.md
+
+```markdown
+# 一、技术领域
+
+本发明涉及 <领域> 领域,具体涉及一种 <细分技术方向> 的 <方法/装置/系统>。
+```
+
+---
+
+## 02_背景技术.md
+
+```markdown
+# 二、背景技术
+
+<段 1 — 行业/技术大背景, 100-200 字: 这事为什么有人做、市场需求或技术痛点>
+
+<段 2 — 现有技术 1, 200-400 字>
+如专利 <CN12345678A> 公开了一种 <名称> 的方法,其通过 <关键技术手段> 实现 <技术效果>。但该方法存在以下缺陷:
+1. <缺陷 1, 具体到指标或场景>;
+2. <缺陷 2>。
+
+<段 3 — 现有技术 2, 200-400 字>
+<文献作者> 等人在 <文献名, 期刊, 年> 中提出 <名称>,通过 <关键技术手段> 实现 <技术效果>。但该方法 <缺陷>。
+
+<段 4 — 现有技术 3, 200-400 字>
+<同上结构>
+
+<段 5 — 综合缺陷, 100-200 字>
+综上,现有技术普遍存在 <共性缺陷 — 通常对应本发明要解决的技术问题>。亟需一种 <本发明的方向描述> 的方案。
+```
+
+---
+
+## 03_发明内容.md
+
+```markdown
+# 三、发明内容
+
+## (一) 技术问题
+
+针对上述现有技术中 <现有技术 N 的缺陷>,本发明所要解决的技术问题是: **<一句话技术问题, 具体不空泛>**。
+
+## (二) 技术方案
+
+为解决上述技术问题,本发明提供了如下技术方案:
+
+一种 <名称> 的 <方法/装置/系统>,包括以下步骤 / 包括以下模块:
+
+**步骤 S1 / 模块 1: <名称>**
+<功能描述: 输入是什么 / 主要处理逻辑 / 输出是什么>
+
+**步骤 S2 / 模块 2: <名称>**
+<同上>
+
+**步骤 S3 / 模块 3: <名称>**
+<同上>
+
+<...如有更多步骤继续>
+
+**步骤 Sn / 模块 n: <名称>**
+<同上>
+
+**其中,<区别技术特征 — 1-2 处区别于现有技术的具体设计>**。
+
+具体地:
+- <关键设计点 1 的说明>;
+- <关键设计点 2 的说明>。
+
+## (三) 有益效果
+
+本发明相对于现有技术,具有以下有益效果:
+
+1. <效果 1, 回指技术方案某步骤/模块, 量化>;
+2. <效果 2, 回指, 量化>;
+3. <效果 3, 量化>。
+```
+
+---
+
+## 04_附图说明.md
+
+```markdown
+# 四、附图说明
+
+图 1 为本发明实施例的整体流程示意图;
+图 2 为本发明实施例的 <关键模块/装置 X> 结构示意图;
+图 3 为本发明实施例的 <时序/数据流向> 示意图;
+图 4 为本发明实施例的 <实验对比> 示意图。
+```
+
+> 附图编号由 `render_docx.py` 全局自增,本节只写题注顺序。`sections/` 里 `![](figures/fig_xxx.png)` 引用顺序 = 这里"图 N"顺序。
+
+---
+
+## 05_具体实施方式.md
+
+```markdown
+# 五、具体实施方式
+
+为使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅用以解释本发明,并不用于限定本发明。
+
+## 实施例 1
+
+### 1.1 整体流程
+
+本实施例提供一种 <名称>,如图 1 所示,包括以下步骤:
+
+```mermaid
+%% caption: 整体流程
+flowchart LR
+  A[输入 <输入对象>] --> B[步骤 S1: <名称>]
+  B --> C[步骤 S2: <名称>]
+  C --> D[步骤 S3: <名称>]
+  D --> E[输出 <输出结果>]
+```
+
+#### 步骤 S1: <名称>
+
+**输入**: <输入数据类型 / 来源 / 规格>
+**处理**: <详细处理逻辑, 可含伪代码>
+**输出**: <输出数据类型 / 含义>
+
+具体地,采用 <具体方法/模型/算法>,参数设置如下:
+
+| 参数 | 取值 | 量纲 | 说明 |
+|---|---|---|---|
+| <参数 1> | <值> | <量纲> | <为什么取这个值> |
+| <参数 2> | <值> | <量纲> | <...> |
+
+伪代码:
+
+```
+函数 <名>(<输入参数>):
+  1. <第一步>
+  2. <第二步>
+  3. 返回 <输出>
+```
+
+#### 步骤 S2: <名称>
+
+<同步骤 S1 结构: 输入 / 处理 / 输出 / 参数 / 伪代码或公式>
+
+#### 步骤 S3: <名称>
+
+<同上>
+
+### 1.2 关键模块详述
+
+针对 <关键模块>,其内部结构如图 2 所示,具体设计如下:
+
+```mermaid
+%% caption: 关键模块结构
+flowchart TB
+  subgraph 模块[关键模块]
+    M1[子模块 1: <名称>]
+    M2[子模块 2: <名称>]
+    M3[子模块 3: <名称>]
+    M1 --> M2 --> M3
+  end
+```
+
+<详细说明各子模块的功能、接口、关键算法>
+
+数学描述(若适用):
+
+设 <符号 1> 表示 <含义>,<符号 2> 表示 <含义>,则本模块的核心公式为:
+
+$$
+<公式>
+$$
+
+其中 <符号 3> 为 <含义,量纲>。
+
+### 1.3 实验/效果验证
+
+本实施例在 <数据集 / 场景> 上进行验证,实验环境: <硬件 / 软件 / 数据规模>。
+
+实验结果如下表所示:
+
+| 指标 | 本发明 | 现有技术 [N1] | 现有技术 [N2] |
+|---|---|---|---|
+| <指标 1> | <值> | <值> | <值> |
+| <指标 2> | <值> | <值> | <值> |
+| <指标 3> | <值> | <值> | <值> |
+
+实验结果可视化(对比柱状图):
+
+![实验对比](figures/exp_compare.png)
+
+由表/图可见,本发明在 <指标维度> 上较现有技术提升 <X%>。
+
+## 实施例 2 (可选 — 展示变体扩大保护范围)
+
+本实施例与实施例 1 的不同在于 <关键设计点的变化>。其余步骤同实施例 1。
+
+<只写差异部分, 不重复全流程>
+```
+
+---
+
+## 06_有益效果.md
+
+```markdown
+# 六、有益效果
+
+本发明实现了以下有益效果:
+
+1. **<效果维度 1, 如准确率>**: 在 <数据集/场景> 上,本发明的 <指标> 达到 <X%>,相比现有技术 (<Y%>) 提升 <Z 个百分点>;
+2. **<效果维度 2, 如性能/时延>**: 在 <硬件 / 输入规模> 条件下,本发明的 <指标> 为 <X ms>,相比现有技术 <Y ms> 降低 <Z%>;
+3. **<效果维度 3, 如资源占用>**: 本发明的 <指标> 为 <X GB>,相比现有技术 <Y GB> 降低 <Z%>;
+4. **<效果维度 4, 如鲁棒性>**: 在 <边界场景, 如长输入/低质量数据> 下,本发明仍能保持 <X% 指标>,而现有技术降至 <Y%>;
+5. **<效果维度 5, 如通用性>**: 本发明可应用于 <场景 A / B / C> 等多个场景,扩展性强。
+```
+
+---
+
+## 07_权利要求建议.md (可选)
+
+```markdown
+# 七、权利要求建议
+
+> 本节为发明人提供给专利代理师的权利要求草稿,供撰写最终权利要求书参考。代理师将基于发明内容与本草稿撰写正式权利要求,正式权利要求以代理师定稿为准。
+
+## 独立权利要求(方法)
+
+1. 一种 <名称> 的方法,其特征在于,包括以下步骤:
+
+   S1. <对应 §03 技术方案的步骤 1, 简洁化>;
+   S2. <步骤 2>;
+   S3. <步骤 3>;
+   ...
+   Sn. <步骤 n>;
+
+   其中,<区别技术特征 — §03 "其中" 段的核心内容, 一两句话>。
+
+## 从属权利要求
+
+2. 根据权利要求 1 所述的方法,其特征在于,所述步骤 S<X> 中,<进一步限定 — 通常是某参数范围 / 某具体实现方式>。
+
+3. 根据权利要求 1 所述的方法,其特征在于,所述步骤 S<Y> 中,<另一进一步限定>。
+
+4. 根据权利要求 1-3 任一项所述的方法,其特征在于,<更广的进一步限定>。
+
+## 装置/系统权利要求
+
+5. 一种 <名称> 的装置 / 系统,其特征在于,包括:
+   - <模块 1>: 用于执行权利要求 1 所述的步骤 S1;
+   - <模块 2>: 用于执行步骤 S2;
+   - ...
+   - <模块 n>: 用于执行步骤 Sn。
+
+## 介质权利要求
+
+6. 一种计算机可读存储介质,其上存储有计算机程序,所述程序被处理器执行时实现权利要求 1 至 4 任一项所述的方法。
+
+7. 一种电子设备,包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序,所述处理器执行所述程序时实现权利要求 1 至 4 任一项所述的方法。
+```

skills/patent/templates/spec.md

@@ -0,0 +1,137 @@
+# 交底书 spec
+
+> 阶段三产物(继承阶段一专利点 + 阶段二检索结论)。**写定后不再改**,阶段四每章前都要 read。`<TODO>` 是占位符,需要用户/发明人明确填值;不要硬编。
+
+## 1. 案件基本信息
+
+| 字段 | 值 |
+|---|---|
+| 案件名(内部) | `<TODO 简短代号, 用于文件命名>` |
+| 拟用发明名称 | `<TODO 一种 XXX 方法/装置/系统>` (后续由代理师定稿,可改) |
+| 客体类型 | 方法 / 装置 / 系统 / 介质 (可多选;典型组合 = 方法 + 装置/系统 + 介质) |
+| 技术领域 (IPC 大类) | `<TODO 如自然语言处理 / 计算机视觉 / 化工材料 / ...>` |
+| 申请类型 | 发明 (默认) / 实用新型 / 外观 |
+| 拟优先权日 | `<TODO YYYY-MM-DD>` (代理师确定) |
+| 代理所/代理师 | `<TODO 已联系/待定>` |
+
+## 2. 发明人 / 申请人
+
+### 发明人 (按贡献排序)
+| 序 | 姓名 | 单位 | 邮箱 | 贡献 |
+|---|---|---|---|---|
+| 1 | `<TODO>` | `<TODO>` | `<TODO>` | `<TODO 主要思路 / 核心算法 / 实验验证 / ...>` |
+| 2 | `<TODO>` | `<TODO>` | `<TODO>` | `<TODO>` |
+
+### 申请人
+`<TODO 单位名称>` (与发明人单位通常一致;校企合作 / 联合申请单独说明)
+
+## 3. 主推专利点 (阶段一筛选结果)
+
+> **一份交底书 = 1 个发明 = 1 个独权**。多个独立点 → 多份交底书。
+
+### 主推点(必填)
+- **名称**: `<TODO 一句话, 如"基于 X 的 Y 方法">`
+- **解决的技术问题**: `<TODO 一句话, 技术性问题不是商业问题>`
+- **关键技术手段**(≥1 个区别于现有的步骤/结构/参数设计):
+  - 手段 1: `<TODO>`
+  - 手段 2: `<TODO>`
+  - 手段 3: `<TODO>` (可选)
+- **三性初判** (待阶段二检索验证):
+  - 新颖性: `<TODO 印象里有/无 + 见 §4 检索>`
+  - 创造性: `<TODO 区别特征对本领域显不显而易见 + 三步法>`
+  - 实用性: `<TODO 默认通过, 异常需说明>`
+
+### 候选点(阶段一冒出但本次不写, 留备查)
+- `<TODO 名称 + 一句话原因(创造性弱/客体排除/合并入主推/...)>`
+- ...
+
+## 4. 现有技术检索结论 (阶段二产物)
+
+**检索时间**: `<TODO YYYY-MM-DD>`
+**检索强度**: 轻量 / 中等 (默认轻量)
+**检索式**:
+- 检索 1: `<TODO 关键词组合>`
+- 检索 2: `<TODO>`
+- ...
+
+**命中归档**:
+
+### [1] `<TODO 标题>`
+- **类型**: 专利 / 论文 / 产品
+- **标识**:
+  - (专利) 公开号 `<TODO CN12345678A>` / 申请人 `<TODO>` / 公开日 `<TODO>`
+  - (论文) DOI / 作者 / 期刊 / 年
+- **技术方案**: `<TODO 一段, 它怎么做的>`
+- **与本发明区别**:
+  - 相同点: `<TODO>`
+  - 不同点 (= 本发明区别技术特征): `<TODO>`
+- **威胁等级**: 高 / 中 / 低
+
+### [2] `<TODO>`
+- ...
+
+**结论**:
+- 高危: `<TODO 列出 + 应对(改方案/换点/继续)>`
+- 中危: `<TODO 列出, 作 §02 背景对照>`
+- 低危/远缘: `<TODO 仅备查>`
+- **漏检风险**: `<TODO 例如"未跑正式专利库,小规模在审专利可能漏检">` (让用户知情)
+
+## 5. 章节预算 (阶段四起草目标)
+
+| 章节 | 字数目标 | 关键内容 |
+|---|---|---|
+| 01 技术领域 | 100 | IPC + 一句话定位 |
+| 02 背景技术 | `<TODO 800-1500>` | 现有技术 2-3 条 + 缺陷 (引 §4 命中) |
+| 03 发明内容 | `<TODO 1500-3000>` | 技术问题 / 技术方案 / 有益效果 |
+| 04 附图说明 | 200 | 图 1-N 题注 |
+| 05 具体实施方式 | `<TODO 2000-5000>` | 实施例 + 关键参数取值 + 流程 |
+| 06 有益效果 | `<TODO 300-800>` | 量化数据 |
+| 07 权利要求建议 | `<TODO 300-1000>` (可选) | 独权 + 从权草稿 |
+| **总计** | `<TODO 5000-11000>` | |
+
+## 6. 附图清单 (阶段四起草前列, 阶段五由 render_diagrams.py 渲染)
+
+| 图号 | 类型 | mermaid caption / 文件名 | 内容 |
+|---|---|---|---|
+| 图 1 | 流程图 | `<TODO 整体流程>` | 本发明端到端流程 (必有) |
+| 图 2 | 结构图 | `<TODO 模块结构>` | 关键模块/装置结构 |
+| 图 3 | 时序图 | `<TODO 时序>` | 并发 / 异步场景(可选) |
+| 图 4 | 实验对比 | `<TODO 准确率对比>` | matplotlib 出 png(若 §06 有量化数据) |
+
+## 7. 关键参数清单 (供 §05 实施方式填具体值)
+
+| 参数名 | 取值 | 量纲 | 说明 |
+|---|---|---|---|
+| `<TODO 阈值 X>` | `<TODO 0.5>` | — | `<TODO 为什么这个值>` |
+| `<TODO 窗口大小>` | `<TODO 100>` | ms | `<TODO>` |
+| `<TODO 学习率>` | `<TODO 1e-4>` | — | `<TODO>` |
+| ... | ... | ... | ... |
+
+> 起草 §05 时取自本表;此表项空着或写 `<TODO>` → 起草必出 `<TODO>` → 自查 3.2 拦截 → 找用户/发明人补。
+
+## 8. 脱敏边界
+
+> 哪些词商业敏感需要中性化,哪些技术信息**不能脱敏**(脱敏完代理师没法写)。
+
+### 需脱敏(写进交底书时替换为中性词)
+| 原词 | 替换为 |
+|---|---|
+| `<TODO 客户名 A>` | 某客户 / 某工业用户 |
+| `<TODO 内部产品代号 X>` | 本系统 / 该装置 |
+| `<TODO 内部数据源 url>` | 目标数据源 |
+| `<TODO 内部团队/项目名>` | (删除或不写) |
+
+### 不能脱敏(必须保留)
+- 关键算法名 / 步骤 / 公式 / 参数取值
+- 通用技术栈(Python / PyTorch / Kafka 等)
+- 行业通用术语
+- 实验数据(可隐去采集环境细节,但数值要保留)
+
+## 9. TODO 列表
+
+> 阶段一-阶段三冒出来的"等用户/发明人提供"事项。阶段四每章开头扫一眼;阶段五自查会扫余留的 `<TODO>`。
+
+- [ ] `<TODO 比如: 索取实施例 2 的对比实验数据>`
+- [ ] `<TODO 比如: 确认核心参数取值>`
+- [ ] `<TODO 比如: 联系代理所确认申请窗口>`
+- [ ] `<TODO ...>`

skills/ppt/SKILL.md

@@ -78,6 +78,7 @@ glob <task_dir>/*-<task_short_id>-*.spec.md → 按文件名字典序排,取最
 3. 写一个 `run_python` block,用 python-pptx 添加这一页 (载入已有 .pptx → append slide → save)
 4. 报这一页:版式、标题、要点条数、用了哪些图标
 5. 用户确认 / 微调后再下一页
+6. 用户确认了**实质改动**(改版式 / 换图标 / 改文案要点 / 增删页 / 调主色)后,追加一行到 `<task_dir>/REVISIONS.md` —— 见 §修订日志
 
 **为什么逐页?** 一次性出全 deck 中途改方向就要全推翻;逐页能让用户在第 2 页就发现问题。
 
@@ -113,9 +114,56 @@ python <skill_dir>/scripts/quality_check.py <task_dir>/<output.pptx> --spec <tas
 ├── source/                                  # markitdown 转出的素材(同 working_dir 多 task 共享;用 markitdown -o <task_dir>/source/<name>.md)
 ├── <today>-<task_short_id>-<task_name>.spec.md   # 八条对齐落定,task 级宪法;命名见 system prompt 约定;按 short_id 主锚,重定调时写新日期,旧版保留
 ├── slides/                                  # 各页用到的图片素材 (chart_p3.png 等),多 task 时文件名前缀区分
+├── REVISIONS.md                             # 修订日志:每次卡点用户确认的实质改动,见 §修订日志
 └── <topic>.pptx                             # 最终产物 (按主题命名,多 task 时主题必须不同)
 ```
 
+## 修订日志 (REVISIONS.md)
+
+`<task_dir>/REVISIONS.md` 是产物迭代过程的紧凑可读 changelog。**spec 是宪法(定调一次),REVISIONS 是实施日志(每次卡点累加)** —— 两份独立但互参,后期 review / 复盘 / 跨周回看"上周这页为啥改成这样"靠这份。
+
+### 何时记 / 何时不记
+
+| 情形 | 记? |
+|---|---|
+| 用户确认改**版式 / 主色 / 字体方向** | ✅ 必记 |
+| 用户确认换 / 增 / 删**页 / 关键图标 / 数据图表** | ✅ 必记 |
+| 用户确认改**文案要点 / 核心信息 / 受众定位** | ✅ 必记 |
+| 自查阶段发现版式越界 / 颜色不一致后的修正 | ✅ 必记(说明触发 quality_check 项) |
+| 页首次起草(从 0 加出来) | ❌ 不记(初稿不是改动) |
+| 字号 / 间距 / 对齐微调 | ❌ 不记 |
+| 模型自己改改撤撤、用户没明确确认 | ❌ 不记 |
+
+> 拿不准 → 倾向不记。`REVISIONS.md` 是"用户与 LLM 共同沉淀的实质决策",不是流水账(那是对话历史的事)。
+
+### 格式
+
+文件首次创建时写头(只写一次):
+
+```markdown
+# 修订日志
+
+> 产物迭代过程中每次用户确认的实质改动,按时间倒序追加(最新在上)。spec 是宪法定调,本文件是实施日志。
+```
+
+每次记一笔追加在头注释之后、最新一笔的顶部(一行 = 一次改动):
+
+```
+- `<YYYY-MM-DD HH:MM>` | <第 N 页 / spec §X> | <一句话改了什么> — <为什么>
+```
+
+### 实例
+
+```
+- `2026-03-12 16:20` | 第 5 页 | 版式从 layouts.md "两栏文+图"改为"单栏图占主体" — 用户反馈原版式右侧文字太挤,核心数据需放大
+- `2026-03-12 14:05` | 第 3 页 | 删 chart 图,换成 3 个 KPI 数字块 — 数据点只有 3 个,bar chart 浪费版面
+- `2026-03-11 10:30` | spec §5 配色 | 主色 `#C00000` → `#1F4E79` — 用户给的品牌指南要求蓝色,商务红默认被覆盖
+```
+
+### 操作
+
+每次卡点用户确认后,用 `edit` 在头注释之后插入新一行(不要 append 到文件末尾 —— 倒序读才能秒看最新)。文件不存在就 `write` 创建带头注释的新文件。
+
 ## 反模式
 - 用户没给材料就开始硬编内容
 - 八条没对齐就跑 python-pptx

skills/proposal/SKILL.md

@@ -80,6 +80,7 @@ glob <task_dir>/*-<task_short_id>-*.spec.md → 按文件名字典序排,取最
    - **下一段 (节) 预告**: 标题 + 3-5 条要点骨架 (论点 / 数据 / 表格,每条贴对齐的指南要素与预估字数);若已是本章最后一段,改预告**下一章**首段要点
    - 提问: "本段可以了吗?下一段要点要改 / 加 / 删什么?"
 7. ⛔ **BLOCKING:停下来等用户明确反馈** ("OK"、"下一段"、"继续") 后才动笔。"看起来不错"、沉默、追问都不算确认 —— 用户对下一段要点没异议也算默认通过,但**字数 / 与指南对齐异常**时必须主动追问
+8. 用户确认了**实质改动**(改写技术路线 / 调考核指标 / 换关键引文 / 增删章节 / 改预算结构)后,追加一行到 `<task_dir>/REVISIONS.md` —— 见 §修订日志
 
 两段式 + 段段卡 + 预告下一段是为了拦早 —— 申报书 1.5-3 万字,模型连续生成容易把错方向推到底。
 
@@ -109,9 +110,57 @@ caption 必须写、必须全 task 唯一 —— render_diagrams / quality_check
 ├── source/                                  # 用户给的素材 (指南 PDF / 前期成果),同 working_dir 多 task 共享
 ├── <today>-<task_short_id>-<task_name>.spec.md   # 阶段一定调,task 级宪法;命名见 system prompt 约定;按 short_id 主锚,重定调时写新日期,旧版保留
 ├── sections/                                # 阶段二逐章产物 (按 templates/<fund_type>.md 切的小节命名);多 task 同章节用 LLM 判断/前缀区分
+├── REVISIONS.md                             # 修订日志:每次卡点用户确认的实质改动,见 §修订日志
 └── <topic>.docx                             # 最终产物 (按课题命名,不要 output.docx;多 task 时主题必须不同)
 ```
 
+## 修订日志 (REVISIONS.md)
+
+`<task_dir>/REVISIONS.md` 是产物迭代过程的紧凑可读 changelog。**spec 是宪法(定调一次),REVISIONS 是实施日志(每次卡点累加)** —— 两份独立但互参,后期 review / 复盘 / 跨周回看"上周这章为啥改成这样"靠这份。
+
+### 何时记 / 何时不记
+
+| 情形 | 记? |
+|---|---|
+| 用户确认改写**技术路线 / 考核指标 / 创新点 / 课题分解** | ✅ 必记 |
+| 用户确认换 / 增 / 删**关键引文 / 附图 / 章节小节** | ✅ 必记 |
+| 用户确认调**预算结构 / 经费比例 / 团队组成** | ✅ 必记 |
+| 用户对要点骨架的主动修改(改 / 加 / 删) | ✅ 必记 |
+| 自查阶段发现术语 / 数据 / 指标不一致后的统一改 | ✅ 必记(说明触发自查项) |
+| 章节首次起草(从 0 写出来) | ❌ 不记(初稿不是改动) |
+| 错别字 / 标点 / 纯排版调整 | ❌ 不记 |
+| 模型自己改改撤撤、用户没明确确认 | ❌ 不记 |
+
+> 拿不准 → 倾向不记。`REVISIONS.md` 是"用户与 LLM 共同沉淀的实质决策",不是流水账(那是对话历史的事)。
+
+### 格式
+
+文件首次创建时写头(只写一次):
+
+```markdown
+# 修订日志
+
+> 产物迭代过程中每次用户确认的实质改动,按时间倒序追加(最新在上)。spec 是宪法定调,本文件是实施日志。
+```
+
+每次记一笔追加在头注释之后、最新一笔的顶部(一行 = 一次改动):
+
+```
+- `<YYYY-MM-DD HH:MM>` | <文件:章节/段> | <一句话改了什么> — <为什么>
+```
+
+### 实例
+
+```
+- `2026-03-12 16:20` | sections/03_研究方案.md §技术路线第 2 段 | 加并行训练-推理共享显存设计 — 用户反馈原方案在 V100 上爆显存,需说明工程可行性
+- `2026-03-12 14:05` | sections/05_考核指标.md 表 1 | 准确率指标从"≥85%"提升为"≥90%" — 指南未限上限,加码增强竞争力
+- `2026-03-11 10:30` | <today>-<short>-<name>.spec.md §4 创新点 | 创新点 2 删除"基于量子计算"措辞,改为"基于异构计算" — 评审雷区,量子计算属过度承诺
+```
+
+### 操作
+
+每次卡点用户确认后,用 `edit` 在头注释之后插入新一行(不要 append 到文件末尾 —— 倒序读才能秒看最新)。文件不存在就 `write` 创建带头注释的新文件。
+
 ## 章节骨架速查
 
 写每章前在脑子里过一遍这 4 个 pattern: