企业官网建设流程全解析

patent-disclosure-skill 外观辅助线稿流程全解：默认关闭、参考图门禁与交底纪律

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

导读：外观设计交底书常面临「有实拍但缺干净线稿」的困境，直接让 AI 文生图又存在虚构造型、误导申报的风险。本文聚焦 patent-disclosure-skill 中可选默认关闭的外观辅助线稿流程（prompts/shared/design_lineart_assist.md），讲清它的开启开关、触发反问条件、design_lineart_brief.yaml合同字段、门禁脚本design_lineart_gate.py的校验逻辑，以及生成后如何回写figure_plan.yaml并守住「辅助非终稿」的成文纪律。读完你既能按流程实操生成合规的参考图线稿，也能理解这套「默认关闭 + 无图即拒」设计背后的防错原理。

一、流程定位：交底辅助插图，而非申报终稿

外观辅助线稿在整个技能中的定位有严格的三重限定：

• 合同：references/schemas/design_lineart_brief.schema.yaml，所有 YAML 字段以该合同为准；
• 前置：案件目录中已有或本轮将写出appearance_schema.yaml（或.json）与figure_plan.yaml，填表流程见 prompts/shared/fill_appearance_schema.md；
• 性质：它是交底的辅助插图、非申报终稿，且禁止无参考图的纯文生图。

从 SKILL.md 的目录约定可以看到，prompts/shared/统管写读共用的结构/外观填表与辅助线稿，而辅助线稿是「可选、默认关」功能；外观成文 builder 明确要求辅助线稿不得替代实拍作为唯一证据，默认不占用「见图 N」主序列。这意味着整个流程服务于「给代理人参考的草稿」，不改变外观交底以真实视图为证据主体的原则。

二、开关机制：默认关闭，一句反问授权

外观辅助线稿默认关闭，这是全流程最核心的安全闸门：

• 未询问、或用户未回答「是」之前：不得写design_lineart_brief.yaml，不得调用任何出图工具生成线稿；
• 外观案件在填表/成文前可做一句反问：是否开启外观辅助线稿？（请回是/否）；
• 用户回「否」或跳过：仅用实拍/已有视图走 Appearance + figure_plan；
• 用户回「是」：才执行后续步骤，并可用环境变量PATENT_SKILL_DESIGN_LINEART=1或校验脚本参数--enable-design-lineart标记本轮已授权。

这套「用户显式确认 + 双通道授权标记」在源码中有直接印证。tools/shared/design_lineart_gate.py 中：

ENABLE_ENV = "PATENT_SKILL_DESIGN_LINEART" def parse_enabled(cli_flag: bool) -> bool: if cli_flag: return True return os.environ.get(ENABLE_ENV, "").strip().lower() in {"1", "true", "yes", "on"}

即 CLI 旗标与四个环境变量取值（1/true/yes/on，大小写不敏感）任一命中即视为已授权，且脚本内置了面向用户的中文确认文案CONFIRM_ZH，可随时通过--print-confirm打印：

python tools/shared/design_lineart_gate.py --print-confirm

对应测试 tests/shared/test_design_lineart_gate.py 的test_default_off断言了「默认关闭、旗标开启、文案含『是』」三条契约。

三、何时触发反问：有图才问，无图不绕行

反问不是无条件的，文档给出两条触发与禁止规则：

• 触发：专利类型 =外观设计，且扫描/材料中已有至少一张产品相关图（figure_plan候选或assets实拍/效果图）；
• 禁止：无任何图片时，不得反问「开启线稿」来绕过缺图问题——此时应要求补图，无图则禁止本辅助流程。

这条规则的深层原因是：辅助线稿的合法性完全建立在「有可核验的参考图」之上。design_lineart_gate.py的run_check会先检查figure_plan.yaml中是否收集到任何可用图片路径，collect_source_images_from_plan遍历figures[].path并逐一_resolve_path确认文件真实存在（tools/shared/design_lineart_gate.py）；无任何可读源图时直接拒绝并提示补图，绝不放行。测试test_no_images_forbid（tests/shared/test_design_lineart_gate.py）正是用figures: []的空图清单验证这一拒绝路径。

四、确认「是」后：三步数据准备

