用 ChatGPT Image 2.0 做技术图解：一张多租户权限模型图的生成与返工

最近做一个 SaaS 后台的权限改造评审，产品同事希望在 PRD 里放一张图：能让研发、测试、交付都看懂“租户、组织、角色、用户、资源权限”之间的关系。听起来不难，毕竟权限模型我们已经讨论过好几轮了。但真正开始画图时，问题来了：研发画出来太像数据库 ER 图，产品看不懂；产品画出来像组织架构图，研发又觉得权限边界不准确。

我试着把这件事交给 ChatGPT Image 2.0 做第一版视觉草稿。为了避免只看单个模型的偶然输出，我前期在一个域名为 ouai.me 的多模型调用环境里做过任务拆解，点击即可进入。它能在同一界面切换 ChatGPT、Claude、Gemini、Grok 等模型，适合先把复杂需求拆成结构化描述，再进入图像生成环节。这里不做工具推荐，重点说说 ChatGPT Image 2.0 在技术图解里的可用边界。

这次我选了一个稍微冷门但很常见的任务：为 SaaS 多租户 RBAC 权限模型生成一张可放进技术方案的概念图。验收挑战也很明确：图要让非研发看懂，但不能把权限关系画错。这比生成一张运营海报难一些，因为它既要好看，又要保留技术语义。

第一版翻车：它把权限图画成了“企业管理宣传页”

我最开始的 Prompt 写得很简单：

生成一张 SaaS 多租户权限模型图，包含租户、组织、用户、角色、权限、资源，风格简洁专业，适合放在技术方案里。

输出第一眼还不错：蓝白配色、层级清晰、图标也挺现代。但仔细看就发现不对：

• “租户”和“组织”被画成了并列关系；
• “角色”直接连到了“资源”，中间缺少权限策略；
• 多个租户之间出现了共享用户池，看起来像跨租户打通；
• 图里出现了几段不可读的小字；
• 有些箭头方向反了，像是资源给用户授权；
• 视觉风格更像售前宣传页，不像技术方案图。

这类问题如果只作为配图还勉强能看，但放进评审文档就很危险。权限模型图一旦画错，很容易把讨论带偏，甚至让测试用例按错误关系去设计。

所以我后来换了思路：不让图像模型“理解整套权限系统”，而是先把图拆成可控的视觉元素，再让它生成草图。

核心模块一：先定义图片任务，而不是直接写画面

技术图解和普通插画不一样。普通插画可以容忍一点想象空间，技术图解不行。我的第一步是把图片任务写成一张结构表。

同时我明确了几条关系：

1. 租户是最外层边界；
2. 组织属于租户；
3. 用户属于租户，也可以挂在组织下；
4. 用户通过角色获得权限；
5. 角色绑定权限集合；
6. 权限作用于资源；
7. 不同租户之间不能画成共享权限或共享资源。

这一步很像写接口契约。图像生成不是把一句“帮我画个权限模型图”丢进去，而是把不能错的关系先定下来。

核心模块二：用视觉控制参数约束输出

ChatGPT Image 2.0 对自然语言描述的响应比较好，但如果 Prompt 只写“专业、简洁、科技感”，它会自由发挥。技术图解需要更具体的视觉控制参数。

我这次用的参数如下：

特别要注意“文字”。很多图像模型在生成中文小字时不稳定，即使这类能力已经比早期模型好不少，我也不建议把关键信息完全交给图片内文字。我的做法是：让图里只保留少量英文标签，比如 Tenant、Role、Permission，最终中文说明在文档里补。

核心模块三：Prompt 要把“禁止项”写进去

第二版 Prompt 我写得更像图像需求说明，而不是一句话命令。

Create a clean technical architecture diagram for a SaaS multi-tenant RBAC permission model.

Canvas and style:
- 16:9 horizontal layout
- flat 2D vector diagram
- white or very light gray background
- blue and gray color palette, with a small amount of orange for boundary highlights
- suitable for a technical design document, not a marketing poster
- minimal text, use short English labels only

Required structure:
- Show two separate Tenant containers to emphasize tenant isolation
- Inside each Tenant, show Organization blocks
- Show Users inside the tenant boundary
- Show Users assigned to Roles
- Show Roles connected to Permission Sets
- Show Permission Sets controlling access to Resources
- Use one-way arrows from User to Role to Permission Set to Resource
- Add a clear visual boundary between tenants
- Optional: add a small Audit Log module at the bottom as a supporting component

