多智能体流水线：3小时从需求文档生成架构图的实操指南

从需求文档到架构图，过去我至少要磨三天；最近用一套多智能体流水线，直接把首版架构图的时间压到了3小时。这事不是我拍脑袋吹牛，而是我把流程拆开、把每个环节的耗时算明白之后，跑出来的实操套路。如果你是架构师、技术负责人，或者正准备带团队做系统设计评审，这篇文章值得看完——我会把角色分工、提示词模板、处理步骤、踩过的坑全部摊开讲。

上周某团队找我做一套库存与订单一体化系统的前期设计，六十几页需求文档发过来，换以前，我光通读加划重点就得一整天，再到第一版架构图出来，三天跑不掉。这次我用了解析、设计、制图、校验四个智能体角色串成流水线，一个下午出了首版架构图，团队评审后只补了两处模块边界调整。先说清楚：智能体做不了架构决策，但它能把你从“反复翻文档、反复整理信息”的苦活里捞出来。

1. 先拆时间账：架构师那3天到底耗在哪里

1.1 四件事吃掉绝大部分时间

我观察过不少架构师画图的过程，也统计过自己过去几个项目的实际开销。传统路径大概是这样的：

加起来基本就是3天上下。注意一个容易被忽略的事实：表格里“画图”本身只占了不到三分之一的时间，真正的大头在“读文档、找信息、做判断”。如果只把画图动作自动化，省下来的时间非常有限，必须把前面那几项也一起处理掉，才能实现数量级上的压缩。

1.2 真正慢的不是画图，而是“决策前的情报整理”

很多人误以为架构师的核心价值是“画架构图”这个动作。其实你用绘图工具拖一拖，半小时就出来。时间的黑洞在于：需求文档里描述的功能散落在几十页的不同章节，有的在业务背景里提了一句，有的藏在接口设计里；数据实体分布在各处，命名还不统一。架构师得把这些碎片信息捞出来，在脑子里拼成一张完整的业务地图，然后才谈得上划分模块、决定依赖方向。

这个过程本质上就是一次“信息检索加结构化整理”。而这恰恰是大模型最擅长的事：长文本阅读、实体抽取、跨章节信息合并。把这一步交给智能体做初步整理，架构师直接基于整理结果做判断，省掉的是将近八成的机械劳动。我常跟团队说一句话：AI不是替你思考，是替你把案头工作先干完，让你把精力留给真正需要经验的部分。

1.3 不是所有需求文档都适合这套打法

我试过十几个项目之后，总结出三个前提条件。第一，需求文档有基本结构，至少目录清晰、有功能描述或用例说明。第二，业务流程相对稳定，不会上午讨论完、下午就推翻重来。第三，文档里有可以提取的实体信息，比如角色、数据表、外部系统、接口点。这三点缺一条，智能体的发挥空间就大打折扣。

如果需求全靠口头沟通、文档只有两三页提纲，或者业务本身还在剧烈变动，我的建议是先别上智能体，先把文档补齐再说。智能体再快，也架不住输入本身是空的。另外还有一种情况要警惕：文档写得“看上去很全”，但全是“系统应支持各类营销活动”这种正确的废话，这种文档喂给智能体，吐出来的模块清单会非常虚，后面还得花更多时间返工。

2. 智能体不是一个人干活，而是一条流水线

2.1 四类角色如何分工

刚开始做的时候，我犯过一个典型错误：让一个大模型从需求文档直接生成架构图。结果是图画得漂亮，但经不起推敲——模块边界一会儿按业务流程分，一会儿按数据归属分，层级混乱，根本没法交给研发看。后来我把流程拆成四个角色，每个角色只干一件事：

• 需求解析员：读文档，输出结构化的需求清单，涵盖功能点、用户角色、数据实体、外部依赖。
• 架构设计员：基于需求清单判断架构风格，划定模块边界，给出模块划分表。
• 架构制图员：把模块划分转换成图表描述文本，生成分层架构图。
• 架构校验员：对照需求清单检查架构图覆盖率，找出“有需求没落点”和“循环依赖”两类问题。

四个角色串在一起，前一个的输出直接作为后一个的输入，像流水线一样。为什么要拆开？因为角色越专一，提示词约束越简单，输出越稳定。让一个角色同时做抽取、设计、画图、校验，等于让一个实习生既要读文档、又要拍板决策、还要保证图面美观，结果必然顾此失彼。拆分之后，每个环节都可以独立调优，出了问题也知道去改哪一环。

2.2 角色之间靠什么交接：一份“中间表示”

多智能体协作最怕的是信息丢失。如果每个角色都输出一大段自然语言，下一个角色再加工一遍，信息经过两层转述就走样了，等到画图环节，可能连模块名都对不上。我的做法是在角色之间强制传递一份结构化的“中间表示”，核心是一个JSON结构，里面固定四个字段：

