夜雨聆风过去 1 - 2 年时间，跟一些 CIO、CTO、首席架构师线下聊到的话题里，有一个共性的话题引发了大家的讨论：架构师这个角色，在 AI 时代的定位是怎样的，会何去何从？
这件事值得正面说一说。过去 5 年里，架构师在 CIO/CTO 圈是"被尊敬但很少被讨论"的群体。大家默认架构师是技术决策的最后一道把关者，重要的方案绕不过架构师。但具体到"架构师在做什么、未来要怎么做"，反而少有人正面写过。
这一年开始变了。我自己也是从技术路上一步步走过来的，跟"架构师"这个群体是同路人，或者说，我也会认为自己就是架构师身份。最近这段时间，我跟身边几位企业架构师、技术总监级别的朋友聊下来，大家都在做类似的自我审视。焦点其实不在"会不会被 AI 取代"这件事上，更多是隐约感觉到，自己手里的几件"武器"，正在被同时改写。
这一篇，我想把这种共同的体感摊开看一看，再聊一聊我跟几位同行交流下来看到的几种应对路径。这件事没有标准答案，写出来希望对正在自我重新校准的同行朋友，是个参考。
一、被冲击的三件武器
要讲清楚我们当下共同的体感，绕不开大家手里过去 20 年攒下来的三件"武器"：画图、评审、规划。一件件来看。
武器1 画图能力
过去架构师最显眼的能力，是把一个复杂系统画清楚。系统拓扑图、应用集成图、数据流图、业务流程图，这些图既是设计工具、也是沟通工具，更是话语权的载体。一份能落到细节、又能讲清全局的架构图，往往代表着一个项目的"灵魂"。
Vibe Coding 这一年的崛起，让"图先行"这件事开始变得没那么必要。开发者一句自然语言，AI 就能产出可运行的代码；走一遍跑通，再回头让 AI 反推出系统结构。原先的"先设计、再实现"逻辑被悄悄反转了：实现可以先发生，结构可以后归纳。
还有一层更隐蔽的变化在沟通侧。架构师的图过去之所以有权威感，是因为图本身代表着"思考已经成型"。AI 时代，业务侧、产品侧、甚至年轻的开发者都能在几分钟内拼出一份看起来"也挺像样"的架构示意图。我们独占的图形化表达入口，变成了一种相对开放的资源。
当然这并不是说画图没用了。系统级的边界、跨域的契约、性能与可靠性的取舍，这些图依然需要我们来把控。但画图作为我们独占的"专业护城河"，正在松动。
武器2 评审权威
第二件武器是评审。架构评审、技术评审、上线评审，是架构师在企业内最高频的输出场景。"这个方案我看过了""可以走""不能走""要改这几点"，这些表达既是技术意见，也是组织里的角色定位。
Agentic 系统的不确定性，正在让我们熟悉的评审框架变得不太够用。
过去评审一个系统，能问的问题大致是：接口契约清楚吗？数据一致性怎么保证？故障域隔离得怎么样？容量评估有依据吗？这些问题都建立在一个假设上：系统行为是确定的，可以被穷举、被边界化。
Agentic 系统打破了这个假设。一个能自主调用工具、生成中间产物、根据上下文调整下一步动作的 Agent，它的行为空间是开放的。我们没法用"接口契约"框住它，没法用"数据一致性"判定它，更没法用"容量评估"覆盖它的非确定性消耗。
我接触的几位资深架构师，第一次评审 Agentic 类项目时，普遍有那种"评审工具突然用不太上"的不适感：习惯了 20 年的检查清单，从第一条就开始不太对得上。这跟我们的能力无关，是评审范式本身需要一起重建。
武器3 规划能力
第三件武器，是中长期规划。一个企业架构师真正的价值，往往落在"三年后的 IT 蓝图应该长什么样"这种判断里。当下某个具体项目，反倒不是我们最主要的发力点。中台战略、微服务化路线、数据治理路线图，这些规划性输出是架构师区别于一线技术负责人的主要竞争力。
AI 这一波给规划这件事带来了一个共同的尴尬：可参照的成熟原语还没有沉淀。
spec、skill、Agent、MCP、上下文工程、harness，这些概念过去 18 个月才逐渐定型，连厂商之间的命名都还在反复变。我们这一代架构师习惯用"成熟概念"做规划，习惯引用 TOGAF、Zachman、领域驱动设计这些经过 10 - 20 年验证的方法论。今天要规划企业 AI 架构时，可以引用的成熟方法论几乎是零。
这种情况下规划，难度比过去大得多。规划得太前，可能被 6 个月后的技术演进证伪；规划得太保守，又会被快速跑出去的同行甩开。架构师过去那种"看 3 年"的舒适区，第一次被压缩到"看 6 个月"。
把这三件武器放一起看，大家共同的体感就清楚了。没有哪一件被彻底废掉，但三件同时在被改写，过去依靠它们建立起来的那套工作节奏，确实需要重新校准了。
二、真正的变化：交付物的本位
讲完共同的体感，再往下走一步。我们这一代架构师在 AI 时代真正高杠杆的工作，到底是什么？
我前段时间写过一篇关于 SDD（规范驱动开发）的文章，里面有一句判断是"spec 才是源代码，code 是编译产物"。把这句话顺到我们自己的角色层，会得到一个推论：写 spec 这件事，本来就应该是我们的活。
为什么这么说？
过去我们交付的东西，主要是两类。一类是图，包括架构图、流程图、拓扑图；另一类是文档，包括设计说明、决策记录、规范要求。这两类东西在做同一件事：把企业的技术意图，沉淀成可被反复参照的"约定"。
代码本身，过去并不是我们的主要交付物。我们写代码的时候，更多是示范、是验证、是给开发团队打个样，并不会把代码作为最终资产交出去。
SDD 这一波带来的变化是：真正凝结"技术意图"的载体，从图和文档，集中到了 spec 这一种新形态上。spec 比图更可执行，它直接驱动 AI 产出代码；比文档更活，它跟代码天然同步、跟着系统一起演进；比代码更上游，它承载的是"为什么这么做"这一层意图，"具体怎么做"则交给下游 AI 完成。
这正好是我们的舒适区。
把架构师过去和现在的交付物摆在一起，对比会更清楚：
过去：架构图 + 设计文档 + 评审意见 + 治理规范
现在：系统级 spec + Agent 行为边界 spec + 组织协作 spec + 治理框架（依然需要，但形态升级）
这里要特别说一句：我们并不需要去抢着写代码。过去 5 年里大家或多或少都感受过那种"跟一线越来越远"的距离感，这种距离感在 AI 时代反而有可能被拉回来。因为 spec 这种新交付物，比代码更需要架构师的视角，比如抽象能力、系统观、跨域协调能力。
我接触的几位转得比较顺的同行，都在做一件相似的事：大家没有去抢代码，而是在尝试定义 spec 的话语权。规则谁定、边界谁定、契约谁定、治理框架谁定，这些事重新回到了我们的台面上。
这是 AI 时代给我们这一群人的第一个新机会。
三、三类架构师，三种不同的应对路径
讲完"高杠杆动作变了"，下一步要回到具体的人。不同出身的架构师，面对这场变化的应对方式是不一样的。
国内企业里的架构师，按"出身"大致可以分成三类。我自己一路走来，跟这三类同行都打过比较多的交道，每一类的应对路径分开讲。
路径1 业务系统架构师
第一类是业务系统架构师。最常见的出身是 ERP、CRM、SCM、MES 这一系业务系统，过去十几年的工作方式是"需求→设计→实现→上线"的标准范式。对业务流程的理解扎实，对企业内部的业务部门画像清楚，是这一类朋友的强项。
这一类同行在 AI 时代的工作范式，正在被两面挤压。
一面是 Vibe Coding / Low-code AI 在改写"实现"环节。过去大家的设计输出，需要靠开发团队按部就班翻译成系统功能；现在业务部门自己用 AI 工具就能跑出第一版可用的功能。我们做的"设计中间件"层，正在被压薄。
另一面是 AI Agent 在改写"业务流程"本身。过去设计的是流程审批、单据流转、规则引擎；今天业务部门关心的是"能不能让 Agent 帮我把这件事整段办掉"。Agent 化的流程，跟传统 BPM 的流程，逻辑差异是根本性的。
跟几位转得比较顺的业务系统出身的同行聊下来，大家都在做同一件事：把视角从"系统功能架构"切换到"业务能力 + Agent 协作架构"。具体动作大致是这几条：
把过去的业务流程图，重画成"人 + Agent 协作图"：哪些步骤人做、哪些 Agent 做、哪些是人审 Agent 做的、决策权和兜底责任怎么分；
把过去的需求规格说明书，升级成业务级 spec：用自然语言把业务规则、边界条件、异常处理写清楚，这份 spec 既给业务部门看、也给 AI 执行；
把"画系统图"的精力转一部分到"画组织里的协作架构"上。业务部门、AI Agent、IT 团队之间的协作关系，本身就是新一代企业架构的一部分。
业务系统出身这一脉的优势，其实没有被废掉。对业务的扎实理解，正是把 Agent 化做对的关键壁垒。要做调整的，只是落地的方式。
路径2 技术平台架构师
第二类是技术平台架构师。出身往往是中台、微服务、Service Mesh、消息中间件这一脉，工作方式偏向"做平台收敛、做能力下沉、做基础设施统一"。
这一类同行在 AI 时代会遇到一个反直觉的处境：我们最熟悉的"平台收敛"思路，遇到 Agentic 的"分布式自治"，会有结构性的不适。
过去做技术平台，关键动作是消除重复，把分散的能力收上来，统一治理、统一暴露、统一调用。这套思路对于确定性系统是高效的。100 个业务系统都要做权限校验，那就把权限做成统一服务。
AI Agent 的范式跟这件事不完全兼容。Agent 的关键能力之一是自主规划、自主调用、自主重试。它要的是"被赋能"那种关系，过去那种集中"被调度"的姿态反而会限制它。一个被过度收敛、所有动作都要经过中央调度的 Agent 平台，反而会让 Agent 失去它的优势。
我观察到几个企业里跑得比较吃力的 AI 平台项目，技术起点都不差，但起步阶段就把"统一编排""统一调度""统一上下文管理"做得太重。结果是上层业务方要嵌一个简单的 Agent 应用，要先穿过 4 - 5 层平台抽象，体验上反而比直接调模型还慢、还难。
跟几位平台出身的同行交流下来，比较有效的几条做法：
把"平台思维"换成"基座思维"：基座只做一件事，把通用、确定性强的部分（鉴权、审计、模型路由、向量存储、知识管理）下沉好；基座不该做的事，是替 Agent 决定"该用哪个工具、按什么顺序调"；
接受"分布式 Agent"的现实：业务方会跑出很多自己的 Agent，平台不要试图全部纳管，而是定好契约：什么样的 Agent 必须接上来、什么样的可以自由跑、上下游怎么对接；
重新理解"治理"：从过去的"事前评审 + 事中管控"，转向"事中可观测 + 事后可追溯"。Agent 系统的治理重心，落在运行中能看清楚、能回放、能纠偏。指望在出发前把所有路径都框死，这件事 Agent 时代做不到。
平台出身的同行底子很扎实，转过来之后往往是企业 AI 平台最合适的牵头人。要先放下的，是过去那套"全统一"的本能。
路径3 企业架构师 / EA
第三类是企业架构师，通常受过 TOGAF、Zachman 这类正统 EA 框架训练，工作方式偏向画蓝图、做企业级治理、定中长期规划。
这一类同行在 AI 时代的处境，可能是最复杂的一类。手里的方法论，正在经历这一波最大的考验。
TOGAF 这一类框架的基本假设，是"企业的能力可以被分层建模、可以被中长期规划、可以被自上而下治理"。这个假设在过去 20 年的 IT 环境里基本成立。AI 这一波带来的几个特点，正好踩在它的痛处：
演进周期太短：TOGAF 一份完整的企业架构规划，做下来半年到一年。AI 这一波 6 个月的技术演进，常常足以把规划推翻一次；
不确定性太强：传统 EA 的"目标架构"是一个相对收敛的状态；AI 时代企业的目标架构是开放的、动态的，根本不存在一个稳定的"to-be"状态可以画；
底层原语在重建：能力图、应用架构、信息架构这些 EA 标准视图，里面的元素全部都在被重新定义。一张 EA 蓝图画出来，半年后可能元素表就过时了。
但 EA 这一类同行，恰恰也是最有可能在 AI 时代"二次发挥"的群体。前提是愿意把方法论一起更新。
我看到几位 EA 出身的同行转得比较好的，做法大致是这几条：
接受蓝图从"静态"变"滚动"：放下"做一份用三年"的执念，改成"做一份用 6 个月、每季度滚动修订"。规划频率从年度变成季度，输出形态从大部头变成轻量化决策包；
把治理重心从"标准"转到"边界"：过去 EA 的治理产出是各种"标准""规范""指引"，AI 时代更需要的是"边界"，比如什么数据不能进模型、什么决策不能让 Agent 单独做、什么场景必须留人工兜底；
把"企业架构师"重新定位成"企业 spec 的总设计师"：跨业务域、跨系统、跨组织的 spec 谁来统一？这是 EA 天然的位置。spec 跨越技术层、业务层、组织层，能把这几层串起来的角色，企业里几乎只有 EA。
EA 这一类同行，方法论的更新代价最大，但天花板也最高。
四、几个共同的新坑
讲完三类架构师的应对路径，再讲一下我观察到几位同行最近一年踩过的几个典型坑，做了脱敏处理。希望大家在新阶段少走一些重复路。
场景1 把 Agent 当成"又一个微服务"画进 SOA 图里
这个坑我看到几位平台出身的同行最早做 Agent 试点时都踩过。看到 Agent 这个新东西，本能反应是把它当成"又一种微服务"，给它定义接口契约、纳入服务注册中心、做调用链监控。
这种处理方式短期看起来挺顺，问题往往在 3 - 6 个月后才暴露：Agent 的内部行为是概率性的，把它套进微服务的稳定性预期里，会发现监控告警常态化、SLA 怎么定都不对、版本管理混乱不堪。Agent 跟微服务是两类东西，不能用一套架构语言去描述。这一点几位同行都是踩了几次之后才意识到的。
场景2 spec 写成"详细设计书 2.0"
这个坑，我看到几位 EA 出身的同行都掉进去过。SDD 这一波之后，大家意识到 spec 重要，第一反应就是"那就把 spec 写得详细一点"。颗粒度从功能层一路下沉到行级、字段级、接口参数级，最后写出来的东西，跟 20 年前的"详细设计说明书"几乎没差别。
这种 spec 反而是失效的。AI 时代 spec 的价值不在"详尽"，在"意图清晰 + 边界明确 + 可执行"。写到行级颗粒，第一不可维护、第二束缚 AI 发挥、第三跟代码同步根本做不到。这是一个职业惯性的坑，要主动调整 spec 的层级感才出得来。
场景3 治理框架搭得太早太满
这个坑跟我们这一代人的"管理本能"高度相关。AI 项目刚启动，就把治理委员会、AI 伦理框架、模型审查流程、Agent 上线评审等一整套机制铺开。出发点完全是对的，但节奏不太合适。
企业 AI 当下的真正瓶颈，常常压在"试错不够"这一头。"治理不够"反而不是当下最该解的问题。试错都没做完、典型场景都没跑通、组织对 AI 的认知都没建立，先搭一套重治理框架，结果是把团队的探索空间封死，所有人都在做合规材料，没人在做实际产出。
正确的姿势我觉得是让治理跟着实践分批长出来。先有典型项目、再有具体规则；先有事故、再有评审；先有规模、再有委员会。做治理这件事，节奏比框架本身更重要。这一点几位同行都是踩了一两次之后才慢慢看清楚的。
场景4 只关注模型 / 工具选型，不关注组织协作架构
这是大家共同最容易忽略的一个坑，因为不在我们的舒适区。技术出身的人，遇到新事物本能反应是去研究技术选型：模型怎么选、向量库怎么选、Agent 框架怎么选。
但企业 AI 真正的瓶颈，今天往往不在技术。Agent 化的关键难题，是"人 + Agent + 系统"三者之间的协作架构如何重建：谁有什么权限、谁对什么结果负责、Agent 做错了由谁兜底、跨部门的 Agent 怎么协同、外部供应商的 Agent 怎么接进来。这些东西比模型选型重要得多，但因为不属于我们传统的舒适区，常常被排到后面。
我接触的几位走得比较远的同行，已经开始把"组织协作架构"作为 AI 架构的第一视图来画，技术架构反而退到第二位。这是一种值得我们参考的视角切换。
五、哪些东西在变轻、哪些在变重
讲到这里，回到职业层面的判断。我们过去 20 年攒下的能力资产，AI 时代会有一次再定价。把我观察到的方向粗粗摊一下，供同行们参考。
在变轻的几样：
画图本身的工艺性能力（结构清晰、配色专业、版式精致），这件事 AI 比人快很多；
评审清单（接口、性能、容量、可用性的 checklist 化思考），工具会越来越多地承担；
把方法论作为标签（TOGAF certified、AWS Certified Solutions Architect 之类），单纯认证的含金量在下降；
详尽文档撰写能力，在 spec 时代，详尽不等于价值。
这里说的"变轻"，意思是这些能力不再像过去那样是我们的独占壁垒，能力本身并没有归零。
在变重的几样：
跨域抽象能力，把业务、技术、组织三层捏合起来描述同一件事，这种能力比过去更稀缺；
写 spec 的能力，尤其是用自然语言把模糊意图写成可执行约定的能力，这是新的"代码"；
判断边界的能力，比如什么必须人做、什么可以 Agent 做、什么数据能进模型、什么决策需要兜底，这些判断的市场价格会上涨；
节奏感，包括什么时候做试错、什么时候做收敛、什么时候搭治理、什么时候放手，节奏比能力本身更值钱；
组织感知能力，比如能看清楚一项 AI 决策会在企业里激起什么反应、谁会支持谁会反对、推进的钩子在哪里。这种"软"能力在 AI 时代变成了"硬"价值。
写在最后
回到这篇文章开头那个问题：AI 时代，架构师怎么办？
我自己看下来的判断是，这是一次角色的重定价，谈不上是替代。我们过去 20 年攒下的几样关键资产，包括系统观、抽象能力、跨域协调、组织感知，在 AI 时代非但没有失效，反而变得更稀缺。但承载这些资产的"载体"，正在从图、文档、评审，切换到 spec、边界、协作架构。
这一波变化没有谁是站在岸上的。大家都在重新校准自己的工作定位和方向。如果说有一句话想对正在重新校准的同行朋友讲，我自己的体会是这样的：真正过期的，是我们手里这套工具。我们 20 年攒下的功夫，并没有过期。把工具做一些更新，而这些功夫，依然是这个时代最稀缺的东西。
我是徐翔轩，做了18年企业软件。后续会持续聊聊数字化、企业AI、产品商业化和to B经营方面的观察和思考。如果你也在推动数字化，希望这些内容对你有用。
往期精选：
Claude Code 之父 Boris Cherny 的 Sequoia 演讲，到底讲了什么
CIO 的下一个身份是 C AI OO（一个不算严肃的判断）
企业 AI 团队的负责人，内部转化还是外部招聘？（五种常见的牵头路径与思考）
为什么 AI Coding 产品都在长出 spec？聊聊规范驱动开发（SDD）
Workflow 还是 Agentic？可能是一个被问错的问题
Vibe Coding 来了，还要 IT （部门/团队）干什么？