1. 读 YAML，联读多视

先Readappearance_schema.yaml（或 json）与figure_plan.yaml，然后按figure_plan.relates_to（same_state/alternate_view/detail_of）联读多图，确保件名/造型特征跨图一致。

关于relates_to的语义，references/schemas/figure_plan.schema.yaml 给出了完整枚举：

外观多视之间优先用same_state/alternate_view互链；场景参考图可不写。

2. 写design_lineart_brief.yaml

Write与appearance_schema.*/figure_plan.yaml同级的design_lineart_brief.yaml（常见outputs/{案件标识}/），字段要求：

• overall_shape/design_points/uncertain对齐 AppearanceSchema；design_points必须是在参考图上能看见的特征；
• 每个views[]：至少填一个存在的source_paths（来自 figure_plan 的path或 schemaviews[].source_image/source_images）；
• source_figs/relates_hint抄自 figure_plan；
• gen_prompt必须写明：黑白专利风格线稿、无彩色无棚拍阴影、不发明未见结构、保留可见轮廓与开口/倒角等要点、以参考图为准。

完整的合同骨架见 references/schemas/design_lineart_brief.schema.yaml，其中forbid是生成时的硬禁止清单：

forbid: # 生成时硬禁止 - 内部结构 / 电路 / 受力 - 品牌 LOGO / 广告文案 - 无依据的背面或底面臆造 - 彩色渲染 / 阴影棚拍风

合同「必填」项为：enabled: true（仅用户确认后）、appearance_ref、figure_plan_ref、至少 1 条views且每条source_paths非空且文件存在、overall_shape或非空design_points至少其一。

3. 门禁校验（推荐）

python ${CLAUDE_SKILL_DIR}/tools/shared/design_lineart_gate.py --enable-design-lineart \ --case-dir "outputs/{案件标识}" --prepare-jobs

脚本main支持四个参数（tools/shared/design_lineart_gate.py）：

校验的拒绝规则有三条（源码validate_brief与run_check实现）：

• 无--enable-design-lineart（且无环境变量）→ 拒绝，错误信息提示「默认关闭」；
• 任一条views无有效图片路径 → 拒绝（禁止纯文生图）；校验会逐条解析相对/绝对路径，_resolve_path先试路径本身、再试case_dir/路径，源图不存在或全部不可读都会报错；
• 案件目录缺少figure_plan/appearance_schema、或figure_plan无可用图片、或缺少design_lineart_brief.yaml→ 拒绝。

校验通过后，build_jobs会创建lineart_assist/目录并写出lineart_assist/design_lineart_jobs.json，每条 job 含：

• view_name：视图名（非法字符被替换为_，截断 60 字符）；
• source_paths与兼容字段reference_images：解析为绝对路径的参考图列表，供宿主把路径当参考图入参；
• relates_hint：多视关联提示；
• gen_prompt：若 brief 未写提示词，脚本会用模板自动生成（含 Black-and-white patent-style line art、No color、no logos、match proportions in the reference images 等要点，设计要点取前 8 条）；
• output_path与absolute_output_path；
• forbid_text_only: true与host_hint：明确要求使用当前宿主图像生成能力、勿写死某一厂商工具名、禁止纯文本生成。

脚本退出码与机读前缀约定遵循 SKILL.md 的环境约定：以退出码 0 和DESIGN_LINEART_JOBS:前缀为准，stderr 有字不等于失败。

五、基于参考图出线稿：硬性要求与落地

对design_lineart_jobs.json中每一 job：

