画架构图这件事我几乎每周都要碰上一次。新项目启动要画系统拆分要画跟团队对齐技术方案要画甚至给新人讲业务模块分布也得画。说实话画图本身不累累的是画图之前那段把需求嚼碎、把模块边界划清楚、把依赖关系理顺的思考过程。这张图的价值也从来不在线条和框体本身而在里面承载的系统设计决策。最近我一直在折腾archify这套AI架构图生成Agent技能一个很直接的感受是它跟我以前用过的那些AI生成架构图小工具完全不是一回事。以往的工具更像翻译器你给它一段描述它把这段描述翻译成一张拓扑图AI本身并没有真正理解系统的结构而archify给我的感觉更像一个系统设计助手你告诉它业务场景它先自己推导出需要哪些模块、模块之间是什么关系、数据流向怎么走最后才落到一张可编辑的架构图上。很多人搜archify怎么用、archify skill其实问的本质是同一个问题它到底是靠什么机制做到这件事的我在自己的项目里怎么把它跑起来。这篇文章不会去念说明书我直接把我完整的使用过程、踩过的坑、以及我调试提示词时候的一些思路摊开讲你会看到它从需求到架构图的完整链路是怎么工作的也顺便聊聊我在实际场景里对它的评价。1. 画架构图真正的瓶颈不在画而在想清楚先聊一个稍微有点反直觉的结论架构图生成的难点从来不是渲染代码的语法也不是流程图的长宽比例而是从模糊需求到清晰结构的那一跳。1.1 传统AI画图工具到底卡在哪我之前试用过几种基于文本生成架构图的工具工作逻辑基本都类似你写帮我画一个订单系统的架构包含Nginx、Spring Boot、MySQL、Redis它就乖乖地把这些节点码出来连上线生成一张图。产品看起来没什么问题用起来却总觉得哪里不对劲。后来我想明白了不对劲的地方在于这个过程里没有任何一步在设计。你把每个模块的名字直接告诉它它只不过是个抄写员真正做架构决策的人还是你。可如果我已经连要画哪些组件、组件间是什么关系都想清楚了那我自己打开绘图工具拖几个框就够了为什么要绕道让AI生成呢所以这类工具一直处在一个尴尬的位置——对不会画图的人有点用对真正做架构设计的人用处不大。真正有价值的AI架构图生成应该要能帮人类完成一部分设计推导的活儿给它一句话场景描述它能自己判断这个系统大概需要哪些层、要不要引入消息队列、数据存储怎么选型、哪些模块需要做水平扩展这些决策链条上的一环。只有当它先学会了想清楚再谈画出来才有意义。1.2 Agent技能这个形态意味着什么archify之所以给我的体验和以前那些工具有本质差别核心就在于它的定位不是一个单向工具而是一个Agent技能。这个区别从产品形态上就能感受到使用archify的时候我不是一次性丢给它一个完整提示词然后收图而是像在带一个实习生做设计——我先描述需求背景和目标它会追问有关键信息会主动说明它计划用什么方式组织架构然后分阶段产出结果。在这个互动过程中它并不是在执行文本转图表的固定映射而是在执行一套可拆解的工作流解析需求、识别业务实体、规划模块边界、定义服务依赖、设计部署拓扑、生成绘图代码。每一步都有独立的推理空间也允许我随时介入修正。这种形态的本质价值是把架构图生成从一次性生成任务升级成了可交互的设计过程。我用它来做事的时候可以获得的不只是一张图还能看到这个Agent对系统设计的整套理解路径。这对架构评审特别有用——我可以顺着它的推导去检查哪里遗漏了哪里设计得不合理而不是对着最后的结果图干瞪眼。所以如果你搜索archify skill是想要找到一个软件安装包可能会扑个空如果你理解成一套让AI获得架构设计能力的技能模板就踩到它真正的设计点了。2. archify把模糊需求变成架构图的全过程拆解既然定位是Agent技能那么要弄懂它、用好它就必须掀开它的工作流看看。我在实际使用中反复对比过它处理不同类型需求时的输出路径基本可以归纳成四个阶段。每一个阶段如果出了问题最后那一步的图都会废掉。2.1 需求解析为什么它比我预想的更会追问我第一次用archify的时候输入的需求是我要做一个博客系统支持多作者、标签、评论还要有流量统计。我本以为它会直接开始画图结果它先反问了我几个问题这个博客系统预期的读者规模大概多少是纯静态展示还是需要后台管理评论是否需要实时性流量统计是统计页面访问量还是用户行为分析维度当时我有点意外但这种追问恰恰是架构设计中最重要的环节。这就是我前面说到的它的推理链在入口处就已经启动了如果不确定规模量级后面的服务拆分、缓存设计就无从谈起如果不确定评论的实时性要求就无法判断要不要引入WebSocket或者消息推送。它不是在做表面形式的问答而是在用做系统设计的思路把决定架构形态最关键的那几个变量捞出来。对于我们使用者来说这个阶段最重要的提醒是别嫌它烦。它每追问一个问题都是在为后面的模块划分和拓扑推导收集决策依据。如果它问的问题数量骤减输出图反倒容易变得看起来结构齐全但总差点意思。2.2 架构推导从业务实体到模块边界的推理过程拿到需求约束之后archify会进入核心的架构推导阶段。这一步从外部看不到太多过程只能看到它分步骤输出的设计说明但我通过反复修改输入、观察输出差异大致还原出了它内部的推理链条大致是这样的第一步从需求描述中提取业务实体和核心操作。拿博客系统举例这里会抽取出作者、文章、标签、评论、访问记录这些实体以及发布文章、打标签、发表评论、统计访问量这些动作。第二步按职责相似度和变化频率对这些实体做聚类。比如文章和标签属于内容域评论单独作为互动域访问记录天然就是数据分析域。这一步的产出就是模块划分的依据。第三步分析每个域之间发生交互的路径和方式。博客的前端页面需要同时聚合内容和评论数据那么评论模块需要向内容模块暴露接口流量统计数据不需要同步生成那数据分析模块就可以通过异步管道去消费数据不必耦合在主请求链路上。第四步推演技术组件的角色。什么时候介入缓存、要不要用消息队列、数据库需不需要做读写分离这些都是跟着前两步的业务特征顺出来的而不是套模板套出来的。这一步是archify的推理精度和简单工具拉开差距的地方。简单工具只会做实体到节点的浅层映射不会去分析文章模块和评论模块之间到底应该是同步还是异步关系。Archify则会把关系类型区分出来在输出图里用实线、虚线、带箭头或不带箭头这种不同视觉方式来呈现。2.3 渲染建模架构图数据结构的底层设计推理完成之后archify需要把抽象的架构设计翻译成渲染层可消费的标准化结构。在这个环节它内部构建的架构数据模型非常关键——虽然用户看不见但它决定了这张图能不能自由编辑、能不能局部调整。我现在用下来的感受是archify处理架构图数据的方式接近一个带层级关系的组件树。顶层可能有应用层服务层数据层基础设施这样的逻辑分区每个分区下面挂具体的模块或服务节点节点上记录技术栈、职责描述等属性节点和节点之间单独维护连线关系。这样组织有一个突破性的好处我想在生成后加一个模块只需要单独插入一个节点并补齐它的连线关系不用把整张图重新生成一遍而不带中间模型的工具每次改动都是全局重绘越改越乱。2.4 绘图代码生成为什么它选择面向生态输出archify最后一个环节才是真正画图。它并不会生成一张位图JPG直接丢给我而是输出一套结构化的绘图描述代码再交给渲染器解析成图。我用的是基于Mermaid语法渲染的模式它的输出会按照我配置的渲染格式输出对应格式代码。这里面的设计考量很值得一说输出描述代码本质上是在输出结构与关系而图片只是这份结构与关系的一种可视化呈现。这意味着同一份架构设计可以适配不同的渲染器、可以放到文档系统里做版本管理、可以参与代码评审差异对比——这些能力是静态图片完全不具备的。我第一次看到它输出代码而不是图片的时候还觉得多了一步很麻烦等到我真的把几十张架构图纳入文档库做版本管理的时候才意识到这个选择有多明智。3. 环境准备与安装从零到跑通的实际过程聊完原理进入动手环节。ARCHIFY现在是作为一个Agent技能来分发的所以我先把环境准备这块的要点列出来再讲我实际走过的安装流程。3.1 底座环境它依赖什么样的运行容器Archify不是独立桌面软件它的运行需要依托支持Agent技能机制的AI运行环境。简单理解就是你得先有一个宿主archify作为一项技能被宿主加载出来后才能发挥它的架构图生成能力。这和装插件有点类似——先有一个主程序再往主程序里挂载功能模块。我个人的建议是优先选择支持自定义技能包或支持Agent工作流的运行环境。你可以在配置目录下新增技能描述文件夹然后把archify技能包的文件放进去重启会话后即可识别。3.2 我的加载过程和潜在坑位我的实际操作流程不复杂几步就完成了第一步确认宿主环境的版本支持技能机制然后在本地用户目录下找到技能目录。我是在个人项目里以手动方式放置的如果是团队协作场景通常会放进统一的配置仓库里由管理员分发。第二步下载archify安装包或技能的归档压缩包解压到技能目录下重要是保留目录结构Agent技能通常会从指定文件读取技能描述、参数定义和输出模板目录不完整会导致加载失败。第三步重启宿主环境在对话中触发技能关键字看到archify进入激活状态后就说明加载成功了。整个过程中相对容易踩坑的点是路径不正确或权限不够。技能目录如果被系统安全策略拦住了读写权限会导致Agent无法加载技能包中的任何配置但是宿主环境又不会蹦出明确的错误提示表现出来就是我叫了它半天它毫无反应非常迷惑。我当时就被这个坑了大概十分钟后来检查运行日志才发现是技能目录变成只读了。所以要提醒你装好之后如果发现技能没反应先不要怀疑技能包有问题去检查宿主环境和技能目录的权限八成是这个原因。4. 实战演示从一句话需求到一张可编辑架构图环境准备好之后我用实际案例走了一遍完整链路。很多人在搜索archify怎么用我觉得看完这一段案例基本就能有数了。4.1 我给它的初始需求与约束条件为了测试它在复杂场景下的表现我这次没有选那种规模太小的需求而是模拟了一个典型的业务系统设计任务一句话需求设计一个支持多租户的订单管理后台租户可以自定义订单字段和审批流程平台需要提供审计日志。附加约束要求前期控制成本尽量用单体加模块化的方式不要一上来就微服务但架构要考虑后续可拆分性。我刻意在需求里埋了两个有张力的约束多租户自定义和前期单体。前者天然会诱导人走向复杂的隔离设计后者则要求克制。一个好的架构设计Agent应该在二者之间找到平衡点而不是一味堆技术组件。4.2 它产出的模块划分和推导逻辑archify收到这个需求后先按我前面说的流程确认了一些关键变量租户规模大概在什么量级自定义字段是否需要参与数据库查询工作流的审批节点复杂度如何审计日志的保留周期和查询方式。这轮追问结束之后它给出了一个很务实的方案——采用共享数据库加共享Schema的方案但用租户ID做数据隔离并增加行级安全策略。考虑到成本限制这个选择我认为是合理的。在模块架构上它把系统划分成了这些模块租户管理模块负责租户注册、套餐配置、数据隔离规则生成。字段自定义引擎把租户自定义字段的元数据独立管理持久层用JSONB或扩展字段方案避免频繁改表。流程引擎模块负责用户自定义审批流的解析和执行和订单模块之间是接口调用关系。订单核心模块负责创建订单、修改、查询对外接口要兼容不同租户经过自定义后的数据结构。审计模块通过事件发布与监听的方式收集操作日志和订单主链路解耦。这个划分一眼看上去并没有特别出奇但妙处在细节——我注意它把字段自定义和审批流程都做成了独立的模块而不是塞进订单模块里。这就是在服从那条后续可拆分约束。如果一开始就把自定义字段揉进订单模块后面演进成独立服务时必然要经历一次痛苦的手术现在模块边界已经备好了以后拆分只是把模块升级为服务的问题。4.3 连线关系设计与可视化结果模块划分完下一步是连线关系与数据流设计。它输出的架构图里连线大致分成了几组关系类型同步调用关系客户端调用网关网关分发到订单核心模块订单模块调用字段自定义引擎获取租户Schema信息。这一组连线用实线箭头表示代表实时强依赖。异步事件关系订单状态发生变化后订单模块发出领域事件审计模块监听并落库。这组连线用虚线箭头表示代表非实时弱依赖。数据访问关系字段自定义引擎和订单模块同时访问共享数据库但访问的数据表范围不同。这两条连线的语义是共享存储但职责分离。实际渲染出来的图分成了前端层、网关层、核心业务模块区、异步事件通道、共享数据区几个大的分区视觉上层次分明。我把生成结果同步给团队伙伴看结构能直接拿去做评审底稿。这就是我在前面说的可交付的架构图——不是AI画给自己看的示意稿而是可以拿到正式会议上去讨论方案的基础版。5. 调试提示词的经验几次失败输出的教训用得多了自然也会遇到生成结果不理想的时候。这也是Archify这类Agent技能必须经历的一关它推理能力强但如果输入问题时信息不足输出也会走样。我这边总结了几次印象深刻的失败过程和调整方法供你在实际使用中参考。5.1 当它把架构设计得过度复杂第一次我用它设计一个内部运营工具的后台只丢给它一句做一个运营后台支持活动配置、用户筛选、数据报表。结果它给我输出了一张包含十几个微服务节点的架构图连Kubernetes集群、服务网格都画上去了。对于一个内部运营后台来说这简直是用牛刀杀鸡团队看到这个方案怕是要骂人。我观察了一下原因发现问题出在需求里缺少了使用规模和部署约束这两类信息。一个日活几百人的内部系统和一个日活百万的 C端系统架构形态当然天差地别。那之后我养成了一个习惯输入需求时主动把系统的用户规模、部署环境、可用性要求这些隐含约束写清楚。比如在上面这个场景里我会追加一句预期用户为内部员工约200人部署在公司内网无高并发场景要求架构简洁易维护。加了这句之后它的输出立刻收敛了很多回来的是单体应用加一个任务调度模块的轻量方案。5.2 它把逻辑架构和部署架构混为一谈另一个比较常见的失败模式是archify在画图时会把逻辑架构和部署架构的节点混在同一个图层里。比如说它可能把一个代表用户认证服务的逻辑模块和一台代表应用服务器的部署节点画在了一起导致图里既不是纯逻辑分层也不是纯物理拓扑。出现这种情况通常是因为我给它下达的指令里同时混着业务模块和基础设施部署的词汇而我没有指定视角。调整的方法很简单在需求里明确这次的架构图的视角类型。如果你想表达的是模块职责和接口关系那就明确要求按逻辑架构视角输出忽略物理节点和部署细节如果你想表达的是服务器和环境拓扑就写清楚按部署架构视角输出侧重网络分区与中间件节点。5.3 节点粒度不统一让我反复返工还有一次让我比较难受的是节点粒度不一致。它画的图里有些模块被拆得很细比如支付模块里单独拆了订单支付、退款、对账三个子节点但另一个同样复杂的库存模块却只有一个笼统的大节点。这种粒度不统一直接导致整张图的信息密度忽高忽低读图的人很难判断作者想强调什么。我排查之后发现这个问题出在最初的需求描述对关键模块的侧重没说清楚。我在需求里花了不少笔墨描述支付流程细节但对库存模块只是一笔带过它自然就会把它识别为重点展开对象细节拆得深。如果我希望所有模块粒度保持齐整就得在需求阶段做一次模块列表明确告诉它以下所有模块都只展开到一级子模块。加了这层约束后输出的一致性明显改善。6. 一些具体的使用心得与边界认知前面讲的都是它的能力和调试方法最后我想分享几个相对主观的使用心得以及在使用中意识到的能力边界。6.1 什么场景下它真正省时间我用下来的感受是archify在面对从零开始的项目设计以及需要产出多视角方案对比这两类场景时价值最明显。从零开始的项目意味着没有历史包袱它能顺着需求直接给出结构完整的第一版架构这版架构也许不是最优的但作为讨论起点非常合格需要多视角方案对比的时候它可以用同样的需求分别生成低成本方案高可用方案可演进方案然后我再做比较比我自己手动画三张图要高效得多。但如果是要把一套已经运行多年的老系统用架构图的方式反向还原出来它的价值就会大打折扣。因为它擅长的是基于需求推理应该是什么样而不是通过阅读代码去归纳实际是什么样。对老系统我建议还是用静态代码分析工具去扫描依赖关系再把结果喂给它做视觉化整理或者你把实际代码模块纳入提示词里它才会生成更准确的表达。6.2 和传统绘图工具之间的工作流衔接我现在的工作流已经比较固定先用archify生成一版结构化的描述代码把它存进项目文档仓库里作为源头文件所有架构调整都改这份描述代码再用渲染器导出用于不同场合的展示图。会议上有时候需要临时改个模块我也直接在描述代码里调整后重新渲染整个过程不到一分钟非常顺手。这比我之前用绘图软件按住鼠标拖框的方式效率高太多了更重要的是架构图的源文件从二进制格式变成了可读可改的文本格式可以参与代码审查也可以做差异比较。6.3 它的定位终究是辅助设计不是取代设计回到标题很多人纠结archify是Tool还是Agent我自己的理解是AI Agent是否名副其实看的就是它在设计环节是否介入决策。从这点看Archify确实做了一些Agent该做的事情——它会推理、会追问、会自行判断该用同步还是异步、该拆几个模块而不是被动地等人喂给具体组件清单。但同时我也清醒地认识到高质量的架构设计离不开对业务场景的深刻理解和对团队技术栈的熟悉这些是任何Agent都不具备的上下文。我拿它产出的方案都会再花时间做一轮局部的权衡和精简把不合适的模块合并把缺失的边界补上。Archify帮我把草稿设计的时间压缩了一大半让我能把精力放到那部分真正需要人类经验的取舍判断上去。在我个人这几次实战体验里印象最深的是它以追问需求来开场的方式——大多数号称能画架构图的工具从来不会问我要画什么规模的系统。如果你正准备把它引到自己的工作流里我的建议很简单别怕跟它多聊几轮需求给的信息越像你给团队里资深开发交代背景那样完整画出来的图就越能用。先在一个没那么多历史包袱的新项目上试几次摸索清楚它的推理习惯然后再慢慢把它放到更复杂的架构梳理场景里去它大概率能帮你省下来的时间远比你会花在调试提示词上的时间多得多。
