尧图网站建设 
AI画架构图这事圈子里一直有个心照不宣的痛点生成的图看着像那么回事但真要拿去评审、进设计文档、指导开发又总觉得哪里不对。有的图是模块划分逻辑混乱有的图是缺了关键的数据流向有的图干脆把技术栈都画错了。修修改改半天最后还不如自己从白纸开始画来得快。我前段时间在折腾 AI Agent 辅助架构设计也一直在思考怎么解决这个问题。我的思路是与其纠结怎么让模型一次画对不如反过来给它加一条验收流水线——用自动化的规则去校验 AI 生成的架构图不合格就退回重画直到它真正满足约束条件为止。这就是 archify 这个项目要做的事也是这篇文章想完整拆解的东西。archify 不是什么玄学工具它做的事情一句话能说清楚给 AI 画架构图的过程加一个可执行的验收环节让输出从看起来合理变成验证过合理。这篇文章我会从问题根源、验收流水线的设计思路、具体规则实现、以及实际落地时容易踩的坑这几个角度把整套方案完整讲透希望对正在做 AI 辅助架构设计、或者对 AI Agent 工程化感兴趣的朋友有帮助。1. 总差点意思的本质AI 画架构图缺的不是绘图能力是验收回路先把这个问题的根源掰开来看。很多人在抱怨 AI 画架构图不靠谱但其实画图这个动作本身对现在的 LLM 来说已经不是瓶颈。Mermaid、PlantUML、Graphviz 这类 DSL 语言的生成模型已经学得很扎实语法错误率其实很低。真正的问题出在另一个地方AI 没有对自己画出来的东西进行架构合理性校验的能力闭环。1.1 从需求描述到架构图的语义失真链路你给 AI 输入一段需求描述它输出的架构图中间经历了好几次转化自然语言理解 - 关键要素抽取 - 模块划分决策 - DSL 代码生成。每一步都可能引入语义失真。举一个真实场景。我让 AI 设计一个订单系统的微服务架构需求描述里有这么一句订单服务需要支持拆单拆单后的子订单需要独立流转。结果 AI 生成的架构图里只在订单服务内部画了一个拆单模块完全没体现子订单独立流转所需的消息队列、子订单状态机服务、以及后续的履约对接服务。从绘图的角度看这张图没毛病语法正确、布局规整。但从架构的角度看它就是一张废图——关键的业务语义丢了。这就是总差点意思的第一个来源AI 默认只做最小成本的语义补全它不会主动深挖需求背后的架构诉求。1.2 架构图质量的两个不同维度要真正解决这个问题必须先区分两个维度语法正确性DSL 能否正确渲染成图节点、连线关系是否合法这个 LLM 天然做得不错。架构语义完整性这张图是否完整表达了需求里的业务语义模块划分是否合理关键路径、数据流向、外部依赖是否完备大部分人的挫败感不是来自第一个维度而是第二个维度。语法对了、图也出来了但架构设计得对不对、全不全没人帮我们把关。所以我在设计 archify 的时候定了这么一条原则不要试图提升 AI 画图的能力而是提升 AI 自检的能力。具体做法就是给它加一条可执行、可量化的验收流水线。1.3 为什么纯靠对话式帮我看一下不够用可能有人会说AI 画完图我让它自己检查不就行了我在实际使用中试过效果非常不稳定。原因在于让 AI 自己评审自己等于让它做一次没有题目答案的自我批改——它只会基于自己已有的生成逻辑再完善一下很难跳出自己的思维惯性。比如漏掉的拆单语义你让它自查它大概率说图已经完整覆盖了需求因为它的完整标准和我们期望的完整标准根本不在一个维度上。这就需要一个外置的、确定性的校验机制用一套固定的规则去检查它的产出类似于 CI/CD 里的单元测试。没有这套外置校验回路AI 画图就永远是盲画质量全靠运气。提示想让 AI 产出稳定的架构图核心思路不是换更大的模型、写更长的提示词而是加一条确定性规则的验收回路让不确定的 AI 输出被确定性的规则约束住。2. archify 的验收流水线设计分层校验 自动重绘闭环确定要加验收环节之后接下来的问题是验收流水线长什么样校验哪些东西不合格之后怎么处理我最初的想法很朴素——就是输出后跑一堆检查规则不通过就报错完事。但实际做下来发现光报错没用AI 不知道怎么改你还得把错误原因转化成它能理解的修改指令让它重新生成。所以 archify 的流水线是校验-反馈-重绘的闭环设计。2.1 验收流水线的整体架构整个流水线分四层从前到后是一条完整的链路层级校验目标具体手段不合格时的反馈L1 语法语法层DSL 代码能否被正确解析调用 Mermaid/PlantUML 的解析器和渲染器返回具体语法错误行号和修复建议L2 布局结构层是否存在孤立节点、循环依赖、超宽分层图结构算法扫描强连通分量、出入度检查返回违规节点清单和修改路径建议L3 架构规范层是否符合预设的架构约束用户自定义的 schema 规则匹配返回违反的具体规则和合规示例L4 业务语义层是否覆盖需求中的核心业务要素LLM 辅助的语义要点匹配返回缺失要素清单和补充建议这四层不是可选项而是一条流水线上依次执行的工位。每层通过后进入下一层任一层次不通过就退回到生成阶段把校验结果转化成修改反馈让 AI 调整后重新生成。只有四层全部通过架构图才算验收合格。2.2 为什么不只做规则校验还需要重绘闭环只做校验-报错其实很简单难的是让 AI 理解错在哪、怎么改。这里有一个关键认知对 AI 说你的架构图不合格它听不懂你得告诉它订单服务的拆分逻辑缺少子订单状态机建议在订单服务与履约服务之间增加 message queue 节点并让子订单状态流转指向该队列。所以 archify 在每一层校验失败后都会自动生成一条结构化的修改指令指令包含三部分失败摘要用一句话说明哪里不合格如存在 2 个孤立节点违规详情具体的节点 ID、连线 ID、违反的规则编号修改建议可执行的架构调整建议比如为 nodeA 增加出边或在 X 和 Y 之间增加异步消息通道这其实就是把传统测试框架的断言失败信息翻译成了 LLM 能直接消费的 prompt 片段。AI 拿到这些信息后等于拿着批改过的作业重新做一遍而不是瞎猜答案。2.3 一次完整的验收闭环流程拆解拿前面的订单系统案例走一遍流水线看得更清楚用户输入设计订单微服务架构支持拆单子订单独立流转AI 初稿生成输出一张 Mermaid 图包含订单服务、支付服务、库存服务、用户服务订单服务内部带一个拆单模块。L1 语法校验通过Mermaid 解析无报错。L2 结构校验发现库存服务是一个孤立节点没有与任何其他服务产生连线。生成反馈移除孤立节点 inventory-service或增加与订单服务的调用关系。L3 规范校验项目配置了异步交互必须经过 Message Queue的架构规范图上订单服务直接调用履约服务违反规则。生成反馈订单服务与履约服务的同步调用应改为通过 order-queue 异步解耦。L4 语义校验需求中子订单独立流转未在图中体现。生成反馈图中缺少子订单状态机或子订单服务请在拆分模块后增加子订单状态管理节点并标识独立流转路径。AI 重绘拿着四条反馈信息重新生成一版架构图。再次跑流水线直到四层全部通过输出最终验收报告。这套闭环跑下来架构图的质量是几何级提升的因为每一轮重绘都是带着明确问题去修改而不是无方向地重新画一遍。3. 具体怎么落地我实际配置的验收规则清单与判定逻辑讲完设计思路这部分分享点更实战的内容——archify 里具体配置了哪些验收规则、每条规则的判定逻辑是怎么写的。这些规则我大部分是从真实架构评审中沉淀出来的也都是可以在自己的项目里直接复用或改造成自己规范的。3.1 结构层的核心规则L2 结构层的规则核心目标是把图上所有节点、连线、分层之间的关系盘清楚。我配置了四条规则先看表格再展开说规则名判定逻辑典型违规场景isolated-node扫描图中所有节点的出入度之和若为 0 则判定孤立AI 多画了一个审计模块但没有任何依赖关系circular-dependency用 Tarjan 算法扫描强连通分量若存在包含 2 个及以上节点的 SCC则判定循环依赖A 依赖 BB 又依赖 Aendless-chain检测相邻节点之间是否存在只有左侧无条件分支的链式跳跃判定为死链路一个调用链中间出现了非正常视图跳跃layered-width-bound统计每一层的节点数量若超出配置的阈值如单层 12 个则判定告警微服务图里某一层塞了 20 多个服务节点孤立节点检测这条规则最重要因为 AI 生成架构图时经常会顺手加上一些自己觉得应该有、但实际上没有任何关联的模块。这类节点在图上一摆乍一看没什么问题细看就发现它跟整个系统毫无关系——往往是 AI 在生成时想起了常见微服务应该有什么而不是这个需求需要什么。循环依赖检测我用的是 Tarjan 算法。Mermaid 图拉出来之后把每个节点和连线建图然后跑强连通分量。一旦某个 SCC 里同时出现了两个以上的业务节点说明存在 A 依赖 B、B 依赖 A 的循环这在微服务架构里是大忌必须打回。3.2 规范层的规则模板L3 规范层是所有层里改动最多的因为每个团队都有自己的架构约束。archify 把这层做成了 schema 驱动的形式用户自己声明约束机器按格式去校验。一个最简单的交互规范模板长这样{ rule: async-required, target: order-service:fulfillment-service, constraint: async, message: 订单服务与履约服务之间必须通过消息队列异步交互 }这条规则的意思是当图中出现 order-service 与 fulfillment-service 之间的连接时连线必须标注为异步交互建议出现 message queue 节点。判定逻辑是在图的连线对象中查找 source 为 order-service、target 为 fulfillment-service 的边再检查这条边所属的交互类型是否为异步如果不是判违规。实际项目中规范层的常见规则还有服务分层约束如controller 层不允许直接依赖 DAO 层扫描依赖图中是否存在跨层直连。技术栈约束如缓存必须使用 Redis不允许出现 Memcached 节点扫描节点 label 来判断。数据存储约束如所有写入操作必须经过主库读操作允许走从库对读写链路的终点做判断。这类规则的价值在于把团队沉淀了很久的架构 design rules 从口头文化变成机器可执行的东西。架构师不需要再一个个图去评审大部分机械性的校验规则流水线自动就做了。3.3 语义层的实现思路L4 业务语义层是比较难用纯规则实现的一层因为业务语义完整性本身是模糊的。我的做法是不直接让 AI 判断这张图是否完整而是拆解成关键业务要素是否存在的多个子问题。比如订单系统架构图的语义校验清单可能是是否存在订单服务节点是否存在仓储/库存服务节点是否存在支付相关的节点如果需求提到邮件通知图中是否有通知服务或消息队列具体到 Archify 的实现是先用 LLM 把需求描述里的关键名词抽取出来形成一个业务要素清单再回到架构图的节点标签里去逐一检查是否每一个关键名词都有对应的架构模块体现。这里有个很实用的 trick让 LLM 抽要素时显式要求它区分业务动作和业务对象。比如拆单是一个业务动作子订单是一个业务对象。动作更容易映射到服务或方法对象更容易映射到节点或数据结构。分开抽再一起比对图上的节点覆盖率高很多。3.4 校验规则的判定输出所有校验结果都会输出成一份机器可读的报告格式类似这样{ passed: false, layer: L3, failures: [ { rule: async-required, severity: error, target: [order-service, fulfillment-service], suggestion: 在两个服务之间增加消息队列节点并标注为异步交互 } ] }这份报告有两条岔路可以走一条是作为给 AI 重绘的修改指令把 suggestion 字段提取出来组合成新的 prompt 发给模型另一条是作为给架构师的评审辅助直接展示在界面上方便人快速定位问题。两种用途我都用到了前者让流水线自动化运行后者让我在关键架构评审时能人工复核一遍。所以整体上L1 到 L4 这四层价值是逐层递增的语法有问题最多是渲染不出来结构有问题可能是图要改版语义有问题则是方案要推翻。流水线做得越细AI 画出来的图离可直接评审就越近。4. 从画一张图到做成一件事业务验收层的设计思路结构层、规范层的规则能把图校验到结构正确但真正决定一张架构图有没有用的还是它有没有把业务讲清楚。这也是 archify 和其他架构图工具差异最大的地方不只是画图而是验收这张图对应的事情成没成。4.1 让 AI 先给验收标准再画图我在实践中最切身的体会是大多数人用 AI 画架构图时只给了需求描述没有给验收标准。这等于让施工队盖房子但不给图纸和验收标准盖出来肯定不像样。archify 的做法是生成架构图之前先让 AI 根据需求描述输出一份架构图验收清单——列出这张图必须包含哪些节点、哪些连线、哪些路径。这份清单既会被用于最终的语义层校验也会提前同步给生成环节让 AI 画图之前就清楚什么是对的行活。实际操作是把它做成一个独立的 prompt 环节第一步分析以下需求描述输出这份架构图的验收清单。 清单格式 - 必须出现的核心模块节点 - 必须体现的关键调用链 - 必须覆盖的跨服务交互 - 需要避免的架构问题这个环节跑完你手里就有一份可以对齐需求的检查基准。有意思的是同一份需求让 AI 生成两份清单结果高度相似因为核心业务语义是稳定的。但让 AI 对着需求直出架构图每次输出的差异却不小因为画图时有太多自由发挥的空间。提前锁定验收清单就是把这些自由发挥的空间约束住。4.2 从节点存在到路径正确的语义校验飞跃早期的语义校验我只看节点存在与否后来发现这远远不够。因为架构图的本质是描述过程和路径不是描述名词列表。光有节点没有路径这张图无法指导开发。于是语义层校验里增加了一类路径校验规则。这类规则的逻辑是针对需求中的关键业务链路检查图中是否存在一条从入口到出口的完整路径。再拿订单系统举例需求里有这么一句话用户下单后进行拆单子订单分别路由到不同仓库发货。那么语义层至少要校验这条链路用户端/入口网关 - 订单服务 - 拆单逻辑 - 路由分发 - 仓库服务 - 发货服务只要图上缺了这条链路里的任何一个环节或者中间某个连线断裂流水线就判不合格。这类校验的粒度比节点是否存在细得多它本质上是在说语义层关心的不是世界要有什么而是需求里那件事能不能干成。这里我用了两种方式来实现路径校验一种是直接把路径写成模板规则类似于入口网关必须连通订单服务、订单服务必须连通仓库服务这种逐跳断言另一种是借助 LLM 抽取需求中的动作序列再启发式地匹配到图上的链路。后者更灵活但可能有误报所以我一般会加一层人工确认。4.3 验收流水线带来的额外价值自动化的架构评审记录流水线跑完之后生成的验收报告本身就是一份有价值的文档。里面记录了每一次迭代的问题、修复方向、最终结果。这在团队协作中是很好的设计决策留痕——以后有人问订单服务为什么拆成这么多模块翻验收记录就能看到当初的语义校验是怎么约束出来的。而且流水线是可重复执行的同一个需求来回来去跑所有中间过程都有记录。这对需要经常向架构委员会汇报设计方案的场景特别有用比纯靠人脑记忆要可靠得多。4.4 业务验收层与整体流水线的协同把业务验收层整合到 archify 的流水线里之后整个验证流程的定位就变了不再是一个纯粹画图纠错的工具更像是一条架构设计 CI。设想这样一个场景你打算在 xxx 应用里引入一个新的外部依赖涉及订单服务、仓库服务、支付服务。传统的做法是翻代码、画图、做方案、拉评审非常耗时。有了 archify 的流水线可以先把这个改动抽象成需求描述让 AI 生成一版带验收清单的架构图再让流水线校验依赖方向对不对是否引入了循环要不要走异步通道——很多前期设计问题在画图阶段就能暴露出来而不是等到代码评审阶段才被人拍桌子指出来。这也是我在从画一张图到做成一件事这个点上最大的收获架构图的意义不在于图本身而在于它是架构决策的载体。给这个载体加上验收回路等于给架构决策加了一道质检。5. 落地实践中的常见问题与调整建议这部分聊聊把 archify 这套方案用在自己的项目里会遇到的几个关键问题。这些问题是我实际跑了大大小小几十张架构图后总结出来的每一道都踩过坑。5.1 不同领域的架构图侧重点完全不同先说一个最容易忽略的问题不同架构图的校验重点是完全不同的无法用一套固定规则通吃。我主要跑过三种场景配置差异很大架构图类型核心关注点典型验收规则微服务部署架构图服务依赖、通信方式、数据独占性循环依赖检测、异步边界约束、服务间耦合度业务系统模块图模块职责划分、调用关系、数据流转分层约束、关键业务链路完整、模块大小均衡数据流架构图数据源、处理节点、目标端、上下游依赖必经路径校验、数据源/目标端完整性、流向一致性如果不加区分地套同一套规则最容易出现的就是误杀或假通过。比如微服务部署架构图里我要求服务节点不能孤立但数据流架构图里的数据源节点在某些场景下孤立反而是正常的——它只是被读取不一定要有出边和入边。所以 archify 的规则集是按架构图类型来分组的。你告诉它当前画的是什么类型的图它自动加载对应的规则集。这样语义阶段更准同时避免了一堆无效校验干扰。5.2 验收规则集群肯定是越描越复杂的要留弹性规则写得多了之后会遇到一个新问题规则之间的冲突、规则的误报、规则对特殊情况的不容忍。比如我一度设了所有服务间调用必须是异步的规范结果一个强一致性的内部接口被反复打回——这个调用确实必须要同步。设计规则集群的时候一定要给规则加分级和豁免机制级别分为 error必须修复、warning提醒但不阻止、info仅供参考每条规则允许配置 exempt-nodes豁免节点列表对特定目标单独放行分级的好处是让流水线会说话error 级的问题是真的会翻车的问题warning 级的问题是建议关注的提示。这样 AI 重绘时也不会因为一些无所谓的问题反复空转。5.3 重绘轮数的合理上限反馈-重绘闭环虽好但不可能无限循环下去。每轮重绘都会调用 LLM有时间和成本开销。如果一个问题来回三次还修不好大概率是初始 prompt 里的信息就不足而不是 AI 画图能力的问题。我实际跑的阈值是最多三轮重绘如果第三轮仍有校验不通过流水线会停止把前三轮的报告汇总成一份问题清单直接输出给用户。此时的不通过原因有非常高的诊断价值——它说明需求描述或者架构约束的配置本身就有模糊之处需要人来介入了。每轮重绘失败时我还会额外生成一条轻量的失败摘要提示给用户。比起把一堆 JSON 报告砸给人看一句订单服务与库存服务之间的调用关系在四轮迭代中始终未通过结构层校验请检查需求描述中是否遗漏了库存服务的交互场景要有用得多。5.4 提升一次通过率的 prompt 技巧流水线能自动纠错但最好的体验是 AI 一次就画对让流水线直接绿灯。这里分享三个我的实操技巧能显著提升首轮通过率技巧一给架构图类型一个明确的上下文标签。不要只说帮我画个架构图要说帮我画一个订单微服务的部署架构图重点关注服务间依赖关系和异步通信边界。给 AI 定义的上下文任务越具体它选择规则集的准确率越高语义层面的表现也会好很多。技巧二交互需求前置。prompt 里显式声明本系统中服务间调用必须走消息队列这样 AI 在初始生成时就会主动把消息队列节点放进去而不是先画一条同步箭头等规范层打回再改。技巧三给关键路径点一个明确的流转说明。需求描述里提到数据从用户端进入经订单服务、支付服务最终到达履约服务时就把这条路径写在画图前置条件里图出来后基本不会缺路径。5.5 验收流水线对架构师工作的改变说点可能超出工具本身的体会。这套流水线跑久了最大的变化是我自己的架构评审习惯被反向优化了。以前评审架构图完全靠经验偶尔会凭感觉说这里不对但不知道具体哪里不对。现在我会习惯性地先把设计原则拆成可校验证的约束画图之前就想好这张图通过什么标准才算合格。这种思维方式本质上是把架构评审从经验驱动向规则驱动迁移架构师的经验被沉淀成了可执行的 schema 规则。团队里新同学画完图流水线先跑一遍老同学只需要看流水线报告里那几条 error 和 warning评审效率高了很多倍。6. 给想尝试的人一个最简实践方案讲完设计思路和落地细节最后给一套可以直接起步的最简实践路径。archify 不是只能作为平台工具使用它的核心逻辑可以拆出来用任何支持 LLM 调用和简单脚本的体系去实现。最简版本长这样用任何主流的 LLM API我是基于 Spring AI 体系做的封装也可以用你顺手的那套。准备一个生成架构图的 prompt要求输出 Mermaid 格式。准备一个校验架构图的脚本实现 L2 结构层的核心规则孤立节点、循环依赖。准备一个语义校验的 prompt按业务要素清单检查架构图完整性。把校验失败的结果 修改指令回传给 LLM让它重新生成。每一轮失败时都保留记录最多重试三轮。校验通过后输出最终的 Mermaid 图和验收报告。每一条的工程量都不大但组合起来就是一条完整的验收流水线。我根据自己的实践给一个建议的落地次序先跑通 L1 L2语法 结构这两条的确定性最高、见效最快再逐步加 L3 规范规则最后把 L4 语义校验做成人机搭配AI 抽要素、人复核清单这样综合收益最稳。6.1 一个可直接复用的最小校验脚本骨架顺手分享一段我最早验证用的孤立节点检测脚本骨架虽然简单但能说明流水线的运行方式def find_isolated_nodes(nodes, edges): nodes: [{id: str, label: str}, ...] edges: [{source: str, target: str}, ...] connected set() for edge in edges: connected.add(edge[source]) connected.add(edge[target]) isolated [n for n in nodes if n[id] not in connected] return isolated # 示例调用 if __name__ __main__: graph_nodes [ {id: order-service, label: 订单服务}, {id: inventory-service, label: 库存服务} ] graph_edges [ {source: order-service, target: inventory-service} ] result find_isolated_nodes(graph_nodes, graph_edges) print(孤立节点:, result)这段逻辑跑完把result里的节点转成反馈信息拼进新的可用 prompt就是一条真正的验收打回。后面你可以在同样的思路下逐步补充循环依赖检测、布局检查等规则。6.2 场景边界与适用性最后说清楚这套机制的边界。它对结构清晰、依赖关系复杂、需要多轮打磨的架构图价值最大比如微服务架构图、系统间集成图、数据流图。但对画一张 lo-fi 产品流程图这类需求就有点大材小用了——本来 10 秒能出的图硬要跑一套流程反而影响效率。所以也不用一上来就把所有输入都往流水线上怼。建议是核心系统、高风险模块、需要评审留痕的图进流水线日常草稿、头脑风暴、临时示意图直接画就行。工具永远服务于效率不要为了流程而流程。至于 archify 这套方案之后还能往哪走我在实际使用中已经有了一些想法。比如把验收流水线从画架构图扩展到设计 API 接口契约——让 AI 生成接口定义时也走一遍可执行的校验参数完整性、依赖约束、幂等性声明解决类似AI 生成的接口总差几个字段的问题。再比如把验收记录自动沉淀成架构决策记录配合知识库构建团队专属的架构规则集。这些方向本质都是同一件事给 AI 的生成式输出加一条确定性验收回路。这个思路在除了架构图之外的大量 AI 辅助场景里都值得再试一轮。 AI架构图生成不靠谱？用“验收流水线”让架构图从“画得出”到“画得对”
AI画架构图这事圈子里一直有个心照不宣的痛点生成的图看着像那么回事但真要拿去评审、进设计文档、指导开发又总觉得哪里不对。有的图是模块划分逻辑混乱有的图是缺了关键的数据流向有的图干脆把技术栈都画错了。修修改改半天最后还不如自己从白纸开始画来得快。我前段时间在折腾 AI Agent 辅助架构设计也一直在思考怎么解决这个问题。我的思路是与其纠结怎么让模型一次画对不如反过来给它加一条验收流水线——用自动化的规则去校验 AI 生成的架构图不合格就退回重画直到它真正满足约束条件为止。这就是 archify 这个项目要做的事也是这篇文章想完整拆解的东西。archify 不是什么玄学工具它做的事情一句话能说清楚给 AI 画架构图的过程加一个可执行的验收环节让输出从看起来合理变成验证过合理。这篇文章我会从问题根源、验收流水线的设计思路、具体规则实现、以及实际落地时容易踩的坑这几个角度把整套方案完整讲透希望对正在做 AI 辅助架构设计、或者对 AI Agent 工程化感兴趣的朋友有帮助。1. 总差点意思的本质AI 画架构图缺的不是绘图能力是验收回路先把这个问题的根源掰开来看。很多人在抱怨 AI 画架构图不靠谱但其实画图这个动作本身对现在的 LLM 来说已经不是瓶颈。Mermaid、PlantUML、Graphviz 这类 DSL 语言的生成模型已经学得很扎实语法错误率其实很低。真正的问题出在另一个地方AI 没有对自己画出来的东西进行架构合理性校验的能力闭环。1.1 从需求描述到架构图的语义失真链路你给 AI 输入一段需求描述它输出的架构图中间经历了好几次转化自然语言理解 - 关键要素抽取 - 模块划分决策 - DSL 代码生成。每一步都可能引入语义失真。举一个真实场景。我让 AI 设计一个订单系统的微服务架构需求描述里有这么一句订单服务需要支持拆单拆单后的子订单需要独立流转。结果 AI 生成的架构图里只在订单服务内部画了一个拆单模块完全没体现子订单独立流转所需的消息队列、子订单状态机服务、以及后续的履约对接服务。从绘图的角度看这张图没毛病语法正确、布局规整。但从架构的角度看它就是一张废图——关键的业务语义丢了。这就是总差点意思的第一个来源AI 默认只做最小成本的语义补全它不会主动深挖需求背后的架构诉求。1.2 架构图质量的两个不同维度要真正解决这个问题必须先区分两个维度语法正确性DSL 能否正确渲染成图节点、连线关系是否合法这个 LLM 天然做得不错。架构语义完整性这张图是否完整表达了需求里的业务语义模块划分是否合理关键路径、数据流向、外部依赖是否完备大部分人的挫败感不是来自第一个维度而是第二个维度。语法对了、图也出来了但架构设计得对不对、全不全没人帮我们把关。所以我在设计 archify 的时候定了这么一条原则不要试图提升 AI 画图的能力而是提升 AI 自检的能力。具体做法就是给它加一条可执行、可量化的验收流水线。1.3 为什么纯靠对话式帮我看一下不够用可能有人会说AI 画完图我让它自己检查不就行了我在实际使用中试过效果非常不稳定。原因在于让 AI 自己评审自己等于让它做一次没有题目答案的自我批改——它只会基于自己已有的生成逻辑再完善一下很难跳出自己的思维惯性。比如漏掉的拆单语义你让它自查它大概率说图已经完整覆盖了需求因为它的完整标准和我们期望的完整标准根本不在一个维度上。这就需要一个外置的、确定性的校验机制用一套固定的规则去检查它的产出类似于 CI/CD 里的单元测试。没有这套外置校验回路AI 画图就永远是盲画质量全靠运气。提示想让 AI 产出稳定的架构图核心思路不是换更大的模型、写更长的提示词而是加一条确定性规则的验收回路让不确定的 AI 输出被确定性的规则约束住。2. archify 的验收流水线设计分层校验 自动重绘闭环确定要加验收环节之后接下来的问题是验收流水线长什么样校验哪些东西不合格之后怎么处理我最初的想法很朴素——就是输出后跑一堆检查规则不通过就报错完事。但实际做下来发现光报错没用AI 不知道怎么改你还得把错误原因转化成它能理解的修改指令让它重新生成。所以 archify 的流水线是校验-反馈-重绘的闭环设计。2.1 验收流水线的整体架构整个流水线分四层从前到后是一条完整的链路层级校验目标具体手段不合格时的反馈L1 语法语法层DSL 代码能否被正确解析调用 Mermaid/PlantUML 的解析器和渲染器返回具体语法错误行号和修复建议L2 布局结构层是否存在孤立节点、循环依赖、超宽分层图结构算法扫描强连通分量、出入度检查返回违规节点清单和修改路径建议L3 架构规范层是否符合预设的架构约束用户自定义的 schema 规则匹配返回违反的具体规则和合规示例L4 业务语义层是否覆盖需求中的核心业务要素LLM 辅助的语义要点匹配返回缺失要素清单和补充建议这四层不是可选项而是一条流水线上依次执行的工位。每层通过后进入下一层任一层次不通过就退回到生成阶段把校验结果转化成修改反馈让 AI 调整后重新生成。只有四层全部通过架构图才算验收合格。2.2 为什么不只做规则校验还需要重绘闭环只做校验-报错其实很简单难的是让 AI 理解错在哪、怎么改。这里有一个关键认知对 AI 说你的架构图不合格它听不懂你得告诉它订单服务的拆分逻辑缺少子订单状态机建议在订单服务与履约服务之间增加 message queue 节点并让子订单状态流转指向该队列。所以 archify 在每一层校验失败后都会自动生成一条结构化的修改指令指令包含三部分失败摘要用一句话说明哪里不合格如存在 2 个孤立节点违规详情具体的节点 ID、连线 ID、违反的规则编号修改建议可执行的架构调整建议比如为 nodeA 增加出边或在 X 和 Y 之间增加异步消息通道这其实就是把传统测试框架的断言失败信息翻译成了 LLM 能直接消费的 prompt 片段。AI 拿到这些信息后等于拿着批改过的作业重新做一遍而不是瞎猜答案。2.3 一次完整的验收闭环流程拆解拿前面的订单系统案例走一遍流水线看得更清楚用户输入设计订单微服务架构支持拆单子订单独立流转AI 初稿生成输出一张 Mermaid 图包含订单服务、支付服务、库存服务、用户服务订单服务内部带一个拆单模块。L1 语法校验通过Mermaid 解析无报错。L2 结构校验发现库存服务是一个孤立节点没有与任何其他服务产生连线。生成反馈移除孤立节点 inventory-service或增加与订单服务的调用关系。L3 规范校验项目配置了异步交互必须经过 Message Queue的架构规范图上订单服务直接调用履约服务违反规则。生成反馈订单服务与履约服务的同步调用应改为通过 order-queue 异步解耦。L4 语义校验需求中子订单独立流转未在图中体现。生成反馈图中缺少子订单状态机或子订单服务请在拆分模块后增加子订单状态管理节点并标识独立流转路径。AI 重绘拿着四条反馈信息重新生成一版架构图。再次跑流水线直到四层全部通过输出最终验收报告。这套闭环跑下来架构图的质量是几何级提升的因为每一轮重绘都是带着明确问题去修改而不是无方向地重新画一遍。3. 具体怎么落地我实际配置的验收规则清单与判定逻辑讲完设计思路这部分分享点更实战的内容——archify 里具体配置了哪些验收规则、每条规则的判定逻辑是怎么写的。这些规则我大部分是从真实架构评审中沉淀出来的也都是可以在自己的项目里直接复用或改造成自己规范的。3.1 结构层的核心规则L2 结构层的规则核心目标是把图上所有节点、连线、分层之间的关系盘清楚。我配置了四条规则先看表格再展开说规则名判定逻辑典型违规场景isolated-node扫描图中所有节点的出入度之和若为 0 则判定孤立AI 多画了一个审计模块但没有任何依赖关系circular-dependency用 Tarjan 算法扫描强连通分量若存在包含 2 个及以上节点的 SCC则判定循环依赖A 依赖 BB 又依赖 Aendless-chain检测相邻节点之间是否存在只有左侧无条件分支的链式跳跃判定为死链路一个调用链中间出现了非正常视图跳跃layered-width-bound统计每一层的节点数量若超出配置的阈值如单层 12 个则判定告警微服务图里某一层塞了 20 多个服务节点孤立节点检测这条规则最重要因为 AI 生成架构图时经常会顺手加上一些自己觉得应该有、但实际上没有任何关联的模块。这类节点在图上一摆乍一看没什么问题细看就发现它跟整个系统毫无关系——往往是 AI 在生成时想起了常见微服务应该有什么而不是这个需求需要什么。循环依赖检测我用的是 Tarjan 算法。Mermaid 图拉出来之后把每个节点和连线建图然后跑强连通分量。一旦某个 SCC 里同时出现了两个以上的业务节点说明存在 A 依赖 B、B 依赖 A 的循环这在微服务架构里是大忌必须打回。3.2 规范层的规则模板L3 规范层是所有层里改动最多的因为每个团队都有自己的架构约束。archify 把这层做成了 schema 驱动的形式用户自己声明约束机器按格式去校验。一个最简单的交互规范模板长这样{ rule: async-required, target: order-service:fulfillment-service, constraint: async, message: 订单服务与履约服务之间必须通过消息队列异步交互 }这条规则的意思是当图中出现 order-service 与 fulfillment-service 之间的连接时连线必须标注为异步交互建议出现 message queue 节点。判定逻辑是在图的连线对象中查找 source 为 order-service、target 为 fulfillment-service 的边再检查这条边所属的交互类型是否为异步如果不是判违规。实际项目中规范层的常见规则还有服务分层约束如controller 层不允许直接依赖 DAO 层扫描依赖图中是否存在跨层直连。技术栈约束如缓存必须使用 Redis不允许出现 Memcached 节点扫描节点 label 来判断。数据存储约束如所有写入操作必须经过主库读操作允许走从库对读写链路的终点做判断。这类规则的价值在于把团队沉淀了很久的架构 design rules 从口头文化变成机器可执行的东西。架构师不需要再一个个图去评审大部分机械性的校验规则流水线自动就做了。3.3 语义层的实现思路L4 业务语义层是比较难用纯规则实现的一层因为业务语义完整性本身是模糊的。我的做法是不直接让 AI 判断这张图是否完整而是拆解成关键业务要素是否存在的多个子问题。比如订单系统架构图的语义校验清单可能是是否存在订单服务节点是否存在仓储/库存服务节点是否存在支付相关的节点如果需求提到邮件通知图中是否有通知服务或消息队列具体到 Archify 的实现是先用 LLM 把需求描述里的关键名词抽取出来形成一个业务要素清单再回到架构图的节点标签里去逐一检查是否每一个关键名词都有对应的架构模块体现。这里有个很实用的 trick让 LLM 抽要素时显式要求它区分业务动作和业务对象。比如拆单是一个业务动作子订单是一个业务对象。动作更容易映射到服务或方法对象更容易映射到节点或数据结构。分开抽再一起比对图上的节点覆盖率高很多。3.4 校验规则的判定输出所有校验结果都会输出成一份机器可读的报告格式类似这样{ passed: false, layer: L3, failures: [ { rule: async-required, severity: error, target: [order-service, fulfillment-service], suggestion: 在两个服务之间增加消息队列节点并标注为异步交互 } ] }这份报告有两条岔路可以走一条是作为给 AI 重绘的修改指令把 suggestion 字段提取出来组合成新的 prompt 发给模型另一条是作为给架构师的评审辅助直接展示在界面上方便人快速定位问题。两种用途我都用到了前者让流水线自动化运行后者让我在关键架构评审时能人工复核一遍。所以整体上L1 到 L4 这四层价值是逐层递增的语法有问题最多是渲染不出来结构有问题可能是图要改版语义有问题则是方案要推翻。流水线做得越细AI 画出来的图离可直接评审就越近。4. 从画一张图到做成一件事业务验收层的设计思路结构层、规范层的规则能把图校验到结构正确但真正决定一张架构图有没有用的还是它有没有把业务讲清楚。这也是 archify 和其他架构图工具差异最大的地方不只是画图而是验收这张图对应的事情成没成。4.1 让 AI 先给验收标准再画图我在实践中最切身的体会是大多数人用 AI 画架构图时只给了需求描述没有给验收标准。这等于让施工队盖房子但不给图纸和验收标准盖出来肯定不像样。archify 的做法是生成架构图之前先让 AI 根据需求描述输出一份架构图验收清单——列出这张图必须包含哪些节点、哪些连线、哪些路径。这份清单既会被用于最终的语义层校验也会提前同步给生成环节让 AI 画图之前就清楚什么是对的行活。实际操作是把它做成一个独立的 prompt 环节第一步分析以下需求描述输出这份架构图的验收清单。 清单格式 - 必须出现的核心模块节点 - 必须体现的关键调用链 - 必须覆盖的跨服务交互 - 需要避免的架构问题这个环节跑完你手里就有一份可以对齐需求的检查基准。有意思的是同一份需求让 AI 生成两份清单结果高度相似因为核心业务语义是稳定的。但让 AI 对着需求直出架构图每次输出的差异却不小因为画图时有太多自由发挥的空间。提前锁定验收清单就是把这些自由发挥的空间约束住。4.2 从节点存在到路径正确的语义校验飞跃早期的语义校验我只看节点存在与否后来发现这远远不够。因为架构图的本质是描述过程和路径不是描述名词列表。光有节点没有路径这张图无法指导开发。于是语义层校验里增加了一类路径校验规则。这类规则的逻辑是针对需求中的关键业务链路检查图中是否存在一条从入口到出口的完整路径。再拿订单系统举例需求里有这么一句话用户下单后进行拆单子订单分别路由到不同仓库发货。那么语义层至少要校验这条链路用户端/入口网关 - 订单服务 - 拆单逻辑 - 路由分发 - 仓库服务 - 发货服务只要图上缺了这条链路里的任何一个环节或者中间某个连线断裂流水线就判不合格。这类校验的粒度比节点是否存在细得多它本质上是在说语义层关心的不是世界要有什么而是需求里那件事能不能干成。这里我用了两种方式来实现路径校验一种是直接把路径写成模板规则类似于入口网关必须连通订单服务、订单服务必须连通仓库服务这种逐跳断言另一种是借助 LLM 抽取需求中的动作序列再启发式地匹配到图上的链路。后者更灵活但可能有误报所以我一般会加一层人工确认。4.3 验收流水线带来的额外价值自动化的架构评审记录流水线跑完之后生成的验收报告本身就是一份有价值的文档。里面记录了每一次迭代的问题、修复方向、最终结果。这在团队协作中是很好的设计决策留痕——以后有人问订单服务为什么拆成这么多模块翻验收记录就能看到当初的语义校验是怎么约束出来的。而且流水线是可重复执行的同一个需求来回来去跑所有中间过程都有记录。这对需要经常向架构委员会汇报设计方案的场景特别有用比纯靠人脑记忆要可靠得多。4.4 业务验收层与整体流水线的协同把业务验收层整合到 archify 的流水线里之后整个验证流程的定位就变了不再是一个纯粹画图纠错的工具更像是一条架构设计 CI。设想这样一个场景你打算在 xxx 应用里引入一个新的外部依赖涉及订单服务、仓库服务、支付服务。传统的做法是翻代码、画图、做方案、拉评审非常耗时。有了 archify 的流水线可以先把这个改动抽象成需求描述让 AI 生成一版带验收清单的架构图再让流水线校验依赖方向对不对是否引入了循环要不要走异步通道——很多前期设计问题在画图阶段就能暴露出来而不是等到代码评审阶段才被人拍桌子指出来。这也是我在从画一张图到做成一件事这个点上最大的收获架构图的意义不在于图本身而在于它是架构决策的载体。给这个载体加上验收回路等于给架构决策加了一道质检。5. 落地实践中的常见问题与调整建议这部分聊聊把 archify 这套方案用在自己的项目里会遇到的几个关键问题。这些问题是我实际跑了大大小小几十张架构图后总结出来的每一道都踩过坑。5.1 不同领域的架构图侧重点完全不同先说一个最容易忽略的问题不同架构图的校验重点是完全不同的无法用一套固定规则通吃。我主要跑过三种场景配置差异很大架构图类型核心关注点典型验收规则微服务部署架构图服务依赖、通信方式、数据独占性循环依赖检测、异步边界约束、服务间耦合度业务系统模块图模块职责划分、调用关系、数据流转分层约束、关键业务链路完整、模块大小均衡数据流架构图数据源、处理节点、目标端、上下游依赖必经路径校验、数据源/目标端完整性、流向一致性如果不加区分地套同一套规则最容易出现的就是误杀或假通过。比如微服务部署架构图里我要求服务节点不能孤立但数据流架构图里的数据源节点在某些场景下孤立反而是正常的——它只是被读取不一定要有出边和入边。所以 archify 的规则集是按架构图类型来分组的。你告诉它当前画的是什么类型的图它自动加载对应的规则集。这样语义阶段更准同时避免了一堆无效校验干扰。5.2 验收规则集群肯定是越描越复杂的要留弹性规则写得多了之后会遇到一个新问题规则之间的冲突、规则的误报、规则对特殊情况的不容忍。比如我一度设了所有服务间调用必须是异步的规范结果一个强一致性的内部接口被反复打回——这个调用确实必须要同步。设计规则集群的时候一定要给规则加分级和豁免机制级别分为 error必须修复、warning提醒但不阻止、info仅供参考每条规则允许配置 exempt-nodes豁免节点列表对特定目标单独放行分级的好处是让流水线会说话error 级的问题是真的会翻车的问题warning 级的问题是建议关注的提示。这样 AI 重绘时也不会因为一些无所谓的问题反复空转。5.3 重绘轮数的合理上限反馈-重绘闭环虽好但不可能无限循环下去。每轮重绘都会调用 LLM有时间和成本开销。如果一个问题来回三次还修不好大概率是初始 prompt 里的信息就不足而不是 AI 画图能力的问题。我实际跑的阈值是最多三轮重绘如果第三轮仍有校验不通过流水线会停止把前三轮的报告汇总成一份问题清单直接输出给用户。此时的不通过原因有非常高的诊断价值——它说明需求描述或者架构约束的配置本身就有模糊之处需要人来介入了。每轮重绘失败时我还会额外生成一条轻量的失败摘要提示给用户。比起把一堆 JSON 报告砸给人看一句订单服务与库存服务之间的调用关系在四轮迭代中始终未通过结构层校验请检查需求描述中是否遗漏了库存服务的交互场景要有用得多。5.4 提升一次通过率的 prompt 技巧流水线能自动纠错但最好的体验是 AI 一次就画对让流水线直接绿灯。这里分享三个我的实操技巧能显著提升首轮通过率技巧一给架构图类型一个明确的上下文标签。不要只说帮我画个架构图要说帮我画一个订单微服务的部署架构图重点关注服务间依赖关系和异步通信边界。给 AI 定义的上下文任务越具体它选择规则集的准确率越高语义层面的表现也会好很多。技巧二交互需求前置。prompt 里显式声明本系统中服务间调用必须走消息队列这样 AI 在初始生成时就会主动把消息队列节点放进去而不是先画一条同步箭头等规范层打回再改。技巧三给关键路径点一个明确的流转说明。需求描述里提到数据从用户端进入经订单服务、支付服务最终到达履约服务时就把这条路径写在画图前置条件里图出来后基本不会缺路径。5.5 验收流水线对架构师工作的改变说点可能超出工具本身的体会。这套流水线跑久了最大的变化是我自己的架构评审习惯被反向优化了。以前评审架构图完全靠经验偶尔会凭感觉说这里不对但不知道具体哪里不对。现在我会习惯性地先把设计原则拆成可校验证的约束画图之前就想好这张图通过什么标准才算合格。这种思维方式本质上是把架构评审从经验驱动向规则驱动迁移架构师的经验被沉淀成了可执行的 schema 规则。团队里新同学画完图流水线先跑一遍老同学只需要看流水线报告里那几条 error 和 warning评审效率高了很多倍。6. 给想尝试的人一个最简实践方案讲完设计思路和落地细节最后给一套可以直接起步的最简实践路径。archify 不是只能作为平台工具使用它的核心逻辑可以拆出来用任何支持 LLM 调用和简单脚本的体系去实现。最简版本长这样用任何主流的 LLM API我是基于 Spring AI 体系做的封装也可以用你顺手的那套。准备一个生成架构图的 prompt要求输出 Mermaid 格式。准备一个校验架构图的脚本实现 L2 结构层的核心规则孤立节点、循环依赖。准备一个语义校验的 prompt按业务要素清单检查架构图完整性。把校验失败的结果 修改指令回传给 LLM让它重新生成。每一轮失败时都保留记录最多重试三轮。校验通过后输出最终的 Mermaid 图和验收报告。每一条的工程量都不大但组合起来就是一条完整的验收流水线。我根据自己的实践给一个建议的落地次序先跑通 L1 L2语法 结构这两条的确定性最高、见效最快再逐步加 L3 规范规则最后把 L4 语义校验做成人机搭配AI 抽要素、人复核清单这样综合收益最稳。6.1 一个可直接复用的最小校验脚本骨架顺手分享一段我最早验证用的孤立节点检测脚本骨架虽然简单但能说明流水线的运行方式def find_isolated_nodes(nodes, edges): nodes: [{id: str, label: str}, ...] edges: [{source: str, target: str}, ...] connected set() for edge in edges: connected.add(edge[source]) connected.add(edge[target]) isolated [n for n in nodes if n[id] not in connected] return isolated # 示例调用 if __name__ __main__: graph_nodes [ {id: order-service, label: 订单服务}, {id: inventory-service, label: 库存服务} ] graph_edges [ {source: order-service, target: inventory-service} ] result find_isolated_nodes(graph_nodes, graph_edges) print(孤立节点:, result)这段逻辑跑完把result里的节点转成反馈信息拼进新的可用 prompt就是一条真正的验收打回。后面你可以在同样的思路下逐步补充循环依赖检测、布局检查等规则。6.2 场景边界与适用性最后说清楚这套机制的边界。它对结构清晰、依赖关系复杂、需要多轮打磨的架构图价值最大比如微服务架构图、系统间集成图、数据流图。但对画一张 lo-fi 产品流程图这类需求就有点大材小用了——本来 10 秒能出的图硬要跑一套流程反而影响效率。所以也不用一上来就把所有输入都往流水线上怼。建议是核心系统、高风险模块、需要评审留痕的图进流水线日常草稿、头脑风暴、临时示意图直接画就行。工具永远服务于效率不要为了流程而流程。至于 archify 这套方案之后还能往哪走我在实际使用中已经有了一些想法。比如把验收流水线从画架构图扩展到设计 API 接口契约——让 AI 生成接口定义时也走一遍可执行的校验参数完整性、依赖约束、幂等性声明解决类似AI 生成的接口总差几个字段的问题。再比如把验收记录自动沉淀成架构决策记录配合知识库构建团队专属的架构规则集。这些方向本质都是同一件事给 AI 的生成式输出加一条确定性验收回路。这个思路在除了架构图之外的大量 AI 辅助场景里都值得再试一轮。