网站技术插图

Starred Gists，GitHub Gist，即时分享代码、笔记与代码片段。关注
生成一张用于企业级云服务 / SaaS 官网首页功能卡片的技术插图。
【主题】
[主题描述或附件内容]
【核心技术关系，可选】
[希望重点表达的技术关系；留空时根据主题提炼]
【优先场景，可选】
[希望采用的具体应用场景；留空时根据主题选择最容易用图形表达的场景]
【核心表达目标】
先找到一个具体、容易理解的应用场景，再通过场景中的对象关系表达技术价值。
让观众能够直观看到：
正在发生什么事；
哪些信息、资源或能力正在支持这件事；
核心技术如何使这件事得以完成、持续运行或安全推进。
重点不是堆砌技术图标，也不是把功能名称排列成架构图。
应通过“具体任务或事件 + 核心对象 + 必要辅助模块 + 清晰连接关系”，表达一个完整但简洁的技术含义。
场景负责让人看懂，图形关系负责说明技术。
不能只画成普通业务流程或聊天界面，而丢失主题中的核心技术机制。
【场景优先：绘制前的构图判断】
绘制前先完成以下设计判断，无需输出分析过程：
1. 提炼一条核心技术主线
从主题中识别最值得表现的一个核心能力，以及它带来的直接价值。
如果主题包含多组能力，应选择一条最适合当前插图的主线。
其他能力可以弱化或省略，不要把运行时任务、开发测试、资源管理等不同层面的内容强行塞进同一张图。
用户明确要求同时表达的能力，应通过同一个场景建立主次关系，而不是平均分配视觉权重。
2. 将技术能力转化为一个具体事件
不要停留在“电商”“智能客服”“数据分析”等宽泛行业或应用类别。
应具体到：
谁或什么发起了一个请求；
正在处理哪个对象；
需要什么信息或资源；
任务正在发生什么状态变化。
例如，“智能客服”还不是足够具体的场景；
“用户要求继续上次的退货，Agent 找回历史对话并查询当前订单，接着推进同一项任务”才是可以构图的场景。
此例仅说明场景应有的具体程度，不默认使用退货、包裹或客服主题。
3. 优先选择容易图形化的场景
优先选择具有以下特点的场景：
- 有一个清楚、易识别的任务对象或业务对象。
- 能通过少量图形表达输入、支持关系和当前状态。
- 技术价值能够由对象之间的关系体现，而不是依赖解释文字。
- 不需要复杂人物活动、真实环境或长篇业务规则。
- 缩小到 300×300 px 后仍能看懂大意。
4. 建立技术与场景对象的对应
每个保留的技术能力，都应找到一个必要的场景对象或结构关系来表达。
例如：
记忆可以体现为与当前任务有关的历史信息；
资源扩展可以体现为新增节点接入仍在工作的业务路径；
环境隔离可以体现为边界明确、互不干扰的独立区域。
不要仅通过写上技术名称来声称已经表达了该能力。
5. 只截取一个关键时刻
选择最能体现技术价值的一个画面瞬间。
可以让触发条件、支持信息和当前任务同时出现，
但不要把完整业务流程画成多阶段故事板。
【场景化表达边界】
场景化不等于绘制现实生活情景画。
仍然使用抽象、克制的技术插画语言：
任务卡、业务对象、文档、数据模块、请求路径、资源节点、状态标记等。
不需要人物、用户头像、办公室、商店、城市或复杂环境背景。
通过一个清晰的任务对象和相关模块，建立场景感。
辅助对象必须参与同一件事：
它们应是当前任务的输入、依据、资源、状态或结果，
而不是互不相关的能力图标。
不同主题应重新设计场景、主对象与连接关系。
不要只替换标签，反复套用同一个数据库、AI 芯片或包裹构图。
【用途与尺寸】
画布为正方形，比例 1:1，建议输出 1200×1200 px。
实际用于网页中的 300×300 px 功能卡片配图。
所有元素都要以缩小到 300×300 px 后仍然清晰、易识别为标准。
不要设计成海报、完整网页、复杂信息图或产品界面截图。
【整体风格】
采用精致的 SVG 矢量插画视觉风格，
将简洁的几何技术图形与轻量产品界面元素结合。
整体轻盈、克制、干净，
有少量轴测透视和空间层次，但不是写实 3D 渲染。
纯白背景。
以明亮科技蓝 #006AFF 为主色。
深蓝 #082B59 用于少量文字。
浅蓝 #D6E8FF 和 #F2F7FF 用于辅助模块、信息卡片和底座。
仅在状态指示处使用极少量青绿色 #00C8B4。
使用纯色填充、统一描边和清晰的几何轮廓。
以不同明度的纯色色块区分顶面、侧面和前后层次。
不使用渐变、发光、玻璃质感、金属材质、纹理或模糊投影。
不要通过柔和光照、空气透视或渐变底色模拟立体效果。
最终效果应像同一套高端云服务官网中的系列功能插图：
蓝白配色、轻量卡片、简洁技术模块、细线连接、适度留白，
既有装饰性，也有准确的技术含义。
【精致度要求】
精致感来自统一的图形语言，而不是复杂材质和装饰。
要求：
- 几何比例准确。
- 同类线条粗细一致，缩小后仍可辨认。
- 轴测角度与透视关系统一。
- 模块间距稳定，前后遮挡清楚。
- 圆角、倒角、转折和卡片边框风格一致。
- 细节服务于识别，不增加无意义的小零件。
- 不依赖强阴影制造层次。
【总体构图】
采用：
“上方轻量场景卡片 + 中间小型状态胶囊 + 中下部核心对象 + 周围辅助模块”
的紧凑构图。
保留这一视觉层级，但不要机械固定每个辅助模块的位置。
根据场景中的关系，灵活组织围合、汇聚、接入、分发、隔离或扩展结构。
画面只有一个主要视觉中心。
不要设置两个同样醒目的大型主体。
【上方区域：表现触发事件或操作意图】
优先放置 1 张轻量白色信息卡片，带浅蓝色细边框。
只有确实需要对比时，才使用 2 张卡片。
上方卡片的职责是：
告诉观众“现在发生了什么”或“系统正在响应什么”。
根据场景选择最合适的形式：
- 一句简短请求的对话气泡。
- 一张简化任务或查询卡片。
- 一张负载变化或服务状态卡片。
- 一张简化的 SQL / AI 调用卡片。
场景能够通过请求或任务表达时，不强行使用 SQL。
请求文字尽量控制在 2—5 个英文单词。
可以搭配一个与下方任务一致的小型业务对象符号，
不需要用户头像、完整聊天记录或真实订单编号。
如需 SQL / AI 调用示意：
仅保留与主题直接相关的 1—3 行简化代码。
不要画成 IDE，也不要用代码替代场景关系。
如需监控卡片：
每张只保留一个简短指标名、必要的状态或数值，
以及一条逻辑清楚的折线或阶梯线。
上方不要重复罗列下方已经出现的模块分类。
不要加入导航栏、侧边栏、复杂按钮组、密集表格或大段文字。
【中间区域：表现此刻的状态】
在上方卡片与核心主体之间，
放置一个小型蓝色状态胶囊。
胶囊使用白色短文字，通常为 1—2 个英文单词。
左侧搭配一个小型青绿色状态圆点。
标签应来自当前场景的实际状态，
例如任务进行中、上下文已就绪、服务持续在线或环境已隔离。
不要使用与场景无关的泛化宣传词。
不要在任务仍在推进时，显示已经成功完成。
状态胶囊小巧、明确、易读，用于承上启下，不抢主体。
【中下部区域：设计场景化核心对象】
主要视觉主体约占画面高度的一半。
使用主蓝色，使其成为第一眼看到的对象。
核心对象应同时满足：
能识别当前正在处理的任务或对象；
能通过结构体现本主题的关键技术关系。
可以采用：
- 正在推进的任务模块。
- 业务对象与技术核心结合的简洁结构。
- 承载同一任务的共享上下文模块。
- 维持业务连续运行的资源组合。
- 带有明确边界的隔离数据环境。
- 根据主题设计的调度、路由、存储或计算核心。
不要机械套用数据库圆柱。
也不要一律改成带有 Agent 字样的大卡片。
可以使用模块组合、嵌入、分层、同步、汇聚、调度、
扩展、隔离或保护等关系表达技术。
如果主题与 AI 强相关，可以保留小型 AI / Agent 标识，
但不要让 AI 芯片遮盖真正需要表达的场景对象和系统关系。
主体内部只保留一个主要图形和少量必要状态。
如需任务进度，最多使用 2—3 个节点，不展开完整流程。
不要画成后台操作面板或写实服务器机柜。
【辅助模块设计】
通常使用 2—4 个辅助模块，优先控制在 3 个。
围绕核心对象组织，尺寸明显小于主体。
每个模块必须回答一个明确问题：
当前任务需要什么历史信息？
需要什么规则或业务事实？
需要什么资源？
需要向哪里输出？
需要什么保护或隔离条件？
模块内容根据场景选择，
不要为了凑齐数量而添加无关对象。
表现方式可以是：
历史对话片段、规则文档、订单或记录卡片、
资源节点、数据分支、结果对象、状态模块等。
辅助模块要求：
- 使用浅蓝、白色或蓝色轮廓。
- 每个模块只保留一个主要符号和一个必要短标签。
- 文本细节用少量短横线、气泡轮廓或单一高亮表示。
- 不使用完整对话、政策条款、长编号或密集内容。
- 不重复核心对象已经说明的信息。
- 不给每个模块都设置厚重独立底座。
共享平台只在有助于组织关系时使用。
平台应薄、轻、浅，不要做成大型设备舞台。
隔离、分支等主题可以使用分开的薄平台或边界区域，
不要为了统一底座而破坏技术含义。
【贯穿场景的视觉线索】
选择一个能代表“同一件事”的视觉线索，贯穿画面。
可以是：
同一份文档、同一笔订单、同一个数据对象、
同一种请求标记，或一条持续存在的业务路径。
必要时，让同一个简洁符号在 2—3 个位置有意义地出现：
上方表示它被请求；
辅助模块表示与它有关的信息；
核心主体表示它正在被处理。
重复时保持形状和识别特征一致，
通过大小、位置和颜色区分主次。
不要依赖细小编号来证明它们属于同一任务。
也不要为了重复而增加多余对象。
【连接关系规则】
使用清晰、克制的科技蓝色细线，
连接核心对象与必要辅助模块。
优先采用短距离、邻近连接。
圆角折线或平滑几何连线的风格应统一。
尽量不交叉，不穿过文字，不压住核心图形。
明确区分两类关系：
- 主任务路径：请求如何进入、任务如何推进或业务如何持续运行。
- 支持关系：信息、资源或能力如何服务于主任务。
不要把所有关系都画成同样的单向流程。
实线表示稳定存在或正在工作的连接。
虚线只表示待加入、可选、备用、退出中或明确的隔离边界。
不要用虚线随意表达“历史”“智能”或装饰性空间。
箭头只在确实需要说明方向时使用。
不增加无意义箭头，不画复杂网络拓扑。
连接、边界和共享结构必须符合技术含义：
统一管理的信息，不应被误画成彼此独立的系统；
隔离环境，不应被连接成没有边界的共享空间；
业务退回，不应被误用来代表数据库回滚；
资源扩展，不应被画成业务迁移或停机重启。
【图表与技术逻辑】
如果主题包含性能、监控、资源、扩缩容或稳定性，
图表必须像轻量产品监控组件，而不是装饰波浪线。
不同指标与对象变化必须逻辑一致。
例如：
负载上升时，资源容量相应增加；
强调平滑扩缩容时，业务路径保持连续；
强调隔离测试时，生产环境与测试环境边界明确；
强调上下文接续时，历史信息与当前任务有可见关联。
没有真实数据时，优先使用示意曲线和相对状态。
不添加未经支持的精确指标、成功率、性能提升或生产实测结果。
如果主题来自附件，只表达附件支持的能力。
不要为了构图完整而虚构额外功能。
【文字与标签规则】
文字极少，优先使用简短英文标签。
普通标签控制在 1—2 个单词。
上方请求允许 2—5 个单词。
一般控制在 5—7 处必要文字以内。
不是每个图形都需要标签。
不添加标题、宣传口号、说明段落、页脚或品牌标志。
不出现完整政策、长篇对话、详细订单信息或大量技术缩写。
小尺寸下的阅读顺序应当是：
先看见具体任务或核心对象；
再看见模块如何共同支持这件事；
最后才注意到状态和少量文字。
核心含义不能依赖阅读微小文字才能理解。
【留白与版面】
所有元素围绕一个视觉中心组织。
外围保留约 10%—15% 的干净留白。
上方卡片轻、核心主体重、辅助模块弱。
前后层次清楚，避免左右两侧同样拥挤。
不要让插图铺满画布。
不要让卡片、平台或边缘元素被裁切。
不要用放大底座填满下方空间。
构图稳定、居中、平衡，适合官网首页功能卡片长期复用。
【不要出现】
渐变、发光、强阴影、写实材质、玻璃质感、金属纹理、
复杂建筑背景、大朵装饰云、人物、用户头像、植物、
厚重底座、密集仪表盘、大面积文字、水印、品牌 logo、
完整后台界面、复杂 IDE、密集表格、
无意义箭头、过度电路装饰、与当前场景无关的技术图标。
【生成前自检】
确认以下问题：
去掉大部分文字后，是否仍能看出正在发生什么？
所有辅助模块是否都在服务同一个任务或对象？
是否能从结构和关系中看到核心技术，而不只是技术名称？
是否只表达了一条清楚的主线？
缩小到 300×300 px 后，是否仍然轮廓清晰、关系可辨？
如果不满足，优先删除次要元素、简化文字和连接，
不要通过增加更多说明来补救。
【输出要求】
直接生成一张完整插图，不输出分析过程或设计说明。
不要把模板中的占位符、规则文字或示例说明绘入画面。
添加评论
点赞收藏
点踩分享查看原文
评论
?
参与讨论