企业官网建设流程全解析

最近社区里突然冒出来一批「画图类 Skill」，而且不止一个仓库的 star 涨得飞快。我连续试了几套实现之后，最大的感受是：以前画架构图、时序图、流程图，第一反应是打开 draw.io 或者 ProcessOn，从空白画布开始拖框拉线；现在直接在 AI 编程助手（比如 Claude Code、Codex）里对话框描述一句话，让 Skill 把图生成出来，再不行就追加一句“把负载均衡那块改成 Nginx”，它自己就把图改了。这种体验往回退一年是做不到的，至少做不到这么顺。

今天这篇不是单纯夸某个仓库多厉害，而是想拆开聊聊这类“画图 Skill”到底解决什么问题、为什么它能取代 draw.io 这类传统工具的一部分使用场景、底层是怎么设计的，以及我实际跑通一整套流程时踩过的坑。如果你已经在用 AI 编程助手写代码，或者平时画图频率很高，这篇应该能帮你省下不少时间。

1. 为什么画图 Skill 能让 draw.io 失宠

1.1 传统画图工具的三大痛点

先说过往用 draw.io 的习惯。我前几年做项目架构梳理，几乎每个迭代都要画一张系统架构图。draw.io 的优势是免费、开源、功能全、跨平台，甚至支持本地文件。但用久了你会发现，它本质上是一个“手动绘图软件”，画图的效率完全取决于你的拖拽手速和排版审美。一次架构调整，牵一发动全身：新增一个微服务，意味着要拉框、改箭头、调位置、对齐、改配色，动辄半小时没了，而且改完以后缩放到 80% 又发现布局乱了，接着再调一遍。

第二痛是版本管理。draw.io 的源文件虽然有 XML，但团队协作时，没人能直接在 code review 里看出你这次改了哪条线。即便导出 PNG/SVG 放到 Git 仓库里，diff 也没法看，最后大家传文件还是用 IM 软件。遇到想回退上一版布局，只能靠“我本地还有一份老的”，非常原始。

第三痛是“画图工具和代码/文档割裂”。架构图和代码明明描述的是同一套系统，但你要先在代码里改服务拆分，再去画图软件里同步，两边全靠手工维护。时间一长，图就是摆设，和代码真相完全对不上。

1.2 AI 画图 Skill 做了哪件核心的事

这类画图 Skill 的核心思路不是“又一个绘图引擎”，而是把“画图”这件事变成 AI Agent 的一项能力，底层通常靠模型直接生成结构化代码——比如 SVG、PlantUML、Mermaid、HTML/CSS——然后渲染成图。你不需要学绘图软件的复杂交互，也不需要记忆各种图形工具的位置，你只需要把脑子里的结构说清楚，后面的布局、连线、美化全部交给模型。

这里的关键词其实是“可迭代”。过去画图是单向操作：画完一张图，要修改就得重画或手动调整。Skill 模式下，图是文本代码，修改就是改文本，AI 可以基于你的自然语言反馈反复改，每次生成的版本都能比较。我试过让 Skill 画一张登录鉴权流程图，第一版太简单，我回复“细化 token 刷新逻辑，并标注失败分支”，几秒钟后就得到一张新的、更完整的图。这种对话式迭代，比任何手动画图工具都自然。

1.3 谁最需要这类能力

如果你属于下面这几类人，这类 Skill 带来的收益会非常大：

• 写技术文档、架构设计文档时经常需要配图，但画图技术一般的人。
• 后端或全栈工程师，架构图、部署图经常要随着代码迭代而更新，但不想花大量时间维护图形。
• 做项目汇报、PPT 需要快速输出结构清晰图表的人，比如产品经理、技术 Leader。
• 用 AI 编程助手写代码的人，希望 Agent 在解释代码时顺带画出调用关系、模块依赖图。

如果你本来就是资深绘图爱好者，享受手动画图带来的掌控感，那 Skill 未必能取代你的习惯。但如果你要的是“快速得到一张还算专业的图，并且随时能改”，它就是碾压级效率工具。

