Google 近期针对 BigQuery 推出了面向开源模型的第三方生成式 AI 推理功能。这一更新允许数据团队直接使用简单的 SQL 语句，部署并运行来自 Hugging Face 或 Vertex AI Model Garden 的任何模型。该接口目前处于预览阶段，其最大的亮点在于消除了对独立机器学习（ML）基础设施的需求，系统会自动启动计算资源、管理端点，并在任务完成后通过 BigQuery 的 SQL 接口自动清理资源。

这项新功能解决了困扰数据团队已久的痛点。在过去，运行开源模型往往意味着需要管理 Kubernetes 集群、配置端点以及在多种工具之间反复切换。Virinchi T 在一篇关于此次发布的 Medium 文章中指出：

这一过程需要多种工具协同、不同的技能储备以及巨大的运维开销。对于许多数据团队来说，这种摩擦意味着即便模型本身是免费且公开的，AI 能力依然显得遥不可及。

然而，得益于 BigQuery 的 SQL 接口，整个工作流现在被简化为仅需两条 SQL 语句。用户首先通过一条 CREATE MODEL 语句来创建模型，只需指定 Hugging Face 的模型 ID（例如 sentence-transformers/all-MiniLM-L6-v2）或 Vertex AI Model Garden 中的模型名称。BigQuery 会根据默认配置自动分配计算资源，部署过程通常在 3 到 10 分钟内即可完成，具体时长取决于模型大小。

部署完成后，用户可以使用 AI.GENERATE_TEXT（针对语言模型）或 AI.GENERATE_EMBEDDING（针对嵌入模型）直接对 BigQuery 表中的数据进行推理查询。平台通过 endpoint_idle_ttl 选项管理资源的生命周期，该功能会自动关闭闲置端点以节省费用。此外，在批处理任务结束后，用户还可以通过 ALTER MODEL 语句手动卸载端点。

为了满足生产环境的需求，该功能还支持高度定制化。用户可以直接在 CREATE MODEL 语句中设定机器类型、副本数量以及端点闲置时间。通过 Compute Engine 预留功能，还可以锁定 GPU 实例以确保性能稳定。当不再需要某个模型时，只需执行一条简单的 DROP MODEL 语句，系统便会自动清理所有关联的 Vertex AI 资源。

Google 在官方博客中将该系统描述为提供“精细的资源控制”和“自动化的资源管理”，旨在让团队在不脱离 SQL 环境的情况下，找到性能与成本之间的最佳平衡点。2025 年 9 月发布的一篇早期博客曾展示，利用类似的开源嵌入模型处理 3800 万行数据，成本仅需约 2 到 3 美元。

目前，该功能已支持超过 1.3 万个 Hugging Face 文本嵌入模型和超过 17 万个文本生成模型，涵盖了 Meta 的 Llama 系列和 Google 的 Gemma 家族。需要注意的是，所选模型必须符合 Vertex AI Model Garden 的部署要求，包括区域可用性和配额限制。

Virinchi T 强调了这一变革对不同角色的意义：

对于数据分析师而言，你现在可以无需离开 SQL 环境，也不必等待工程资源支持，就能直接实验 ML 模型。对于数据工程师而言，构建由机器学习驱动的数据管道变得极其简单，再也不用维护独立的 ML 基础设施。

此次发布标志着 BigQuery 将与 Snowflake 的 Cortex AI 以及 Databricks 的 Model Serving 展开直接竞争，后两者同样提供基于 SQL 的 ML 推理能力。而 BigQuery 的竞争优势可能在于其与 Hugging Face 庞大模型库在数据仓库内的深度集成，这对于已经在 Google Cloud 上运行业务的用户具有极强的吸引力。

目前，关于 Gemma 模型的文本生成以及嵌入生成的相关文档和教程已正式上线。

原文链接：

https://www.infoq.com/news/2026/01/bigquery-sql-huggingface-managed/

生成式 AI 的投资回报远超预期？Snowflake 调研全球 1900 位企业与 IT 专业人士后发现平均 ROI 高达 41%！点击下载完整报告

每个人都在努力提高大语言模型的精准度。但真正的挑战并非精度，而是上下文理解能力。在 BUILD 2025 大会上，Hex 合作伙伴工程负责人 Armin 探讨了为什么传统的方法，如评估套件或合成问题集往往不够有效，以及成功的 AI 系统是如何通过随着时间推移逐步积累上下文来构建的。

