前言

不得不说 MiniMax H3 是在太强了！👍，开源社区为此掀起了一波热潮。连我这个曾经深入研究 comfyui，已经弃坑的，也不得不重新捡起 comfyui 。

之前我写过 MiniMax H 3 的 comfyui 使用实践：# 【AI技能】本地跑 MiniMax H3：ComfyUI 安装、下载提速与显存拆峰实战

实测后发现，有些痛点是需要解决的：

• 前置输入是什么？如何让 MiniMax H3 理解用户的意图？
• 如何写好提示语？特别是写参考图、参考视频等，手打提示语和参考太费时间了。

为此，我也研究了MiniMax H3 官方的开源项目，发现其实可以通过 comfyui 插件方式，去补全缺失的前置 IRContext 部分的。

先看效果和使用方式

这个插件叫：MiniMax H3 上下文提示词(OpenAI) -leoleexh ，目前还在上架中。

使用方法

使用的方法很简单！把连接到 H 3 工作流的图片也连接到我这个插件：

单图参考或者首尾帧

连接好后，你只需要一句话：

根据图片做一个视频的片头，要生动活泼。

我这个插件就会自动识别上下文关系，用MiniMAX 和 comfyui 的官方提示语规范，进行书写提示语，只要把这个提示语传入 H3 工作流提示语中即可。

这是输出的提示语：

subject_definitions:<Subject 1>: The central adult female traveler: shoulder-length dark brown hair with lighter highlights, round dark sunglasses, broad smile, beige double-breasted trench coat, taupe-brown fringed scarf, dark navy backpack, black camera at her lower torso, blue jeans, holding a pale folded map. Preserve her as the main centered cutout traveler from the reference. Source(s): <Picture 1>.summary:Lively animated opening card based on the supplied Nepal retro travel-poster image, preserving its traveler-led collage design and vertical composition.Hard constraints: Output a 576x736 vertical video lasting exactly 5.166667 seconds. | Preserve the supplied poster’s central female traveler, her map, camera, wardrobe, and recognizable Nepal travel-collage visual language. | Keep the camera physically fixed for the entire clip; all movement comes from animated paper layers, graphic elements, and subtle subject/environment motion. | Do not add narration, spoken dialogue, captions, or subtitles. | Retain the warm retro scrapbook aesthetic with torn paper, sticker-like outlines, print grain, halftone texture, and layered landmark imagery. | End on a clean, readable, stable full-poster composition.Generation controls (authoritative) —Prompt-text rule: every section label and descriptive sentence is silent production direction, never speech content. Do not speak, recite, chant, sing, or read this prompt aloud.Background music: enabled. Generate a context-appropriate non-diegetic score unless the user explicitly requests silence or no music.Dialogue permission is enabled, but this plan contains no dialogue lines. Generate no character speech, conversation, chanting, singing, or other vocals.Narration: disabled. Generate no narrator, voice-over, spoken description, or audible reading of prompt text, section labels, instructions, asset tags, or metadata.Subtitles: disabled. Do not render subtitles or dialogue captions.Creative direction (authoritative within explicit user intent and reference fidelity)Priority: Apply these creative directives clearly wherever they do not conflict with explicit user requirements, identity retention, or fixed first/last-frame composition.Camera execution: Keep the camera physically fixed on a stable support for the full shot; all visible motion comes from subjects and the environment, followed by a clean final hold.Look: Treat connected visual references as authoritative for identity, wardrobe, objects, environment, composition, lighting, color, and medium; do not impose an unrelated restyle.Pacing and composition: Use moderate, readable motion with natural acceleration and enough settling time for each important beat. Use official-aligned automatic shot planning without forcing a numeric shot count; use the fewest purposeful shots that clearly express the requested edit and fit the exact duration. Treat one shot as one continuous camera segment; action beats inside an uninterrupted take do not create new shots. Every cut must add new information about subject, space, state, viewpoint, or time; prefer camera motion for only a distance or slight-angle change. An explicit user-requested shot or cut count remains authoritative over this density preference. Compose for a vertical frame: protect faces, hands, and essential action inside the central mobile-safe area; favor depth movement and avoid losing subjects at narrow side edges.retention_analysis:<Picture 1> -> identity: Use as the authoritative visual reference for the central female traveler’s identity, sunglasses, trench coat, scarf, backpack, camera, map, the Nepal travel collage layout, typography placement, torn-paper layers, landmarks, warm cream/rust/teal/navy palette, and retro printed-paper texture. Preserve its vertical-safe central composition while animating the collage as a lively title-card opening..detailed_description:[Shot 1] At 00:00.000-00:05.167, A dynamic retro Nepal travel-poster opening. Begin with the warm cream paper field and faint printed grain; torn collage panels assemble into their supplied positions with small staggered slides and settling overlaps. The blue-sky panel, mountain-and-temple layer, stupa panel, street-rickshaw panel, market strip, decorative motifs, and illustrated instruments arrive as physical paper pieces, retaining their original placement around the center. The central smiling female traveler remains the visual anchor in her off-white sticker outline, beige trench coat, taupe scarf, dark sunglasses, backpack, waist-hung camera, and pale map. She gives the map a subtle natural adjustment while her scarf fringe and nearby prayer-flag-like banners flutter gently. Add restrained parallax-like layer separation through tiny independent paper settling motions without changing the frontal graphic-poster medium. The headline typography remains crisp and readable. By the final second, all layers settle into the complete recognizable reference composition and hold cleanly. Camera: Locked-off frontal vertical view on a stable support, preserving the supplied poster’s overall framing. No pan, tilt, dolly, zoom, handheld shake, or reframing. Motion: 0.00-1.30: collage components pop and slide into place with paper-like easing. 1.30-3.80: moderate lively secondary motion—gentle banner flutter, slight scarf-fringe movement, minute map adjustment, and soft drifting print-splatter accents—while all key elements remain readable. 3.80-4.30: each layer settles with a subtle paper bounce. 4.30-5.166667: stable final poster hold with only near-imperceptible texture shimmer. Synchronized audio: 0.00-0.70: soft paper-rip and airy collage-assembly whooshes.; 0.70-3.80: upbeat instrumental travel cue begins and continues under subtle paper rustles.; 2.40: quiet camera-shutter click timed to the camera detail.; 3.80-5.17: music resolves into a neat, lightly sustained final accent; paper sounds cease for the final hold.overall_soundscape:A polished graphic-title soundscape: soft paper rustles and layered whooshes synchronize with collage assembly, a subtle camera shutter accent accompanies the traveler’s camera detail, and the upbeat instrumental music carries the opening. No dialogue, narration, captions, or vocal sounds. No narration, voice-over, spoken description, or audible prompt reading.non_diegetic_music:Play a brief upbeat, playful travel-themed instrumental cue with light hand percussion, bright plucked accents, and a compact cheerful finish. No vocals, lyrics, narration, or spoken words.