Do not:
- Do not show users shared across different tenants
- Do not connect resources directly to users
- Do not make Tenant and Organization parallel concepts
- Do not use complex tiny text
- Do not use real company logos
- Do not create a cyberpunk or sales-pitch style
- Do not imply cross-tenant data access

这一版生成的草图明显更接近预期：两个租户边界独立，授权链路从用户到角色，再到权限集合和资源，审计日志也只是作为辅助模块放在底部，没有抢主线。

不过它仍然有一些小问题：部分箭头有点密，某个租户容器里的组织层级不够明显，资源卡片数量偏多。于是我没有继续让它“一次生成最终图”，而是把它当成视觉草稿，再进入人工整理。

图片验收标准：不能只看“像不像高级图”

我给这类技术图解做了一个简单评分表。它比“好不好看”更适合评审。

我最后采用的流程是：图像模型生成底图，设计同事用绘图工具重排元素，研发补充中文注释和边界说明。这样做看起来多了一步，但比反复要求模型把所有细节都画准更稳定。

辅助模块一：把“技术真相”和“视觉表达”分开

做技术图解时，一个常见误区是想把所有真实细节都画进去。比如多租户权限系统里可能还有：

• 用户组；
• 数据权限；
• 菜单权限；
• API 权限；
• 字段级权限；
• 授权缓存；
• SSO；
• 审计策略；
• 超级管理员；
• 临时授权；
• 跨组织协作。

这些都重要，但不一定适合放在同一张图里。我的经验是，一张图最好只回答一个问题。

这张图的问题是：

一个用户如何在租户边界内通过角色获得资源访问权限？

如果想讲字段级权限，就另画一张细化图；如果想讲 SSO，就画登录认证链路。不要让一张图同时承担架构图、流程图、ER 图和产品说明图的职责。

辅助模块二：适合交给图像模型的，不是最终结论

ChatGPT Image 2.0 在这类任务里的价值主要有三个：

1. 快速给出构图方向；
2. 生成统一风格的视觉草稿；
3. 帮团队从“空白画布”进入“可讨论状态”。

但它不适合直接决定权限模型，也不能替代架构评审。尤其是权限、合规、金融、医疗、政务等场景，图像生成只能辅助表达，不能替代专业判断。

如果图片里表达了错误关系，必须以实际设计文档、接口定义、数据库约束和权限策略为准。图好看不代表设计正确。

辅助模块三：敏感信息要提前抽象掉

这类技术图解经常来自真实项目。我的建议是，进入图像生成前先做抽象处理：

这样既能让模型生成有用的结构图，又不会暴露内部信息。图像 Prompt 不是越真实越好，尤其在技术社区、公开文章或对外材料里，抽象反而更安全。

常见误区

1. 图像模型能不能直接画架构图？

可以画概念图和视觉草稿，但复杂架构图最好人工复核。特别是箭头方向、依赖关系、数据边界，不能只看视觉效果。

2. 为什么建议少用中文小字？

技术图的核心信息应该由结构表达，文字只是辅助。小字越多，生成错误、排版拥挤、后期返工的概率越高。

3. 一张图能不能同时讲完所有权限设计？

通常不建议。权限模型本身层次很多，一张图讲主链路，其他细节用补充图或表格说明，效果更好。

4. AI 生成图片能不能直接商用？

要看素材来源、授权范围、品牌规范和发布平台要求。涉及产品、客户、行业结论或真实人物时，要做版权、肖像权、商标和合规检查。

结尾：先让 AI 画“草图”，不要让它拍板“模型”

这次用 ChatGPT Image 2.0 做多租户权限模型图，我最大的体会是：图像模型很适合把抽象技术概念变成第一版可讨论的画面，但它不应该成为技术关系的最终裁判。

比较稳的做法是：

1. 先把技术关系写成结构表；
2. 再用视觉控制参数约束构图、颜色、箭头和文字；
3. Prompt 里明确禁止错误关系；
4. 生成后用验收表检查语义准确性；
5. 最终由研发、产品或设计人工修订。

如果你准备在团队里尝试，可以从低风险图解开始，比如缓存命中流程、灰度发布链路、测试环境分层、消息队列消费流程。不要一开始就把核心权限、安全策略、财务规则完全交给 AI 表达。图像生成降低的是起稿成本，不是审核成本。真正重要的技术判断，还是要回到文档、代码和团队评审。