由 Snowflake Cortex 提供支持的 Hex，启用了一个新的对话式分析模型，每次交互都让模型变得更聪明。通过 Hex 的 Notebook Agent 与 Threads 功能，业务用户可直接定义核心问题，而数据团队则将这些问题精炼、审计并转化为持久且值得信赖的工作流。

在这个模型中，测试用例不再由数据团队闭门设计，而是由业务需求驱动并在数据工作流中自动实施，最终形成一个具有生命力的上下文系统，而非一成不变的提示词或测试集，它能随着组织共同演进。

准确率不是终点

Armin 开场就把矛头对准了一个常见做法：把业务用户会问的问题合成成一批样例，甚至进一步转成 SQL 查询，然后把这些喂给 LLM，用类似单元测试的方式去衡量它的准确率、稳定性与一致性。他不否认“准确性是顶层关注”，但他强调，把 LLM 当作传统软件组件来做单元测试，本身就是一个不合适的范式。

原因在于，当你把业务问题硬转换为一组 SQL，并据此去构建样例与评估集时，你很难覆盖真实业务中不断变化的语义、不断扩张的问题空间，以及不同用户在不同语境下对同一指标的不同问法。更重要的是，即使你做出了一个看似通过率很高的测试集，也依然回答不了企业最在意的那件事：当它在真实环境中生成了一个结论，你如何知道它不是在胡编？你又如何知道它到底做了什么才得到这个结论？

因此，Armin 把正确性从结果层拉回到系统层：你需要的不是一个靠样例证明自己正确的聊天机器人，而是一套可审计的系统，它能够随着时间变得灵活、可塑，能够让业务用户在使用中不断收敛可回答的问题类型，也能够让系统拥有被“硬化”的路径：哪些能力可以放开，哪些问题必须收紧，哪些定义需要固化，哪些数据应该进入上下文、哪些不应该。

在他看来，真正有效的路线是：从一套能运行、能被观察的系统出发，让系统在使用中暴露问题、沉淀模式，再反过来加固上下文。这种思路听起来不如直接做评估来得爽快，但它更接近企业系统的真实生长方式。

对话式分析如何变成“可审计的系统”

为了把“可审计”讲得具体，Armin 用 Hex 的产品演示展示了对话式分析在真实系统中应该是什么形态。演示从一个非常典型的业务问题开始：假设我是营销经理，我想让系统分析销售机会的“首次触达来源”（first touch source），并做营销归因视角的拆解。这里一个很关键的动作，是他先在系统里配置模型提供方：通过密钥对（key pair）连接到 Snowflake 实例，使用 Snowflake Cortex 内托管的 Claude，并强调这是一个“walled garden”的私有网络环境。这样做的直接意义是：模型驻留在数据所在的环境里，数据可以传递给模型，同时也能让 IT 团队对数据出入边界更放心。

进入线程后，Hex 并不是立刻吐出一句“结论”，而是在后台进行一系列用户不可见但决定可信度的步骤：它会先围绕可访问的元数据“思考”，查看平台上已有的 Hex 项目、仪表板或资产，判断是否存在可复用的内容；它会拉取来自数据仓库的表描述、列描述等元数据，并强调这些可以自动导入、不需要复杂配置；如果企业已经有 dbt 元数据，也可以进一步带入；随后它形成一个“漏斗式”的收敛过程：从广义元数据到相关表、再到更具体的模型信息与底层数据，最后才开始把 SQL 单元格、可能的 Python 单元格、图表与可视化逐步组织起来，用以回答最初的问题。

这也解释了他在演示里专门强调的一个点：这种模式一开始会“慢”，但这是刻意设计的。因为此时系统面对的是生产数据仓库，它需要把大量上下文带进来，需要推理与迭代，而这类深度思考天然会以时间为代价。换来的收益是：它可以生成更细致、接近数据科学家或嵌入式数据分析师水平的分析过程。Armin 也提到，未来会有更偏“快速、短促回答”的迭代版本，可能更多依赖语义模型，而不是每次都在全量上下文里深挖。但在这个阶段，他们优先解决的是“在没有分析师介入的情况下，业务用户也能得到一份扎实的分析报告”。

当线程生成结果后，界面里不仅有图表，还能继续做探索：拖拽维度与度量、查看底层表格数据、检查异常、做更深的切片。这时“可信度焦虑”就会自然出现：这么多信息暴露给业务用户，我怎么知道它没有幻觉？我该不该信这些 SQL？我如何让它更确定？Armin 的回答不是“相信模型”，而是把系统的底座亮出来：在 Hex 里，每一个线程、每一个项目，背后都由笔记本支撑。把线程保存为项目后，你可以在笔记本里看到完整对话以 Markdown 的形式呈现；更重要的是，你能看到它实际运行的 SQL、过滤条件、连接逻辑、图表生成过程，以及它如何一步步构建出整份报告。对于负责准确性与治理的数据团队来说，这种“把对话落到可审计的笔记本”非常关键——它让系统从一开始就具备被审核、被追责、被修正的可能。

