先说自己踩过的坑大半年前我想给一个微服务项目画架构图打开 draw.io 手动拖了三个小时丑得像个毛线团还漏了缓存层。后来看到 Archify30k Stars这个项目全程只用一条提示词把整个系统架构描述丢给大模型它就还给我一个能点击、能缩放、能高亮的 HTML 交互式架构图。折腾完我只想说一句这玩意儿解决了架构师、后端、还有我这种懒得画图的人的真实痛点。Archify 是个国产独立开发者的开源作品核心思路不是做一个画图软件而是“教” AI 用 HTML/CSS/JavaScript 自己画出可交互架构图。它把整个方法论封装成一条提示词或者说一个 Skill你只要负责描述系统长什么样剩下的排版、连线、交互、配色AI 全部搞定。这篇就把它从头到尾讲透它是什么、怎么安装、提示词背后的设计逻辑、交互图是怎么生成的、实测会遇到哪些坑以及这个东西对 AI 应用开发的启发。1. 为什么架构图这么难画从“画图工具”到“生成图”的思路转变先聊一个基础问题画架构图到底难在哪如果你只用过 PlantUML 或者 Mermaid一定见过那种“节点全挤在一起、箭头交叉到怀疑人生”的效果。传统工具的问题在于“画布思维”——所有坐标、布局、连线都靠手动控制一旦图复杂起来人类就变成了 PPT 排版工。1.1 传统画图方式的三种痛我简单归纳下以前画架构图遇到的三种情况工具门槛直接上手 draw.io / Visio你得理解图层、容器、锚点、连线样式中间还有一堆快捷键要记。学十分钟能画学一百小时也画不精致。维护成本架构是活的今天加了消息队列、明天改了认证服务图不更新就开始误导人。手动改一次图的成本比写代码还高。沟通效率静态 PNG 没法交互你给团队讲解时只能指着屏幕说“这里对就这条线”对方一脸茫然。1.2 AI 生成架构图为什么是另一个思路传统思路是“人画图、机器导图”AI 时代思路变成“人描述、机器作图”。你只需要提供系统里有什么模块、模块之间什么关系AI 自己决定布局、配色、连线和交互。Archify 能做到这件事本质上是因为它只输出一个自包含的 HTML 文件。这个文件内部嵌入了 CSS 和 JavaScript不依赖任何外部框架。AI 大模型本身就在 HTML/CSS/JS 的代码生成上有很强能力所以“架构图”被重新定义成了“一个可视化网页”而不是一张不可编辑的图片。提示Archify 的关键不是“画图”而是“生成一个自带交互能力的微型应用”。这就是它和 Mermaid、PlantUML 路线最大的分水岭。这个思路转换很关键。当你把架构图当作网页来写交互能力就变成一个纯前端问题AI 能轻松处理当你把架构图当作图片来画每一步都得靠人指挥。后来的实践也证明这条路线让架构图的质量上限和可维护性都远超传统方式。2. Archify 项目速览30k Stars 是什么概念先说结论一个国产独立开发者的项目能到 30k Stars在开发者圈子里已经属于“现象级”。这个量级不仅说明用户需要它更说明它切中了 AI 应用开发中的普遍需求场景。2.1 一个提示词项目的构成Archify 不是一个 GUI 软件也没有安装包。它本质上是一个提示词文件集合附带使用说明和示例。核心文件是SKILL.md或者类似命名的提示词定义里面定义了 AI 在画架构图时的完整行为规范。它的工作方式大概是这样你向 AI比如 Claude发送一条触发指令AI 读取SKILL.md中的规则识别你描述的系统架构AI 按规则生成一个完整 HTML 文件包含样式、布局和交互脚本你用浏览器打开 HTML就能看到一张可拖拽、可点击、可高亮的架构图。整个过程中“一条提示”承载的是方法论而架构描述本身是你的输入。这套模式的好处是不需要安装运行时不需要网络服务跨平台甚至离线可用。2.2 为什么它能拿到 30k Stars我复盘了 Archify 能火的外部原因正好撞上 AI 编程工具爆发期Claude、Cursor、Trae 这类工具的流行让“提示词”成为生产力的一部分大家迫切想知道怎么把大模型用在真实工作流里架构图是刚需后端、前端、运维、甚至产品经理都要画架构图这个需求极度普适结果可感知输入文字输出可交互的漂亮图表这种“哇塞”效果天然适合病毒传播国产开发者身份加持中文开发者看到国产项目也能在 GitHub 上大放异彩自然愿意贡献星标支持。不过星星多不代表没坑。等你实际用起来才会发现提示词在不同模型上的表现差异巨大。这个后面我单独开一节细说。3. 从零上手Archify 在 Claude / Trae / Cursor 里的安装与调用这部分是动手环节。我假设你已经装好了 Claude Desktop 或任意一款支持 Skill/MCP 机制的 AI IDE比如 Trae 或 Cursor。Archify 的安装过程本质上就是把它的 skill 目录放到 AI 工具指定的目录下。3.1 Skill 机制与普通提示词的差别很多人不理解为什么非要搞一个 Skill直接复制一段 prompt 粘贴进对话不行吗我的理解是这样普通提示词是“一次性”的你每次使用都得重新粘贴AI 对上下文的理解也会偏移。而 Skill 是一套持久化、结构化的行为定义它放在固定位置AI 在需要时会自动读取并遵守。相当于你给 AI 配了一份“岗位手册”而不是每天叮嘱它一次。有了这份手册AI 会按照固定的流程生成架构图输出风格也更稳定。比如它知道自己第一步要解析模块清单、第二步确认依赖关系、第三步生成 HTML这样就不会像普通聊天一样把步骤乱掉。3.2 实际操作流程以 Claude Desktop 和 Trae 为例大致步骤如下从 Archify 仓库下载 skill 目录一般是archify-skill/在 Claude Desktop 的配置目录里找到 skills 文件夹没有就新建一个把目录复制进去重启 Claude Desktop让它重新加载 skill 列表在对话里描述你的系统架构例如“我有一个电商系统包含 Nginx 网关、认证服务、订单服务、支付服务、MySQL、Redis订单服务依赖支付服务和 MySQL……”触发 Archify skill 的指令AI 开始工作几秒后它输出一个 HTML 文件你保存并打开浏览器查看。如果你用的是 Trae 或 Cursor 这类 AI IDE逻辑也差不多只是配置目录的位置不同。有的 IDE 支持直接在插件市场搜索“Archify”有的需要手动指定目录具体看当前 IDE 的文档。3.3 关于“archify怎么用在trae”的实操补充不少人在热词里搜“archify怎么用在trae”因为 Trae 在国内比较方便。我试过的方案是在 Trae 的项目配置目录放 Archify 的 skill 文件然后在对话框里直接输入架构描述。如果用/archify这类斜杠命令没有生效多半是 skill 目录路径不对或者文件名不是 Trae 识别的标准命名。注意Archify 依赖的模型必须支持长上下文和代码生成能力老模型或者参数太小的模型效果会差很多经常出现布局乱、脚本无效的情况。实际使用中我发现让 AI 生成完整的 HTML 文件比让它在聊天里画 ASCII 图靠谱得多。这也是 Archify 设计的高明之处利用 HTML 天然的布局能力而不是让模型自己计算坐标。4. 一条提示词的内部拆解Archify 的提示词工程做了哪些事Archify 最核心的资产不是代码是那条设计精巧的提示词。我结合公开资料和自己的测试把它的提示词工程套路拆成几层方便你理解它为什么有效。4.1 角色与目标设定先给 AI 立规矩提示词开头必定包含类似这样的句子“You are an expert software architect and front-end developer.” 这看似简单实际作用很大。大模型的输出风格会跟随角色设定变化当它认为自己是“架构师 前端专家”时生成结果会不自觉地向专业排版和交互设计靠拢。同时提示词会明确“目标”根据用户描述生成一个交互式 HTML 架构图。目标越明确模型越不容易发散成“顺便给我讲讲微服务是什么”这类无关内容。4.2 输入解析层把自然语言架构转成结构化数据这是最精髓的部分。Archify 的提示词要求 AI 在动手画图之前先把用户描述解析成一个中间数据结构。比如{ nodes: [ { id: nginx, label: Nginx Gateway, type: gateway }, { id: order, label: Order Service, type: service }, { id: mysql, label: MySQL, type: database } ], edges: [ { from: nginx, to: order, label: HTTP }, { from: order, to: mysql, label: SQL } ] }这一步的重要性在于先让 AI 做“理解”再做“表达”。直接把需求丢给 AI 让它画等于让一个设计师同时承担产品经理和程序员的工作很容易翻车。而强制生成中间 JSON相当于先把系统模型理清再生成可视化代码输出稳定性大幅提升。4.3 输出约束层统一技术栈和文件格式提示词里会有类似约束“只输出单个 HTML 文件内嵌 CSS 和 JavaScript不要引用外部 CDN不要使用框架文件必须能在浏览器中直接打开。”这个约束解决了两个问题可移植性单 HTML 文件意味着你把它发给谁都能打开不依赖网络和 Node 环境可控性不用 React/Vue模型不需要生成复杂组件代码减少 bug 概率。交互能力则通过原生 JavaScript 实现比如鼠标 hover 高亮周边节点、点击节点展开详情、滚轮缩放画布、拖拽节点等。原生 JS 的写法对大模型来说训练数据够多、生成难度低出错率可控。4.4 分步引导层把画图过程拆成多个子任务Archify 提示词中很可能包含类似“先列出所有节点再确定依赖关系然后规划布局最后生成代码”的分步指令。这种“思维链”式的引导能显著提升大模型的规划能力。我拿一个 8 节点 10 条依赖的架构做过对比直接说“请画出架构图”AI 给的布局基本靠猜节点重叠严重用 Archify 的分步引导节点分组、层级关系、连线路径明显更有条理。原因是模型分步思考时每一步的注意力更集中相当于把一个复杂任务降维成几个简单任务依次执行。4.5 校验与自我纠错层让 AI 自己检查部分版本提示词会要求 AI 在生成完毕后做一次自查检查节点有没有遗漏、连线是否正确对应、交互事件是否绑定。这种“自校验”机制虽然不能保证 100% 正确但能明显减少低级错误。5. 交互式架构图的真实形态与实现原理Archify 生成出来的 HTML 到底长什么样我实际用下来说几个共同特征也讲讲背后的实现原理。5.1 布局方式绝不只是绝对定位很多人以为 AI 画图就是生成一堆position: absolute的 div然后连线用 SVG。这确实是一种做法但高质量的生成会采用更聪明的布局比如 CSS Grid 或 Flexbox 实现服务分组。实际效果是整个图分成多个区域比如网关在最上层、服务在中间层、数据存储在底层同层服务水平排列区域之间用容器框住。这种分层布局不需要精确计算像素坐标AI 只需要决定“哪个节点放在哪个容器里”排列交给 CSS 完成效果更稳定。5.2 连线方式SVG 与 Canvas 的取舍Archify 生成的图中连线通常用 SVG 实现。SVG 对 AI 来说比较好生成每个line或path都带明确属性修改起来也容易。复杂的依赖连线还会用贝塞尔曲线视觉上比直线更美观。Canvas 方案能驾驭更复杂的交互但代码量大、调试难AI 生成的 bug 率较高。所以 Archify 倾向 SVG 是合理的取舍够用、好看、可控。5.3 交互能力高亮、缩放、拖拽、详情面板交互式架构图比静态图强在哪我给你列举实际体验Hover 高亮鼠标悬停一个服务节点它和所有关联节点、连线会高亮其余部分变暗。给人讲解时视觉焦点非常清晰缩放平移架构图一大局部细节看不清你可以滚轮缩放、拖动画布想象成浏览地图点击详情点击节点弹出详情面板显示该服务的职责、依赖、端口、数据库表等这个信息其实也是从你的描述里提取的搜索定位部分版本支持输入关键字定位节点大架构图里的查找效率极高。这些交互看着花哨实际上全是标准 DOM 事件和 CSS 样式切换加起来不过 100 多行 JS。对主流大模型来说生成这种代码已经非常成熟。5.4 离线可用一个 HTML 打完所有我特别喜欢 Archify 的一点是最终产物是一个.html文件。没有服务器依赖、没有第三方 CDN、没有 Node 包你甚至可以在没有网的内网环境打开它。对于一个架构图来说这种交付方式堪称优雅。6. 实测踩坑实录我用 Archify 生成架构图时遇到的五类问题工具好用不等于没坑。我在多个模型和多个场景下实测把最容易翻车的五类问题列出来给你省点时间。6.1 上下文窗口不够导致输出被截断这是最频繁的问题。一个复杂系统可能包含二十多个节点HTML 生成后轻松超过 2000 行。如果模型上下文长度不够或者单次输出 token 有上限文件会中途被截断浏览器打开后白屏。我的经验是先用小架构测试确认当前模型的输出上限对超大架构手动拆成“核心层 外围依赖”两个部分分别生成再用一个总览页把两张图嵌进去。不要试图一次生成完整系统图。6.2 中文字体与乱码问题默认情况下AI 生成的 HTML 可能不指定中文字体导致依赖系统字体渲染在 Windows 和 Mac 上观感完全不同。部分情况下架构描述里的中文服务名会变成乱码。解决方式在提示词里手动追加“使用系统默认中文字体文件编码为 UTF-8并在head中声明meta charsetUTF-8”。实测加上这些约束后中文渲染问题基本消失。6.3 布局重叠与节点覆盖当你的系统有大量微服务且依赖关系复杂时模型生成的绝对定位节点很可能互相重叠。尤其是“服务 A 同时依赖服务 B 和 CB 和 C 又在不同容器里”的场景连线路径很容易穿墙。我的建议是在描述架构时显式地分组说明比如“订单模块内部包含订单服务和库存服务支付模块内部包含支付服务和对账服务”。让模型理解分组它就会用容器来隔离节点重叠概率大幅下降。6.4 交互脚本不生效有些模型的 JavaScript 生成能力较弱生成出来的 HTML 打开后页面是好看的但点击、拖拽完全没反应。问题通常出在事件监听代码错误、DOM 元素 ID 不匹配或重复定义。排查思路很简单按 F12 打开 DevTools 的 Console 面板看有没有报错。我遇到的报错大多是getElementById返回 null原因就是 HTML 结构和 JS 中引用的 ID 不一致。给 AI 一个纠错指令“检查所有 getElementById 引用的 ID 是否存在于 HTML 中”通常能修复。6.5 模型之间效果差异大同一个 Archify 提示词在 Claude 上效果最好在部分国内模型上表现就比较拉胯。原因是生成 HTML CSS JS 的综合任务对模型的代码能力要求很高。注意Archify 不是“万能画笔”它的上限由底层模型决定。如果你用了较弱的模型建议先完成架构解析 JSON 这一步把 JSON 交给擅长前端代码的模型去生成 HTML也是一种降级方案。7. 从 Archify 看独立开发者的机会提示词工程的商业化路径Archify 的火爆不是偶然它给独立开发者提供了一个很清晰的样本用提示词工程包装一个通用需求做成 Skill/插件形态通过开发者工具分发。7.1 Skill 生态是一片新蓝海传统软件生态是“安装 App”AI 时代的新生态是“安装 Skill”。一个 Skill 本质上是结构化知识 提示词 工作流。它的开发成本远低于传统 App不需要账号体系、不需要服务器、不需要应用商店审核分发路径就是 GitHub 仓库。独立开发者完全可以借鉴 Archify 的模式把某个垂直领域的工作流封装成 Skill。比如“一键生成数据库设计文档”“一键做 API 接口测试”“一键生成 K8s 部署方案”这些都是程序员日常重复劳动市场空间非常大。7.2 国产开源项目出海的标杆意义Archify 用 30k Stars 证明了一件事国产独立开发者不必只做中文市场只要切中通用痛点GitHub 全球开发者都会买单。架构图是一个国际通用的需求Archify 的英文提示词天然适配全球用户这是它能在 GitHub 拿到高星的一个重要原因。7.3 可复制的产品化公式从 Archify 身上能提炼出一个可复制的产品化公式找到一个高频刚需场景画架构图设计一套结构化提示词流程解析 → 建模 → 生成 → 校验定义统一的输出格式自包含 HTML封装成 Skill 或插件发布到 GitHub 和 AI 工具生态持续迭代提示词适配更多模型。这套方法论不限行业产品经理也可以做“一键生成 PRD 文档”的 Skill运维可以做“一键生成排查手册”的 Skill设计师可以做“一键生成设计规范页面”的 Skill。根据我个人的体验做完 Archify 的尝试之后最大的收获其实不是多了一个画架构图的工具而是对“提示词也可以成为产品”有了实感。过去我们瞧不起提示词觉得那是“ChatGPT 的雕虫小技”现在看到 Archify 用一条提示词做出 30k Stars、无数人集成到自己的工作流里你就会明白真正值钱的不只是模型能力还有把模型能力组织成清晰工作流的方法。最后再分享一个实用建议如果你准备在自己的项目里用 Archify别直接照搬默认提示词务必在架构描述前加上“请先输出节点清单和依赖清单确认之后再说”这一步能帮你提前挡住一半以上的信息描述错误。等跑通第一个案例后再逐步调整配色、布局方向和交互细节把 Archify 调教成你自己的架构图引擎。