Yuri Gubin，DataArt 首席技术官 – 访谈系列

Yuri Gubin，DataArt 的首席技术官，是一位资深的技术高管和软件架构师，在 DataArt 工作超过 18 年，历任软件架构、解决方案架构、云技术、创新以及高层管理等职位，直至 2026 年 3 月成为首席技术官。他的工作重点是解决金融服务、医疗保健、旅行和物联网等行业的复杂技术挑战，尤其专长于云计算、人工智能、数据平台和企业软件架构。在成为 CTO 之前，Gubin 曾担任 DataArt 的首席创新官超过五年，并自 2021 年起成为公司合伙人委员会成员。他还是 Forbes Technology Council 的专业会员，参与其 AI 与云计算专家组，并担任 Girls Who Code 的技术顾问，提供架构、数据保护、平台治理和技术政策方面的建议。DataArt 目前将他列为总部位于纽约的首席技术官。

DataArt 是一家全球软件工程及数据和 AI 转型公司，成立于 1997 年纽约。公司已发展至拥有超过 6,000 名技术专业人员，遍布 20 多个国家，并为超过 400 家客户提供服务，业务涵盖人工智能与机器学习、数据与分析、云转型、定制软件工程、网络安全以及遗留系统现代化等领域。DataArt 在金融服务、医疗保健与生命科学、旅行、媒体娱乐和零售等行业开展业务，并与包括 AWS、Google Cloud、Microsoft Azure、Snowflake 和 Databricks 在内的平台保持技术合作伙伴关系。2025 年，公司宣布对其数据和 AI 能力进行 1 亿美元、为期三年的投资，随后在 2026 年推出 Artisyn——一种 AI 驱动的运营模型，旨在将 AI 代理、可复用加速器、治理、安全和合规性融入企业软件开发。

您在 DataArt 工作近二十年，从软件架构师和解决方案架构师晋升为首席创新官，现任 CTO。这个历程如何影响您区分真正的变革性技术与炒作周期，并且如何塑造您对 AI 的“怀疑的乐观”态度？

多年来，我们目睹了许多不同的浪潮，包括云计算和移动技术的兴起、不同代际的 AI、自动化、DevOps 和 SRE，我在此期间一直在为客户编写代码、进行架构设计并提供咨询。我的体会是，的确，技术几乎可以实现任何事，且技术本身非常强大，但关键在于细节，必须了解自己在做什么，才能让它有意义并发挥作用。

我见证了云环境成本日益上升、AI 模型未能如预期表现，以及自动化发布周期的糟糕实现。我也看到过好决策和坏决策的影响，因此每当出现新事物并阅读所有公告、承诺和炒作时，我都会回到同一个前提：技术几乎可以实现任何事，但你 需要 知道自己在做什么。

通过研发，尤其是通过实际项目，你才能真正掌握一项技术，因为只有这样才能了解哪些是可能的，哪些是不可能的，以及可能出现的问题。你从每一次合作中汲取经验，与你的同事、其他架构师和分析师交流，尝试判断是否存在模式以及能否围绕这些模式建立某种体系。最终，这些经验会转化为指导原则，进而检验你原本认为是正确的决策是否真的产生了良好结果。

这正是怀疑的乐观来源所在。无论技术承诺了什么，你仍然需要了解自己在做什么，而这种知识来源于经验、协作以及持续的学习、进步，并在炒作背后构建某种体系。

企业 AI 似乎正从鼓励实验的阶段转向决定哪些实验真正值得规模化。哪些信号表明 AI 用例已准备好更广泛的部署，哪些警示则说明公司扩展得太早？

我使用两种方法来判断我们是否可以规模化某项技术，或是否需要采取其他措施：采纳曲线和学习曲线。

