| name | cn-patent-general-template |
| description | Support generic Chinese patent drafting collaboration for invention patents and utility models, especially common patent format summarization, figure usage principles, GPT drawing prompts, local file workflow, and Codex review-iteration loops. |
中国专利通用模板草稿
这份草稿不只用于“修图”,而是用于整理一套可复用的中国专利协作流程,重点覆盖:
- 总结中国发明专利 / 实用新型常见文稿格式
- 规范附图表达和附图使用原则
- 让 Codex 在本地生成和管理文件
- 由 GPT 承接局部绘图或表达精修
- 再由 Codex 审查 GPT 结果并继续迭代
默认目标不是替代专利代理人,也不是虚构技术内容,而是把“本地成稿、外部改图、回收审查、反复迭代”的协作链条做稳。
何时使用
当用户有下面这类需求时,优先使用本 skill:
- 想把现有技术方案整理成更像中国发明专利或实用新型的交底或草稿
- 想总结专利常见结构和写法边界
- 图不像专利附图,更像 PPT 或流程海报
- 箭头乱、线穿框、编号重叠、文字压线
- 图在 Word 中显示不全
- 需要一段更专业的 GPT 改图指令
- 需要统一替换矢量图、预览图和文档内图片
- 需要 Codex 审查 GPT 改图结果,再继续多轮迭代
默认目标
默认追求以下结果:
- 文稿结构更接近中国发明专利 / 实用新型常见表达
- 图面风格接近中国专利附图
- 黑白线稿、无装饰、无渐变、无阴影
- 箭头、引线、框线、编号和文字关系清楚
- 主链、支链、汇合关系一眼能看明白
- 本地源文件、预览图和文档中的图片版本保持一致
- GPT 负责局部生成和修改,Codex 负责归档、审查和闭环迭代
最简使用顺序
根据任务读取对应参考文件,不要一上来全读:
- 想看中国发明专利 / 实用新型常见结构:
读取 references/cn_patent_format_summary.md
- 想看附图什么时候该画、怎么画、怎么放进文稿:
读取 references/patent_figure_usage_principles.md
- 想直接给 GPT 发改图指令:
读取 references/gpt_patent_figure_polish_prompts.md
- 想做 Codex 本地落文件 + GPT 生成 + Codex 审查闭环:
读取 references/codex_gpt_patent_iteration_workflow.md
- 想在每轮后做检查:
读取 references/patent_figure_checklist.md
附图风格硬约束
处理时默认遵守下面规则:
- 只用黑白线稿
- 不在位图内部写“图1、图2”之类图号
- 中文为主,必要时可保留少量括号说明
- 线条不能穿过方框
- 箭头尖端要贴在目标边缘,不能压进框里,也不能悬空太远
- 编号圈如
101/102/103 不得与框线、箭头、文字重叠
- 判断框、模块框、时间轴、关系线要表达明确,不能图面整齐但逻辑错误
- 不虚构技术内容,只修表达
类型边界
这份模板适用于两类常见技术专利文本整理:
- 发明专利
- 实用新型
默认边界:
- 发明专利可以围绕产品、方法、装置、系统、用途改进等组织
- 实用新型只适合围绕产品的形状、构造或者其结合来组织
- 如果目标是实用新型,不要把“方法流程”写成主保护对象
- 如果目标是实用新型,附图重点应放在结构、连接、布局、组件关系,而不是算法步骤
工作方式
1. 先判断问题属于哪一层
先区分问题来自:
- 图逻辑本身有误
- 矢量图几何布局有误
- 预览图导出时被裁切
- Word 插入后缩放或分页导致看不全
- GPT 修改建议本身逻辑不对,只是图面更整齐
不要一上来就改 Word。先看预览图,因为很多“Word 显示不全”其实是图本身就被截掉了。
2. 看图时优先检查的点
优先检查:
- 主逻辑是否一眼清楚
- 是否有任何线穿框
- 是否有箭头与框重叠
- 是否有编号圈压线
- 是否有某一路被误画成主链
- 标注引线是否唯一指向目标
- 画布边缘是否太紧,底部或右侧是否贴边
3. 处理顺序
推荐顺序:
- 先修源图
- 再导出预览图
- 先肉眼检查预览图
- 确认没问题后再回写 Word
不要先改 Word 再猜图源。
通用经验
常见真问题
- 多路输入图容易把中间一路误画成主链,另外几路像支路
- 多条件判据图容易让某一个条件看起来像唯一主条件
- 带边界标注的图最容易出现引线歧义
- 画布底边太紧时,Word 中会表现为“图没显示全”,但根因其实是源图画布不够高
常见有效修法
- 多路输入先汇合到公共汇合节点或总线,再进入后续模块
- 多条件判据改成并列等权输入,不让任何一个条件承担唯一主干
- 边界标注使用清晰引线,终点必须落在唯一目标上
- 贴边图优先增加源图画布留白,不急着改 Word 缩放
文稿与附图分工
默认分工如下:
- Codex 负责本地文件组织、命名、版本替换、文档回写
- GPT 负责局部图面精修、句式润色或备选表达生成
- Codex 负责审查 GPT 输出是否存在逻辑偏差、图面歧义或专利风格退化
- 最终以 Codex 回写到本地的文件为准,不以聊天截图为准
源图 → 预览图 → 文档 工作流
通用稳定流程是:
- 先确认源图是最终版或当前工作版
- 再导出对应预览图
- 再用预览图回写文档
- 最后检查文档内嵌图片是否已更新
预览图导出原则
- 统一从最终源图导出
- 导出后文件名应与文档当前引用的预览图文件名一致
- 导出后先看预览图,不要直接信任“导出成功”
文档回写原则
- 先关闭 Word
- 再运行对应的文档重写或图片替换流程
- 回写后检查文档时间戳和内嵌媒体是否已更新
Codex 与 GPT 的迭代闭环
默认按下面顺序协作:
- Codex 在本地建立清晰目录,放置源图、预览图、文稿和中间草稿
- Codex 先自己判断哪一张图最值得修改,并列出明确问题
- Codex 生成一段高约束 GPT 指令,只允许 GPT 改指定图和指定问题
- 用户把该指令和当前图发给 GPT
- GPT 返回改图结果或修改建议
- Codex 审查 GPT 返回结果,优先找逻辑问题、歧义和几何错误
- 若不合格,Codex 继续给出下一轮更具体的修正指令
- 若合格,Codex 把最终结果回收到本地文件并更新文档
关键原则:
- GPT 不作为最终归档端,Codex 才是本地文件真源
- 每轮只聚焦 1 张图或 1 类问题,避免一轮改太多
- 先保逻辑,再保图面,再保格式统一
- 每轮都要能回答“哪里变好了、哪里还不对”
给 GPT 下指令的写法
默认写法:
- 明确“只改哪一张图,不改别的图”
- 明确“保留哪些编号和语义不变”
- 明确指出“当前哪里不对”
- 明确给出几何约束,如不能穿框、箭头贴边、编号圈不压线
- 明确最终目标是“中国发明专利附图风格”
优先读取:
输出时的默认组织
如果用户让你给意见或给 GPT 指令,默认输出:
- 先给结论:最该改哪张图
- 再给逐图意见
- 再给可直接复制的 GPT 指令
如果用户让你直接替换文档中的图片,默认输出:
- 先替换预览图
- 再替换文档中的图片
- 最后说明哪些文档已更新,哪些文档尚未接入图片引用
如果用户让你建立 Codex+GPT 协作法,默认输出:
- 先明确本地目录与当前工作文件
- 再生成给 GPT 的单图精修指令
- 再对 GPT 返回结果给出审查意见
- 再决定是否进入下一轮迭代