1. 这个组合为什么值得认真对待做企业架构的同行应该都有同感TOGAF这套框架本身逻辑严密从架构愿景、业务架构、数据架构、应用架构到技术架构一环扣一环但真正落地的时候最耗时的往往不是方法论理解而是信息收集、现状梳理、文档编制、一致性检查这类琐碎工作。企业的存量系统少则几十个多则几百上千个架构师面对的是堆积如山的系统清单、接口文档、需求说明和会议纪要单靠人力去建立完整的架构视图动辄一两个月。AI进入这个场景解决的并不是“要不要用TOGAF”的问题而是“怎么让TOGAF项目跑得更快、更准、更省人”的问题。我最近做了一个企业内部架构梳理的实践把TOGAF的ADM阶段工作拆开逐段接入了大模型和Agent能力整体效率提升非常明显。以前需要架构师连续加班两三周才能完成的现状建模和差距分析现在配合AI工作流几天内就能出一个高质量初稿人工只需要做关键的判断和审查。这篇文章就把这套做法的整体设计、核心步骤、踩坑经验完整讲一遍。适合正在做企业架构规划、数字化转型项目或者在TOGAF落地过程中感觉“文档产出压力大、信息整合费时”的架构师、技术负责人和项目经理。不需要你精通大模型训练只要会写提示词、能理解TOGAF的基本概念就可以参考落地。1.1 TOGAF落地的老问题文档太多人力不够我以前做过一个制造型企业的架构项目光业务访谈纪要和现有系统功能清单就有两百多页。四个架构域要覆盖销售、供应链、生产、财务、人力每一块都要现状、目标、差距、迁移路径。那时我们的做法是组建一个六人架构小组每天开评审会加班画视图、写架构定义文档整个ADM第一阶段到第三阶段走了将近两个月。问题出在哪里三个点。第一现状信息的提取依赖人工阅读大量文档架构师的时间大量消耗在“读”而不是“想”。第二从现状到目标架构的映射经常出现不一致。业务域改了名称数据域还是旧叫法技术域的系统归属也常对不上。第三各个架构域的交付物之间缺乏自动校验全靠评审会上人眼发现矛盾。这些问题本质上不是TOGAF框架的缺陷而是执行效率的问题。AI刚好可以在这三个点上帮上忙而且不是取代架构师的判断是把架构师从低价值的重复劳动里解放出来。1.2 AI在架构场景的切入点我评估过很多AI应用方向最后觉得在企业架构领域最有价值的不是让AI直接画一张完美的架构图而是下面这几类工作第一类是信息提取与结构化。架构师把访谈纪要、系统清单、存量文档丢给大模型让它把实体、关系、属性抽出来生成JSON格式的元模型数据供后续建模使用。这个环节人工做非常枯燥AI却相当擅长。第二类是架构视图生成。基于提取好的结构化数据让AI生成业务能力地图、应用系统关系图、数据实体清单等技术方案。生成的图虽然需要人工调整布局但内容的完整度很高能覆盖到人工容易遗漏的边角系统。第三类是差距分析和一致性校验。把AS-IS模型和TO-BE模型同时交给AI让它逐项对比找出能力缺口、系统冗余和数据不一致输出差距清单和迁移建议。这个环节过去的做法是专家开会拍脑袋现在有了AI的逐项扫描讨论的质量明显不一样。第四类是文档自动编制。TOGAF要求交付物非常多比如架构需求规格、架构定义文档、架构合规审查记录。AI可以基于模型数据自动起草人工只需修订。理解了这四个切入点后面整个智能建模的思路就清楚了。2. 智能建模整体设计分层拆开各司其职2.1 总体架构链路我把这套企业架构智能建模体系设计成五层每一层的职责都尽量单一方便替换和扩展。第一层是资料接入层。负责收集和预处理所有原始输入包括访谈纪要、系统清单、接口文档、日志摘要、组织结构图、流程文档等。这层主要做格式统一、去重、敏感信息标记输出为统一的文本块和结构化数据表。第二层是信息抽取层。使用大模型对文本进行实体识别和关系抽取按TOGAF的元模型类别归档。具体会分成业务域、数据域、应用域、技术域四类实体和它们之间的依赖、归属、调用关系。第三层是模型构建层。把抽取结果映射到标准架构元模型上形成AS-IS架构基线并支持手工修正。这里我用的是“以代码表达模型”的方式即所有架构元素都表示为一组YAML文件和JSON关系表而不是直接用绘图工具原因后面再说。第四层是分析推演层。基于AS-IS基线结合业务战略和项目目标生成TO-BE模型草案然后做差距分析和迁移路径建议。这层也是AI参与最深的环节。第五层是交付与治理层。把建好的模型自动生成架构文档、视角视图和合规审查记录并输出给评审团队。各层之间通过标准的文件接口衔接没有做太重的平台化封装。对我这种需要快速验证的方案来说轻量、透明、可回溯比什么都重要。2.2 为什么用“文本即模型”的方式这个决策是我在这套方案里比较想强调的一个点。一开始我也考虑过用现成的建模工具比如Archi、Sparx Enterprise Architect配合它们的脚本接口来做自动建模。但实际用下来发现几个问题这些工具的数据模型很难跟大模型输出的JSON直接对上批量写入往往要走插件开发版本对比和差异追溯不友好团队评审时要逐图核对非常痛苦而且图形化模型在AI生成过程中很容易因为布局、样式问题造成返工。后来我换了个思路把所有架构信息从工具中剥离出来统一用YAML文件表达元模型用JSON表表达实体关系。绘图只作为输出物的一种从YAML自动转换生成绝不作为编辑主载体。这样做的好处非常直接。YAML文件可以被大模型轻松读写也可以在Git里做版本管理任何一次修改都可追溯。一致性检查也可以写成脚本去扫不用逐图肉眼排查。比如业务能力、业务服务、应用组件、数据实体之间的关系全部落到结构化文件里AI在任何环节的修改后续都能被审查。实际经验是这层设计对整个项目的进度起着决定性作用。如果还是坚持图形工具为主AI改一版人工就要同步一版效率会被拖回去。2.3 Agent分工谁干什么谁管什么我在工作流里配置了四个角色用Agent的方式协作。编排Agent是主控接收用户的任务目标拆分步骤调度其他Agent汇总结果。分析师Agent负责原始资料的信息抽取、实体识别和关系判定。建模Agent负责把分析师输出的结构数据转成标准元模型并生成AS-IS和TO-BE视图。审查Agent负责对建模Agent生成的模型做双盲检查找出实体遗漏、关系矛盾和命名不一致。这四个Agent在同一套知识库和模型文件上工作但上下文各自隔离避免互相干扰。审查Agent的输出不会直接覆盖建模结果只生成问题清单由人工或编排Agent决定是否修订。这种“生成与审查分离”的做法显著压低了AI幻觉影响架构模型的概率。3. 实操过程从原始资料到TOGAF架构模型3.1 资料准备和信息提取这一步决定了整个建模的地基质量我吃过亏所以先说优先级。你和AI合作的第一步是按四个架构域准备资料。业务域的优先级最高重点是组织结构、职责分工、业务流程清单、业务服务目录数据域准备主数据清单、数据字典、报表需求应用域准备现有系统清单、系统间接口列表、系统功能说明书技术域准备基础设施清单、技术平台标准、部署拓扑描述。资料不需要一下子齐全但每份资料必须带上明确的来源标识和日期这样后续AI抽取时能知道信息的置信度和时效性。我通常用一个简单的文本预处理脚本把PDF、Word、PPT统一转成Markdown格式表格尽量扁平化避免大模型读表出错。资料处理完后进入信息抽取。这一步的提示词很关键我给分析师Agent写的核心指令大致如下你是一名资深企业架构分析师请阅读以下资料提取与业务架构、数据架构、应用架构、技术架构相关的实体和关系。输出格式为JSON包含实体列表和关系列表。实体类型包括业务能力、业务流程、业务对象、数据实体、应用系统、技术组件。关系类型包括支持、依赖、归属、调用、组成。不要推测资料中未体现的信息无法确定的关系标记为uncertain。这个提示词的要点是约束输出格式、明确实体和关系类型、禁止推测。很多人第一次用AI做信息提取失败的原因往往是没做这三点限制结果AI自由发挥输出了大量“看起来合理但其实不存在”的内容。提取完的数据建议人工抽检20%左右。我做了两次项目后发现AI在系统清单这种结构化资料上的召回率比较高但在访谈纪要上的判断需要人工盯紧。访谈里经常有主观描述和模糊表达AI容易把“可能准备上”的系统也当成在建系统。3.2 一键生成AS-IS架构基线信息提取完成后就是建模Agent的主场。我让建模Agent把JSON数据转化为YAML元模型文件每个架构域一个目录目录下按“实体类型”维护清单文件关系统一存到center-relations.yaml。举个例子业务能力的YAML条目大致长这样- id: cap_sales_order name: 销售订单管理 domain: 业务架构 description: 覆盖销售订单创建、变更、取消和查询的生命周期管理 owner: 销售运营部 related_objects: - data_entity: d_orders - application: app_crm status: as-is这里每一行都有对应的出处和来源标记我要求建模Agent在description字段里带上“信息来源”和“提取时间”。这样的设计在后续争议环节非常有用。谁质疑模型数据直接查YAML的来源就行不用再翻原始文档。关系表长这样{ source: cap_sales_order, relation: supported_by, target: app_crm, confidence: high, evidence: 访谈纪要-销售部-20250115 }实体和关系都带上证据链是我这条流程里自认为最值得借鉴的经验。很多企业架构项目最后答辩时扯不清数据从哪来的有了这个相当于每个建模结论都带了“引用出处”。AS-IS基线建立之后建模Agent还会自动生成一版视图描述文件用于后续绘图。我这边视图图使用的是PlantUML因为纯文本定义方便AI生成也方便在Git里做差异对比。AI生成完PlantUML源文件本地渲染一次就能出架构图。比如业务架构的用例图、应用架构的组件依赖图这种描述性视图用PlantUML完全够用。3.3 差距分析和TO-BE模型推演AS-IS基线落定后接下来是做目标架构设计。这个环节我分为两步。第一步是让AI根据战略目标、业务痛点和项目范围生成TO-BE模型的草案。第二步是把AS-IS和TO-BE放在一起做差距分析。TO-BE生成阶段的提示词我会下得比信息抽取阶段更开放一些因为这里需要AI发挥设计辅助的能力而不只是信息搬运。核心提示大致如下基于AS-IS架构模型和业务目标清单生成TO-BE架构模型草案。要求保留现有合理的架构资产针对痛点提出改进方案对新增业务能力补充所需的数据实体和应用支撑每条设计变更注明原因。输出格式沿用YAML元模型规范变更项单独标记为to-be。这里要注意的是AI生成的TO-BE草案只作为“建议稿”不要直接当成最终设计。我踩过的一个坑就是让AI自由发挥后直接进入评审结果它给出的目标架构过于理想化完全没考虑现有投资的利用和团队的实施能力。后来我加了限制条件要求每项变更必须写清楚“对现状做了哪些调整、为什么调整、预期收益是什么”评审的效率和质量都上来了。差距分析环节是工作量最直观的地方。AI逐项比对AS-IS和TO-BE模型找出缺失能力、重叠应用、数据孤岛、技术欠账然后输出差距清单。我让输出格式统一成表格每一行包含差距编号、所属架构域、差距描述、影响程度、建议行动、涉及实体。这个表格直接作为后续项目规划的依据比过去开会讨论出来的零散结果要好用得多。举例来说我在制造业项目里跑差距分析时AI发现销售订单流程里“订单状态实时可视化”的能力在AS-IS中缺失但在业务战略清单里属于高优先级需求。它就把这个差距标记为高影响并建议在应用域增加订单追踪模块同时关联数据域新建订单状态事实表。这个建议方向基本准确人工只需要评估落地成本就会拍板。3.4 文档交付物一键衍生TOGAF的交付物很多但本质都是对模型的描述和解读。既然模型已经在YAML里结构化管理了文档生成就变成一个模板展开的过程。我维护了几套文档模板包括架构概览报告、业务架构说明、数据架构说明、应用架构说明、差距分析报告、架构合规审查记录。建模Agent根据模型数据按模板填充内容审查Agent再做一轮交叉验证确保文档里的描述和模型文件一致。这里有个细节文档中凡涉及具体数字和系统名称的我会额外让审查Agent对着YAML逐项查一遍。因为大模型在长文档生成时偶尔会“记忆漂移”把A系统写成B系统。双检查虽然多花一点时间但对外汇报时能避免非常尴尬的错误。4. 常见问题与避坑实录4.1 AI幻觉导致架构实体虚增这是所有AI辅助建模项目里最头疼的问题。大模型在信息不全时会脑补虚构出根本不存在的系统或者业务环节。我的应对方法是三层防线。第一个是信息抽取提示词里强制“不确定就标记uncertain”禁止用默认状态代替未知状态。第二个是实体和关系的置信度字段凡是低置信度的内容不进入正式模型只进候选区。第三个是人工抽检制度对高影响实体如核心系统、关键数据实体逐条核对来源。有一次AI在某个项目里“发现”了一个叫“客户主数据平台”的系统实际来源只是访谈里客户提了一句“我们在考虑建”但AI直接把它当成了已有系统写进AS-IS。我们靠置信度字段和人工抽检拦下来了这个教训说明来源标记的机制是必须的不能省略。4.2 长文档超出上下文窗口企业架构项目的原始资料动不动几十万字单次塞进大模型几乎不可能。我的处理方式是分域、分章节切片处理每个切片控制在5000字以内提取完再合并。合并阶段也有坑不同切片分别提取时同一实体的命名可能不同比如“CRM系统”和“客户关系管理系统”在AI眼里有时会当成两个实体。我后来在合并脚本里做了同义词归一化配合手工维护的别名表基本解决了这个问题。4.3 敏感信息边界企业架构数据里必然涉及系统账号、网络配置、业务经营指标等敏感信息。我给这套工作流立了一条铁律所有数据本地处理AI调用必须经过脱敏网关系统名称、人员姓名、具体金额全部替换成代号架构分析完成后再由人工映射回真实信息。这不是技术难度问题而是职业底线问题。企业架构数据一旦泄露影响范围比大部分人的想象严重得多。宁可多花一天做脱敏也不要在安全上省功夫。4.4 提示词质量的经验总结最后分享一个通用经验。用AI做TOGAF建模不要追求“万能提示词”而是为每个环节准备专用提示词并不断迭代。我目前维护的专用提示词有十二组涵盖信息抽取、命名归一、AS-IS生成、TO-BE设计、差距分析、文档生成、合规审查等环节。每版提示词都带版本号和变更记录每次项目结束我会复盘一次把失效的约束删掉把缺的约束补上。做过三轮项目之后这套提示词体系基本稳定普通同事拿过来也能跑出七十分的效果再由架构师人工补齐三十分。我个人在实际操作中的体会是AI做企业架构建模真正的价值并不是“自动产出正确答案”而是“把人工从繁琐的整理、对比、初稿编制中释放出来让人把时间花在判断和决策上”。这个分工想清楚之后TOGAF落地这件事就突然变得轻快了很多。如果你正在做架构项目不妨先用一个小范围内的问题跑通流程再逐步扩大范围。把第一步走稳后面自然就顺了。