前阵子我试着给一篇内部技术分享配张图，主题是“异常订单进入风控队列后的处理流程”。原始材料是一段接口说明、几条状态机规则，加上一张产品经理手绘的流程图。想着不就是把文档丢给图像模型，让它生成一张清爽的技术图解吗？
结果呢？第一张图出来时，视觉上确实像模像样——蓝灰配色、流程箭头、节点卡片、数据流线一个不少。但研发同事端详了两分钟，说：“这图不能用，状态流转是错的，重试队列画反了。” 那一刻才意识到，用 ChatGPT Image 2.0 做技术图解，关键不在于让它“画得像设计稿”，而在于让它“在可控范围内准确表达已经确认过的技术事实”。
第一版是怎么翻的？模型会自动补全你没说清的部分
最初的 Prompt 大概是这样的：
请生成一张异常订单风控处理流程图，适合技术文章配图。风格简洁、科技感、蓝色系，包含订单系统、风控系统、消息队列、人工审核、结果回写。这段描述的问题，细数一下：
- 没说清楚哪些节点是同步调用，哪些是异步消息；
- 没限定状态名称；
- 没说明失败重试和人工审核之间的关系；
- 没要求箭头方向必须符合真实流程；
- 没约束中文文字的准确性；
- 最关键的是，没告诉模型哪些内容不能随意添加。
于是模型会根据常见业务流程“自动补全”。补全出来的东西看起来合理，但未必符合你的系统。对于技术图解来说，“合理”和“正确”是两回事。尤其是架构图、流程图、状态机图，一旦箭头方向、状态名或模块边界出了偏差，图片越精致，误导性就越强。
第一步：先拆解任务，别急着写生成
这次的任务是：把异常订单风控状态机画成一张技术文章配图。不是产品海报，也不是普通运营图，而是带有技术解释性质的图解。推荐的拆解方式是把任务分成三层。
1. 事实层：必须来自原始文档
这部分不能让模型自由发挥：
| 类型 | 示例 |
|---|---|
| 系统模块 | 订单服务、风控服务、消息队列、审核后台、通知服务 |
| 状态名称 | CREATED、RISK_PENDING、MANUAL_REVIEW、APPROVED、REJECTED |
| 流向关系 | 订单创建后进入风控；高风险进入人工审核；审核结果回写订单 |
| 异常分支 | 风控调用失败后进入重试队列 |
| 禁止内容 | 虚构接口名、真实客户名、内部 IP、数据库表名 |
2. 表达层：可以交给图像模型处理
比如版式、配色、卡片样式、图标抽象、信息层级、视觉重点、文章封面比例。
3. 审核层：生成后必须人工检查
包括：箭头方向有没有错？节点有没有遗漏？状态名有没有拼错？有没有出现不该出现的品牌、Logo 或敏感字段？是不是把异步流程画成了同步调用？是不是暗示了系统并不存在的能力？
这三层分清楚之后，图片生成就不再是“凭感觉出图”，而是一个可验收的技术内容生产流程。
第二步：视觉控制参数要具体，不能只写“科技感”
图像 Prompt 里只写“科技感”“高级”“简洁”，通常不够。不如先准备一张视觉控制表，再改写成 Prompt。
| 参数 | 选择 |
|---|---|
| 图片用途 | 技术文章配图 / 方案说明图 |
| 画幅 | 16:9 横版 |
| 风格 | 扁平化技术图解，不要拟物化 |
| 主色 | 深蓝、浅灰、少量橙色告警色 |
| 布局 | 从左到右流程，异常分支向下 |
| 字体感觉 | 清晰、工程化、少量中文标签 |
| 元素 | 服务卡片、队列图标、审核节点、状态标签 |
| 避免 | 真实品牌、复杂小字、伪代码、错误接口名 |
| 验收挑战 | 中文状态名和箭头关系不能错 |
这里“验收挑战”写得很明确。ChatGPT Image 2.0 能生成很自然的视觉图，但技术图解里常见的坑是：小字不稳定、箭头关系被美化、图标语义模糊、节点数量被自动增减。所以 Prompt 里必须把最不能错的地方写得足够明确。
第三步：Prompt 示例——先约束结构，再描述风格
下面这个版本是我后来实际使用的：
生成一张 16:9 横版技术文章配图，主题是“异常订单风控处理流程”。
画面结构：
从左到右展示主流程：
1. 订单服务：订单创建
2. 风控服务：风险评分
3. 消息队列：异步投递
4. 审核后台：人工审核
5. 订单服务：结果回写
异常分支：
从“风控服务”向下分出一条支线，连接“重试队列”，表示风控调用失败后的异步重试。
从“审核后台”向右分出两个结果标签：通过、拒绝。
视觉要求：
扁平化技术图解风格，深蓝和浅灰为主色，少量橙色用于异常分支。
每个模块使用简洁卡片，不要复杂背景。
箭头方向必须清晰，从左到右表示主流程，向下表示异常分支。
整体适合放在技术博客文章中。
文字要求：
只保留这些中文标签：
订单服务、风控服务、消息队列、审核后台、重试队列、结果回写、通过、拒绝。
不要添加其他接口名、代码、IP、数据库表名、公司名或品牌 Logo。这个 Prompt 比第一版长，但长度不是关键。真正有用的是：把结构、异常分支、文字范围和禁止项写清楚了。如果模型仍然把文字画错，可以退一步——生成无文字版本，只保留模块卡片和箭头，后续用设计工具或 Markdown 绘图工具加文字。这比反复赌中文小字准确率稳得多。
辅助模块一：让文本模型先整理“图解规格”
现在一般不会直接让 ChatGPT Image 2.0 根据长文档画图。更好的做法是，先让文本模型把文档整理成图解规格。
你是技术图解编辑。
请根据下面的接口说明和状态机规则，整理一份用于生成技术配图的图解规格。
要求输出：
1. 必须出现的模块；
2. 必须出现的状态；
3. 箭头方向；
4. 异常分支；
5. 不应出现在图片中的敏感信息；
6. 建议画幅和布局。
注意：
不要新增原文没有的业务规则。
依据不足的地方标注“待确认”。这样做的价值在于，图片生成之前就能发现需求里没说清楚的地方。比如“风控失败后是否阻塞订单创建”“人工审核是否一定经过消息队列”“拒绝后是否通知用户”，这些都不应该由图像模型来猜测。
辅助模块二：技术图解的验收表
图片生成后，建议不要只看“美不美”，而是用一张简单的表来验收：
| 验收项 | 检查问题 | 结果 |
|---|---|---|
| 结构完整性 | 原始文档中的核心模块是否都出现 | 待检查 |
| 流程正确性 | 箭头方向是否符合真实系统流程 | 待检查 |
| 异常分支 | 重试、失败、人工审核是否画对位置 | 待检查 |
| 文字准确性 | 中文标签是否错字、变形、遗漏 | 待检查 |
| 信息安全 | 是否出现内部字段、真实客户、品牌 Logo | 待检查 |
| 视觉可读性 | 缩小到文章宽度后是否仍能看清 | 待检查 |
| 合规风险 | 是否夸大系统能力或暗示未实现功能 | 待检查 |
对于技术社区，读者通常不缺审美，他们更在意图是否能帮助理解。所以一张合格的 AI 技术图解，第一标准不是“像海报”，而是“别把技术关系画错”。
辅助模块三：复杂中文尽量后置，不要强行一次性生成
ChatGPT Image 2.0 对中文短标签的支持已经比以前好很多，但如果你需要放很多状态名、接口名、字段名，还是建议谨慎。
- 8 个以内短中文标签可以尝试直接生成；
- 接口名、参数名、表名不建议直接交给图片模型；
- 长句说明、注释、警告文案最好后期添加；
- 如果要保证绝对准确，可以生成“留白卡片版”，再用设计工具补字；
- 如果图片用于正式方案、合同附件、招投标材料，必须人工复核。
一个更稳的 Prompt 可以这样写：
生成一张无文字技术流程图。
保留 5 个空白模块卡片和 1 个异常分支卡片。
卡片内留出文字区域，但不要生成任何文字。
使用清晰箭头表示主流程和异常分支。
风格为扁平化技术图解，适合后期添加中文标签。这类无文字图在实际项目里反而更好用。设计同事能接着改，技术同事也不用担心模型把状态名写错。
一个可复用的技术配图模板
如果你经常写技术文章、方案文档或产品说明，可以把下面这个模板存起来。
生成一张【画幅】技术图解，用于【使用场景】。
主题：
【一句话说明图片主题】
必须出现的模块：
- 【模块1】
- 【模块2】
- 【模块3】
流程关系：
- 【模块1】 -> 【模块2】：【关系说明】
- 【模块2】 -> 【模块3】：【关系说明】
- 异常分支：【从哪里分出】 -> 【到哪里】
视觉风格：
- 【扁平化 / 白底线框 / 深色科技风 / 手绘草图风】
- 主色：【颜色】
- 强调色：【颜色】
- 布局：【从左到右 / 从上到下 / 中心辐射 / 分层架构】
文字限制：
只允许出现以下文字：
【列出允许出现的文字】
禁止出现：
真实公司名、品牌 Logo、客户名、手机号、邮箱、内部 IP、数据库表名、未经确认的接口名、复杂代码片段。
验收重点：
箭头方向正确；模块数量不变；异常分支位置正确；文字不乱码；缩小后可读。这个模板不适合所有图，但适合大多数技术文章配图、流程图、架构概念图、产品能力说明图。
风险边界：AI 图片能做初稿，但不能替你承担发布责任
图像生成很容易让人低估审核成本。尤其是技术图解、产品展示、金融医疗政务说明图，不能只看画面效果。
- 不上传包含客户资料、合同、日志、账号、真实截图的敏感内容；
- 对外图片不得出现未经授权的商标、Logo、人物肖像；
- 产品能力图不能暗示未上线功能；
- 医疗、金融、政务、教育类图片不能伪造真实机构或真实事件；
- 生成图用于商用前，要检查版权、品牌规范和平台发布规范；
- 重要技术图必须由对应研发、产品或合规人员确认。
AI 可以提高出图速度，但它不会知道你们系统的真实边界，也不会替团队承担误导用户的责任。
从低风险技术图解开始试
如果你准备在工作里使用 ChatGPT Image 2.0，不建议一上来就做高精度产品图、复杂 UI 截图或对外宣传主视觉。更稳妥的起点是低风险、可验证的技术图解，比如：
- 流程概念图；
- 简化架构图；
- 数据流说明图；
- 故障排查步骤图；
- 文档封面插图；
- 培训材料中的抽象场景图。
固定流程现在是这样的：先让文本模型把需求拆成图解规格；再把模块、箭头、文字范围和禁止项写清楚；用 ChatGPT Image 2.0 生成一版视觉初稿；通过验收表检查结构、文字、合规和可读性；关键文字和品牌元素尽量后期人工处理。
把图像模型当成“视觉初稿助手”，而不是最终设计负责人，使用体验会稳定很多。对技术社区作者来说，它最有价值的地方不是替我们省掉所有设计工作，而是把原本没人愿意画的流程图、概念图和说明图，变成一个可以快速讨论、修改和审核的草稿。至于最终能不能发布，最终还是回到事实、审核和责任链上。