这是效果： 

多图参考

像这种多图参考的，只要连好线，简单一句话提示语，就可以让这个插件帮你完成后续的提示语生成工作：

一句话提示语：

图1 女孩，在 图3 场景，和图2女孩一起跳舞，卡点运镜。

输出的视频： 

使用创意导演节点

配套节点，有创意导演功能，便于大家去理解和使用视频类型和各种常用的视频技巧。

更多视频效果

创意类

广告类

我的研究和实践

❝

H3 开源之后，最容易被低估的是提示词前面的那层工作：谁是人物参考，谁是场景参考，视频到底参考动作还是运镜，三秒钟里要安排几个动作，音乐、对白和环境声又该如何落进同一条时间线。把这些关系交代清楚，才轮到模型生成。

❞

MiniMax H3 开源以后，我很快把它接进了 ComfyUI。

模型能跑，图片、视频、音频也能接，真正测试时却出现了一个明显落差：同样是参考图和参考视频，网页端似乎更懂“图一的人物穿图二的服装，在图三的场景里，沿用视频一的运镜”；本地工作流如果只塞一段自然语言，素材多一点，关系就容易散。

再多写几个形容词也解决不了这个问题。

我的判断是：对于 H3 这类原生音视频、多参考输入模型，提示词已经不只是文案。它更接近一份接口协议，要同时描述素材身份、引用关系、时间线、镜头、动作、对白、环境声和背景音乐。

于是，我做了一个 ComfyUI 前置节点：先用多模态模型分析素材，建立可校验的 Context IR，再把它确定性地渲染成 H3 接受的提示格式。

这篇文章不讨论“万能神词”，而是拆开三个问题：官方 H3-Context-IR 到底在做什么；ComfyUI 为什么不能直接照搬；一套能稳定运行的工程适配应该怎样设计。