1. 使用当前宿主环境提供的图像生成能力完成出图（可能是内置生图工具、图生图 API、本地模型或插件等）——不要写死某一产品的工具名；
2. 硬性要求：必须以该 job 的source_paths（jobs 里亦作参考图列表）作为视觉参考/条件输入再生成，等价于「有参考图的图生图 / 图像条件生成」；
3. 禁止在未附带任何参考图的情况下，仅用gen_prompt做纯文生图；
4. 提示词以 job 的gen_prompt+ brief 中design_points为准；多视 job 须同时参考relates_hint所涉源图，保持同一产品；
5. 输出写到 job 的output_path（默认lineart_assist/*.png）。若宿主工具不能指定落盘路径，生成后须把结果复制/保存到该路径，再回写 figure_plan。

design_lineart_gate.py对多视 job 的默认提示词模板体现了同样的约束（tools/shared/design_lineart_gate.py）：View:指名视图、Overall:引整体造型、Emphasize visible design points:引设计要点，并强制No color, no photoreal shading, no logos, no invented internal structure; match proportions and openings in the reference images; white background.——所有「不发明、以参考图为准」的纪律都被固化进了默认提示词，从源头压缩模型自由发挥空间。

六、回写 figure_plan：默认不入正文

每张辅助线稿在figure_plan.yaml追加一条（默认不入正文）：

- fig: null # 或分配序号但不入文 role: reference # 或与源图同 role path: lineart_assist/….png covers: ["立体图"] # 对齐 view_name kind: lineart score: 50 use_in_disclosure: false reason: AI 辅助线稿（非申报终稿） relates_to: - fig: 1 # 源实拍/参考图 fig relation: same_state note: 由图1辅助生成的线稿草稿

关键纪律：

• 仅当用户明确要求「辅助线稿也写入交底」时，才将对应条改为use_in_disclosure: true并分配连续fig；
• 辅助条默认fig: null，不占用「见图 N」主序列；
• 外观成文时正文只嵌figure_plan中use_in_disclosure: true的条目，勿临场扫全目录挑图（prompts/disclosure/design/disclosure_builder.md §7.3）。

这与 figure_plan 合同（references/schemas/figure_plan.schema.yaml）的多轮同步规则一致：换图、改主题、部件表/设计要点变更或图际关系变化时，先更新 figure_plan 再改正文，被剔除图保留条目并设use_in_disclosure: false以便审计。

七、成文纪律与内部自检

成文纪律（写入交底正文时）：

• 正文视图说明以实拍/原始参考图为主；辅助线稿可一句带过「另附线稿草稿供代理人参考」；
• 禁止把 AI 线稿写成「已按国知局规范绘制的正式视图」；
• uncertain中的特征不得在线稿说明里写成既定设计要点。

对应地，外观 builder §7.5 自检要求确认：有用户「是」、有参考图、无纯文生图、辅助条默认未强行入正文、未把功能构造写成外观要点、查新已用tools/crawl/cnipa_epub_search.py --type design。

流程内部自检清单（每轮执行）：

• 本轮确有用户是（或等价授权）
• design_lineart_brief.yaml每视均有真实存在的source_paths
• 未做纯文生图
• 多视参照了relates_to/relates_hint
• figure_plan 中辅助线稿默认use_in_disclosure: false

八、与实用新型结构线稿的分流

外观线稿不是孤立功能，它与实用新型的 prompts/shared/structure_lineart_assist.md 形成双通道分流：

两者共用「默认关、须参考图、禁纯文生图、辅助非终稿」的底线，但严禁混用：外观流程禁止给实用新型乱加「美感线稿无件号」当结构图，实用新型流程也禁止处理外观。SKILL.md的模式 A 检查清单同样要求两者各自走各自的门禁，并确认「未自创件号」「优先 overlay」「辅助条默认不入正文」。

九、适用前提与限制

• 本流程仅适用于外观设计交底的辅助线稿草稿生成；发明、实用新型走各自通道；
• 必须以已有实拍/效果图/正投影图为视觉参考，无图时流程整体禁用；
• 生成结果默认不进入正文证据序列，不构成正式视图；
• 门禁脚本以 Python 运行，design_lineart_gate.py无第三方硬依赖（YAML 解析失败会回退 JSON），${CLAUDE_SKILL_DIR}需指向本技能在宿主中的安装目录；
• 出图能力由当前宿主环境提供，技能不绑定任何具体生图产品，也不对具体模型的出图质量作承诺——这正是其「提示词纪律 + 门禁校验」双重防错的用意所在。

通过「默认关闭的开关、无图即拒的门禁、参考图条件生成、默认不入正文的落位」四层约束，patent-disclosure-skill 把 AI 外观线稿从「碰运气的文生图」收敛为「有参考、可核验、不越位」的交底辅助工具——这套流程纪律同样值得其他知识密集型写作技能借鉴。

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