这是「Codex 实战系列」的第 5 篇。
前一篇文章我们聊了如何让 Codex 驱动浏览器自动测试页面。
这一篇我们要进入视觉产出的深水区。
很多人用 AI 生图，第一反应就是输入 “生成一张科技感封面”。
模型很听话，立刻给你一张蓝紫渐变、发光线条、芯片堆叠的图。
这种图看起来很炫，但说实话，它毫无意义。
它没有信息，没有上下文，和你的文章观点没有任何关系。
它只是一层昂贵的 “发光滤镜”。
真正的高效生图工作流，不应该追求画得更酷，而应该追求图片服务于正文。
我们要把图片从 “装饰品” 变成 “内容资产”。

---

一、 为什么你的 “科技感” 提示词总出废图

“科技感”、“未来感”、“高级感”…… 这些词在模型眼里只是某种模糊的 “气味”。
它们无法告诉模型具体要画什么。
结果就是你得到了大量看似精致、实则空泛的图。
比如没意义的仪表盘、不知道代表什么的机器人、悬浮的半透明窗口。
这些图在文章里无法解释概念，也无法强化观点。
读者滑过去的时候，大脑会自动忽略这些没有信息量的视觉噪音。
这就是第一条实操准则：不要让 AI 猜你的画面，要把画面任务说清楚。
不要只写 “科技感封面，AI 编程”。
要写成：“左侧是一个杂乱的代码编辑器，右侧是一个被提炼出来的逻辑架构图，中间用光束连接，表达从混乱到有序的转换。”
具体的实体、明确的关系、清晰的用途，这才是生图的基石。

---

二、 拒绝平均插图：按任务规划视觉分布

很多技术博主有个习惯：写两段，插一张图。
这像是在给文章按固定间距装路灯。
但真正好的配图应该是按 “任务” 出现的，而不是按 “距离” 出现的。
在一篇深度教程中，图片通常承担以下四种任务：

1. 解释抽象概念

比如你讲 “模型上下文窗口”，文字解释很累，但一张装水的杯子示意图就能秒懂。

2. 呈现逻辑对比

比如 “传统开发” 与 “Codex 自动化开发” 的区别，左右对照的结构最有效。

3. 承接结构转折

当文章从 “痛点分析” 转向 “解决方案” 时，一张思维导图能帮读者重新抓住主线。

4. 关键观点强化

把金句做成视觉信息卡。
在动笔生图前，先让 Codex 读一遍你的草稿，执行这样一个任务：

“请阅读这篇文章，找出 3 个最需要配图的关键点。说明每个位置为什么要配图，以及建议采用流程图、对比图还是场景图。”
这样做的好处是，Codex 不再是盲目插图，而是站在内容架构的角度去规划视觉。

---

三、 从截图到素材：安全脱敏的工作流

如果你手里有现成的产品截图或后台截图，那是极好的原始上下文。
截图比任何文字描述都精准，它告诉 AI 真实的界面布局、信息层级和用户卡点。
但截图不能直接用，它可能包含真实的 Token、邮箱、订单号或公司私密信息。
我们的目标是：保留结构信息，去掉敏感数据。
以下是推荐的 Codex 实战步骤：

第一步：视觉审计

将截图发给 Codex，让它描述截图的主体、状态以及其中包含的所有文本信息。

第二步：任务抽象

要求 Codex 将上述信息改写为 “图片生成任务”。
例如，把真实的 “北京某某科技公司” 抽象为 “项目名称占位符”；把真实的报错代码抽象为 “醒目的红色错误提示区域”。

第三步：构造提示词

利用抽象后的任务，生成最终的生图指令。
这种方法生成的配图既保留了真实产品的 “神韵”，又完全合规。

---

四、 工程化配置：接入模型服务环境

在 Codex 工作流中，我们需要配置稳定的模型服务环境来执行生图和文字分析任务。
由于我们需要调用支持 OpenAI 兼容格式的接口，配置通常在 .env 文件或项目的 config 模块中完成。

下面以 iThinkAPI 为例展示配置方式。
这里仅作为配置示例，
实际可用模型、接口格式和配置方式请以对应的服务文档为准。

像 codex适用模型，gpt-5.5,claude-opus-4-8, 生图模型 gpt-image-2, 0.05/张图，支持 2k,4k，用起来不带心疼的。

# 示例配置文件：.

base url ="https://token.ithinkai.cn/v1" 
model
SERVICE_KEY="YOUR_API_KEY" 

在代码中，我们可以这样封装一个简单的生图请求逻辑：