2. 从开源仓库拆解：这类 Skill 的技术构成与选型逻辑

2.1 Skill 本身是什么，目录结构长什么样

先普及一个背景。在 Claude Code、Codex 这类工具里，Skill 可以理解成一个“给 AI 助手附加的结构化技能包”。通常一个 Skill 就是一个目录，里面包含一个SKILL.md作为主描述文件，里面写清楚这个技能在什么场景下被调用、需要遵守哪些输出规范、有哪些可用脚本。可能还会有scripts/、references/、assets/等子目录，用来存放辅助脚本、模板示例、参考素材。

我拆过社区里比较热门的几套画图 Skill，它们的通用目录大致是：

diagram-skill/ ├── SKILL.md # 技能说明，引导模型使用步骤 ├── scripts/ │ ├── render.py # 负责把 SVG/HTML 生成图片，转换格式 │ └── validate.py # 简单校验输出 SVG 是否有明显错误 ├── templates/ │ ├── architecture.svg # 架构图模板 │ ├── flow.svg # 流程图模板 │ ├── sequence.svg # 时序图模板 │ └── mindmap.html # 思维导图模板 └── assets/ └── examples.md # 调用示例和提问范式

这个结构本身不复杂，但SKILL.md的编写水平，极大影响实际效果。写得好的 Skill 会给模型明确的指令：比如“先分析用户描述中涉及几个实体，再决定使用架构图还是流程图；输出时必须严格使用 SVG，宽高不低于 1200×800，样式统一用某个色板，并在代码块内输出，方便直接存为文件”。模型看到这样的约束后，生成的图质量会明显更稳定。

2.2 为什么很多实现选择 SVG 作为主力渲染方案

这里有一个挺关键的选型问题：画图 Skill 底层到底让模型直接生成什么格式？主流选择有几个：Mermaid（文本类图）、PlantUML（文本类图）、SVG（矢量描述）、HTML/CSS（网页渲染），以及 Canvas/SVG 的 JS 库封装（比如 mermaid.js、DrawIO 的 mxGraph）。我实际比较过这几个方案的体验差异，其中很多问题用起来才发现。

从实操角度讲，Mermaid 和 PlantUML 的优势是语法简单，模型生成的成功率高，图表类型覆盖也广，尤其是时序图、甘特图、流程图。但它们的排版是自动布局，复杂图形会挤成一团，样式定制能力弱，想调成漂亮的“架构图”风格比较难。比如画一张包含十几个微服务、中间还有网关、消息队列、数据存储的系统架构图，Mermaid 用 flowchart 硬画，出来的效果往往层次不齐，往文档里一放，视觉上就是“简陋”。

SVG 的优势恰恰是布局完全可控，它本质上就是 XML 描述的矢量图。模型可以把方框放在指定坐标、连线拐弯处精确控制、颜色填充、圆角矩形、渐变、文字居中都能做到。虽然生成 SVG 的代码量比 Mermaid 大不少，但这类 Skill 普遍会准备模板，让模型在模板基础上改文字和结构，而不是从零写，这就解决了“代码量大导致失败率高”的问题。从我的实测经验看，只要模板设计得够好、模型遵循指令的能力够强，SVG 方案的出图质量上限是最高的，这也是很多新开源 Skill 默认用 SVG 的原因。

另外还有一部分 Skill 会选用 HTML/CSS 再配合 headless 浏览器或者 Playwright 截图导出 PNG。这种方式的好处是：CSS 布局引擎强大，Flexbox/Grid 天然能做复杂排版，模型写 JSX/HTML 的语感也更熟练，最终视觉表现非常接近网页设计图。缺点是多了一层环境依赖，本地必须有浏览器内核或渲染服务，安装门槛高一点。我自己更倾向“优先输出 SVG，需要位图时再用工具转一次”的方案，因为 SVG 在文档系统、Git 仓库、PPT 插入里都很好用。