• requirements：需求清单，每条带需求编号和来源章节。
• modules：候选模块划分，每个模块标注职责描述。
• relations：模块之间的依赖关系、数据流方向。
• constraints：强约束，比如“必须复用统一认证服务”“所有流量走网关”。

这样设计的好处是：解析员只要做好一件事，把散落在文档里的信息塞进requirements；设计员拿到的是同一种格式，不需要反复猜测前一个角色的口语化描述；制图员只关心modules和relations，按固定模板生成图。信息交接的损耗被压到最低。我把这个JSON结构比作工业流水线上的统一接口标准——每个工位只管好自己的输入输出，不用理解整条线的复杂度。

2.3 两个必须保留的人工检查点

完全无人值守我也试过，结论是不行。智能体再强，也有两类问题它看不见：一类是团队内部的隐性约定，文档里没写但所有老员工都知道；另一类是业务上的“常识性错误”，比如把“用户管理”和“客户管理”当成两个独立模块，实际上在业务里它们指的是同一套账号体系。

所以我在流水线上保留了两处人肉检查点。第一个在架构设计员输出风格判定之后，让负责人确认“微服务还是单体、模块划分大致对不对”，只需要10分钟。第二个在最终图生成之后，做一次正式评审。其余环节全部放手让智能体跑。这两个检查点加起来半小时，换来的是结果可靠性质的提升。切记：检查点不要设太多，否则又退回了传统流程；也不要一个不设，出了问题追责时你会很被动。

3. 3小时实操流程：每一步做什么、怎么写提示词

以下是我目前跑得最顺的一套流程，总共四个步骤，合计约3小时。注意时间分配是递减的：第一步最重，后面越来越轻。不要试图压缩第一步，那里省下的每一分钟，最后都会在返工里加倍还回来。

3.1 第一步：需求清洗与实体抽取（约90分钟）

拿到需求文档后，不要直接整个塞给模型。我的做法是先把文档按章节切成若干片段，每个片段单独抽取，最后再合并去重。为什么这样做？因为大部分需求文档超过50页时，一次全部送入会超出上下文窗口，而且模型对中间部分的内容会“失焦”，读到最后可能把前几章的细节忘得差不多。切成片段后，每个片段都在可控范围内，抽取质量明显更稳。

给解析员的提示词，核心是定义产出格式。我用的是这样一套指令：

你是一名需求解析员。请阅读输入的需求片段，抽取以下四类信息： 1. 功能点：描述系统需要做什么，保留原始表述，标注需求编号。 2. 用户角色：系统服务的角色，注明角色权限线索。 3. 数据实体：涉及的数据对象，如订单、库存、用户，保留字段线索。 4. 外部依赖：与外部系统或服务的交互点。 输出要求： - 使用JSON数组格式。 - 每条记录包含id、type、description、source章节号。 - 无法确认的信息不要编造，在note字段里标注“待确认”。

抽取完成后，把多个片段的JSON合并，再做一次聚类去重。这一步我会再调用一次模型，把表述相近的功能点归并，比如“订单创建”和“提交订单”合并为一条。归并结果就是后续所有环节的需求底表，也是整个项目的信息基准线。这一步实测90分钟左右，真正调模型的时间不过20分钟，其余时间花在人工扫一遍抽取结果、把明显错位的条目修正上。不要省这个过程，直接拿机器结果去画图，大概率会在评审时被业务方指正好几处。

3.2 第二步：架构风格判定与约束注入（约60分钟）

需求底表出来后，进入设计环节。我把架构风格判定做成了“打分加决策”的流程，而不是让模型自由发挥。判断维度固定在几个关键项上：目标用户量与峰值并发、团队是一个整体还是多个小组并行开发、业务上能不能接受最终一致、部署环境是内网单体还是容器化弹性部署。维度固定之后，模型输出的理由才可对比、可质疑，而不是每次给出不同的玄学答案。

设计员的提示词里，我会把需求底表、判定维度和团队约束一起给进去，要求输出决策记录：

你是一名架构设计员。基于需求清单，完成以下任务： 1. 对四个维度逐项评估，给出结论和依据。 2. 推荐架构风格（单体分层/模块化单体/微服务/事件驱动），说明理由。 3. 给出候选模块划分表，每个模块包含：模块名、职责边界、核心功能点编号列表。 4. 标注模块间依赖关系，方向为“谁依赖谁”。 5. 检查是否存在循环依赖，若有，提出调整建议。 团队约束如下： - 技术栈以Java为主，必须复用统一认证服务。 - 内部通信优先走同步接口，异步只在解耦必要处使用。 - 模块命名遵循“业务域+功能”的风格。