要判断 AI 用例是否有效，需要给它一些时间，了解它带来的价值以及用户旅程的表现，因为这样才能看到其起伏，而不仅仅是某个团队或工作流中瞬间的“惊艳”效果。还要观察几周后同一批用户的情况。他们仍在使用吗？他们仍对该用例、该自动化或他们创建的 AI 能力感到满意吗，还是这仅是一次不应被规模化的短暂亮点？

其中一些事情只能随着时间的推移进行验证。总会有第一批先驱者，通常是技术最娴熟且极具好奇心的人，然后你需要在其他细分领域进行尝试，跟随早期采用者的后续者以及早期多数者。一旦它在那里证明了自身价值，是的，你就可以开始规模化并将该用例扩展到其他部门。

每一次重大模型发布都可能在组织内部产生压力，迫使员工立即获取最新功能。技术领袖应如何评估新模型是否代表实质性改进，而不是仅仅引发新一轮的实验和成本？

再次表达我的怀疑性乐观。假设你已经拥有一个模型，并且有数千人每天使用 AI，且已有不同的模型和工具可用。当新模型出现时，由于炒作和自然的好奇心，你可以预期每个人都会想要进行实验，这本身是好事，但这种实验可能并未得到指导或针对特定结果导向，有时甚至无法衡量差异。

在大规模时，这一点很重要。这不仅仅是一两个人尝试新模型相对于旧模型的表现。可能有成千上万的人花时间进行实验，而对于特定用例来说，结果可能并不显著。同时，如果某些东西真的运作良好，组织内部关于什么有效的学习可能并未被清晰阐述或让所有人看到。

这就是为什么首批评估新模型的团队不应是组织中的所有人。它应当是一个研发团队，紧密合作相关团队以及法务和安全部门。我们对模型进行全面评估，快速评估后再向更广泛的受众提供一些关于安全、合规和技术的评论与指导。随着新模型和重大更新不断涌现，你需要具备这种模型和思维方式。这绝不是一次性或偶发的工作。

DataArt 已组建了一个跨职能的 “AI SWAT” 小组，涵盖技术、法务、合规、信息安全等团队。该小组在实践中如何运作？在批准新 AI 工具供更广泛使用之前，需要解决哪些风险或问题？

自成立以来，我认为我们大约每四到五个月就为该小组设定不同的目标。我们会更改优先级、目标，有时甚至使命，而这些目标中有很多围绕 AI。可能是提升员工技能、市场推广和新功能、合作伙伴关系，或在组织及整个 ADLC 中更广泛地推动 AI 的应用。

具体议题会随时间演变，我认为这很健康，因为你必须不断重新审视自己的战略，验证假设，并了解是否需要转向以及团队的下一个主题应是什么。

该小组由不同部门的代表组成，其目的之一就是让所有人保持信息同步。每当有新公告、问题或机会时，任何人都可以在我们的例会中提出。即使看似仅与某个小团队相关的技术问题，如今也可能对组织的许多部门产生影响。

因此，当我们评估新的合作伙伴、工具或加速器时，会公开讨论，让每个人了解进展并有机会提问或提供监督。对于新 AI 工具，技术部门不能单独评估。安全、法务和合规也需要了解它如何处理公司或客户数据、适用的约束条件，以及是否能够安全地大规模使用。

AI SWAT 团队有时也会负责具体项目，例如技能提升，我们会设定目标、绘制路线图并决定不同团队的入职方式。这正是它的运作方式：让人们保持信息同步、在具体项目上协同工作，并向董事会提供公司 AI 动态的可视化。

你会看到对 AI 辅助软件开发的态度差异很大，有些组织积极扩展代理式开发，而另一些仍然禁止 AI 生成的代码。是什么导致了这种分歧？在更多注重风险的企业对 AI 在软件工程中扮演更大角色感到舒适之前，需要做出哪些改变？

可能导致说不和说是之间差异的，是它们的风险偏好以及对模糊性和不确定性的态度。持续的教育、实验和评估有助于两类组织。即使在我们合作的许多拥抱 AI 并将其融入各处的组织中，仍然面临衡量结果和影响的挑战。说实话，如何衡量 AI 的影响以及如何评估团队绩效的问题，有时几乎是凭空出现的，仿佛之前没有人真正思考过。