在此基础上，Armin 进一步展示了一个更现实的协作场景：业务用户提出问题后，不一定要立刻去找数据团队提工单，而是先在对话线程里得到初步洞察；如果需要更深入的分析（比如进一步做季节性拆解），技术用户可以把笔记本智能体（notebook agent）限定在这个项目范围内，和智能体一起继续规划、推理、生成图表，并在生成的“待处理变更”中逐条审核、决定保留哪些结果。分析由此变成一种可协作、可迭代、可沉淀的工作流，而不是一次性、不可解释的问答。

从一次性对话到可复用资产

如果到这里为止，Hex 展示的是“可观察性”，那么 Armin 在后半段想讲的，是上下文如何变成系统能力，如何从一次性对话沉淀为可复用资产。

他先展示了一个从笔记本走向应用（app builder）的路径：当某些分析内容需要“持久化”，例如营销与销售负责人希望随时看到季节性分析或关键指标，而不是每次回来重新提问，那么就可以把笔记本中已经生成的图表、文本等资产拖拽到应用构建器里，做成一个仪表板、报告或更像 BI 的交互界面。这里的核心并不是“又做了一个 BI”，而是强调：即便呈现形态变成 BI 风格，背后依然由笔记本驱动，仍然保留 SQL、Python、Snowpark 等灵活性；同时，笔记本与应用这两种范式始终连接，资产是可回溯的。换句话说，展示层可以更友好，但底层逻辑并不会因此变成不可审计的黑箱。

紧接着他抛出了“连接胶水”的问题：当我们有线程、有笔记本、有应用，如何让它们构成一个一致的策略？答案是语义模型——它是 Armin 所谓“上下文引擎”的关键组成部分。原因也很务实：企业里那些精心构建的报表与仪表板，通常包含大量转化逻辑、业务口径、SQL/Python 查询，这些恰恰是 LLM 最需要、也最容易误解的上下文。如果不能把这些上下文结构化，LLM 的确定性就无从谈起。

在演示里，语义模型有两条路：一是导入已有的 Snowflake semantic view。Hex 可以浏览生产仓库、发现可访问的语义视图，然后快速引入，例如引入一个 B2B sales model，让 enriched metadata 直接在 Hex 中可用。另一条路更贴近多数团队的起点：不是先有语义视图，而是先有一堆被业务反复使用的仪表板项目。Hex 的语义建模工作台里有一个“建模智能体”（modeling agent），它能理解 Hex 的语义建模能力，并且能针对某个具体项目（例如 sales and marketing dashboard）去阅读项目里包含的 SQL 单元格、DataFrame 操作、joins、函数与过滤条件，形成建模计划，做错误预防，推断表关系，把“项目里已经存在的业务逻辑”烘焙进语义模型中。

这一段其实回答了一个关键的企业问题：语义模型从哪来？它不一定需要从零凭空设计，它可以从企业已经在用的分析资产中被抽取、被规范、被版本化。建好之后，语义模型还能用一种“拖拽式”的方式被检查：你可以选择维度、度量，查看聚合、查看系统生成的 SQL，在发布之前把模型硬化到你满意的程度。

更进一步，Armin 也回应了“供应商锁定”的担忧。他明确表示，Hex 不希望用专有 YAML 把用户锁死，并提到两个方向：其一是和 Snowflake 等一起推动“开放语义交换”（Open Semantic Interchange），一个由约 18 家甚至更多公司组成的联盟，目标是让语义模型信息能在不同系统之间互换，以促进 LLM 采用并避免 vendor lock-in；其二是更近期开启“写回”能力，让在 Hex 中构建的语义模型可以写回到 semantic views 中，保证不同系统间“友好共存”。这些内容在分享里出现得很明确：终点不是锁定格式，而是让用户愿意因为体验与工作流而持续使用。

当语义模型准备好后，线程侧的使用方式也随之变化：你可以把对话线程限定为“只使用语义模型”，而不是访问整个生产数据仓库。Armin 强调，这会让系统随着时间更确定：当你不断硬化语义模型、补充上下文，它会越来越稳定、越来越可控。也正因此，他再次回到开场的观点：把精力放在构建上下文系统上，而不是试图用合成样例把原型聊天机器人测到“看起来准确”。