先把边界说清：这不是官方 IR 的复刻

根据 MiniMax H3 官方模型卡，完整的 H3 系统可以理解为三层：

1. 「H3-Context-IR」：接收自由形态的文字、图片、视频和音频，理解它们之间的关系，解析用户指令，完成跨模态关联、时间理解和必要推理，再序列化为 H3-Base 能接受的结构化中间表示。
2. 「H3-Base」：根据 Context IR 生成 768p 的原生音视频，画面、对白、音效和音乐在统一生成过程中完成。
3. 「H3-Regenerate-2K」：把 768p 结果连同原始上下文再次送回 H3 做 in-context regeneration，借助原始语义恢复细节。它不等同于普通超分。

当前开源权重主要对应 H3-Base。官方 Context IR 和 Regenerate-2K 仍依赖托管的多阶段模型与服务，没有开源。

图：自由输入先由 Context IR 整理，再交给 H3-Base 生成 768p 音视频；官方 2K 链路还会带着原始上下文再生成一次。

所以，我的插件只能依据官方公开的模型卡、提示词写作指南和 ComfyUI 原生节点协议，做一套独立的工程适配。它不复制官方私有实现，也不应该被宣传成“官方同款 IR”。

这条边界很重要。知道哪些能力来自公开协议，哪些仍在云端系统里，才能正确判断本地效果差距，也能避免把一次 LLM 润色误认为完整的 Context 编排。

从公开格式里，能读出 Context IR 的核心任务

官方没有公开内部 IR Schema，但公开了 H3 的提示词输出规范。这个规范已经透露了很多信息。

在 T2VA、I2VA、FL2VA、L2VA 等 Base 模式中，官方 Base 提示词指南要求最终提示包含三个核心部分：

• integrated_multimodal_description：沿时间线描述画面、动作、镜头、说话者、对白、歌唱和画内声音；
• overall_soundscape：概括整段视频的环境声、物理动作声和非语言人声；
• non_diegetic_music：只描述观众能听见、画中角色听不见的背景音乐。

在 Full-Reference，也就是 Ref2VA 模式中，官方参考模式指南把结构扩展为六段：

subject_definitionssummaryretention_analysisdetailed_descriptionoverall_soundscapenon_diegetic_music

这六段不是排版要求那么简单。它们承担了不同的语义职责：先定义主体，再说明任务，再规定每份素材保留什么，最后才展开镜头和声音。

官方还区分了四类标签：

• <Subject N>：从参考素材中抽象出的可复用可见内容，例如人物身份、服装、环境或视觉风格；
• <Picture N>：一张具体参考图，可以是目标帧、关键帧或构图锚点；
• <Video N>：整段视频提供的时序、动作、剪辑、运镜或延续关系；
• <Audio N>：被复制或参考的音频信号。

图：Picture 是具体素材；Subject 是从素材中提炼出的可复用人物或内容角色。六段协议再分别回答“谁、做什么、保留什么、怎样演、听见什么”。

这里最值得注意的是：Subject 是内容单元，Picture 才是来源文件。图一里的人物可以成为 <Subject 1>，图一也可以只作为这个人物的身份来源，而不必在每个镜头里机械地重复“参考 Picture 1”。

这正是 Context IR 的价值：它先把“素材文件”转换为“可被生成模型调用的语义对象”，再为这些对象安排保留关系和时间位置。

ComfyUI 的难点，在接口对齐

官方 Ref2VA 最多支持 9 张图片、3 段视频、3 段音频，混合文件总数最多 12。数字看起来很大，真正接到节点图里，问题马上出现。

ComfyUI 知道哪根线连到了哪个端口，却不知道“这张图负责人物，那张图负责场景”；多模态模型能看懂内容，却不应该拥有修改物理输入顺序的权力；原生 H3 节点最终又只认严格对应的 Picture、Video、Audio 编号。

如果让 LLM 自己猜编号，一次输出 <Picture 2>，下一次写成 <Picture 3>，提示词再漂亮也没有意义。因为下游拿到的仍是固定顺序的张量。

因此，这套节点的第一原则是：「先在本地建立素材注册表，再让 AI 分析。」

