专利技术交底书撰写
范围
产出物仅限"技术交底书"：发明人向专利部门/代理机构提交的技术披露文档，核心价值是讲清技术方案、创新点、保护点。若用户要求权利要求书/说明书/审查意见答复等正式申请文件，说明超出本技能范围，但交底书中"权利要求布局建议"一节可为其后续撰写提供支撑。
不可逾越的真实性红线
- 绝不编造：专利号、专利名称、申请人/企业名、作者、实验数据、测试结果、个人信息。
- 文中引用的每个专利号/公开号必须在官方来源（Google Patents 等）逐条核对；核对不一致或查无此专利的，一律删除或改写为"某厂商类方案"这类稳妥表述，不得保留具体名称。
- 实验/性能数据必须来自用户提供的真实测试；没有真实数据就写定性实施例，并注明"量化指标可在真实试点测试后补充，不影响技术内容公开的完整性"。
- 封面信息表（通常含发明名称、申报单位/公司、发明人、联系人等字段，以用户模板实际字段为准）保留模板原有占位文案（如"需发明人填写/请填写"），永不代填。
- 用户未提供但撰写必须用到的信息，允许基于专业知识合理假设，但必须在正文中以"（待发明人确认）"明确标注。
- 把"某公司确实存在"等同于"某公司有某名称的专利"是典型造假路径：没有官方出处的企业具体专利名一律不写。
工作流（五步，顺序不可颠倒）
- 访谈取齐信息：按
references/interview-checklist.md提问（一问一答或一次列清单均可），一次不超过 5 问。对用户给出的每个数字追问来源（实测/估算/示例）。 - 模板解析：用户提供模板 → 解析其封面字段与章节结构（含表格、注意事项表），严格按模板输出；未提供模板 → 用
references/disclosure-template.md内置的通用十二部分模板兜底。 - 检索查新：按
references/search-and-verification.md强制检索（Google Patents、必应、百度专利等），找出最接近的现有技术并明确写出区别点；所有引证逐条核验；检索记录存入本次任务的 work 目录。 - 撰写：按模板章节撰写。技术方案采用"系统总体架构 → S1..Sn 步骤化详述 → 实施例"的结构；每个 S 步骤给出输入、处理、输出；公式用 Word 原生公式（OMML）并就地定义符号；创新点编号（创新点A/B/C/D…）并与"关键点和欲保护点"一一对应；实施例写 3~5 个定性场景并明确"示例性"，绝不编造量化效果。
- 自检与交付：按
references/quality-gates.md过六道自检门；按references/docx-building.md生成 .docx 并跑通scripts/verify_disclosure.py；汇报时分成三类：已完成内容 / 需发明人填写的信息 / 建议代理机构确认的事项（如正式查新）。
交付规范
- 默认交付可提交的 Word（.docx）：保留模板样式与封面表；公式为 OMML 对象（非图片）；图片与用户提供的源图逐字节一致（MD5 校验）；图片内文字不截断；封面占位保留；无"待补充/XXX"等残留。用户需要时另出 Markdown 底稿便于审阅。
- 结构完整：模板每一节都必须存在；"如无可不填"的节（项目信息/产品信息）保留提示文案，不编造内容。
- 迭代版本用 v1→vN 另存，不覆盖用户已确认的版本。
- 与用户交流使用中文、非技术视角汇报，除非用户明确要求技术细节。
参考资料（按需读取）
references/interview-checklist.md— 发明人访谈清单（含每个问题的目的）references/disclosure-template.md— 通用十二部分模板的封面与章节规范（无用户模板时的兜底结构）references/search-and-verification.md— 检索渠道、检索式构造、引证核验与防重复判断references/quality-gates.md— 六道自检门（交付前必过）references/docx-building.md— .docx 构建与排版校验方法（OMML/图片/MD5/文字越界）scripts/verify_disclosure.py— 交付前自动校验脚本
