1. 为什么AI画架构图总差点意思——先搞清楚痛点在哪我一直觉得让AI画架构图这件事像极了让一个实习生第一次独立画系统设计图。你说他不会吧他确实能画出来你说他会吧画完你总得改半天改到最后还不如自己重画来得快。这个“差点意思”的感觉在过去一年里几乎每次用AI画架构图都会冒出来。拿我最近一次用某款AI画微服务架构图举例。我给的需求很简单一个电商系统前端、网关、订单服务、库存服务、用户服务、支付服务再加一个消息队列做异步解耦。模型吐出来的图第一眼看上去真像那么回事方框、箭头、分层都有。可仔细一瞧就露馅了订单服务直接连到了数据库但库存服务的数据源标成了“MySQL订单库”支付回调的箭头画到了前端实际上是应该到网关更重要的是这幅图里没有一个地方标注了服务之间的调用协议是HTTP还是RPC是同步还是异步全靠我靠常识去猜。这种问题不是偶发而是几乎每次都会出现。我试过换更好的模型试过写更长的提示词也试过把参考架构贴给它让它模仿结果改善程度都很有限。为什么根子上的原因在于大模型天生是一个“生成器”不是一个“校验器”。它的训练目标是从概率分布里采样出最像样的内容并没有一种“画完之后逐条检查对错”的机制。就好比你让一个很会写诗的人去改自己的诗是否符合格律他能改但改完依然可能出现平仄问题因为他的注意力在“写得漂亮”上而不在“逐字核对”上。AI生成架构图也是一样它的注意力在“画得完整”上而不在“每个连接是否真的说得通”上。另外还有一个现实问题——上下文长度。一次画图任务里几十个组件、几十条连线、每个组件的属性这些信息叠加起来很容易就把模型的上下文撑得很大。模型在这种状态下很容易顾此失彼前面定的命名规则后面忘了前面说的连接方式后面画歪了。这不是模型笨而是它在超长上下文里的注意力天然会衰减。你让一个人同时处理五十个变量的逻辑关系他也一定会出错。这些痛点积累到一定程度就逼着我思考如果“让AI自己画得对”这条路走不通那能不能换一条思路——既然AI画完总有问题那我们就给它的输出加一道验收让图在交付之前自动被检查一遍不合格就打回去重画直到满足所有规则为止。这就是我后来折腾 archify 这个方案的核心出发点。2. archify的核心思路给AI加一条验收流水线2.1 验收流水线到底是什么我第一次听说“验收流水线”这个词是在一个做AI编程工具的朋友那里。他说他们在给AI生成的代码做自动化测试、静态扫描、构建检查一套流程走下来没通过的代码根本不会合并进主干。我当时就冒出一个念头代码能这么干架构图凭什么不能archify做的就是这件事——它不试图教AI怎么画得更好而是给AI画完的图加了一整套自动验收流程。这个流程从三个层面层层检查就像工厂里的质检线第一层语法层检查图本身是不是合法的。节点有没有名字、类型是否在允许范围内、连线有没有指向不存在的节点、图文件能不能被标准工具正常解析。这一层解决的是“图能不能用”的问题。第二层语义层检查连接关系是否合理。A服务的输出端口是否连到了B服务的输入端口关联的协议标注是否一致有没有悬空的孤立节点有没有同一条连接被重复定义了两次。第三层架构合理性层检查整体设计是否符合架构规范。有没有出现循环依赖、有没有跨层调用、有没有把数据库直接暴露给了前端以及一些你自定义的组织级规则。每层检查的结果都会汇总成一份“验收报告”报告里会明确列出哪条规则不通过、涉及哪些节点和连线、建议怎么修。AI拿到这份报告后会根据反馈进行针对性修改改完再送检直到全部通过为止。有人可能会问这跟让用户自己看图、发现问题、再去改提示词重画有什么区别区别非常大。人工看图这件事本质上是一个隐性知识密集的过程。你需要知道这个系统应该长什么样、服务边界在哪、依赖方向怎么合规这些经验不是每个人都能快速调用的。而验收流水线把这一堆隐性知识变成了显性规则机器可以自动执行可以瞬时反馈100次检查结果稳定一致。它不依赖当时的心情、不依赖瞌睡程度、也不依赖你今天是不是特别想仔细看这张图。我在实际使用中最直观的感受是过去用AI画架构图一个来回至少10分钟因为我要自己看、自己找问题、自己组织语言去反馈常常一个图要来回三四次才能满意。现在有了验收流水线一个来回可能就2分钟因为AI自己就能看到哪里不满足规则自己就能迭代修正我只需要做最后的人工确认。2.2 每一层在干什么为什么非要分层这里我想多说几句为什么非要把验收拆成三层而不是全部揉成一条规则。如果全部揉在一起会有一个很麻烦的问题错误定位困难。比如AI画了一张图数据库直接暴露给了前端同时还有一个节点没有名字两个问题同时存在。这时候如果只给AI一句“验收不通过请修正”它是不知道该先改哪个的而且很可能改了数据库暴露的问题之后又忘记了节点没命名这事。因为模型的上下文是有限的一次反馈里指出的问题太多它反而容易漏掉关键项。分层的意义在于让问题被逐层暴露被逐层解决每一轮迭代的修改范围都足够小。语法层不通过就不进入语义层语义层不通过就不进入架构合理性层。这就像你写代码时先过编译再跑单元测试最后做代码评审——每一道关卡负责一类问题不会混在一起。以我自己配置过的一个真实场景来举例。我之前做一个订单中台项目要求所有服务依赖必须单向流动网关层可以调用服务层服务层可以调用数据层但服务层决不允许反向依赖网关层。我把这条规则写进了架构合理性层。结果第一次验收AI画了一张图里面有个服务居然反向调用了网关的一个接口。这个错误语法层查不出来因为节点合法、连接合法语义层也查不出来因为端口匹配、连接也没有悬空。只有到了架构合理性层规则引擎识别出“服务层节点访问了网关层节点”才把它拦截下来。这也说明了为什么分层是必须的——不同类型的错误需要用不同的规则去识别而每一类规则的数据来源和判定逻辑完全不同。语法层只需要解析图结构本身语义层需要理解组件的输出输入语义架构合理性层需要理解你自定义的架构约束。硬把它们混在一层里规则引擎会变得异常复杂而且很难排查“为什么这条规则没生效”。2.3 一次典型的验收失败过程我来讲一次真实的失败案例。有一次我让AI画一个数据中台的架构图需求包含了数据采集、数据存储、数据计算、数据服务四个层次。AI画完第一版我把它送到验收流水线里结果反馈是这样的语法层发现两个节点没有填写类型字段一个节点命名重复图文件使用标准解析器加载时报错。这属于很基本的问题说明模型在长上下文中丢失了基础元信息。修正后送到语义层提示“数据采集节点的输出端口(output_raw)未连接到任何目标节点”同时“数据服务节点的API端口被连接到了数据存储节点的存储端口端口类型不匹配”。再修正后送到架构合理性层发现“数据计算层的调度组件直接访问了数据服务层提供的API违反了分层规范”。这个过程看起来挺折腾但它比我手动看图修改要快得多——每轮验收只需要几十秒三轮下来不到五分钟。如果用人工方式我得自己打开图、一个个对节点、查连线、回想架构规范没有二十分钟搞不定。而且最让我放心的是最后一版图通过验收之后所有规则都是我事先定义好的不是我拍脑袋临时想的。2.4 为什么“先想后画”能大幅提升验收通过率这里还有一个关键点要提——大部分人在用AI画架构图时拿到需求直接就让AI开画。这是很容易踩坑的做法。AI在没有经过深层次思考的情况下很容易选择一个“差不多”的方案然后在这个方案上衍生出各种细节。这种“差不多”方案往往隐藏着架构层面的硬伤比如把某种中间件放到了不合适的位置、把原本应该解耦的服务硬耦合在一起。archify的skill配置里有一条很值得借鉴的强制规则在生成任何图形代码之前必须先输出一份设计说明。包括这个架构图的业务目标是什么、有哪些关键组件、组件之间的依赖关系怎么定义、数据流怎么走、哪些组件需要扩展。设计说明输出完之后AI才能开始画图。这个机制本质上是在逼AI先把架构思考清楚再用图形语言复现这个思考。实践中我发现加了这一步之后第一版图通过验收的比例提升了非常多。为什么因为当AI把设计思路用自然语言先表达出来时相当于经历了一次内部的逻辑整理很多明显的矛盾在这个阶段就被发现了。这和程序员写代码前先写设计文档是一个道理——并不是说文档有多重要而是写文档的这个过程强迫你把逻辑理顺乱成一团的想法很难在纸面上立住脚。AI也是一样它不会像人一样主动“想清楚再动手”你需要在流程上强制它这么做。3. 实操把archify接入你的AI画图流程3.1 环境准备与安装archify不是一款独立的桌面软件它更像一个“技能包”可以接入到主流的AI对话工具里。具体安装过程在这里不展开太多我只说几个容易出问题的地方。Skill 文件配置你需要把archify的skill定义文件放到指定的目录里。这个文件定义了“验收流水线”的所有规则和步骤。装好之后你可以在AI对话里通过特定的触发词启动它比如直接说“用archify检查一下这张图”。规则配置这是最关键的一步。archify默认带了一些通用规则包括组件类型校验、连接合法性校验、孤立节点检测、重复组件检测等。但真正的价值来自你根据自己项目定制的那部分规则后面我会单独说。MCP工具链对接如果你用的是支持MCP模型上下文协议的AI工具可以把archify暴露成MCP服务让它具备读取项目文档、读取既有架构图文件、甚至读取代码仓库里依赖关系的能力。这一步做好的话能达到一个很实用的效果——AI画图之前可以先扫描一下你项目的实际依赖关系画出来的图就不会跟真实代码脱节。安装完成之后我建议你用一个非常简单的测试用例先验证流水线是否正常工作让AI画一个只有三个组件的最小架构图然后手动制造一个明显错误比如让B组件连接到不存在的C组件再让archify去检查看它能不能准确捕获到这个错误。这一步能确认配置正确之后再用真实项目来跑。3.2 怎么写验收规则才能让流水线真正干活这是我认为archify整个方案里最值得花时间琢磨的部分。规则写得好不好直接决定了这套流水线是在替你干活还是在替你添乱。我的建议是规则不要从一开始就追求大而全而是从三个方向逐步补齐。第一个方向基础通用规则。这类规则每个项目都需要也是默认就有的。包括节点必须有名称、节点类型必须在合法范围内、连线两端必须指向真实存在的节点、不能有孤立节点、不能有重复的组件ID。这些规则不需要你去创造你只需要确保它们处于开启状态即可。第二个方向项目定制规则。这类规则来自你的项目实际情况。比如你的项目规定所有微服务都必须有独立的数据库不能共享规定外部请求必须经过API网关不能直接打到服务上规定服务之间的调用必须标注协议类型否则视为无效连接。这些规则怎么提炼我的做法是翻自己过去画过的架构图把我在评审时经常提的意见整理成清单再把这清单转成规则。如果你发现自己每次检查架构图时都会说“这里不应该这样连”或者“这个组件不应该出现在这个位置”那这句话就是一条很好的规则素材。第三个方向组织级规则。这类规则来自团队或公司的架构规范。比如规定数据访问层只允许被服务层调用、规定所有状态变更必须经过某个事件总线。这类规则通常有强约束力一旦违反就需要打回重画。规则文件本身我建议用声明式的方式写每条规则包含四个部分规则名称、适用对象、判定条件、处置建议。比如“服务数据库隔离”这条规则适用对象是所有标注为微服务的节点判定条件是检查每个微服务节点关联的数据库节点是否唯一且不共享处置建议是如果发现共享数据库提示为相关服务拆分独立数据存储或者明确说明使用共享数据库的业务合理性。这样AI在接收到验收报告时能拿到足够明确的修正指引。3.3 让流水线跟AI工具链联动起来装好skill、配好规则之后接下来的问题是怎么让archify真正嵌入到你日常的AI画图工作流里。我的使用习惯是这样的直接在AI对话里发起一个画图任务把业务需求和约束条件一次性说清楚。然后AI会先输出设计说明我快速看一下设计方向有没有问题没有的话就让它开始画。画完第一版我会说一句“用archify验收这张图”它就自动进入验收流程返回一份验收报告。如果报告里有需要修正的地方我会让AI根据报告逐条修正然后再验收直到通过。整个流程里我做的事情就是两次确认第一次确认设计方向第二次确认最终结果。这里有一个经验分享提示词里最好明确要求AI每次修改后报告修改内容不要让它只回一句“已修改”。我踩过这个坑。有一次验收不过AI说“已将不规范的连接修正”我信了结果一看图它只是把那条不规范连线的颜色改了一下方向并没有变。后来我在提示词里加了一条“每次修改后列出修改的具体内容和原因”这种虚假操作基本就杜绝了。你不需要把这个要求写进skill规则里但建议把它加到你的常用提示词模板中。另外如果技术条件允许把archify和本地的代码分析工具做联动效果会上一层楼。比如我在一个Java项目上试过让AI根据代码里实际的依赖关系生成架构图生成的节点关系与Maven依赖分析结果完全一致。这样画出来的图就不是“AI想象中的架构”而是“代码里真实存在的架构”。虽然这一步不是archify的必需功能但做好的话对架构评审的准确率提升很明显。4. 踩坑实录与排查技巧4.1 验收器为什么总报“节点类型不合法”我刚开始用archify时遇到最多的问题是语法层报“节点类型不合法”。一开始我以为是规则配置写错了后来才发现问题出在架构图文件本身。很多AI在生成架构图时会用一种比较自由的格式来描述节点类型。比如在Mermaid格式里节点类型有固定的枚举值包括[矩形]、(圆角矩形)、{菱形}、((圆形))等。但模型有时候会写出一些非标准语法比如把(())写成()嵌套或者漏了结束括号。这些不合法内容在Mermaid渲染器里通常会引发告警或显示异常但很多AI工具在生成时并不会主动检查这一点因为它们没有解析器。解决方法有两个。第一在提示词里明确告诉AI“必须使用标准语法生成架构图”并给出一个标准示例。第二在验收规则里把语法解析放在最前面任何语法不正确的图直接打回重画不要进入语义检查。这样能减少很多不必要的排查时间。4.2 “伪通过”问题验收全过了图还是有瑕疵这是很考验使用经验的一个问题。验收通过了说明图在语法、语义、架构合理性三层都满足了你定义的规则。但这不等于图完美无缺因为你的规则集不可能覆盖所有方面。举个例子。有一次我把验收规则配置得很严格端口匹配、依赖方向、命名规范全都过了。结果验收通过之后我拿给团队里的同事看他一眼就发现——支付服务的超时时间设置成了60秒而这个业务的SLA要求是3秒。这个明显不合理但验收器根本管不了因为我没有定义“超时时间不能超过5秒”这条规则。所以要理解“验收通过”不等于“设计正确”——它只代表“符合当前规则约束”。想要图的质量越来越高规则集需要不断迭代。我的建议是每次评审完AI画出的图之后把现场提出的修改意见沉淀为新的规则。有两条我就加两条有三条我就加三条。这样迭代两三个项目之后你的规则集就非常有针对性了。4.3 上下文过长导致模型信息混乱运行archify的时候还有一个很实际的问题需要处理整个流程的上下文长度消耗非常快。一次完整的验收可能要经历多轮“画图→检查→修正→再检查”每一步都得把当前版本的图结构完整放在上下文里。如果项目比较庞大几十个组件加上几十条连线再加上验收报告和修改指令非常容易撑爆上下文窗口。上下文过长之后会出现什么情况AI开始“忘了”之前的验收反馈或者对节点命名开始漂移同一个组件在这轮叫“OrderService”下一轮就变成了“ordersvc”。这种信息混乱会导致验收过程反复振荡——明明上一轮已经修好了A问题这一轮又冒出来了原因就在于上下文里相关信息被挤掉了。我踩过这个坑之后调整了使用方式不要把整个画图流程放在同一个会话里。每个环节尽量精简上下文画完第一版之后就把图文件保存下来在验收阶段用“文件引用简短指令”的方式来启动验收而不是把整个图都贴在对话里。这样能显著减少上下文占用验收的稳定性也会提高很多。如果用的是支持MCP的工具还可以把“读取架构图文件”的能力暴露给模型这样模型只需要告诉工具“读取xxx文件并发送给验收器”而不需要自己在上下文里保留整张图的完整文本。这个技巧对大型架构图特别有用推荐有条件的都试一下。4.4 验收反馈太模糊模型不知道怎么改这个问题常见于规则配置初期。很多人刚配好规则时给出的处置建议往往是一句话比如“连接不符合规范”。但模型收到这种反馈时并不知道“规范”具体指什么也不知道应该改成什么样结果就是它只能瞎猜改完之后大概率还是不通过。我在前文提到规则要包含“处置建议”这部分一定要尽量具体。举个对比模糊的反馈“服务A到服务B的连接不符合规范”具体的反馈“服务A到服务B的连接使用了HTTP同步调用但根据规则R12服务之间的调用必须通过消息队列进行异步解耦。请将连接类型修改为MQ异步消息并更新连线标签。”第二种反馈里规则编号、当前问题、期望行为、修改方法全部都有了模型在这种反馈下基本能一次改对。如果你发现自己的模型总是一轮又一轮地改不对先去检查一下验收报告是不是写得不够具体很多时候问题出在这里而不是模型能力上。4.5 不同模型对同一验收结果的修复能力差异巨大这个坑比较隐蔽但也值得说一说。archify这套验收流程的效果很大程度上取决于你用的是哪款模型。实测下来不同模型在“根据验收反馈修复图形”这个任务上的表现差异非常大。能力强的模型在拿到验收报告后能够精准定位到具体节点和连线一次性把所有问题都改掉。能力较弱的模型则经常出现“修A坏B”的情况它在修复某个连线规则问题时又弄坏了另一个原本合法的节点属性导致验收反而从“差一步就通过”变成了“错误更多了”。我的应对策略也很简单在修复阶段让AI每次只修一个层级的规则问题。先只修语法层验收过了再修语义层最后再处理架构合理性层。虽然看起来多做了几轮但实际时间基本上也是可控的。总的情况是不管用哪个模型如果一次让它处理太多问题出错率就会明显上升。逐层修复是提高验收通过率最稳妥的方法。5. 一点补充心得用了一段时间archify之后最大的感触不是“AI画架构图变得更准了”而是“我终于可以从画图这个环节里抽出时间来做更有价值的事情了”。过去我把大量时间花在跟AI来回对话、手动纠正细节上那是一种消耗性的工作你做完了并不会觉得自己有什么进步。现在有了验收流水线画图和审图的流程被自动化了大半我可以把精力放在更重要的架构决策上——比如边界划分是否合理、未来演进方向是什么、当前方案的取舍在哪里。另外一个感触是这套“给生成式AI加验收”的思路价值远不止架构图这一个场景。代码生成需要CI流水线来验证架构图生成需要验收流水线来把关将来AI生成测试用例、生成部署文档、生成数据分析报告哪一个场景不需要类似的验收机制AI生成内容的质量越不稳定验收机制的刚需就越大。这个思路未来还有很大的扩展空间我后续也计划把同样的模式用到AI生成技术方案文档的流程里规则已经在设计了。最后分享一个小技巧如果团队里有人要评审你AI生成的架构图而你又不想被追问“这图靠不靠谱”那就把验收报告也一并贴过去。这比你说一百句“我检查过了”都有说服力。我自己就是这么干的。
AI画架构图总出错？用验收流水线让AI自动修正
1. 为什么AI画架构图总差点意思——先搞清楚痛点在哪我一直觉得让AI画架构图这件事像极了让一个实习生第一次独立画系统设计图。你说他不会吧他确实能画出来你说他会吧画完你总得改半天改到最后还不如自己重画来得快。这个“差点意思”的感觉在过去一年里几乎每次用AI画架构图都会冒出来。拿我最近一次用某款AI画微服务架构图举例。我给的需求很简单一个电商系统前端、网关、订单服务、库存服务、用户服务、支付服务再加一个消息队列做异步解耦。模型吐出来的图第一眼看上去真像那么回事方框、箭头、分层都有。可仔细一瞧就露馅了订单服务直接连到了数据库但库存服务的数据源标成了“MySQL订单库”支付回调的箭头画到了前端实际上是应该到网关更重要的是这幅图里没有一个地方标注了服务之间的调用协议是HTTP还是RPC是同步还是异步全靠我靠常识去猜。这种问题不是偶发而是几乎每次都会出现。我试过换更好的模型试过写更长的提示词也试过把参考架构贴给它让它模仿结果改善程度都很有限。为什么根子上的原因在于大模型天生是一个“生成器”不是一个“校验器”。它的训练目标是从概率分布里采样出最像样的内容并没有一种“画完之后逐条检查对错”的机制。就好比你让一个很会写诗的人去改自己的诗是否符合格律他能改但改完依然可能出现平仄问题因为他的注意力在“写得漂亮”上而不在“逐字核对”上。AI生成架构图也是一样它的注意力在“画得完整”上而不在“每个连接是否真的说得通”上。另外还有一个现实问题——上下文长度。一次画图任务里几十个组件、几十条连线、每个组件的属性这些信息叠加起来很容易就把模型的上下文撑得很大。模型在这种状态下很容易顾此失彼前面定的命名规则后面忘了前面说的连接方式后面画歪了。这不是模型笨而是它在超长上下文里的注意力天然会衰减。你让一个人同时处理五十个变量的逻辑关系他也一定会出错。这些痛点积累到一定程度就逼着我思考如果“让AI自己画得对”这条路走不通那能不能换一条思路——既然AI画完总有问题那我们就给它的输出加一道验收让图在交付之前自动被检查一遍不合格就打回去重画直到满足所有规则为止。这就是我后来折腾 archify 这个方案的核心出发点。2. archify的核心思路给AI加一条验收流水线2.1 验收流水线到底是什么我第一次听说“验收流水线”这个词是在一个做AI编程工具的朋友那里。他说他们在给AI生成的代码做自动化测试、静态扫描、构建检查一套流程走下来没通过的代码根本不会合并进主干。我当时就冒出一个念头代码能这么干架构图凭什么不能archify做的就是这件事——它不试图教AI怎么画得更好而是给AI画完的图加了一整套自动验收流程。这个流程从三个层面层层检查就像工厂里的质检线第一层语法层检查图本身是不是合法的。节点有没有名字、类型是否在允许范围内、连线有没有指向不存在的节点、图文件能不能被标准工具正常解析。这一层解决的是“图能不能用”的问题。第二层语义层检查连接关系是否合理。A服务的输出端口是否连到了B服务的输入端口关联的协议标注是否一致有没有悬空的孤立节点有没有同一条连接被重复定义了两次。第三层架构合理性层检查整体设计是否符合架构规范。有没有出现循环依赖、有没有跨层调用、有没有把数据库直接暴露给了前端以及一些你自定义的组织级规则。每层检查的结果都会汇总成一份“验收报告”报告里会明确列出哪条规则不通过、涉及哪些节点和连线、建议怎么修。AI拿到这份报告后会根据反馈进行针对性修改改完再送检直到全部通过为止。有人可能会问这跟让用户自己看图、发现问题、再去改提示词重画有什么区别区别非常大。人工看图这件事本质上是一个隐性知识密集的过程。你需要知道这个系统应该长什么样、服务边界在哪、依赖方向怎么合规这些经验不是每个人都能快速调用的。而验收流水线把这一堆隐性知识变成了显性规则机器可以自动执行可以瞬时反馈100次检查结果稳定一致。它不依赖当时的心情、不依赖瞌睡程度、也不依赖你今天是不是特别想仔细看这张图。我在实际使用中最直观的感受是过去用AI画架构图一个来回至少10分钟因为我要自己看、自己找问题、自己组织语言去反馈常常一个图要来回三四次才能满意。现在有了验收流水线一个来回可能就2分钟因为AI自己就能看到哪里不满足规则自己就能迭代修正我只需要做最后的人工确认。2.2 每一层在干什么为什么非要分层这里我想多说几句为什么非要把验收拆成三层而不是全部揉成一条规则。如果全部揉在一起会有一个很麻烦的问题错误定位困难。比如AI画了一张图数据库直接暴露给了前端同时还有一个节点没有名字两个问题同时存在。这时候如果只给AI一句“验收不通过请修正”它是不知道该先改哪个的而且很可能改了数据库暴露的问题之后又忘记了节点没命名这事。因为模型的上下文是有限的一次反馈里指出的问题太多它反而容易漏掉关键项。分层的意义在于让问题被逐层暴露被逐层解决每一轮迭代的修改范围都足够小。语法层不通过就不进入语义层语义层不通过就不进入架构合理性层。这就像你写代码时先过编译再跑单元测试最后做代码评审——每一道关卡负责一类问题不会混在一起。以我自己配置过的一个真实场景来举例。我之前做一个订单中台项目要求所有服务依赖必须单向流动网关层可以调用服务层服务层可以调用数据层但服务层决不允许反向依赖网关层。我把这条规则写进了架构合理性层。结果第一次验收AI画了一张图里面有个服务居然反向调用了网关的一个接口。这个错误语法层查不出来因为节点合法、连接合法语义层也查不出来因为端口匹配、连接也没有悬空。只有到了架构合理性层规则引擎识别出“服务层节点访问了网关层节点”才把它拦截下来。这也说明了为什么分层是必须的——不同类型的错误需要用不同的规则去识别而每一类规则的数据来源和判定逻辑完全不同。语法层只需要解析图结构本身语义层需要理解组件的输出输入语义架构合理性层需要理解你自定义的架构约束。硬把它们混在一层里规则引擎会变得异常复杂而且很难排查“为什么这条规则没生效”。2.3 一次典型的验收失败过程我来讲一次真实的失败案例。有一次我让AI画一个数据中台的架构图需求包含了数据采集、数据存储、数据计算、数据服务四个层次。AI画完第一版我把它送到验收流水线里结果反馈是这样的语法层发现两个节点没有填写类型字段一个节点命名重复图文件使用标准解析器加载时报错。这属于很基本的问题说明模型在长上下文中丢失了基础元信息。修正后送到语义层提示“数据采集节点的输出端口(output_raw)未连接到任何目标节点”同时“数据服务节点的API端口被连接到了数据存储节点的存储端口端口类型不匹配”。再修正后送到架构合理性层发现“数据计算层的调度组件直接访问了数据服务层提供的API违反了分层规范”。这个过程看起来挺折腾但它比我手动看图修改要快得多——每轮验收只需要几十秒三轮下来不到五分钟。如果用人工方式我得自己打开图、一个个对节点、查连线、回想架构规范没有二十分钟搞不定。而且最让我放心的是最后一版图通过验收之后所有规则都是我事先定义好的不是我拍脑袋临时想的。2.4 为什么“先想后画”能大幅提升验收通过率这里还有一个关键点要提——大部分人在用AI画架构图时拿到需求直接就让AI开画。这是很容易踩坑的做法。AI在没有经过深层次思考的情况下很容易选择一个“差不多”的方案然后在这个方案上衍生出各种细节。这种“差不多”方案往往隐藏着架构层面的硬伤比如把某种中间件放到了不合适的位置、把原本应该解耦的服务硬耦合在一起。archify的skill配置里有一条很值得借鉴的强制规则在生成任何图形代码之前必须先输出一份设计说明。包括这个架构图的业务目标是什么、有哪些关键组件、组件之间的依赖关系怎么定义、数据流怎么走、哪些组件需要扩展。设计说明输出完之后AI才能开始画图。这个机制本质上是在逼AI先把架构思考清楚再用图形语言复现这个思考。实践中我发现加了这一步之后第一版图通过验收的比例提升了非常多。为什么因为当AI把设计思路用自然语言先表达出来时相当于经历了一次内部的逻辑整理很多明显的矛盾在这个阶段就被发现了。这和程序员写代码前先写设计文档是一个道理——并不是说文档有多重要而是写文档的这个过程强迫你把逻辑理顺乱成一团的想法很难在纸面上立住脚。AI也是一样它不会像人一样主动“想清楚再动手”你需要在流程上强制它这么做。3. 实操把archify接入你的AI画图流程3.1 环境准备与安装archify不是一款独立的桌面软件它更像一个“技能包”可以接入到主流的AI对话工具里。具体安装过程在这里不展开太多我只说几个容易出问题的地方。Skill 文件配置你需要把archify的skill定义文件放到指定的目录里。这个文件定义了“验收流水线”的所有规则和步骤。装好之后你可以在AI对话里通过特定的触发词启动它比如直接说“用archify检查一下这张图”。规则配置这是最关键的一步。archify默认带了一些通用规则包括组件类型校验、连接合法性校验、孤立节点检测、重复组件检测等。但真正的价值来自你根据自己项目定制的那部分规则后面我会单独说。MCP工具链对接如果你用的是支持MCP模型上下文协议的AI工具可以把archify暴露成MCP服务让它具备读取项目文档、读取既有架构图文件、甚至读取代码仓库里依赖关系的能力。这一步做好的话能达到一个很实用的效果——AI画图之前可以先扫描一下你项目的实际依赖关系画出来的图就不会跟真实代码脱节。安装完成之后我建议你用一个非常简单的测试用例先验证流水线是否正常工作让AI画一个只有三个组件的最小架构图然后手动制造一个明显错误比如让B组件连接到不存在的C组件再让archify去检查看它能不能准确捕获到这个错误。这一步能确认配置正确之后再用真实项目来跑。3.2 怎么写验收规则才能让流水线真正干活这是我认为archify整个方案里最值得花时间琢磨的部分。规则写得好不好直接决定了这套流水线是在替你干活还是在替你添乱。我的建议是规则不要从一开始就追求大而全而是从三个方向逐步补齐。第一个方向基础通用规则。这类规则每个项目都需要也是默认就有的。包括节点必须有名称、节点类型必须在合法范围内、连线两端必须指向真实存在的节点、不能有孤立节点、不能有重复的组件ID。这些规则不需要你去创造你只需要确保它们处于开启状态即可。第二个方向项目定制规则。这类规则来自你的项目实际情况。比如你的项目规定所有微服务都必须有独立的数据库不能共享规定外部请求必须经过API网关不能直接打到服务上规定服务之间的调用必须标注协议类型否则视为无效连接。这些规则怎么提炼我的做法是翻自己过去画过的架构图把我在评审时经常提的意见整理成清单再把这清单转成规则。如果你发现自己每次检查架构图时都会说“这里不应该这样连”或者“这个组件不应该出现在这个位置”那这句话就是一条很好的规则素材。第三个方向组织级规则。这类规则来自团队或公司的架构规范。比如规定数据访问层只允许被服务层调用、规定所有状态变更必须经过某个事件总线。这类规则通常有强约束力一旦违反就需要打回重画。规则文件本身我建议用声明式的方式写每条规则包含四个部分规则名称、适用对象、判定条件、处置建议。比如“服务数据库隔离”这条规则适用对象是所有标注为微服务的节点判定条件是检查每个微服务节点关联的数据库节点是否唯一且不共享处置建议是如果发现共享数据库提示为相关服务拆分独立数据存储或者明确说明使用共享数据库的业务合理性。这样AI在接收到验收报告时能拿到足够明确的修正指引。3.3 让流水线跟AI工具链联动起来装好skill、配好规则之后接下来的问题是怎么让archify真正嵌入到你日常的AI画图工作流里。我的使用习惯是这样的直接在AI对话里发起一个画图任务把业务需求和约束条件一次性说清楚。然后AI会先输出设计说明我快速看一下设计方向有没有问题没有的话就让它开始画。画完第一版我会说一句“用archify验收这张图”它就自动进入验收流程返回一份验收报告。如果报告里有需要修正的地方我会让AI根据报告逐条修正然后再验收直到通过。整个流程里我做的事情就是两次确认第一次确认设计方向第二次确认最终结果。这里有一个经验分享提示词里最好明确要求AI每次修改后报告修改内容不要让它只回一句“已修改”。我踩过这个坑。有一次验收不过AI说“已将不规范的连接修正”我信了结果一看图它只是把那条不规范连线的颜色改了一下方向并没有变。后来我在提示词里加了一条“每次修改后列出修改的具体内容和原因”这种虚假操作基本就杜绝了。你不需要把这个要求写进skill规则里但建议把它加到你的常用提示词模板中。另外如果技术条件允许把archify和本地的代码分析工具做联动效果会上一层楼。比如我在一个Java项目上试过让AI根据代码里实际的依赖关系生成架构图生成的节点关系与Maven依赖分析结果完全一致。这样画出来的图就不是“AI想象中的架构”而是“代码里真实存在的架构”。虽然这一步不是archify的必需功能但做好的话对架构评审的准确率提升很明显。4. 踩坑实录与排查技巧4.1 验收器为什么总报“节点类型不合法”我刚开始用archify时遇到最多的问题是语法层报“节点类型不合法”。一开始我以为是规则配置写错了后来才发现问题出在架构图文件本身。很多AI在生成架构图时会用一种比较自由的格式来描述节点类型。比如在Mermaid格式里节点类型有固定的枚举值包括[矩形]、(圆角矩形)、{菱形}、((圆形))等。但模型有时候会写出一些非标准语法比如把(())写成()嵌套或者漏了结束括号。这些不合法内容在Mermaid渲染器里通常会引发告警或显示异常但很多AI工具在生成时并不会主动检查这一点因为它们没有解析器。解决方法有两个。第一在提示词里明确告诉AI“必须使用标准语法生成架构图”并给出一个标准示例。第二在验收规则里把语法解析放在最前面任何语法不正确的图直接打回重画不要进入语义检查。这样能减少很多不必要的排查时间。4.2 “伪通过”问题验收全过了图还是有瑕疵这是很考验使用经验的一个问题。验收通过了说明图在语法、语义、架构合理性三层都满足了你定义的规则。但这不等于图完美无缺因为你的规则集不可能覆盖所有方面。举个例子。有一次我把验收规则配置得很严格端口匹配、依赖方向、命名规范全都过了。结果验收通过之后我拿给团队里的同事看他一眼就发现——支付服务的超时时间设置成了60秒而这个业务的SLA要求是3秒。这个明显不合理但验收器根本管不了因为我没有定义“超时时间不能超过5秒”这条规则。所以要理解“验收通过”不等于“设计正确”——它只代表“符合当前规则约束”。想要图的质量越来越高规则集需要不断迭代。我的建议是每次评审完AI画出的图之后把现场提出的修改意见沉淀为新的规则。有两条我就加两条有三条我就加三条。这样迭代两三个项目之后你的规则集就非常有针对性了。4.3 上下文过长导致模型信息混乱运行archify的时候还有一个很实际的问题需要处理整个流程的上下文长度消耗非常快。一次完整的验收可能要经历多轮“画图→检查→修正→再检查”每一步都得把当前版本的图结构完整放在上下文里。如果项目比较庞大几十个组件加上几十条连线再加上验收报告和修改指令非常容易撑爆上下文窗口。上下文过长之后会出现什么情况AI开始“忘了”之前的验收反馈或者对节点命名开始漂移同一个组件在这轮叫“OrderService”下一轮就变成了“ordersvc”。这种信息混乱会导致验收过程反复振荡——明明上一轮已经修好了A问题这一轮又冒出来了原因就在于上下文里相关信息被挤掉了。我踩过这个坑之后调整了使用方式不要把整个画图流程放在同一个会话里。每个环节尽量精简上下文画完第一版之后就把图文件保存下来在验收阶段用“文件引用简短指令”的方式来启动验收而不是把整个图都贴在对话里。这样能显著减少上下文占用验收的稳定性也会提高很多。如果用的是支持MCP的工具还可以把“读取架构图文件”的能力暴露给模型这样模型只需要告诉工具“读取xxx文件并发送给验收器”而不需要自己在上下文里保留整张图的完整文本。这个技巧对大型架构图特别有用推荐有条件的都试一下。4.4 验收反馈太模糊模型不知道怎么改这个问题常见于规则配置初期。很多人刚配好规则时给出的处置建议往往是一句话比如“连接不符合规范”。但模型收到这种反馈时并不知道“规范”具体指什么也不知道应该改成什么样结果就是它只能瞎猜改完之后大概率还是不通过。我在前文提到规则要包含“处置建议”这部分一定要尽量具体。举个对比模糊的反馈“服务A到服务B的连接不符合规范”具体的反馈“服务A到服务B的连接使用了HTTP同步调用但根据规则R12服务之间的调用必须通过消息队列进行异步解耦。请将连接类型修改为MQ异步消息并更新连线标签。”第二种反馈里规则编号、当前问题、期望行为、修改方法全部都有了模型在这种反馈下基本能一次改对。如果你发现自己的模型总是一轮又一轮地改不对先去检查一下验收报告是不是写得不够具体很多时候问题出在这里而不是模型能力上。4.5 不同模型对同一验收结果的修复能力差异巨大这个坑比较隐蔽但也值得说一说。archify这套验收流程的效果很大程度上取决于你用的是哪款模型。实测下来不同模型在“根据验收反馈修复图形”这个任务上的表现差异非常大。能力强的模型在拿到验收报告后能够精准定位到具体节点和连线一次性把所有问题都改掉。能力较弱的模型则经常出现“修A坏B”的情况它在修复某个连线规则问题时又弄坏了另一个原本合法的节点属性导致验收反而从“差一步就通过”变成了“错误更多了”。我的应对策略也很简单在修复阶段让AI每次只修一个层级的规则问题。先只修语法层验收过了再修语义层最后再处理架构合理性层。虽然看起来多做了几轮但实际时间基本上也是可控的。总的情况是不管用哪个模型如果一次让它处理太多问题出错率就会明显上升。逐层修复是提高验收通过率最稳妥的方法。5. 一点补充心得用了一段时间archify之后最大的感触不是“AI画架构图变得更准了”而是“我终于可以从画图这个环节里抽出时间来做更有价值的事情了”。过去我把大量时间花在跟AI来回对话、手动纠正细节上那是一种消耗性的工作你做完了并不会觉得自己有什么进步。现在有了验收流水线画图和审图的流程被自动化了大半我可以把精力放在更重要的架构决策上——比如边界划分是否合理、未来演进方向是什么、当前方案的取舍在哪里。另外一个感触是这套“给生成式AI加验收”的思路价值远不止架构图这一个场景。代码生成需要CI流水线来验证架构图生成需要验收流水线来把关将来AI生成测试用例、生成部署文档、生成数据分析报告哪一个场景不需要类似的验收机制AI生成内容的质量越不稳定验收机制的刚需就越大。这个思路未来还有很大的扩展空间我后续也计划把同样的模式用到AI生成技术方案文档的流程里规则已经在设计了。最后分享一个小技巧如果团队里有人要评审你AI生成的架构图而你又不想被追问“这图靠不靠谱”那就把验收报告也一并贴过去。这比你说一百句“我检查过了”都有说服力。我自己就是这么干的。