所有 Picture、Video、Audio 标签由本地代码按端口顺序分配；视频配套音轨也在注册表里固定配对。LLM 只能引用受信资产 ID，不能创造不存在的素材，也不能改写编号。

图：插件的实际处理路径。原始媒体直接进入原生 H3；缩放、压缩和抽帧副本只用于分析。

在这张图里，LLM 只负责它擅长的部分：理解画面、总结动作、建立引用关系、规划镜头与声音。顺序、预算、校验、时间和最终格式，则留给本地代码。

这项分工后来成了整个项目最稳定的一条经验：「语义可以是概率性的，接口必须是确定的。」

视频输入其实是一批帧

第一次把 VideoHelperSuite 接进来时，我也遇到了一个很实际的问题：上游 VHS Load Video 输出的“图像”，究竟怎样传给分析节点？

答案是：它不是视频文件路径，而是一个形状近似 [帧数, 高, 宽, 通道] 的 ComfyUI IMAGE 批次。

图：同一份媒体分成分析路线和生成路线。前置节点只产生 H3 prompt，原始素材仍由原生 H3 直接读取。

图：VHS Load Video 的“图像”输出，本质上是按顺序排列的帧批次。

这个批次需要分成两路：

• 一路进入 Context IR 节点，供多模态模型抽帧理解；
• 另一路原样进入原生 MiniMax H3 Reference to Video，作为真正的 reference conditioning。

分析节点不会替代 H3 的媒体输入，也不会把压缩帧转发给 H3。它只输出结构化提示词。

还有一个细节：IMAGE 批次本身没有可靠的 FPS 元数据。H3 的时间基准是 24fps，所以在 VHS 中最好设置 force_rate=24、select_every_nth=1，并让 frame_load_cap 与最终 H3 的 length 对齐。这样，“第 48 帧”在分析侧和生成侧都代表约两秒。

为什么我主动把参考视频限制为一段

官方能力允许三段视频，我在第一版插件里却只保留一个视频输入。

我是在主动收窄工程边界。

多张图片很适合分工：人物、服装、商品、环境、光线，各自承担相对静态的事实。一段视频也容易指定角色：只参考动作，只参考运镜，只参考节奏，或者作为完整参考。

多段视频同时进入后，冲突会成倍增加：视频一的人物动作、视频二的镜头路径、视频三的剪辑节奏，到底谁覆盖谁？短短 4—15 秒里，规划模型很容易写出逻辑成立、实际却无法生成的复杂方案。

所以当前版本采用“多图 + 单视频 + 可选音频”的组合。它牺牲了一部分官方上限，换来更明确的引用关系和更容易解释的失败原因。

等单视频链路稳定后，再增加多视频策略，应该同时增加显式的角色分配与冲突消解，而不是再多开两个端口就算完成。

抽帧、压缩和视觉预算，决定了节点能不能长期使用

把整段 24fps 视频逐帧送给通用视觉模型，几乎一定会遇到速度、请求体、费用或上下文上限问题。

插件因此增加了两个预算：

• max_visual_inputs 默认 40：一次执行中，所有静态图片和视频抽帧共用的总名额；
• max_video_frames 默认并硬限制为 32：唯一参考视频最多发送的帧数。

图：静态图和视频帧共用全局视觉预算，避免一次请求无限膨胀。

分配时，先扣除静态图片的数量，剩余额度再给视频。视频只分析 H3 实际采用的时间线前缀，以大约 2fps 均匀抽样，并同时受 32 帧上限约束。

例如输入 6 张参考图，max_visual_inputs=40，视频最多还剩 34 个名额，但最终仍受 max_video_frames=32 限制。若目标视频只有 5 秒，以约 2fps 抽样，实际只需要大约 10 帧。

图：6 秒视频共有 144 帧，分析侧通常只需约 12 张均匀代表帧；静态图数量、全局预算和视频硬上限会继续约束实际上传量。

所有发往视觉模型的图片都会先在本地生成分析副本：保持宽高比，最长边不超过 1024px；通过逐级降低 JPEG 质量，必要时继续缩小尺寸，把每张图片严格压到 100,000 bytes 以下。

原图和送给 H3 的完整帧序列不会被改动。要注意，JPEG 变小不代表网络请求等量缩小，Base64 和 JSON 封装仍会增加约三分之一体积，但它已经能显著改善上传时间和兼容渠道的稳定性。