import openai def generate_article_asset(prompt, output_path): # 这里配置演示环境，实际请参考服务商文档     client = openai.OpenAI(         api_key="YOUR_API_KEY",         base_url="https://token.ithinkai.cn/v1" )     response = client.images.generate(         model="dall-e-3",         prompt=f"风格统一，简洁科技感，{prompt}",         n=1,         size="1024x1024" ) # 保存逻辑...

通过这种方式，我们可以将生图能力无缝集成到 Codex 的自动化脚本中。

---

五、 批量生图与视觉统一：使用 images.json

技术文章最忌讳的是：第一张图是手绘风，第二张图是 3D 写实，第三张图又是扁平化 PPT 风格。
这种割裂感会让读者觉得文章是东拼西凑出来的。
批量生图不仅仅是为了快，更是为了通过同一组 “全局提示词” 来锁定视觉风格。
我建议在项目文件夹中创建一个 images.json 文件。
它负责定义整篇文章的配图标准：

{ "style_config": { "color_palette": ["#1A73E8", "#F1F3F4"], "theme": "Minimalist Technical Blueprint", "aspect_ratio": "16:9" }, "tasks": [ { "id": "cover", "purpose": "封面", "content": "展示 Codex 自动化处理图片的工作流示意" }, { "id": "workflow_step", "purpose": "过程演示", "content": "展示从截图到脱敏 JSON 的转换过程" } ] }

Codex 会读取这个 JSON，确保生成的每一张图都在同一个审美坐标系内。
记得把生成的图片文件和 Markdown 文章放在同一个文件夹下。
这样在预览、发布或迁移时，你才不会面对一堆丢失的本地路径抓耳挠腮。

---

六、 避坑指南：如何判断一张 AI 图能否 “活” 过初审

生成图片后，别急着往文章里塞。
先用这三个硬指标过一遍：

1. 它是 “哑巴” 吗？

如果去掉文章正文，只看图，读者能读出有效信息吗？
如果只能看出 “好看”，那它就是个哑巴。
一个好的技术配图，应该自带 30% 的信息量。

2. 它有 “中文恐惧症” 吗？

目前的 AI 生图对中文支持依然不算完美。
我的避坑经验是：字越少越稳。
一张图里最多放 4-8 个汉字。
如果发现生成的字缺笔少划，千万别凑合。
要么用 Codex 调用专门的图片处理工具打字，要么干脆去掉文字，改用纯构图表达。

3. 它是否破坏了 “呼吸感”？

有些生图由于细节堆叠过多，视觉上非常拥挤。
在手机屏幕上看，这简直是灾难。
确保你的配图有足够的留白，重点元素要突出。

---

七、 常见问题与排错思路

在实操过程中，你可能会遇到以下技术卡点：

1. Base URL 配置无效

如果你在 Codex 脚本中设置了 base_url 但依然报错，首先检查环境变量是否正确读取。
其次，确认你使用的 SDK 版本是否支持该配置项。
在本地开发环境配置中，如果是接入稳定性测试，确保你的网络能正常访问该地址。

2. 模型不支持生成特定比例

DALL-E 3 等模型对比例有严格要求（如 1024x1024, 1792x1024）。
如果 Codex 传入了非标准比例，会导致调用失败。
建议在 images.json 中统一预设合法参数。

3. 提示词冲突导致画面混乱

当你给的限制条件太多（比如又要写实，又要扁平，还要加霓虹灯），模型会产生 “认知混乱”。
解决办法是采用 “分层提示法”：先定基调（风格），再定主体，最后定细节修饰。

---

八、 总结：素材是提炼出来的，不是画出来的

AI 生图的门槛已经降到了零。
一句指令，十秒出图。
但也正因为太方便，我们往往忽略了图片作为 “内容载体” 的本职工作。
真正能给读者留下深刻印象的技术文章，其素材一定是从上下文里提炼出来的。
从逻辑冲突中提炼，从操作流程中提炼，从数据对比中提炼。
Codex 在这里扮演的角色，不是一个美工，而是一个视觉架构师。
它帮你拆解任务、脱敏截图、统筹风格、执行生成。
如果你还没尝试过这种 “全生命周期” 的视觉流，建议从今天起，扔掉那些空洞的 “科技感” 关键词。
下一篇，我们将回到工程安全的防线。
AI 自动化执行越猛，我们越需要 “后悔药”。
让我们聊聊如何通过 Git 回滚，把 “试错” 变成一种安全的日常动作。