一旦你开始更全面地评估 AI 项目，就会逐渐了解其实际产生的影响和价值，这有助于在技术适用的地方做出更好的决策。对于那些拒绝 AI 的公司，仍然需要持续审视技术能够做什么以及它目前所处的阶段。你不希望三年前的决定因为没有人重新审视其背后的假设而仍然成为公司的政策。

Agentic AI 让各个团队自行创建代理变得越来越容易，这可能导致多个代理执行几乎相同的任务。实验何时会演变为代理蔓延？需要怎样的治理层来管理所有权、权限、重复以及生命周期管理？

当我们看到一种典型情形：每位开发者都获得 AI 许可证，实验缺乏指导，大家各自创建自己的东西并以各自的方式工作时，通常会导致团队表现不佳、期望落空、质量滞后以及费用上升。根本问题在于它并未实现大家的预期，质量差且成本高。为了解决这些问题，需要将其作为更大部门或组织层面的团队协作，而这正是治理发挥作用的地方。

在项目层面，你可以就知识库、上下文以及开始使用 AI 的用例达成一致。随后创建的技能和代理会成为开发工作流的一部分，供所有人复用，从而累积知识和最佳实践，而不是每次都重新创建。这类项目层面的工作应由企业架构委员会、技术团队、CTO 或负责 AI 采纳的团队等组织进行协调。你希望复用表现良好的代理，确保流程稳固，并让这些工作在整个组织中发挥作用，而不是陷入混乱和噪音。

因此，我认为这需要在项目层面、甚至项目计划层面同步推进，同时在部门和组织层面也要保持一致。

在试点阶段，令牌消耗和推理成本可能相对较小，但当 AI 系统在数千名员工或自主代理中部署时，这些成本会变得显著。企业应如何思考 AI 成本管理？你是否预期会出现专门针对 AI 工作负载的 FinOps 类似体系？

我先说，几乎理想的情形是 AI 成本先上升、达到平台期，然后随时间略有下降。这表明你可以预测、控制成本，了解实际在 AI 上的支出，并看到所做决策的结果。糟糕的情况是成本持续上下波动，这通常意味着不可持续；或者成本先上升后完全下降，说明采纳可能未真正发生、某些环节失效，或人们转而使用其他方案，而你根本看不到这些情况。

所以 FinOps 本身是一回事，AI FinOps 也是如此。有些技术手段非常专业，另一些则相当简单。比如选择首选模型，避免总是使用最昂贵的模型，逐步的决策就能节省开支。同时，了解如何节约和控制成本只是方程式的一半。FinOps 在我看来是一种学科和方法论，也需要产品和业务负责人参与，因为在评估 AI 工作时必须明确衡量的指标。

因此，我认为 AI FinOps 是一个适合 AI 特遣队讨论的话题：花了多少、收获多少、如何控制以及有哪些机会。

许多公司被要求展示 AI 的投资回报率，却从未为 AI 引入前团队的生产力建立可靠的基线。组织在想要判断 AI 是否创造了有意义的商业价值时，实际上应该衡量哪些指标？

无论你对 AI 持何种态度，或目前处于何种阶段，也许你已经在四处使用代理，亦或计划明年开始使用 AI，如今建立基线已是必不可少的前提。

指标大致可分为几类。有些是主观的，例如开发者或员工的反馈，因为与人合作时，了解他们对 AI 价值的感受至关重要。更客观的衡量可以从机械或合成指标入手，尽管我建议大家不要过于拘泥于此。比如代码提交次数或故事点等，这些指标能显示工作在进行，但并不能真正体现价值或影响。

