写技术文章时最容易拖慢进度的往往不是正文而是配图封面需要概括主题正文插图需要解释段落生成后还经常要调整标题、比例或局部元素。现在用 AI 生图已经方便很多但还缺少一款能根据整篇文章自动规划配图的工具。所以我做了一个「博文视觉生成器」上传 Markdown 文档后点击“AI 智能规划配图”即可为全文生成封面和核心段落插图也可以单独选择全文或某个段落生成图片。这个项目的文本模型使用GLM5.3通过蓝耘元生代接入视觉生成和图片编辑使用商汤科技的 Sense U1.5 Lite。本文叙述模型名称时统一写作“GLM5.3”在配置和真实请求中则使用蓝耘控制台给出的模型 IDglm-5.3。一、成品与整体架构《博文视觉生成器》会先让大模型理解全文并生成配图计划再创建若干生图任务。每个任务先调用语言模型生成视觉指令再调用商汤Sense U1.5 Lite生成封面或插图。对于已生成或已有的图片还可以继续微调。这次使用Codex开发项目并通过CC Switch管理和切换模型服务。图1 项目最终效果项目使用 Vue 3 Vite 开发是一个不含业务后端的纯前端应用。界面分成左右两块左边是博文文档支持上传、编辑、预览以及按内容块选择段落右边是视觉创作区可选择封面或插图、视觉风格与画面比例。整个调用链路如下Markdown 全文或选中段落蓝耘元生代 · GLM5.3理解内容、抽取主题与信息层级生成视觉指令商汤 · Sense U1.5 Lite根据视觉指令生成封面或正文插图图片编辑器上传或复用生成结果继续通过自然语言改图二、开发环境与 CC Switch 配置2.1 为什么选择蓝耘元生代选择模型服务时我先看接入方式、模型信息和用量管理模型数量也是参考因素之一。这个项目既要在 Codex 中开发也要在前端调用文本模型分析长文章因此接口是否容易接入、模型参数是否清楚会直接影响开发和排错效率。我最终选择蓝耘 MaaS主要基于以下几点提供 OpenAI 兼容接口查阅蓝耘官方文档后可以看到只需替换base_url、api_key和模型 ID即可继续使用 OpenAI SDK 或兼容客户端现有代码不必为此重写请求层。图2 蓝耘接口文档模型信息展示得比较完整平台模型列表给出了模型类型、上下文长度、供应商和 API 入口。选型时可以先确认模型能否处理长文再复制真实调用 ID不必根据展示名称猜配置值。多种模型可以放在同一个 MaaS 平台中管理如果以后要尝试 Kimi、Qwen 等其他文本模型可以沿用相同的兼容接口主要调整模型 ID 和提示词并对比不同模型的实际效果。API Key 和资源用量有独立入口API Key 可以按项目创建资源包页面可以查看剩余量和使用量。出现鉴权或额度问题时定位范围更清楚。图3 蓝耘用量监控这些能力都可以在蓝耘 MaaS 平台文档和模型列表中查到。这个项目最终选择 GLM5.3是因为任务既包含编码协作也包含 Markdown 长文理解和结构化视觉策划通过蓝耘发起真实请求时模型字段填写glm-5.3。图4 蓝耘模型列表2.2 为什么使用 Codex 配合 CC Switch我日常经常使用 Codex 处理代码但使用额度偶尔会见底因此会通过 CC Switch 切换其他模型服务。CC Switch 可以同时保存多个供应商配置并在界面中切换 Provider。选择配置后它会更新 Codex 当前使用的模型、端点和认证信息省去了反复修改配置文件的步骤。CC Switch 的核心是维护 Codex 配置。Codex 使用~/.codex/config.toml保存 Provider、模型与端点设置API Key 则由相应的认证配置管理。对于只提供 OpenAI Chat Completions 接口的第三方服务需要启用本地路由让 CC Switch 把 Codex 的 Responses 请求转换为上游支持的格式。CC Switch 接入文档和Provider 配置说明都介绍了相关设置。2.3 在蓝耘元生代创建专用 API Key打开蓝耘平台 https://maas.lanyun.net/#/system/apiKey。创建一个只给本项目使用的 API Key。在模型列表确认模型 ID。日常称为 GLM5.3蓝耘控制台中的实际调用 ID 是glm-5.3。两者含义相同但配置时必须使用后者。打开蓝耘提供的接口说明确认 OpenAI 兼容的基础地址和路径。不要把控制台网页地址当作 API Base URL。建议为每个项目单独创建 API Key并在项目结束后停用。这样即使发生泄露、401 或额度异常处理时也不会影响其他项目。图5 创建API Key2.4 在 CC Switch 中添加蓝耘 GLM5.3 Provider打开 CC Switch切换到Codex页面点击新增 Provider。如果没有蓝耘预设选择“自定义”即可。需要填的字段如下CC Switch 字段应填写的内容说明Provider 名称蓝耘-GLM5.3仅用于自己识别Base URL蓝耘控制台提供的 OpenAI 兼容基础地址不是蓝耘控制台网页地址API Key刚创建的蓝耘专用 Key不提交到仓库不放截图里模型glm-5.3蓝耘控制台显示的实际调用 ID接口格式按蓝耘接口文档选择如果上游只有 Chat Completions需要打开本地路由这里有一个容易混淆的点是否需要打开 CC Switch 的本地路由不取决于模型叫不叫 GLM而取决于上游接口格式。如果蓝耘给你的端点原生支持 Codex 所用的 Responses 兼容格式可以直接按 Provider 配置使用。如果蓝耘公开的是 OpenAI Chat Completions 兼容接口则在 CC Switch 的“设置 → 路由”中启动本地路由并在可路由应用中启用 Codex。这样 CC Switch 会承担协议转换Codex 仍可以正常工作。如果是第一次配置可以严格按下面四步操作在 Codex 页点击新增 Provider选择“自定义”。填入蓝耘的基础地址、专用 API Key并将模型填写为glm-5.3。根据蓝耘接口文档选择协议格式若只有 Chat Completions打开本地路由并勾选 Codex。保存后回到 Provider 列表点击“启用”再重新打开 Codex。不要手工把真实 Key 写进文章里的config.toml示例。CC Switch 切换后可以检查当前的~/.codex/config.tomlmodel_provider、model和base_url应该已经变成刚启用的 Provider。密钥不要贴到文章、终端录屏或 Git 提交记录里。图6 CC Switch配置先测试一下是否连通。图7 接口连通测试2.5 用 Codex 验证开发模型是否切换成功图8 Codex模型验证切换 Provider 后重新打开 Codex给一个足够具体但不消耗太多额度的任务例如阅读当前 Vue 项目的目录结构说明将 Markdown 文档拆成“全文”和“段落”两种生成范围时状态应该放在哪个组件并给出修改建议。不要直接改文件。这一步的目的不是评测模型分数而是验证三件事Codex 能正常响应、模型名确实来自蓝耘 Provider、以及项目上下文能被正确理解。图9 Codex理解项目三、创建项目3.1 创建并启动项目图10 输入初始Prompt这个项目从零开始开发。我先用一条基础 Prompt 生成项目框架再通过多轮对话逐步补充功能。最初的 Prompt 只描述整体方向后续再补充页面布局、并行任务、图片编辑和错误重试等需求。这也是我常用的开发方式先确认大方向再逐项微调。图11 追加开发Prompt项目使用 Vue 3 Vite 开发。markdown-it负责把文档转换为 HTMLdompurify负责清理渲染结果避免将上传 Markdown 中不可信的 HTML 直接插入页面。图片生成和编辑请求统一放在src/services页面组件只处理状态和交互。工程目录为md-visual-studio。图12 项目目录结构3.2 在页面中配置模型项目启动后点击右上角“模型配置”打开设置弹窗。蓝耘部分填写服务地址、接口路径、模型 IDglm-5.3和项目专用 API Key商汤部分填写服务地址、生图路径/images/generations、编辑路径/images/edits、模型 ID 和访问密钥。保存后配置写入当前浏览器的本地存储页面顶部会同步显示蓝耘和商汤的配置状态。整个过程都在页面弹窗中完成不需要修改项目配置文件。四、核心实现4.1 让 GLM5.3 先做视觉策划而不是直接让生图模型读全文文章往往很长直接整篇交给图像模型得到的画面容易只抓住几个表面关键词。我的处理方式是把“理解文章”和“生成图片”拆开。上传 Markdown 后项目会提取标题和内容块用户可以选择全文也可以点击某个段落。随后createImagePrompt把选中的文本、图片用途、画面比例和风格发给蓝耘模型。请求中的model来自页面配置本项目实际发送的是glm-5.3。核心调用逻辑如下省略了错误处理constpayload{model,messages:[{role:system,content:visualDirectorPrompt},{role:user,content:请根据以下${scopeName}生成一条${targetName}指令。 文章标题${documentTitle}画面比例${ratio}视觉风格${style}--- 内容开始 ---${source}--- 内容结束 ---,},],temperature:0.45,stream:false,}visualDirectorPrompt里我明确约束了七件事封面概括全文插图解释段落图片里的标题、数字和技术名词由图像模型直接生成需要出现的文字用中文引号逐字标出只保留一个主标题和不超过三项核心信息描述构图、层级、配色和留白不添加原文中没有的事实和结论最终只返回一条图像指令而不是解释性文字或 JSON。这一步是蓝耘在项目中承担的核心任务。GLM5.3 输出的不是通用的“帮我画一张科技图”而是一份以原文为边界、可直接传给 U1.5 Lite 的视觉简报。4.2 把 U1.5 Lite 的生图和改图收敛成同一个图片工作流右侧创作区没有把“智能生成”和“图片编辑”硬切成两个页面。用户生成图片后可以点击“编辑图片”直接进入近全屏编辑器也可以先点击“编辑已有图片”上传一张本地图片。编辑器处理了三个细节保留当前图片版本列表方便回看原图和每次编辑结果。编辑指令只要求描述“要改什么”例如“把背景改成浅色网格保留中间标题和流程结构”。编辑时把当前图片、修改要求和输出比例一起发送未修改部分是否保留则直接写进本次编辑 Prompt。文生图请求使用顶层prompt核心结构如下constpayload{model,prompt,n:1,size:editSizeByRatio[ratio]||auto,output_format:png,response_format:b64_json,watermark:true,prompt_extend:true,}图片编辑走/images/edits原图放进images自然语言修改要求仍放在顶层promptconstpayload{model,images:[{image_url:imageUrl}],prompt:instruction,n:1,size:editSizeByRatio[ratio]||auto,response_format:b64_json,watermark:true,prompt_extend:true,}前端不负责给图片二次排字只把视觉指令、原图和比例交给模型。图片中的标题和技术名词与画面一起生成避免浏览器叠字与原图风格不一致。五、实际问题与处理方式页面做出来后真正花时间排查的是三个问题浏览器跨域、批量任务并发以及生图接口偶发失败。它们不算复杂但不处理好工具就只能偶尔生成一张图很难连续使用。5.1 本地页面直连接口时触发 CORS 限制一开始页面从http://localhost:5173直接请求商汤接口浏览器控制台随即报出跨域错误。这并不是 localhost 不能调用 AI而是浏览器的同源策略在起作用页面和模型接口的协议、域名或端口不同接口又没有放行当前来源请求还没到业务处理阶段就被浏览器拦下了。项目用的是 Vite开发阶段可以直接加一层同源代理。浏览器请求本站的/api/sensenovaVite 开发服务器再把它转发给商汤constsensenovaProxy{target:https://token.sensenova.cn,changeOrigin:true,rewrite:(path)path.replace(/^\/api\/sensenova/,),}exportdefaultdefineConfig({server:{proxy:{/api/sensenova:sensenovaProxy,},},})在请求层中如果识别到目标地址是商汤官方域名就把浏览器实际请求地址改写为同源代理路径if(target.originhttps://token.sensenova.cn){return/api/sensenova${target.pathname}${target.search}}改完以后浏览器看到的始终是同源请求跨域转发由 Vite 完成生图和改图接口都恢复了正常。这套代理只在 Vite 的开发和预览服务中生效打包出来的静态文件不会自带代理能力。要公开部署服务器仍需配置同名反向代理或者由后端代调模型接口。页面保存在localStorage中的 API Key 也无法真正隐藏因此这个版本只适合本机测试或受控演示。5.2 全篇配图从逐个等待改为并行任务第一版一次只能处理一张图前一项结束后才会开始下一项。“AI 智能策划全篇配图”通常会产生一张封面和多张正文插图串行执行时几次模型调用的耗时会叠在一起等起来很慢。我又给 Codex 中使用的蓝耘 GLM5.3 补了一条 Prompt大意是将智能配图方案改成独立任务并行执行。应用方案后立即创建全部任务卡片 每个任务分别维护提示词生成、生图、完成和失败状态单个任务失败不能阻塞其他任务。实现时没有在循环里逐项await而是先为每条建议创建任务再立即调用executeTask。简化后的代码如下taskList.forEach((item){constnewTask{id:task-${Date.now()}-${Math.random().toString(36).slice(2,7)},title:item.title,status:pending,// 其余字段保存目标段落、图片类型、风格和比例}tasks.value.unshift(newTask)executeTask(newTask)})每张图单独维护prompting、generating、completed和failed状态。哪张先完成就先显示其中一张报错其他任务照常运行。智能策划目前只推荐少量关键配图直接并行已经够用。如果以后允许一次生成几十张图还要加并发上限和等待队列避免短时间内发出太多请求。5.3 接口偶发报错时保留任务并支持重试生图接口并不总能一次成功。测试时我碰到过网络中断、服务端报错、响应超时也遇到过请求返回成功但程序没有解析出图片的情况。如果失败后直接移除卡片错误原因看不到段落、比例和风格也得重新选择。所以我没有删除失败任务而是把状态改成failed将错误信息留在卡片上并显示“重试”和“重新下发”按钮asyncfunctionexecuteTask(task){task.statuspromptingtask.errortry{task.promptawaitcreateImagePrompt(/* 当前任务参数 */)task.statusgeneratingtask.imageUrl(awaitgenerateImage(/* 当前视觉指令 */)).imageUrl task.statuscompleted}catch(error){task.statusfailedtask.errortoErrorMessage(error)}}functionretryTask(taskId){consttasktasks.value.find((item)item.idtaskId)if(task)executeTask(task)}点击重试后文章内容、图片类型、风格和比例都会沿用原任务不用再填一遍。现在采用的是整条链路重跑也就是重新生成视觉指令再调用商汤生图。这样写比较稳两个阶段的错误都能处理。后面如果要节省调用量可以缓存已经生成成功的视觉指令只重试生图接口。六、效果实测6.1 上传 Markdown 文章测试时我上传了一篇包含多个章节、操作步骤和技术名词的 Markdown 文章。程序读取一级标题并统计字符数、文件大小和内容块数量。这几项信息可以快速判断文件有没有读全。图13 上传Markdown界面分为上、中、下三部分。顶部放项目名称、模型状态和配置入口中间左边是 Markdown 文档右边是视觉生成控制台底部集中显示生图任务。文档区可以在“编辑”和“预览”之间切换改完原文后能立即检查标题、列表和代码块的渲染结果。这篇文章的标题和内容块都识别正确。选择“文章全文”可以生成封面切换到“选中段落”再在预览区点选一个或多个内容块就能生成对应的正文插图。阅读原文、配置参数和查看结果都在当前页面完成省去了反复复制段落的步骤。6.2 AI 智能策划全篇配图点击“AI 智能策划全篇配图”后蓝耘 GLM5.3 会通读文章挑出适合配图的位置。它不会给每段都塞一张图而是优先处理封面、核心流程、参数对比和操作重点同时给出标题、推荐理由及对应段落。图14 全文配图方案确认方案后页面一次创建所有任务。每项任务都记下标题、用途、比例、风格和目标段落然后分别调用蓝耘生成视觉指令再交给商汤出图。几张图会同时生成不再一张接一张地等。图15 配图并行生成任务卡片会显示当前阶段和等待时间。图片完成后直接出现在卡片里还可以展开查看蓝耘生成的视觉指令。如果结果跑偏也能从这里判断问题出在文章理解还是生图环节。图16 配图生成完成这次生成的封面抓住了文章主题正文插图也能对应到所选段落没有变成泛化的科技背景图。并行任务中即使有一项失败其他任务仍会继续已完成的图片也会保留。6.3 图片编辑图片生成后可以点击任务卡片中的“微调”继续编辑也可以另行上传一张图片。编辑时只要用自然语言说明改哪里不用重写整条生图提示词。图17 图片编辑窗口这次我要求模型把画面右侧的一台平板改成两台分别表示安卓平板和苹果 iPad同时保留标题、电脑主体、配色和整体构图。前端没有用 Canvas 覆盖元素也没有在本地重新排字只负责把原图和修改要求交给 Sense U1.5 Lite。图18 图片编辑结果每次编辑都会生成一个新版本原图仍然保留。左侧的版本列表可以来回切换方便比较修改前后的差异再选择下载或继续调整。对于主体已经可用、只需替换设备或局部文字的图片这比重新生成更省事。6.4 配图回填与文章导出图片完成后可以逐张插入对应段落也可以点击“一键插入到文章”统一处理。封面放在文章标题附近正文插图根据任务中保存的原始段落定位匹配不到时则追加到文末。图19 插入并导出文章导出文件会在原名称后加上“配图版”不会覆盖原始 Markdown。整理投稿文件时我把 Markdown 和下载的原图放在同一目录下图片集中放进images子目录1-单测--开学季平板远程控制电脑实测ToDesk让iPad安卓平板秒变生产力工具-配图版 ├──1-单测--开学季平板远程控制电脑实测ToDesk让iPad安卓平板秒变生产力工具-配图版.md └── images ├── iPad远程控制电脑ToDesk实测平板秒变生产力工具-1788140637816.png ├── 出门前检查电脑状态与安全设置-1788140635804.png ├── 二次微调修图版本-1788140632987.png ├── 双指缩放解决Windows小按钮操作难题-1788140636451.png ├── 远程打开WPS原文件与格式完整保留-1788140635165.png └── 远程桌面连接iPad操作Windows电脑-1788140637078.png图20 导出文章预览重新打开导出的文章封面和正文插图都在预期位置原来的标题、段落和代码块也没有被改乱。Markdown 上传、全篇配图、并行生图、自然语言改图和文章导出这几步都跑通了。七、小结蓝耘 MaaS 平台在这个项目的两个环节中承担了实际任务开发阶段通过 Codex CC Switch 作为编码协作模型帮助我完成 Vue 组件拆分、接口边界设计和配置排错。运行阶段作为视觉策划模型把全文或段落转换成结构化、受原文约束的图像指令再把任务交给商汤 U1.5 Lite。而商汤 U1.5 Lite 则专注图像生成与编辑。把文本理解和视觉生成拆成两个清晰的职责后项目既保留了多模型协作的灵活性也避免让一个模型同时承担所有工作。目前完成的是一个可运行的 MVP仍有继续完善的空间。下一步我准备使用后端代理保护长期密钥并加入持久化生成记录、提示词对比和调用日志。调用记录也能帮助我比较不同蓝耘模型在“长文理解 → 视觉指令”任务中的实际差异。