2.3 输出可复用文件：被很多人忽略的“工程化”设计

真正体验好的画图 Skill，通常不只是把图画出来，还会“落盘”。也就是说，生成的 SVG 源文件会单独存成一个.svg文件，下次修改时只需要在对话里说“读取./docs/architecture.svg，给订单服务加上 Redis 缓存”，AI 就能直接对 SVG 内容继续编辑。这种“文本即文件、文件可复用”的设计，才是 Skill 替代 draw.io 的精髓。

我们对比一下两种使用方式：

这里我不太建议把 Mermaid 的.mmd文件当唯一源文件，虽然它确实更易读，但复杂架构的美观度不够。比较好的策略是“SVG 做最终交付，必要时让 Skill 附赠一份 Mermaid / Markdown 摘要说明，方便在技术文档里快速引用”。有的新开源 Skill 也支持生成 PlantUML 适配旧系统，但我觉得没必要一开始就追求多格式，先做好 SVG 这一种，就足够支撑绝大多数画图场景了。

3. 动手实操：从安装到生成第一张架构图的完整流程

3.1 准备阶段的工具环境

我用的主力环境是 Claude Code 命令行版本，操作系统是 macOS，终端走的是 zsh。其实这套流程对 Codex CLI 或者其他支持 Agent 的类似工具也适用，因为 Skill 本身是个通用机制。你只需要满足两件事：第一，能安装并运行对应的 Agent CLI；第二，有可以调用的模型 API 或订阅账号。局部试玩的话，DeepSeek 的开源模型也能做到基础生成，但代码能力与遵循长指令能力会比顶级模型弱一些，架构稍复杂的图容易出现连线对不齐、元素丢失之类的现象，不建议新手一上来就用弱模型排障。

安装 Skill 的第一步是拉取项目仓库。以我用的这个仓库为例，基本操作：

git clone https://github.com/example/diagram-skill.git ~/.claude/skills/diagram-skill

不同工具识别 Skill 的路径不太一样，有的支持项目级目录.claude/skills/，有的放在用户级全局目录。我建议优先放全局目录，因为画图需求不限于某个项目，全局模式在任何仓库下都能调用。放好后，在同一对话里重新启动一次 Agent，让它重新扫描技能目录。

3.2 用一段话生成“订单系统架构图”

我实际开始画的时候，没有用套话模版，而是直接把项目里的真实需求描述丢给它：

请使用 diagram-skill，帮我画一张订单系统的微服务架构图。 核心服务包括：前端、API网关、订单服务、用户服务、库存服务、支付服务、消息队列。 订单服务和库存服务之间通过消息队列解耦，支付成功后回调订单服务更新状态，并发送事件到消息队列，库存服务消费事件完成扣减。 要求：用 SVG 格式，风格简洁大方，最好使用蓝灰配色，宽度 1280，高度建议 800，服务模块旁附一行文字标明职责。

模型收到后，通常会按 Skill 指引先做一次简短分析，判断这属于“系统架构图”类型，然后读取模板目录里的architecture.svg，把服务节点和文字替换进去，再按照我描述的关系连线。大约 20 秒后，它会输出一个 SVG 代码块，我直接保存为/docs/order-architecture.svg。

第一版结果整体可用，但有个小问题：支付服务和订单服务之间的回调箭头方向不够直观。我的处理方式是直接追加一句：“把支付服务到订单服务的线改成虚线，并在线上标注‘异步回调’。” Agent 会读取刚才生成保存的 SVG 文件，精准修改对应路径的stroke-dasharray属性和文本标签。这种修改粒度，基本能对应到 draw.io 里的“选中一条线，改样式”。

3.3 导出为 PNG：处理中文字体和分辨率的正确姿势

很多文档平台不支持直接展示 SVG，或者团队习惯看图时用 PNG 格式。我一开始直接用系统自带工具把 SVG 转 PNG，发现中文全部变成了豆腐块，这是因为系统默认的字体没被正确嵌入。后来我改用开源工具rsvg-convert，并指定系统中文字体，效果就好了很多。命令大概是：

