在AI增强的变革流中，架构师要承担何种角色？
Source: InfoQ - AI & LLM
引言：悖论
数据能够反映出很有意思的现实。麦肯锡的“人工智能现状（State of AI）”报告显示，72%的组织已经在至少一项业务职能中采用了AI。投资速度令人震惊，数百亿美元正在被投入AI研究，企业为AI项目划拨了前所未有的预算。然而，在现实中，大多数组织并没有从中获得实质性的价值。
一个鲜明的例子是优步的Michelangelo平台（来自Wang Kai等人）。该平台经过多年建设，已经成为其机器学习的基础设施，能够使开发团队快速掌控自身的领域，并部署从路径优化到需求预测等各类解决方案。随着AI技术演进，优步进一步利用生成式AI（GenAI）加速了开发进程。正是由于早已建立了坚实的组织与技术基础，优步才能在AI浪潮中占据先机。
与此同时，过去几年采纳AI的大多数大型企业却难以突破试点阶段。这些企业拥有相同的技术和知识资源，却缺乏必要的组织结构与平台来释放AI的真正价值。Gartner 2025年的研究显示，在AI成熟度较高的组织中，仅有45%能将项目维持三年以上，此外，57%的高成熟度组织已准备好采用新的AI解决方案，而低成熟度组织中这一比例仅为14%。
我们谈论的 vs 真正重要的
正如麦肯锡的AI状态报告所示，AI的采纳速度在不同行业及组织内部不同类型工作中呈现出显著的差异。在软件平台与工程领域，AI的应用已明显加速。
随着开发与DevOps社区拥抱AI，其放大效应显而易见。谷歌的“DORA：AI辅助软件开发现状”报告指出，采用AI带来了可观的收益，包括：
个体效能的提升
工作重心转向更高价值任务
产品性能改善
代码质量提高
组织整体绩效增强
然而，尽管技术在不断进步，但是组织层面的影响仍参差不齐。JetBrains的“开发者生态系统现状”调查显示，超过50%的开发者每天有20%至60%的时间花在会议、工作聊天和邮件上。沟通与状态对齐仍是核心挑战。矛盾点在于，更快地交付成果，并不必然意味着更快地创造商业价值。
将更多精力投入到理解价值流与业务上下文，才是交付更高价值的可行路径。架构师在此过程中扮演关键角色，也就是弥合组织目标与开发速度之间的鸿沟。他们帮助团队设计具备韧性、可扩展的系统，将业务意图转化为稳健的技术实现。
归根结底，真正重要的并非我们编码或部署的速度有多快，而是我们能否有效地将持续改进融入业务运营与组织体系之中。
迈向AI驱动的持续变革流
显然，人工智能（尤其是生成式AI和AI Agent）正在促使组织重新思考如何适应持续发生的变化。但这并不意味着传统的架构定义方法已经过时。相反，这条路径在于利用AI增强既有的架构实践，从而在业务上下文、设计与交付之间建立持续的流动。
Anthropic的“经济指数报告”基于数百万条匿名的Claude对话数据，将用户与Claude的交互模式分为两类：自动化（AI在无需显著用户输入的情况下完成任务）和增强（用户与AI协作完成任务）。不到两年间，自动化交互占比从41%上升至49%，而增强型交互则从55%下降至47%。
这为软件相关工作中AI的应用提供了一个有趣的代理指标：尽管AI工具和Agentic AI发展迅速，但用户正越来越多地依赖AI处理更复杂的组织任务。在技术驱动型组织中可以推断，虽然AI已经能够显著提升个体在离散任务上的生产力（自动化），但在组织流程层面的更大效率增益（与增强相关）仍面临障碍，主要是数据就绪度和业务领域上下文信息的缺失。在CGI的架构实践中，当组织试图将AI从孤立试点扩展到规模化应用时，这些挑战反复出现，凸显了领域清晰度与上下文工程（context engineering）的重要性。
架构师支持组织从个体生产力提升迈向整体运营效率的提升。这需要架构层面的努力来保障组织资产，即确保数据可用性、明确业务上下文边界，并重新对齐流程。如前所述，这些需求本质上是人力、组织或信息层面的，而非单纯的技术栈现代化。新兴的业务需求将要求更高的一致性与清晰度，以便AI Agent或AI辅助开发团队能在组织层面实现改进。在此背景下，架构的意义愈发聚焦于赋能人类与AI智能体协同演进的流动机制。
为何“快速流动”优先？
如前所述，AI如同水流，会沿着组织现有的渠道渗透。渠道清晰直接，流动便会加速，渠道曲折狭窄或存在死胡同，则引发洪涝与瓶颈。在组织的语境中，“快速流动”指快速响应变化并基于早期反馈及时调整航向的能力。它关注系统级的敏捷性，即快速收集、理解并将业务需求转化为可交付解决方案的能力。这种流动必须与真实用户需求和业务战略对齐，而不仅仅是追求技术效率。实现快速流动的组织通常具备四大特征：
业务对齐（Business alignment）
清晰的领域边界（Clear domain boundaries）
可控的认知负荷（Managed cognitive load）
优化的交互模式（Optimized interaction patterns）
战略对齐确保AI解决的是真正的问题。在考虑技术之前，快速流动型的组织始终紧密耦合业务战略、用户需求与技术领域。团队清楚自己的工作对用户的意义及其如何驱动商业价值。当这类组织采纳AI时，目标明确指向特定用户的痛点与战略业务目标。而许多组织则为了“现代化”而部署AI，未与用户成果建立清晰的联系，这可能会取得技术成功，却遭遇商业方面的失败。
清晰的领域边界使AI能在业务上下文中安全自治。当团队所负责的领域明确对应业务能力与用户需求时，AI就可以在这些边界内有效地运作。这种对齐意味着AI决策天然反映业务规则与用户诉求。如果缺乏这种清晰性，技术边界与业务边界脱节，将放大系统的模糊性与复杂性。从领域驱动设计（DDD）视角看，要实现AI支持的组织效率提升，架构师可能需要更新限界上下文（bounded contexts）的交互模式，审视核心子域的关键流程，或优化支撑性子域的流程。
优化交互模式确保跨边界协作始终以用户为中心。在快速流动型的组织中，团队互动是有意设计且定期复盘的。缺乏这种纪律，会经常导致多个团队重复解决相同的问题、构建相同的方案。为了应对混乱，有些组织又走向了另一个极端，即强制所有人频繁沟通，这反而会引发了混乱。快速流动型组织采用Team Topologies框架，在必要时促成团队高效协作与沟通。
激活流动性
为了说明AI在架构中的流动应用，我们描述一个组织在生成新解决方案规范（specification）时如何借助AI的历程。他们并非一开始就得出了结论，而是经历了启动、激活流动性，并在推进过程中不断演进架构方法的过程。
以下案例研究展示了“架构流动性”在实践中的具体体现。在CGI的一项倡议中，目标是将AI用例转化为跨多个业务解决方案的规模化AI实现。
团队首先通过战略指导，超越传统的研讨会，加速将业务AI的用例推进至概念验证（Proof of Concept，PoC）实现阶段。为此，团队推出了一种队列式（cohort-based）的计划，与各团队合作细化业务价值、用户旅程及潜在的AI用例。通过快速迭代，我们将UI原型迅速转化为PoC实现。
业务负责人通过UI原型直观感受到AI的潜在影响与收益，同时也能看到其他团队的思路。除了宝贵的协作体验外，开发者也首次拥有了明确的视觉目标来指导实现。持续的积极反馈证明该计划深受参与者认可。下图展示了该队列式流程的迭代循环及其输入/输出：定义用户旅程、原型设计、演进AI辅助的规范。
在启动阶段，团队通过调研业务负责人，使用统一的MadLib格式确认优先的主题与用户故事（基于“Next Best Action/Recommendation”框架）：
根据每期队列的战略主题，邀请团队成员。在首次研讨会中，队列成员深入探讨所选用户故事并定义用户旅程。随着时间推移，队列逐渐转向通过自然对话描述上下文，而非提交结构化输入，用户故事演变为由业务负责人讲述简短故事后自动生成。贯穿队列过程的一项关键考量是，在有限时间内平衡交付引人注目的成果与保持专注性。
因此，首次研讨会聚焦于使用简洁布局定义用户旅程图（如下图），以价值流图为背景（触发事件 → 步骤1 → 步骤2 … → 步骤6 → 结束事件/结果），并按故事板划分泳道（角色、行动、情绪、痛点、机会、交付价值）。
在明确PoC范围的上下文与边界后，UX设计师与队列快速协作，设计UI线框图与可点击的原型。设计师在“过渡仪式（cross-over ceremony）”中向队列展示成果，随后由一支精简的跨职能小队（全栈开发、数据科学家、提示工程师、AI 解决方案架构师）接手，使用不同模型、算法与方法推进PoC。最终仪式展示了每个PoC的可行选项。该小队的核心目标是直接用AI解决业务挑战，并因聚焦队列优先级，与业务价值建立更直接的联系。
团队采取滚动交付模式，每月产出 2–3个UI原型或AI PoC实现。他们运行了多个队列，获得宝贵反馈并持续优化策略。然而，下一个挑战随之而来：如何将这些早期解决方案推进至生产级实现？
不出所料，实现团队提出的第一个问题就是：“规范文档在哪里？”尽管PoC有记录，但它们不能被视为可供其他团队进行实现的设计规范。这一挑战在CGI的转型项目中十分常见：PoC能带来清晰的认知，却往往缺乏下游交付团队所需的结构化规范。
不过，在过去6个月中，团队已积累了超过50小时的设计会议、UI原型演示和PoC实现记录。为避免回溯成本（比如，重新召集分析师和设计师细化方案），团队转而采用上下文工程（context engineering），利用基础模型（Gemini与GPT表现相当）进行处理。
假设：给定一个精心策划的设计模式知识库和标准输出格式，团队可以从对话记录或研讨会白板内容中生成一致的用户故事与用例规范。业务负责人认为生成结果的方向是正确的。
生成的规范包含典型的正常流与异常流，并涵盖系统组件、依赖关系等设计元素，附带初步的结构图与交互图。经过迭代，甚至纳入了旅程图，并根据故事叙述中的关键词自动分配情绪分值。团队进一步扩展规范，加入了验收标准、初始测试用例，以及安全、数据隐私等方面的检查清单问题，供实现阶段回答。
生成这些规范的基础是一个围绕实现设计模式（implementation design pattern）构建的知识库。团队扩展了传统的设计模式格式，加入检查清单问题，使生成的规范涵盖了以下的关键维度：
采纳与商业价值：确保方案能够交付可衡量的业务成果，并通过清晰的价值对齐与用户采纳策略获得认可；
用户体验：强调实现中的考量因素，确保用户交互直观、透明、可信，提升全程的信心、参与度与满意度；
运维因素：通过健壮的监控、性能与生命周期管理，维持可靠、可扩展、可解释的AI系统；
合规性与治理：嵌入伦理、法律和审计框架，以确保AI的运维能够负责任、透明且符合法规要求。
数据源与集成：定义数据质量、可访问性及连接性等考量因素，确保方案有效运行与可持续性；
安全与数据隐私：尽量左移（shift left），从源头将安全与隐私纳入考量。
这些实现设计模式从一开始就按业务负责人排序的AI用例优先级进行分类归档，形成以下原型：
原型 1：对话式Agent
原型 2：AI驱动的异常检测
原型 3：超个性化与下一步最佳行动/推荐
原型 4：智能工作流自动化
原型 5：多模态与全渠道AI
原型 6：预测性维护与安全监控
……（随着流动持续，将涌现更多原型）
默认模式实现的考量因素
下图展示了这些原型按架构关注点（UX与交互、监控与感知、业务流程与规则）的分类，为默认模式实现提供了有用的参考。
随着知识库不断扩充，团队现在能从一次研讨会讨论中自动生成包含验收标准和“左移”要素（比如，安全、隐私甚至法律视角）的完整规范初稿。但是，需要注意，团队的核心目标是构建扎实的架构知识上下文，而非开发工具。
AI与AI Agent持续演进。尽管团队正在探索如何根据规范反向生成UI原型，但从架构的视角来看，其信心源于精心策划的知识库。随着规范驱动开发（Specification-Driven Development, SDD，参见“理解SDD”）理念的兴起（比如，Spec Kit，一款基于AI的SDD工具包），团队更加确信自己走在正确道路上。这一旅程远未结束，AI在架构中的应用方式将持续演变，并会改变架构师的工作范式。
上述案例特别适用于“绿地”（greenfield）场景，也就是架构师与团队有足够的空间在启动新方案或向现有系统引入创新时，主导对AI的应用。然而，大多数组织还维系着支撑核心业务能力的成熟系统体系。这些系统构成一幅马赛克式的实现图景，各自处于不同生命周期阶段。对于那些专门构建的系统，其最新架构视图很可能已“铭刻于代码之中”。
毫无疑问，编码助手、Copilot和编码Agent已经引起开发者的广泛关注，他们日益将其用于日常的开发活动，从代码补全、文档生成，到覆盖整个软件开发生命周期（SDLC）的更高级能力，SDLC中的变革之流从未停歇。
在这样的“棕地”（brownfield）环境中，将AI应用于架构的机会广阔而多元化。AI可在多个阶段帮助架构师弥合组织业务能力与技术实现之间的鸿沟。例如：
使用AI来支持架构评估：评估架构决策的各个方面非常适合结合上下文工程与先进的基础模型（比如，Gemini、GPT、Claude等）。更稳健的权衡结果（例如，扫描技术选项以填补架构能力缺口）需要以关键架构原则和其他架构需求为依据。此外，采用少样本提示（few-shot prompting）技术，通过提供“好/中/差”示例，可引导权衡分析。此类策略可用于多种架构权衡的场景（例如，给定某种实现方案，更适合单体还是微服务？事件驱动还是API驱动？）
使用AI来生成规范性架构：在大型组织中，常见的棕地环境挑战在于，随着时间的推移，架构发生了漂移但并未文档化，甚至缺乏架构图与文档。这些应用多为大规模单体系统，而掌握其知识的人员往往已调岗或离职。手动逆向工程风险高、耗时长。此时，AI可评估应用并自动生成操作手册、架构图、数据模型与依赖关系等必要的文档。
AI Agent提出架构与设计方面的更新：在DevSecOps中，AI Agent正被用于持续摄取运行时事件流。它们可能监控已部署方案的安全漏洞，或分析运行日志以减少事件噪音与冗余工单。通过识别重复漏洞或运行模式，Agent可在适当时机提出设计改进建议。
结论：前行之路
人工智能本身无法凭空创造组织能力。人类必须先以组织知识为其基础，AI才能强化已有的基石。成功与停滞的分野，不仅在于模型、工具或基础设施的选择，更取决于组织是否具备支撑AI快速演进的架构基础。清晰的领域边界、可控的认知负荷、对齐的价值流，才能让AI增强交付，而不是仅仅添加复杂性。在此意义上来讲，架构师与架构本身成为AI的赋能者，而非旁观者。
正如案例所示，当架构师从控制结果转向框定上下文（定义语义、边界与护栏，使AI及未来的AI Agent自治变得安全可靠），AI的承诺才能真正兑现。
真正的问题并非“如何采纳AI”，而是“如何演进我们的架构，以支持AI增强的持续变革流”。
原文链接：