抽帧当然有代价。一个只持续两三帧的高速动作可能被漏掉，所以分析报告会明确说明：通用视觉 API 看见的是采样帧，不是原始视频。这个限制应该被暴露，而不是藏在“AI 已理解视频”的宣传语里。

时长和分辨率必须只有一个来源

早期版本把 width、height、length 直接写在 Context IR 节点内部。这样很方便，但也留下了一个危险：提示词可能按 5 秒规划，原生 H3 却只生成 3 秒；节点里写 16:9，下游实际跑的是 9:16。

H3 的镜头描述包含明确时间点。时长一旦漂移，动作节奏、转场、对白和音乐落点都会错位。

后来我把这三个参数改成了可连线输入，让它们与官方工作流共享同一个上游：

图：Resolution Selector 和 Duration 对齐公式同时连接 Context IR 与原生 H3。

具体做法是：

Resolution Selector.width  ─┬─> Context IR.width                            └─> Native H3.widthResolution Selector.height ─┬─> Context IR.height                            └─> Native H3.heightDuration → aligned length  ─┬─> Context IR.length                            └─> Native H3.length

ComfyUI 官方 H3 教程说明，H3 使用 24fps，时长会对齐到 17k+5 的帧数网格。插件不再维护另一套秒数，而是直接用同一 length 计算 duration = length / 24。

如果 length 是 73，提示计划的终点就是 3.042 秒，原生 H3 也生成同样的 73 帧。画幅和时长一旦同源，创意导演才能知道竖屏要保护人物的脸和手，短视频只能容纳一个主动作，长一点的片段才有空间安排第二个镜头。

最意外的 bug：H3 把提示词读成了旁白

有一次测试，我的原始输入是：

❝

图1女孩，在图3场景，和图2女孩一起跳舞，卡点运镜。

❞

多模态模型输出的结构化提示里，又加了一行：User request and hard constraints (verbatim)，然后逐字重复这句话。

结果 H3 把它当成了可听见的语言内容，直接生成旁白。

这个问题提醒我，音视频模型的 prompt 里，任何自然语言都有可能被理解成“要说出来的话”。仅仅补一句“不要朗读提示词”还不够，必须从数据流上隔离原始输入和最终输出。

现在的处理方式是：

• 用户原始输入只进入规划模型，并保存在审计用的 Context IR JSON 中；
• 本地 renderer 不再接收原始文本，因此不会把 verbatim user request 自动写回 H3 prompt；
• 最终 prompt 只保留规范化创作意图、硬约束、正式素材标签、镜头时间线和显式 <d> 对白；
• 段落标题、素材标签、说明文字和元数据在任何情况下都禁止朗读。

同时，声音控制被拆成四个独立开关：背景音乐、对白、旁白和字幕。音乐与对白默认开启，旁白与字幕默认关闭。

“对白开启”并不等于强制角色说话。如果规划结果没有实际对白行，renderer 会明确禁止额外人声、念白、吟唱和演唱。只有用户写出明确对白，或叙事确实需要时，才会生成 <d>[语言] ...</d>。

这种写法看起来保守，却比模糊的“可以有对白”稳定得多。

LLM 不直接写最终提示词

如果让多模态模型一次性输出最终 H3 prompt，格式错误很难处理：标签可能不存在，Subject 可能跳号，镜头时间会越过目标时长，关闭对白后仍可能残留 <d>。

这套节点采用了三段式处理：

1. 「计划」：模型按严格 JSON Schema 输出 Context 计划；
2. 「校验」：本地检查素材 ID、标签、Subject 连续编号、镜头时间线、目标时长、逐字对白和声音开关冲突；失败时最多修复一次；
3. 「渲染」：本地代码根据模式确定性输出 Base 三段或 Ref 六段协议，再次检查段落顺序和未知标签。

于是，模型可以自由描述“这个人物的金色发饰应该完整保留”，却不能把 <Picture 1> 改成不存在的 <Picture 7>；它可以规划两个镜头，却不能让最后一个镜头结束在目标时长之外。

在这个架构里，LLM 是语义规划器，renderer 才是编译器的最后一道关口。

创意导演也应该是结构化控制

基础链路稳定后，我又增加了一个独立的“创意导演”节点，用来控制视频类型、导演语法、物理运镜、视觉风格、运动强度、剪辑节奏、创意强度和参考视频用途。