brew install librsvg rsvg-convert -w 1600 -h 1000 -o order-architecture.png order-architecture.svg

如果的 SVG 里引用的是浏览器渲染才支持的 CSS 样式，rsvg-convert 偶尔会解析不完全，这种时候我会改用 Playwright 脚本加载 SVG 再截图，虽然重一点，但还原度最高。再补充一个经验：输出图片时宽高尽量按 2 倍尺寸导出，否则在文档中插入图片时稍微放大一点就会发虚。SVG 本身是矢量无损的，但 PNG 不提前高清化，后面想补救就只能重导。

3.4 批量生成多图：一次对话画完“系统全景图 + 时序图”

画架构图只是热身。我试过最痛快的一次，是在同一个对话里连续让它画了五张图：一张系统全景图，一张用户登录时序图，一张支付状态机图，一张部署拓扑图，一张数据库 ER 图。全程只靠自然语言描述需求，偶尔指定一下“用蓝色突出高可用组件”“表的数量不要超过 10 张”。

这里最大的感受是：对话上下文连贯性让配套图之间不容易互相矛盾。比如先画了“订单服务通过 MQ 通知库存服务”的架构图，后面让它画“下单时序图”时，它会自动延续前面定的通信方式，而不是重新发明一套。传统方式下，不同图往往由不同人画，很容易出现架构图说用 HTTP，时序图却画成 Feign 调用的低级错误。

当然，连续生成多张图对模型能力要求更高，如果中途发现输出开始“忘事”，可以把前面的关键约束放进一个context.md文件里，让它每次都先读一眼再画。这个技巧是我实验多次后最有效的稳定方案。

4. 实操中的高阶用法：让 AI 不止“画得出来”，还“画得专业”

4.1 用示例文件和“风格词”约束出图颜值

纯靠 prompt 让模型每次都输出好看、统一风格的图，还是有一定运气成分。后来我学乖了，看社区 Skill 的模板目录里通常有几个 example 文件，这些 example 不只是给用户看，更是让模型参考风格的“锚点”。我会在 prompt 里明确写：“仿照模板 examples/architecture.svg 的视觉风格，但内容替换成 xxx。” 实测这样生成出来的图，结构层次感明显更强。

如果你想要现代感更强一点的风格，可以要求模型在 SVG 中使用卡片式布局、圆角矩形、外发光、柔和的阴影。说得越具体，比如“主色 #2563EB，背景 #F8FAFC，边框 #E2E8F0”，最终效果越靠近你脑子里的设想。我在微调了几次之后，形成了一套自己的默认参数：

• 背景：浅灰白 #F7F9FC
• 容器底色：白色，矩形圆角 8px，加浅灰色描边
• 主服务节点：蓝色系 #EFF6FF 底、边框 #60A5FA
• 数据存储节点：紫色系 #F3E8FF 底、边框 #C084FC
• 外部系统：灰色系 #F1F5F9 底
• 箭头统一 #64748B，关键路径用粗线或虚线并用文字标注
• 字体统一用系统默认的无衬线字体（避免特殊字体在渲染机上不兼容）

这几组参数其实花不了多少 token，但能保证多张图风格统一，整套文档看起来像出自同一个设计师之手，很值。

4.2 使用 SVG 模板做快速结构替换

有些设计模式是固定复用的，例如“网关 + 多个微服务 + 数据库”的经典分层。如果能让 Skill 默认识别到这类模式，再套用固定模板，速度和稳定性都会提升。我在实际使用中会故意写这种 prompt：

用模板 templates/microservice.svg，帮我把四个后端服务替换为：用户、订单、商品、支付。 注意模板中各模块之间的横向间距保持一致，箭头连线不要交叉。