更重要的是能够说明工作交付速度或质量的度量指标。可以考虑 DORA 指标，例如交付前置时间或 MTTR，衡量您从故障中恢复的速度、在生产环境中修复 bug 的速度，或这些指标随时间的变化。单一时点的数值并不能揭示趋势。我们的一位架构师最近提到，在软件开发中，一个好的指标也可能是随着 AI 采用率提升，估算的可靠性，因为这反映了这些工作可持续性以及团队的真实生产力。您还需要跟踪成本，因为如果只谈收益而不了解实现这些收益的成本，就无法看到全貌。

在软件开发之外，我也会以类似的方式思考。每个工作流或流程都有其工作单元和完成定义。无论是处理理赔、审阅文档还是处理客户请求，都要明确交付内容，然后衡量在引入 AI 之前所需的时间、现在的速度和质量，以及其成本。这为基准线和度量框架提供了良好的起点。

DataArt 已通过诸如 Artisyn 的计划在软件交付生命周期中嵌入 AI。随着 AI 接管更多的实现、测试和工作流任务，软件工程的哪些部分对人类更有价值，哪些技能可能变得不那么重要？

只有当你仍然记得 好 的定义时，才能在开发中有效使用 AI。你需要这种专业知识来指导你的代理，审查结果，设定约束并定义规则。你必须了解最佳实践以及良好架构的样子，因为如果没有这些，你可能不知道正在开发什么，而这类专业知识的价值正以极其显著的速度上升。

理解架构模式很重要，同样了解在特定行业、应用或解决方案类别中何为合适也很关键。你需要知道当前哪种架构是好的，以及当解决方案扩展时哪种仍然是好的，因为有时同一架构并不能在整个解决方案或平台的生命周期内始终适用。

对特定解决方案的适配平衡正是人的因素。这体现了服务和软件开发背后的品味与工匠精神。你必须了解自己在做什么，而这也来源于对客户和行业的理解。

哪些技能变得不那么重要？我很难给出明确答案，或许是代码输入的速度。我开玩笑的，但现在代码可以生成得更快得多，利用 AI 也能更快地学习特定库或语言的专业知识。

我曾看到 .NET 开发者很快转型为 Java 开发者，而在五六年前，我会说大规模这样做几乎不可能。如今，你完全可以做到。资深开发者越来越能够在语言之间切换，因为真正重要的是他们对技术、架构、解决方案最佳实践、软件开发生命周期（SDLC）和 AI 开发生命周期（ADLC）的理解。

随着企业从数十个 AI 试点转向能够自主行动的生产系统，当 AI 代理出现代价高昂的错误时，最终的责任应归于何方：开发者、业务所有者、模型提供方、治理团队，还是它们的某种组合？

我赞同无责协作和共享责任的理念，因为组织中的每个人都在为最佳实践、架构框架和解决方案做出贡献。即使某位开发者使用或不使用 AI 编写代码，另一位开发者会进行审查，团队负责人提供指导，架构师制定架构和约束，治理团队则参与预算、时间表和发布的决策。每个人都以某种方式参与其中。

通常情况下，问题出现时是流程出现了缺陷，从这个角度看，责任在不同角色之间是共享的。但仅仅说责任共享因此无可指责是不够的，仍需将其细化为具体的职责。

开发者对其提交的 pull request 代码负责，并且需要了解其中的情况。架构师对其所作的决策以及提供给代理和开发者的架构决策负责。平台团队对解决方案的可靠性负责，无论特定代码行是由谁或什么生成的。

因此责任是存在的，但需要按团队、角色和部门进行细化。不能仅停留在“AI 做了这件事”的分析上，需要追问是什么控制、测试或监督导致该故障进入生产环境。

如果缺乏单元测试导致劣质代码被推送到生产，或缺乏监督审查导致此类情况发生，不能将责任推给 AI。同样也不能把每一次错误或宕机都归咎于模型提供商或云服务提供商。

感谢这次精彩的访谈，想了解更多的读者请访问 DataArt。