我没有把“电影感、某导演风格、史诗运镜”这类词直接拼到用户提示后面。预设节点输出的是一个有类型的 M3_CREATIVE_PROFILE，主节点再结合真实时长、画幅、生成模式和已有素材，把它展开成具体指令。

图：下拉预设先进入结构化 Profile，再结合真实工作流条件展开。具体约束同时交给 LLM 规划和本地 Renderer 保底。

例如，“slow push in”会被解释为：从较宽构图开始，摄影机沿观看轴进行一次连续物理推进，焦距不变，保留自然视差，末段轻微减速并稳定落幅。竖屏时还会补上手机安全区、脸和手的边缘保护；三秒短片则限制为一个主动作和一个主要摄影机意图。

预设名不会直接进入最终 prompt。展开后的具体摄影约束既送给规划模型，也由本地 renderer 保底写入。即使 LLM 在长上下文中忽略了一条，最终 H3 prompt 仍能保留关键要求。

冲突优先级也是固定的：用户明确要求和逐字对白最高，其次是身份、商品、首尾帧，再到声音与字幕开关、创意导演、素材风格推断，最后才是模型自由发挥。

这让“导演预设”从装饰性下拉框，变成了一层可检查、可复现、可冲突消解的生产控制。

一个可复用的 ComfyUI 接法

如果把整套工作流压缩成最少的连线，大致是这样：

参考图 / VHS 视频帧 / 音频 ─┬─> Context IR 预处理                            └─> 原生 MiniMax H3 素材输入Resolution Selector ───────┬─> Context IR.width / height                           └─> 原生 H3.width / heightDuration 对齐公式 ─────────┬─> Context IR.length                           └─> 原生 H3.lengthCreative Director ───────────> Context IR.creative_profileContext IR.h3_prompt ─────────> 原生 H3.prompt

这里有三个必须保持一致的东西：素材顺序、尺寸、length。只要其中一个分叉，提示计划和实际 conditioning 就可能不再描述同一条视频。

做完这个节点后，我得到的几个结论

第一，「多模态接入的成本主要在编排，不在调用接口。」 真正耗时间的是素材预算、稳定编号、时间基准、音视频配对、失败修复、隐私和缓存。

第二，「结构化输出只有配上本地验证才有意义。」 JSON Schema 能减少错误，本地素材注册表和时间线校验才决定错误能否被拦住。

第三，「模型参数和提示参数必须共享权威来源。」 镜头节奏依赖时长，构图策略依赖画幅。让两个节点各填一遍，迟早会漂移。

第四，「越是原生音视频模型，越要警惕提示文字被声音系统误读。」 原始需求、说明文字、对白、旁白必须在结构上分开。

第五，「简化输入有时能提升整体可控性。」 官方支持三段视频，不代表第一版产品就必须开放三段。先把一段视频的角色说清楚，比允许所有组合更专业。

第六，「界面本地化也属于工作流兼容性。」 当前插件会跟随 ComfyUI 语言环境显示中文、英文或日文，但内部字段和值保持英文稳定。切换语言不会改工作流键，也不会破坏已有连线。

目前这个私有插件已经通过 55 项 Python 自动化测试，基础链路可以稳定运行。它仍然有明确局限：视频理解来自抽帧，音频转录可能出错，不同 OpenAI 兼容渠道的视觉、严格结构化输出和转录能力也不完全一致；最终画质上限仍由本地 H3-Base 权重与是否具备官方 Regenerate-2K 链路决定。

但这次实践至少验证了一件事：当生成模型开始同时接收文字、图片、视频和音频时，“提示词工程”正在变成“上下文接口工程”。

真正有价值的前置节点，会把模糊意图、真实素材和模型协议，编译成同一份可执行、可校验、可复现的上下文，而不只是替用户多写一段华丽描述。

这可能也是未来 ComfyUI 多模态工作流里，最值得补齐的一层基础设施。

参考资料

• MiniMax H3 官方模型卡
• MiniMax H3 Base 模式提示词指南
• MiniMax H3 Full-Reference 模式提示词指南
• ComfyUI MiniMax H3 官方教程
• ComfyUI 官方 MiniMax H3 R2V 工作流模板

「更多 AI 前沿技术与设计灵感，欢迎关注「设计小站」公众号（ID：sjxz00），一起探索科技与设计的融合创新。」