这样省去了模型每次重新设计布局的思考过程。原因很简单：模型虽然懂坐标，但在动态规划一条从 (120, 310) 到 (840, 310) 的连线时，偶尔会有失误，导致线条穿过不该穿过的框。固定模板里这些连接路径都是验证过的，替换文字内容风险最小。

如果你对自定义模板感兴趣，可以拿一张模型生成的效果最好的 SVG，自己手工微调布局以后放到templates/里，以后就成了你的专属样式，下次会让 Skill 优先选择这张图做底子，逐步积累自己的模板库。这也是 Skill 生态比较迷人的地方，不需要会复杂编程，只需要“把一次成功的输出固化成模板”。

4.3 与其他 Skill 组合：不只是画图，是文档自动化

画图 Skill 单独用已经很香，但更强的玩法是和其他 Skill 组合。我目前的自动化工作流里，画图 Skill 常常和写作类 Skill、代码解释类 Skill 串联使用：

1. 让 Agent 扫描项目代码目录，分析模块依赖，生成一份 markdown 描述。
2. 把描述喂给画图 Skill，让它生成对应的模块依赖图。
3. 最后再让文档类 Skill 把图插入到设计文档里，并配一段说明文字。

这相当于把“代码分析 → 架构可视化 → 文档编写”串成一条流水线。以前一个架构师做完这些至少小半天，现在我自己一个人操作，半小时能产出一整套配套图齐全的设计初稿。质量上初稿不一定能直接用，但它把最费时间的“从无到有”阶段解决了。剩下的调整，也都是对话式修改。

当然，这种组合玩法对模型能力要求更高。我在用普通开源大模型测试时，它生成的 SVG 经常出现“圆角矩形标签和文字重叠”“箭头没有指向节点中心”之类的小 bug。如果你遇到类似情况，别急着怪模型，可以先考虑检查一下 prompt 是否有足够限制，或换一个更强代码能力的模型。

5. 避坑指南：我从频繁使用中整理出的高频问题

5.1 生成图片文字乱码、中文不显示怎么办

这个问题主要是字体原因。SVG 文件里如果写了font-family="Arial"，而当前渲染环境没有安装 Arial 字体或中文字体映射异常，中文就会显示成方框。解决办法：

• 生成时在 prompt 里明确要求字体使用“PingFang SC, Microsoft YaHei, sans-serif”。
• 在本地做 PNG 导出时，确认系统已经安装了至少一款中文字体。
• 如果多次导出仍有问题，检查一下 SVG 文本标签里是否缺少xml:lang="zh-CN"，部分渲染器会有语言相关字体选择逻辑。

5.2 SVG 元素大量堆叠导致输出中断或信息丢失

大而全的架构图，比如超过 30 个节点、50 条连线，仍然强依赖模型的输出长度和逻辑一致性。模型在中途输出截断、自行发挥优化、少画了一个模块的情况，在这一类任务中不算罕见。规避方法：

• 把大图拆成多个子图，每个子图控制在 15 个节点以内，最后再让 Skill 生成一张“总览图”，总览图里不展示细节，只画分组和关键链路。
• 明确告诉模型“不必为每个节点都要用不同的配色，层次关系用分组边框表达即可”，降低视觉复杂度。
• 在长输出前提醒它“先规划坐标再输出完整代码，别中途换思路”。

5.3 修改某个细节时，背景样式全变了

对话进行到第 N 轮，如果你让它“把第一个框的宽度从 160 增加到 200”，模型有时候会误判为“整张图重新调整布局”，结果连背景颜色、配色、间距全改了。这不是不可用，而是提示词不够精确。修正后的说法是：

只修改 id 为 service-order 的矩形元素，将其 width 属性从 160 改为 200， 新增宽度会导致后面的连线起点可能偏移，请一并调整该节点右侧所有连接的起点坐标。 其余元素不要修改。

借助元素定位描述，模型就能精准编辑 SVG。这套玩法也验证了为什么 SVG 落盘模式比直接生成 PNG 更好用——PNG 一旦生成就无法局部修改，SVG 能直接做到代码级微调。