这一步通常40分钟能跑完，剩下20分钟做一件重要的事：人工确认架构风格和模块边界。我一般会拉技术负责人一起看，重点检查“模块边界有没有把业务概念切碎”。比如库存和订单两个业务域，到底是谁依赖谁，这种判断模型给的往往是默认方向，但实际业务可能是反过来的，必须人来看。模块边界一旦定错，后面图画得再漂亮都是白费。

3.3 第三步：分层架构图生成与一致性校验（约30分钟）

模块划分确认后，制图员的工作相对机械，但有个关键设计：要分层。我参考C4模型的思路，把架构图分成三层。第一层是系统上下文图，画系统与外部角色、外部系统的关系；第二层是容器图，画应用内部的模块级容器以及模块间依赖；第三层是组件图，只对核心模块展开，画出关键组件的接口。三层分开画，而不是塞进一张图里，这是后面避免“图太密没法看”的根本手段。

生成的时候直接用图表描述文本输出，不做位图渲染。制图员的提示词大概是：

你是一名架构制图员。根据模块划分表和依赖关系，生成架构图的描述文本。 要求： 1. 按三个图层分别组织，图层间用标记区分。 2. 每个模块标注职责和关键功能点编号。 3. 依赖关系标注在模块间连线上。 4. 输出为纯文本的图表描述格式，保持名称与输入完全一致，不得改写。 格式要求如下： [系统上下文] 参与者: 用户, 运营人员, 财务系统, 短信服务 系统: 库存与订单一体化系统 [容器图] 节点: 订单服务, 库存服务, 统一认证服务 连线: 订单服务 -> 库存服务, 标注: 库存扣减API [组件图] 节点: 订单服务.订单创建组件, 订单服务.支付回调组件

输出格式我会用主流的图表描述语言（Mermaid、PlantUML那一路），方便后续转成团队协作绘图空间里可编辑的源文件。图生成后马上接校验环节：校验员拿着需求底表逐条检查每个需求是否至少对应一个模块，模块间有没有反向或循环依赖，有没有需求清单里存在但图上消失的条目。校验输出是一张“需求覆盖矩阵”，每行一个需求编号，每列一个模块名，交叉点打勾。这张表一定要保留，它是后面和业务方对齐需求的“铁证”。

3.4 第四步：人工复核与交付（约30分钟）

3小时的最后30分钟属于人。我一般会把生成的图表源文件拉进绘图工具里做人工排版，同时补两件事。第一，把需求映射表发给熟悉业务的同事过目，确认没有业务概念被合并错，比如“客户”和“会员”在不同团队可能是两个含义。第二，检查架构图上体现不了的隐性依赖，比如运维约定的午夜批量任务、定时报表链路，这些在图上看不见，但真实存在，必须写进决策记录。

交付物是三件套：架构图的源文件、需求映射表、架构决策记录。决策记录里要写明“为什么选微服务而不是单体”“为什么订单服务依赖库存服务而不是反过来”，这些文字比图本身更有价值。有了这三样，后续评审、排期、研发入场都能直接开工，不需要再拉人从头讲一遍背景。

4. 我踩过的坑：常见问题与排查技巧实录

4.1 需求文档质量差：先让智能体提问，而不是硬抽

第一个坑，也是最常见的：需求文档写得很含糊，例如“系统要支持各种优惠活动”这种话，硬抽的结果是抽出一堆“优惠活动”“活动管理”“促销规则”等语义重叠的条目。我现在的处理方式是：第一轮不做抽取，先让解析员基于文档列出“模糊点清单”，也就是它读不懂、需要业务方确认的地方。

把提示词的任务从“抽取信息”改成“列出歧义与缺漏”，效果完全不同。整理出的模糊点发给业务方逐条确认，一版下来文档质量反而提升了。后来我把这个经验固定成了团队培训内容：AI智能体不是拿来取代阅读的，而是拿来逼你把需求讲清楚的。很多需求文档的问题不是缺字，而是表述不一致，智能体恰恰是发现不一致的好工具。

4.2 生成的图要么太密，要么太空

第二个坑是图的可读性。模块划分之后关系一多，一张图塞了几十个节点和上百条连线，根本没法看；或者反过来，图只有八个节点，细节全丢。排查下来，问题出在制图环节没有分层意识。解决方法就是前面说的强制三层结构，并且给每层定上限：系统上下文层不超过10个元素，容器层不超过15个节点，组件层只画核心模块，每个模块展开不超过8个组件。

如果某层超过上限，就停下来重新审视模块划分是否过细，把边界上移。这条规则我现在直接写死在提示词里，作为输出校验条件，超过数量就报错重来，而不是硬着头皮生图。宁可少画一个组件，也不要让看图的研发同事在密密麻麻的连线里找半天。

4.3 幻觉问题：需求映射表是定海神针

