AI智能体工作流：3小时从需求文档到架构图的实践

你遇到过这种情况吗产品经理丢过来一份五十多页的需求文档里面有用户故事、业务流程、接口备注、遗留系统说明甚至还有几段表格粘贴错了格式。作为架构师你接下来要做的就是把它变成一张能用来评审、能指导后续开发的架构图。过去我干这事通常要两到三天第一遍通读第二遍圈出冲突第三遍跟产品确认边界第四遍画图第五遍因为评审意见重画。如今我用一套 AI 智能体工作流把它压到了三个小时左右产出不是玩具级示意图而是可以直接进评审会的架构草稿。这篇文章就把这套流程拆开讲清楚AI 智能体到底在“需求文档到架构图”这条链路里做了什么哪些环节真的能替代人力、哪些环节是在帮倒忙以及 3 小时和 3 天之间到底差在哪一步。不管你是正在被需求文档折磨的架构师还是想给团队引入智能体工作流的技术负责人这篇都值得往下看。我会把缺陷和翻车现场也一并说透因为后半部分才是真正决定你能不能省下那两天的关键。1. 拆解架构师的“三天”时间其实都花在哪里1.1 第一天的真实消耗不是阅读是“消化”很多人以为画一张架构图最花时间的是动手画其实不是。我统计过自己做这类任务的真实时间分配真正打开绘图工具的时间通常不超过 20%剩下 80% 都在做信息处理。需求文档远没有你想象的那么规整——功能需求混在用户的抱怨里接口定义散落在附录中关键的业务规则可能只出现在某一次会议纪要的某一行。第一天下午你往往不是在读文档而是在判断“这句话对系统边界到底有没有影响”“这个角色到底是外部系统还是普通用户”。这种消化工作为什么如此费时因为需求文档中大量信息是隐式的。举个例子文档里写“用户可以通过微信扫码登录也可以使用手机号验证码登录”看起来只要画一个统一的认证模块就行。但细想一下会发现“微信扫码”意味着引入了第三方身份服务这里涉及跳转、回调、用户协议隐私边界而“手机号验证码”则意味着短信网关、频率限制和防刷机制。这些隐含的组件和外联系统需要一个有经验的架构师逐句补全而补全的过程本质上是在调用你脑子里已经存好的架构经验库。1.2 第二天的时间黑洞边界收敛与技术拉扯第一遍消化完成后你会设计出一个大致的模块划分。第二天最痛苦的地方在于你自以为理解清楚了但找来产品经理确认时对方总会给出新信息——“这个功能不是给 C 端用户用的是给运营后台的”“这里我们打算用异步消息不直接走 HTTP”。于是模块边界要调数据流要改架构图上刚摆好的组件又要挪位置。更麻烦的是技术选型带来的连锁反应。比如需求文档里提到“需要支持多租户”你可以简单地在图上画一个 Tenant 概念但真正画架构图时你得决定隔离粒度是数据库隔离、Schema 隔离还是应用层隔离选择不同图中需要表达的地理范围、数据链路、权限中心全都不一样。这些决定没法通过纯读文档获得需要向业务方求证需要跟团队成员对齐时间就这样一天天消耗掉了。所以我经常跟人讲架构图上的每一个组件都是一个决策的结论而不是一个图元。1.3 第三天剩给画图的其实是最没太多产出的体力活等到边界和技术选型都定了画图本身倒是很快。但是这里有个反直觉的点架构师最容易吃亏的地方恰恰在“快”字上。快速画出的图往往没有层次只有一堆框和箭头评审时别人看了三分钟就会问“你这里为什么有一根清晰的线块和块之间所有权是谁”于是你又得重新整理图面增加层次区域、标注边界、补充依赖关系说明。光是把一张逻辑图调整到“别人能在十分钟内看懂”的程度反复挪动组件和重画布局就要花上大半天。这也是我后来决定把流程交给 AI 智能体去跑的原因之一。图是可以无限重构的低价值劳动但它又非常消耗耐心。真正有价值的判断——为什么要拆这两个服务、为什么数据要走这条链路AI 智能体在当下还很难独立完成但它完全可以在短时间内完成“读文档、抽实体、搭骨架、出初稿”这一整套体力活。剩下的半天时间留给架构师去做判断那么 3 天压缩到 3 小时就有了解释。2. 智能体真正压缩掉的三个半环节2.1 环节一需求文档的实体抽取与信息结构化AI 智能体最擅长的是把非结构化文本变成结构化信息。当我拿到一份需求文档后会先让智能体做实体抽取系统角色、用户类型、外部依赖、数据实体、核心业务流程、关键约束全部变成带 ID 的结构化条目。这一步放在以前是我用荧光笔在 PDF 上做标注整理到笔记软件里再手动归纳通常要小半天。智能体做这件事的优势不只是快而是它可以做到“比人更不遗漏”。需求文档 100 页里可能有 30 处提到同一个外部系统只是叫法不同人读到最后容易忘掉第 12 页那个别名智能体通过上下文关联把这些同义实体归并到一条记录里并保留出处引用。有了这样的结构化清单后续生成架构图时就能追踪每一个组件到底来自哪条需求依据。这一点我会在第 5 章质检时再展开。2.2 环节二系统边界与模块划分的候选生成实体抽取之后智能体给出的第二份关键产出是分层和模块划分候选。我会让它按照“接入层 / 应用服务层 / 领域核心层 / 基础设施层 / 外部集成”这类常见分层结构对实体进行归类。但需要注意这一步的产出是“候选”不是“终稿”。因为系统边界这件事天然有业务含义和团队归属问题。比如订单和支付你可以把它们放在一个模块里也可以拆成两个服务这在很大程度上取决于团队职责边界和未来扩展预期不一定能从文档里得到答案。智能体能给出的价值是它通过需求中出现的频次和业务描述的相关性列出几种划分可能并注明为什么倾向于某一种划分。这相当于把一道判断题变成了选择题把架构师的精力省下来做真正需要裁决的事。2.3 环节三依赖关系整理与绘图渲染在模块划分确定后智能体能够自动分析模块之间的数据流和调用关系。比如“用户登录后需要查询订单列表”这一句话它能自动把它转换为“客户端 → 用户服务 → 订单服务”这样一条链路。同时它会把外部依赖短信服务、对象存储、第三方支付等单独抽出标注在边界区域而不是混在核心模块里。绘图这一步则是纯粹的机械动作。智能体把模块、依赖、边界信息生成图形描述文本再交给渲染工具生成架构图。这当中的关键点在于智能体还可以对渲染出的图做可读性自检判断组件是否过多、连线是否交叉密集、边界区域是否清晰。它不会像人一样有审美洁癖但至少能保证图面不混乱。所以我才说它压缩的是“三个半环节”——第四部分只有一半是它做的那就是架构决策和取舍这部分智能体只能提供材料和辅助分析最终拍板还是要人来做。2.4 为什么还是需要一个人守住工作流入口在实际跑通这套智能体工作流后我最大的感受是一个人机边界的问题智能体处理的是“从文档到图的推演”人处理的是“从业务到架构的裁决”。如果你把智能体的产出直接当成最终架构省下来的两天会在后续开发里加倍还回来。我的做法是把智能体当成“一个随叫随到的初稿生产器”给它明确输入边界和质量标准然后架构师只在真正需要判断的地方介入。3. 完整跑一遍从需求文本到可评审的架构草稿3.1 第一步对需求文档做清洗与切片很多团队拿到一份 Word 或者 PDF 后直接把全文塞给大模型这其实是很偷懒的做法。我发现效果比较好的方式是先做切片把文档按章节结构拆成“业务背景”、“角色说明”、“核心流程”、“接口定义”、“非功能需求”等区块每个区块大小控制在适合上下文处理的范围内并且把表格信息单独提取成 CSV 类型的结构。切片的理由有两个。第一避免上下文窗口被无关内容挤占尤其是文档开头一长串团队介绍和修订记录对架构设计毫无帮助。第二不同的切片内容对应的处理策略不同——角色说明主要抽人和系统边界核心流程主要抽时序关系接口定义主要抽模块依赖。统一处理虽然也能出结果但细节质量明显不如分区处理。这一步我用脚本做了半自动化文档进入后自动转成 Markdown按标题层级拆分智能体消费的是拆分后的结果。3.2 第二步用“角色流程约束”三段式引导智能体经过几十次调试后我把面向智能体的工作提示词稳定成了三段式结构。第一段要求它识别角色包括用户角色、后台角色、外部系统角色。第二段要求它梳理核心流程每个流程都要标注触发方、参与方、数据实体和最终结果。第三段要求它提取约束包括技术约束、性能约束、部署约束和安全约束。比如一篇典型的需求文档里会包含这样一句“用户在小程序端发起预约申请系统校验库存后生成预约单并向用户推送确认消息。”给智能体后它应当拆成流程预约申请触发方小程序端用户参与方库存服务、预约单服务、消息推送服务数据实体预约单、库存快照外部依赖消息推送通道当整个文档处理完后智能体会把流程之间的相同实体合并形成一张实体关系候选表。这个候选表就是架构图的“原材料”。我见过比较靠谱的做法是要求智能体输出表格时带上“置信度”标记这条依赖是文档里明确写出的还是根据上下文推测的。这样就避免了一个常见问题——它把想象出来的关系混进真实依赖里让人防不胜防。3.3 第三步把实体关系表落成架构图描述文件有了实体和关系之后画图就是顺理成章的事。我会让智能体把组件按层次排列把不同领域的模块用边界块区分开外部系统放在虚线区域外。这里的关键是不要让智能体直接在画布上自由发挥而是输出一份结构化的架构描述文件再由渲染工具统一生成。我习惯的产物是这样一种结构化中间表示{ system: 预约服务系统, layers: [ {name: 接入层, components: [小程序网关, H5网关]}, {name: 应用服务层, components: [用户服务, 预约服务, 通知服务]}, {name: 基础依赖层, components: [MySQL集群, 消息队列]} ], externalSystems: [微信身份服务, 短信网关, 对象存储], dependencies: [ {from: 小程序网关, to: 用户服务, type: 同步调用}, {from: 预约服务, to: MySQL集群, type: 数据读写}, {from: 预约服务, to: 消息队列, type: 异步投递} ] }这份中间表示有两个好处一是它可以被程序校验比如检测出组件在依赖关系里出现了但没有定义二是它可以反复用于增量修改当需求文档更新后只需要变更局部节点不用整张图重建。这一步就是智能体省下“第三天”的关键——绘图不再是人工拖动方框而是从结构化数据自动展开同时因为它保留数据和图形的双向对应关系改图不会导致箭头错乱。3.4 第四步人机协同的“一小时修正窗口”整个流程里我会给智能体留一段人工修正时间通常是一个小时。这段时间做什么呢第一是检查模块划分是否和团队职责匹配比如智能体把“支付”和“订单”合并到一个服务里而当前团队其实是两个小组分别维护那我就手动在中间表示里拆开。第二是补上文档里从未出现但架构师根据经验知道必须存在的组件比如监控、日志采集、配置中心这些体系设施。第三是把外部依赖的约束补全比如通过 VPC 内网访问数据库S3 存储走内网端点等部署细节。修正完之后再让智能体重新渲染一次图这张图就可以拿进评审会了。三个小时的时间预算基本是这样分配的半小时清洗文档一个半小时智能体抽实体和生成候选结构半小时人工修正中间表示剩下半小时出图和自检。听起来很紧凑但实测这条链路非常稳因为真正花脑力的判断都集中在那一个小时的修正窗口里前面两小时更多是按指令执行的体力活。4. 哪些需求适合交给智能体哪些会直接翻车4.1 适合智能体发挥的场景信息量大、结构重复、边界相对清晰的系统我最推荐用这套流程去处理的是中后台管理系统、预约类平台、订单流转系统和常规的 CRUD 业务系统。这类需求有一个共同点包含大量重复的业务流程描述用户角色固定数据实体清晰外部依赖不多。智能体在这种场景下表现出色是因为它本质上是在做模式匹配就算文档写得再乱“用户提交表单、后台审核、数据落库、外发通知”这类套路它见过太多了。我拿一个模拟项目 X 跑过四十页的需求文档包含五个后台模块、三种用户角色、六条核心流程。智能体把实体抽得基本准确模块划分方向上也没有大问题我唯一要做的就是把它的两个候选模块合并成一个并且补一个文档里没有说明但运维约定俗成需要的配置中心。从开始处理到评审用图出来总共不到两个半小时。4.2 容易翻车的场景安全和合规约束、遗留系统兼容、严重缺失的需求翻车场景也是有规律可循的。第一类是需求文档里出现大量安全合规词汇比如“等保”“数据加密”“审计日志”“跨境数据”。智能体可能会在架构图上画出加密模块但它不知道加密具体在哪一层做、密钥如何管理、合规审计日志需要保留多久这些需要架构师结合运维制度和法律要求补齐。第二类是遗留系统兼容需求。很多架构图并不是从零画起而是在老系统边上画一个新系统。文档里通常只写“兼容老旧接口”但老接口具体有多老、负载能力如何、是否还在维护智能体无法从文档中获得这些信息。它很容易把遗留系统当成一个标准外部系统对待画一个简单的箭头连接就完事但实际设计中往往需要一层防浪涌适配器甚至需要做双写和回退方案这就是典型的“文本里没有但图纸上必须有”的部分。第三类是需求缺失严重的情况。如果文档里只有几条大纲式的用户故事没有业务细节智能体就会开始自由发挥。它生成的架构图会看起来非常完整模块齐全、边界清晰但你去追问就会发现很多组件是它脑补出来的。这种假完整性比没有图还要危险因为团队成员会在评审时顺着这张图往下聊浪费一整个下午讨论一个并不存在的组件的内部设计。这类场景下我会直接放弃智能体初稿先花半天人工访谈业务把需求补到位再谈画图。4.3 机制陷阱智能体输出的“高置信幻觉”智能体画架构图有一个非常有迷惑性的问题我把它称为“高置信幻觉”。它不像人那样不确定的时候会犹豫、会反问而是倾向于给你一个有板有眼的答案。你在需求文档里随便提了一句“预留未来扩展空间”它就会在架构图里画上消息队列和微服务网关尽管这个系统只有三个模块、日均请求量几百。从纯文本逻辑来看它没错但从架构决策的角度看这是严重的过度设计。应对办法也很简单但必须严格执行我在工作流里加了一道约束即要求智能体在生成架构描述文件时对每一个组件和依赖给出“依据来源字段”。组件要么引用需求文档的具体章节编号要么标注为“推测组件待人工确认”。没有依据来源的组件在渲染成图之前必须先经过我确认否则直接过滤掉。加上这个约束之后智能体产生的无用组件比例明显下降因为“必须给出处”这个要求逼着它收敛了自由发挥的空间。下面这张表基本可以代表我这段时间总结出来的匹配度判断需求文档特征智能体完成度人工介入重点流程清晰、角色明确、模块重复高可直接产出草稿模块粒度调整、补充运维组件存在大量安全和合规要求中结构可用但缺关键决策加密边界、审计链路、密钥管理涉及遗留系统对接低容易低估兼容成本适配层设计、双写方案、回退机制需求只有大纲级描述低容易产生假完整性先补需求再谈架构文档内部矛盾较多中能把矛盾集中暴露出来逐条确认冲突点并和业务对齐5. 三小时之后的质检别让 AI 草稿直接流进评审会5.1 用需求追踪矩阵做组件溯源我以前靠经验和直觉判断一张架构图有没有漏掉东西但用智能体出图之后我发现必须有一套可核对的方法否则心里始终没底。现在我在流程里固定加了一步让智能体输出一张需求追踪矩阵左边是需求编号右边是该需求对应的架构组件和依赖关系。评审会之前我拿着这份矩阵逐条对照原始需求文档看是不是每一条需求都落在了某个组件或链路上。这一步极其管用。有一次智能体生成的架构图已经相当完美模块分层、数据流、边界区域都很清晰但对照矩阵时发现有一条“用户注销后关闭第三方授权”的需求没有映射到任何组件上。顺着链路查下去发现智能体在流程抽取阶段漏掉了这条细节。像这样的漏项如果不做追踪矩阵你看着图根本发现不了——因为图的整体气质太流畅了。所以我的结论是智能体越擅长做出好看的图你越需要一套严格的校核机制。5.2 架构评审的关注点从“看图”变成“看决策依据”有了智能体初稿之后评审会的模式也发生了改变。以前评审是架构师带着图讲一遍流程大家围绕这张图提问题很多时候讨论的是“这个模块是不是放在这里合适”“这个箭头是不是应该反过来”这类问题往往流于表面也特别耗时。现在的评审会我会提前把架构图、实体关系表、需求追踪矩阵三份材料发给参会者会议开始后直接进入决策环节每个标注了“推测组件”的地方解释理由每一个我人工改过模块划分的地方说明取舍每一处新识别出的外部依赖给出影响评估。整个会议的密度高了很多讨论的都是真正影响系统走向的架构决策而不是在图面上绕圈。智能体并没有替代评审但它让评审这个活动从低信息密度的看图变成了高信息密度的决策。5.3 增量更新才是智能体工作流的分水岭最后再说一个我在实践里体会最深的事这套智能体工作流最大价值不在第一次画图而在持续迭代更新。传统手工画架构图一旦系统演进每次更新都是一次小的重构。你可能因为加了一个新服务要重新调整整个布局因为一个数据流改了路径牵动的箭头和分组可能有一大片。智能体工作流下更新是结构化的新增一条需求文档切片后进入实体抽取流程智能体对比现有架构描述文件告诉你新增的实体应该挂在哪个模块下面会产生哪些新依赖然后在原本的架构图上做局部重绘。相当于把“从零画图”变成了“按需求增量打补丁”这一下把架构图的维护成本也降下来了。当然前提是你把架构描述文件管理得当每次变更都走完整的更新流程而不是偶尔手动去以源文件修改图最后导致两份文件不同步。我在实际维护某个跨平台系统时做过一个测试需求文档每次更新后从同步到出新版架构图整个过程控制在二十分钟以内。这套流程跑顺之后团队里的架构评审材料几乎都是当天同步的不再有“按上个月的架构图评审这周的新需求”这种尴尬情况。坦率地说AI 智能体不是把 3 天硬生生变成 3 小时的魔法它只是把 3 天里本来就不该由人来做的那部分机械劳动拿走了。文档消化、实体抽取、绘图渲染、局部更新这些环节占用了架构师一半以上精力却没有创造不可替代的价值当这部分被压缩掉之后架构师才能真正把精力放在边界取舍、技术选型、风险预判这些配得上“架构师”头衔的事情上。这三小时节省下来的不是两天半的时间而是整个团队从需求到架构决策之间的反馈周期这才是这件事真正值得反复尝试和优化的原因。