5.4 想让图片背景透明，导出时会有白边

如果你生成的 SVG 需要嵌入到深色 PPT 或网页里，背景透明非常重要。我一开始默认生成的架构图都是白底，插到深色主题的页面里非常突兀。后来我习惯在 prompt 里明说：“背景使用透明，不要添加任何 rect 作为全局背景，不要使用 fill="#fff"。” SVG 输出时可以很好支持透明背景，但在用 rsvg-convert 转 PNG 时，需要额外加参数：

rsvg-convert --background-color none -o output.png input.svg

不加--background-color none的话，即使 SVG 透明，PNG 也会默认渲染成白色背景。

5.5 Team 协作中，AI 生成的 SVG 能否被其他人直接编辑

很多人会担心一个问题：AI 生成的 SVG，团队成员没装 Agent 工具是不是就改不了了？亲测结果是：可以。把 SVG 文件直接拖到 draw.io 里，draw.io 支持导入或打开 SVG 文件？严格来讲，draw.io 原生编辑 SVG 的能力有限，它更偏向识别合适的 XML 再导入。如果你希望团队成员以后能在 draw.io 里继续编辑，最稳的办法是让 Skill 生成时同时输出一个.drawio格式的 XML 文件，或者至少画完架构图之后导出一次可以导入 draw.io 的格式。不过这样一来，“用 AI 生成原始图、再在 draw.io 里精修”就形成了一个混合工作流，也是一种很实在的团队协作姿势。

就我自己目前的使用偏好来说，凡是给我自己维护的技术文档用的图，我全走 SVG 落盘 + Git 管理，因为后续我自己用 AI 改起来最顺。凡是需要给团队里不熟悉这些工具的人做二次编辑的图，我会多花一步转成 draw.io 可以识别的格式，双轨并行，避免协作时卡在工具链上。

6. 我对这类 Skill 未来走向与个人使用心法

这类 Skill 出现得这么快，确实给“画图”这个传统领域带来了新的工作方式。往深一点看，它在把“结构化表达”这件事彻底文本化、可编程化，也让“文档图例随代码演进”变成可能。未来不管底层的模型怎么换，这套“文本生成 → 文件落盘 → 对话式修改 → 版本管理”的工作流大概率会沉淀成技术文档的标准干活方式。

不过我也必须泼点冷水：Skill 不是万能钥匙。模型能力不足时，生成的复杂图示依然会翻车；输入的业务描述含糊不清时，它也画不出精准的图。它更像一个“非常了解绘画规范的实习生”而不是“脑子里自动长出一套架构的架构师”。你需要先把逻辑讲清楚，它才能把图做漂亮。

聊聊我现在的使用习惯：日常快速文档配图，我已经基本不再打开 draw.io 了；但遇到一张图需要精细叠层设计、需要严格控制输出的像素级布局时，我还是会把 AI 生成的 SVG 作为底稿带进 Figma 或 draw.io 精修。动笔思路和骨架是 AI 帮我想清楚的，省掉了最枯燥的空白画布阶段；而精修阶段需要人类审美和经验的地方，则仍然值得自己动手。

如果你也想基于这类开源 Skill 搭一套自己的画图工作流，我的建议是先别追求功能大而全，只装一个针对架构图/流程图优化最好的仓库即可，每天真的在写文档时强迫自己用三次以上，慢慢把 Prompt 习惯调顺，再逐渐尝试组合其他 Skill。等这套流程成为肌肉记忆，你再回头看那些必须手动拖线框图的日子，会有一种明显的“效率代差感”。

真正影响工作流上限的往往不是工具本身，而是你喂给它的信息结构和迭代思路。给模型越清晰、越模块化的描述，你收回来的图就越接近一张值得直接放进技术方案里的作品。这是我尝试了近半个月这类 Skill，踩过无数乱码和错位坑之后，最想分享给你的一句话。