第三个坑，也是做这类方案最怕的：模型在生成图时自己“脑补”了一个不存在的模块，或者把业务实体名称张冠李戴。我第一次遇到时，因为没做映射校验，差点把错误的架构图发出去。后来我把“映射表”当成硬性产出物，校验员必须逐条检查需求到模块的映射，任何一条需求如果没有落点模块，必须显式标注“未覆盖”，不允许悄悄吞掉。

为了进一步压缩幻觉，我在提示词里加了一条硬规则：制图员和校验员都不允许创造新的实体名称，所有名称必须来自输入的需求清单。哪怕模型觉得某个地方缺一个“订单查询组件”，也只能以“待补充”标记，不能凭空写上去。这招实测非常管用，把幻觉出错的概率降到了很低。记住：给智能体越少的自由发挥空间，结果就越可控。

4.4 和团队现有工具链的衔接

最后一个坑在协作层面。智能体生成的图表文本直接贴进团队已有的绘图工具，经常出现样式混乱、字体丢失的问题。我的做法是让制图员输出标准图表描述格式，然后在本地用脚本批量转换，转入团队的在线协作绘图空间，再手动调整布局。整个转换成本不到10分钟，但是比“复制粘贴然后全员抓瞎”强得多。

另外一个小建议：生成的架构图源文件一定要进版本库，和代码同仓管理。架构图和代码一样是会被持续修改的资产，不进版本库的图，三个月后就没人知道当时为什么这么画了。我见过太多项目，架构图躺在某个人的本地磁盘里，团队迭代半年后，图早就和真实系统脱节，变成一张挂在墙上供人参观的“历史文物”。

5. 边界在哪里：哪些环节智能体真的替代不了

5.1 这套打法适合什么、不适合什么

把适合的场景列成一张清单，方便你对号入座：

• 新系统从零设计，需求文档相对完整，需要一个可讨论的首版架构。
• 遗留系统重构，要对现有模块做盘点，先画“现状图”再谈改造方案。
• 技术预研或售前方案，需要快速从客户需求里整理出系统蓝图和功能边界。
• 架构评审前的草稿准备，给评审提供一个供大家质疑和修改的基础版本。

不适合的也很明确：高度创新的架构方案、安全关键系统（支付清算、医疗核心、军工类），以及需要极深领域知识才能判断的业务域。不是说智能体在这些场景完全不能用，而是一旦出错，代价远高于节省下来的几天时间。我在这类项目上的建议是：可以用智能体做资料整理和初稿辅助，但最终架构认定要走更严格的人工评审流程，甚至引入外部专家复核。

5.2 智能体是“超强实习生”，不是“架构师”

这句话我反复跟团队讲。智能体能快速整理信息、给出合理的候选方案、把图画得工整，但它不理解业务背后的权衡。为什么这里要接受最终一致而不是强一致，为什么某个模块宁可保留耦合、也不要为了表面优雅强行拆开，这些决策依赖的是架构师在项目现场摸爬滚打积累的判断力。

我能给的最贴切定位是：智能体是一个“检索速度极快、绘图手艺极好、从不抱怨的实习生”。它帮你把三天压缩成三小时，但最终拍板的那个人必须是你。你要做的，是把前三个小时当成快进播放的“信息整理阶段”，把省出来的两天放在真正的架构决策、风险评估和与业务方的对齐上。

5.3 真正的收益：把省下来的两天花在刀刃上

我实测多次之后，最大的感受是：省时间只是表面收益，更深层的变化是工作方式的改变。以前画架构图是“先画后对”——先凭记忆画一版，再回头翻文档校对；现在变成“先对齐再画”——需求底表先出来，业务方先确认信息无误，再进入画图环节。智能体把“信息整理”这件事做得又快又结构化，反而把架构师拉回到真正有创造性的决策环节。

这也是我想强调的：不要把这套流程当成一个“自动化工具”来崇拜，它本质上是一套把需求结构化、把决策显性化的方法。智能体只是恰好把最枯燥的那一步提速了。工具会迭代，模型会换，但“先结构化、再决策、再可视化”的思路，在任何一轮技术浪潮里都成立。

最后分享一个我自己的使用习惯。每次跑这套流程，我都会把第一步产出的“需求底表”单独存档，哪怕后面架构图改了三版，这份底表始终是唯一的参照系。几次项目下来，我发现团队对需求的理解一致性明显变好，因为大家在评审时讨论的是同一份结构化清单，而不是各自脑子里那本需求文档。

我个人体会是，AI智能体的意义不在于替代人画出一张完美架构图，而在于它把“从需求到架构”这个过程从一潭浑水，搅出了一条清晰的过滤通道。至于怎么在通道尽头做出好的架构决策，那永远是我们自己的功课。