规模化审计与上下文飞轮

分享的最后一部分，Armin 把问题推到最现实的规模化挑战上：当系统从一个人试用扩展到五十、一百个用户时，你如何监控它？你如何知道 LLM 系统到底在做什么，业务用户到底拿它解决什么问题？这时，“可审计”就不能停留在某个线程或某个项目，而必须成为一套能覆盖全局的治理能力。

他提到 Hex 的“上下文工作室”（context studio），目前处于少数 Alpha 合作伙伴的 Alpha 阶段，但他之所以专门强调它，是因为它承载了上下文系统最关键的一环：理解使用行为，反过来指导上下文如何演进。

具体来说，你可以看到平台总体使用情况：用户更常用笔记本还是线程？创建了多少语义模型？也可以按对话量看用户分布，查看某个用户使用线程的频次、提问的类型。更重要的是，当你下钻到“问题类型”时，Armin 给出了一个很强的判断：这些真实问题才是你的单元测试。不是你在上线前试图一次性“破坏一切”并用评估集兜住，而是看清业务用户到底在问什么，再回去硬化你需要硬化的上下文与问题类型。

围绕“如何策划上下文”，他在分享里给出了三个层次的抓手。最直接的是规则文件（rules file）：你可以在里面定义 SQL 的数据质量防护、业务定义、偏好的 SQL 风格、杂项信息，以及希望系统使用的可视化方式，并且这些内容可以即时编辑、保存或导出。第二层是“经认可的数据”（endorsed data）：由数据团队或所谓“金层”背书的数据资产，可以在 Hex 的语境下被定义清楚，决定哪些数据可以喂给 LLM。第三层则是更成熟、也最关键的做法：语义项目（semantic projects）。随着审计能力增强，你不仅能看到语义模型被使用的次数，还能观察是否有多个语义模型被同时使用、是否需要在某些场景中合并；你也能判断哪些项目最常被引用，从而决定是否需要对下游数据做更多建模，或者是否需要补充列描述、表描述等元数据来改善上下文质量。

这些细节共同指向同一个结论：上下文不是一次性设计出来的，它是被真实使用不断“磨”出来的。你从稍微宽的范围起步，抽取一两个语义模型，让业务用户用起来；再通过审计看到真实问题与真实路径，回去修规则、补语义、加背书数据、完善元数据。如此循环，系统才会越来越确定、越来越可信。

这场分享最有价值的地方，在于它没有把“可信”简化为一个指标，也没有把“准确率”当作唯一的归宿。Armin 反复强调的其实是另一套思维：企业要的不是一个在评估集上表现漂亮的聊天机器人，而是一套能持续吸收上下文、可审计、可治理的系统。

从线程到笔记本的可观察性，从笔记本到应用的资产化，从项目到语义模型的上下文结构化，再到面向规模化使用的审计与上下文工作室——这些环节被串成一个整体，目的只有一个：让 LLM 在真实业务里变得更确定，并且在需求增长时仍然能保持可控与可信。

原视频地址：https://www.snowflake.com/en/build/americas/agenda/?login=ML

🔥【活动推荐】2 月 2 日-6 日，Snowflake Discover重磅上线！这是一场免费、线上、可实时互动的技术活动，旨在帮助您全面提升数据与 AI 能力，深入了解如何更高效地管理、整合与分析数据。4 天时间 18 场技术干货分享，由来自亚太地区的一线技术专家亲自分享与讲解～

点击报名 Discover，更多 Snowflake 精彩活动请关注专区。

引言：悖论

数据能够反映出很有意思的现实。麦肯锡的“人工智能现状（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 如同水流，会沿着组织现有的渠道渗透。渠道清晰直接，流动便会加速，渠道曲折狭窄或存在死胡同，则引发洪涝与瓶颈。在组织的语境中，“快速流动”指快速响应变化并基于早期反馈及时调整航向的能力。它关注系统级的敏捷性，即快速收集、理解并将业务需求转化为可交付解决方案的能力。这种流动必须与真实用户需求和业务战略对齐，而不仅仅是追求技术效率。实现快速流动的组织通常具备四大特征：

1. 业务对齐（Business alignment）

2. 清晰的领域边界（Clear domain boundaries）

3. 可控的认知负荷（Managed cognitive load）

4. 优化的交互模式（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 增强的持续变革流”。

原文链接：

Architecture in a Flow of AI-Augmented Change