企业官网建设流程全解析

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生成的架构图，而你又不想被追问“这图靠不靠谱”，那就把验收报告也一并贴过去。这比你说一百句“我检查过了”都有说服力。我自己就是这么干的。