德瓦特公司（Devart）董事总经理安东·奥努弗里恩科（Anton Onufriienko）- 专访系列

安东·奥努弗里恩科，德瓦特公司（Devart）董事总经理，是一位具有深厚经验的技术高管和运营专家，曾领导过多家软件公司的业务扩张、收入增长和大型跨职能团队管理，涵盖了SaaS、企业软件和金融服务等领域。在他的职业生涯中，他从建立销售组织和启动初创公司逐步晋升到负责大型业务单元的全面盈利运营，包括德瓦特公司最大的部门，拥有130多名员工。在成为董事总经理之前，他曾担任德瓦特公司的首席收入官和销售负责人，领导公司的市场战略、定价转型和国际增长计划。他同时也是时间跟踪和盈利平台TMetric的首席执行官，该平台专注于帮助服务驱动型企业获得运营清晰度。

德瓦特公司是一家专门从事数据库开发、数据连接、集成和生产力工具的软件公司，服务对象包括开发人员、数据库管理员、分析师和企业团队。成立于1997年，公司最著名的产品是dbForge数据库管理工具套件，支持包括SQL Server、MySQL、Oracle和PostgreSQL在内的主要数据库系统。德瓦特公司还开发数据连接解决方案，如ODBC、ADO.NET、Python和Delphi连接器，以及其基于云的无代码数据集成平台Skyvia，用于ETL、自动化、备份和工作流编排。公司服务于全球50万多名用户，包括大量财富100强企业，并且越来越注重将AI驱动能力集成到其产品中，例如dbForge AI助手，帮助开发人员使用自然语言生成、优化、排除和解释SQL查询。

您从建立和领导销售团队逐步晋升到全面盈利运营和现在管理德瓦特公司最大的业务单元。这种经历如何塑造您在产品战略和决策中整合AI的方法?

销售经验教会我一切都要衡量ROI。当我进入CRO角色时，我将这种纪律扩展到整个功能。管理业务单元迫使我将其应用于AI本身。

我对AI持有一种务实的态度。这并不意味着我对AI持怀疑态度：我们2026年的四个产品投注中有三项都是AI原生。但我认为，炒作会阻碍真正、持久的成果。

有一则梗概括了行业经常出错的地方。公司用每月1000美元的API费用和需要不断修复的自建工具取代了400美元的SaaS订阅。这不是真正的改变，只是昂贵的表演。

我在销售中获得的经验很简单：每个计划都必须自负盈亏，否则就会失败。我以同样的方式运营我们的AI推出，就像我曾经运营一个销售区域一样。每个工作流程都有明确的ROI假设，采用三波推出方式，并在扩大规模之前记录影响。

我们的北极星指标是每员工收入，我们的目标是到2028年底将其增加一倍以上。您不能通过招聘来关闭这一差距，您必须通过改变工作的性质来实现，而AI是实现这一点的唯一现实机制。

我对每个AI计划的过滤器，内部或产品，都是一样的：什么是衡量的价值，谁为其买单，以及我们如何知道它有效？任何未能通过这三个问题的内容都不属于生产环境。错误的成本会迅速累积，多数公司将会以昂贵的方式发现这一点。

德瓦特公司在数据库工具和开发人员生产力方面建立了强大的声誉。您如何将AI嵌入这些产品，以提供真正的价值而不是表面上的自动化?

我们的用户是硬核技术专家：DBA、senior工程师、数据架构师。他们可以在几秒钟内检测出表面自动化，并对被出售的营销玩具感到厌恶。两年前，当AI炒作达到巅峰，竞争对手争相将聊天面板添加到每个UI元素时，跟随的诱惑是真实的。我以前见过这种模式，在移动设备、云计算、低代码中，我拒绝重复它。

原则很简单：客户价值第一。建立AI功能而没有人要求的功能，是对有限的工程资源的最糟糕的使用。尤其是当您的受众可以立即发现差异时。

2026年发生了变化的是，AI从炒作转变为真正的技术革命。这些系统在2023年和今天可以做的事情之间的差距不是增量的。这是一个完全不同的能力类别。我们现在可以解决以前真正无法解决的问题：为AI代理提供安全的企业数据访问，在开发人员的IDE内提供上下文数据库智能，并提供不需要专用分析师的自治业务分析。

这些是因为AI使得底层问题变得可解决而存在的新产品线。这就是我们对自己的标准：真正的AI产品是如果去掉AI层，产品就会崩溃。行业已经花了两年时间将聊天面板称为“AI产品”。那些是功能，而不是产品。

我们花了更长的时间，因为我们想做对。接下来的十二个月将表明这种纪律是否得到了回报。

AI越来越多地编写、优化和调试代码。您如何看待这将如何在未来几年内改变数据库开发人员的角色?

知道SQL语法的价值正在迅速贬值。如果AI可以在几秒钟内生成复杂的多表JOIN，并在几分钟内从日志中识别缺失的索引，则工程师的价值不再来自于输入SQL。这种工作正在变得像商品一样。

但是，自动化的倡导者总是忽略的一个关键细节是，数据库中的AI错误与前端的AI错误不同。前端的AI错误可能是按钮对齐错误，您可以刷新页面解决。但是，数据库中的AI错误可能会导致生产环境被擦除、PII泄露或整个业务的交易关闭。

数据库保存状态。它们不宽恕幻觉。

这种不对称性完全重新定义了这个角色。在接下来的两到三年内，数据库开发人员和DBA将从编码人员演变为架构师和审计员。他们的主要工作将转变为三件事：

• 设计AI无法自行推理的可靠架构，因为它缺乏业务背景。
• 为生产系统中的AI代理设置严格的警戒线和安全策略。
• 在代码部署到数据库之前，审查和审计机器生成的代码。

我反复想到的思维模型是：工程师将管理AI助手的军队。像dbForge这样的工具将不得不从传统的IDE演变为命令和审计中心。工作的重点将从手动编写SQL转变为审查AI生成的内容、验证它并执行AI无法安全跨越的边界。

在这里，专业机会是巨大的。升级到架构和监督的开发人员将会将他们的市场价值增加几倍。他们将成为AI生产力和生产安全之间不可或缺的层。数据库专业知识的溢价不会消失；它将转移到设计、治理和判断，这正是AI无法单独运作的地方。

当前AI工具在数据库管理中的最大局限性是什么，您认为在哪里会有最有意义的突破?

当前的AI仍然停留在表面上的自动化。生成基本的SELECT查询或样板代码已经不令人印象深刻了。更大的问题是，大多数AI系统仍然像盲打员一样，而不是系统架构师。它们可以生成语法，但它们不真正理解它们所操作的环境。真正的突破发生在AI开始同时考虑上下文、依赖关系、状态和业务逻辑时。

目前，我看到三个主要限制阻碍了AI在数据库环境中的发展。

首先，有上下文的问题。大型语言模型可以看到模式、DDL和列名，但它们不真正理解执行计划、索引碎片化、数据分布模式或数据背后的实际业务逻辑。没有这种更深入的理解，很多优化建议就变成了统计猜测，伪装成专家建议。

第二，有幻觉的问题。企业几乎对数据库层面的幻觉有零容忍度。一个JOIN的幻觉可能会减慢生产系统的速度。一个UPDATE的错误可能会擦除关键记录。在这种层面上，即使是小的准确性故障也会变得非常昂贵。

第三个问题是安全性和治理。没有严格的数据隔离和控制保证，严肃的企业不会将生产模式或PII粘贴到公共AI工具中。直到供应商正确解决这个问题，AI在受监管行业中的采用将保持有限。

有意义的突破将会发生，当AI从语法生成转变为更像背景架构师或分析师时。

其中一部分是语义层：从原始表名转变为实际的业务含义。不仅仅是“table_users”，而是理解诸如客户群、流失风险、第三季度LTV趋势等概念。

另一个转变是AI在后台更像高级DBA。持续分析工作负载，识别瓶颈，建议索引，发现有风险的查询，并在系统故障之前捕获问题。

然后你有机器到机器的操作，自治代理监视数据库负载，测试优化策略，并在人类监督下部署改进。

这些发展将塑造未来五年数据库工具的发展。

从您的经验来看，AI如何重塑软件公司的定价模式、产品包装和客户获取?

传统的市场推广剧本已经破产。我们在自己的数字和整个开发工具类别中都看到了这一点。

传统获取的消亡。尽管我们在2026年产品的搜索排名方面取得了显著改善，但我们正在面临零点击现实。AI搜索直接在结果页面上提供答案，并剥夺了网站的流量。强大的排名不再像两年前那样转化为潜在客户。

五年前，强大的内容策略足以推动增长。今天它只是基本要求。LLM权衡品牌实力、正面提及和社区密度，以形成答案。如果您的品牌不可见且不受信任，AI系统将停止一致地表面您。您不仅会失去流量，您将完全消失于购买过程中。更糟糕的是，整个市场已经陷入恐慌，转向付费广告，导致CPC达到荒谬的水平，并在暗中摧毁大多数SaaS公司的单位经济效益。

这种转变特别影响传统的开发工具公司。依赖SEO驱动的获取渠道来推动增长的B2B SaaS公司正在迅速失去效率。任何仍然依赖它们作为主要增长杠杆的公司都需要积极地建立替代方案：生态系统分销、社区和合作伙伴关系。

定价演变：从座位到PLG 3.0。我们正在进入PLG的下一个阶段。每个座位的定价开始崩溃，当一个AI代理可以做多个员工的工作时。在这样的环境中，按人头收费不再有意义。未能将产品重新包装为价值而不是人头的公司将在接下来的24个月内大量流失MRR。

下一步是PLG 3.0：自治AI代理（而不是人类）评估、测试和购买企业软件的时刻。这种模式的大规模采用还需要几年时间，但为机器买家设计产品和定价是一项2026年的任务，而不是2028年的任务。

许多组织难以将AI从实验转变为真正的生产影响。决定AI计划是否真正成功的关键因素是什么?

大多数AI功能在构建之前就已经失败了。它们在“我们需要在这个产品中添加AI”这样的会议室中失败，不是因为用户要求，而是因为董事会想要一个AI故事，或者营销团队认为它会吸引新受众。这是大多数AI计划的原罪，它塑造了接下来发生的一切。

我一直看到同样的错误在公司中重复出现，这些公司难以将AI从实验转变为真正的生产影响。

第一个错误是建立没有人真正需要的AI功能。一旦AI功能被强加而没有真正的用户需求，团队就会倒退一步，从技术开始，编造一个用例。结果是可预测的：一个聊天面板被添加到现有的UI上，一个会妨碍的自动完成功能，或者一个“总结”按钮，生成的输出比用户自己写的要差。这些功能被发布，获得新闻发布，然后在每个采用率预测中都表现不佳。更深层次的损害是，它们消耗了原本应该用于用户真正需要的功能的工程能力。

第二个问题是，团队严重低估了干净的演示数据和真正的生产数据之间的区别。AI演示运行在干净、策划过的示例上。生产运行在实际的客户数据混乱中：重复、缺失字段、同一产品有十种不同的拼写方式、十五年来的遗留边缘案例。一个在评估中取得了令人印象深刻的准确性的模型，在实时数据上可能会严重退化，大多数团队在用户投诉之前都不会发现这一点。在生产中发现这一点的成本通常是无法挽回的。

另一个常见的失败点是用户研究。标准的产品访谈不适用于AI功能。用户无法表达他们对AI的期望，因为他们不知道什么是可能的。询问“您是否会使用AI来做X？”会得到礼貌的肯定回答，但这些回答对采用率没有任何预测价值。有效的AI产品研究需要展示原型，观察实际使用情况，并衡量用户在新鲜感消失后是否会返回。很少有产品团队重建了他们的研究实践以适应这一点。他们仍然在运行2019年的剧本来解决2026年的问题。

最后，许多公司衡量AI活动而不是业务影响。“两百人本周使用了AI功能”是一个采用率指标，而不是影响指标。真正的影响是周期时间减少、质量提高、收入增加或成本降低。如果您无法从AI功能直接画出一条线到损益表上的一个数字，您就没有生产影响，您只是有一个昂贵的活动。

有一个变得越来越重要的第五个因素，大多数产品团队都完全忽略了它。

合规性和AI免费构建路径。受金融、医疗保健、政府、国防和法律等监管政策约束的企业用户占比相当大。这些政策禁止或限制供应商软件中的AI功能。如果您的产品将AI功能硬连接到核心体验中，而没有禁用或绕过它的方法，您不会通过添加AI来扩大您的受众，您会失去现有受众的一部分。

这正是我们通过AI连接性解决的问题。监管行业中的合规团队并不反对AI本身；他们反对数据离开他们的周边。解决方案不是剥离AI，而是为这些组织提供符合他们约束的AI架构。这就是为什么AI连接性以本地方式交付的原因：AI能力保持不变，数据永远不会离开客户的基础设施，采购审查在第一轮而不是第三轮就能通过。

那些做对了的团队会从一开始就为合规性进行设计。那些做错了的团队会在采购审查期间发现这个问题，当时交易已经丢失了。

德瓦特公司在多个数据库生态系统中运营。AI如何帮助简化在不同平台上管理数据的日益复杂性?

痛苦是真实的。典型的财富500强公司同时运行八到十二个不同的数据库引擎：用于财务的旧版Oracle，用于新服务的PostgreSQL，用于运营的SQL Server，用于分析的Snowflake或BigQuery，用于嵌入的向量存储。每个都有自己的方言、自己的工具、自己的治理制度。加入这种环境的开发人员可能会花三个月的时间仅仅学习数据的存储位置以及谁被允许访问它。

AI本身并不能解决这种复杂性。它会放大给定的任何上下文。八个不连贯的数据库会产生八个不连贯的建议集。这种失败模式正是我们在企业AI推出中看到的。

机会在于一个上下文层，它位于AI代理和底层数据库之间。一个可以与所有数据库对话、规范化元数据、执行统一的治理策略并向任何AI代理（无论是Claude、GPT还是内部模型）提供干净的MCP接口的层，以便在整个资产上以一致的规则工作。

这就是我们通过AI连接性构建的架构：一个具有多数据库支持的本地MCP服务器，一个捕获业务定义的语义层（只需一次），一个基于角色的访问控制（在SQL操作级别）以及完整的审计日志。

简化并非免费。有人仍然需要建模语义层并设置策略。但是，这项工作只需完成一次，而不是为每个添加的AI代理重复进行。

您曾领导过大型跨职能团队。AI如何改变产品、工程、营销和销售团队之间的内部协作和决策?

大多数跨职能团队的摩擦实际上只是人们在等待其他团队的信息。AI比任何管理框架都能更快地消除这种摩擦。

转变是实际的和立即的。

在产品和工程领域：产品经理以商业术语询问数据库问题，“我们前三种定价层的LTV差异是什么？”，并立即获得可行的答案，而不是提交Jira票并等待三天。

在营销和数据领域：同期分析可以在线完成，而不是通过请求队列。营销经理询问，获得数字，并在同一天早晨构建活动。

在销售和工程领域：技术答案不再需要安排与高级工程师的通话。销售代表获得可信的技术回复，实时完成，交易周期也随之缩短。

决策转移到对话中，而不是等待。让人说“让我回头给你那个数字”的模式正在消亡。会议缩短了，因为AI处理了以前会占用每次会议前半段的预读和摘要。

这迫使管理层进行更深层次的转变，这也是大多数领导团队低估的转变。

每家公司都声称自己是结果导向的。但是，看看他们的内部运作，多数公司仍然运行在代理指标上：故事点、代码行、关闭的票数、记录的小时数。我们使用活动作为价值的代理，因为实际价值很难衡量。AI打破了这种代理关系，永久地打破了它。当一个代理可以在一分钟内编写10,000行代码或关闭500个支持票时，衡量活动变得非常具有误导性。

我们正在转向真正的结果导向管理，绩效严格按照结果和判断力来衡量。实践中很残酷，因为大多数绩效系统都不是为此而设计的。那些曾经通过高活动隐藏自己的人会立即变得可见，领导层必须愿意对此采取行动。

结构后果是更扁平的组织图表。协调和信息路由层被压缩。能够最快适应的组织将以结构上更少的人员和更高的杠杆运营。

随着AI辅助开发和无代码工具的兴起，我们是否正在走向一个数据库管理变得对非技术用户更易访问的未来?

目前行业中存在一种危险的混淆。人们将小型绿地项目中的数据库和企业遗留数据库当作同一件事对待。它们不是同一件事。

对于小型绿地项目，民主化已经到来。我个人曾经在没有深入的数据库管理技能的情况下，从零开始构建小型应用程序。如果整个模式都在LLM的上下文窗口中，AI就像魔术一样工作。但是，企业现实却大不相同。大量的遗留数据库面临与大型单体代码库相同的问题：上下文墙。你不能将十五年的未记录的模式演化、跨数据库依赖关系和自定义触发器逻辑装入一个提示中。当AI在大型数据库上丢失上下文时，幻觉不会优雅地降级。它们会以指数级的速度增加。

被低估的风险是大规模的错误信心。自然语言接口在产生看似合理但微妙错误的答案方面具有独特的优势。如果一个SQL查询有语法错误，你会得到一个错误消息。如果一个自然语言接口由于你的数据有六个不同的活动定义而误解“活动客户”，你会得到一个数字。这个数字看起来很好。它可能会有30%的偏差。用户没有办法知道。

因此，企业数据库管理并不会成为非技术用户的游乐场。

大规模的公民DBA是一个神话。

未来属于使用专业工具来弥合上下文差距的专家数据架构师，使AI能够在其上安全运行。

结构解决方案是语义层：一个在AI交互中只需一次就可以固定业务定义的受控词汇表。没有它，易用性就会成为负担。

展望未来，什么样的“AI原生”开发工具包，我们应该如何开始为这一转变做准备?

AI原生工具包不是将聊天机器人添加到IDE上。今天市场上宣传的“AI原生”大多是聊天接口加上自动完成模型。这是基本要求，而不是目的地。

对我来说，真正的AI原生工具包需要三件事。

首先，AI需要深入的上下文。它必须连续地理解代码库、基础设施、历史决策和数据环境，而不是仅仅通过粘贴到聊天窗口中的提示。当前的大多数工具都未能通过这一测试。它们的上下文会话重置，用户必须不断地重建它。

第二，工具本身需要正确地相互通信。您的IDE必须与数据库交谈，数据库必须与可观察性栈交谈，CI/CD必须与AI审查器交谈等。模型上下文协议正成为这一层的标准，2026年第一季度每月有9700万次SDK下载，相比2024年末的10万次下载量增加了970倍。这是15个月内增长最快的曲线，我所见过的。

第三，生产级AI需要严肃的安全防护。操作前预览，依赖分析，自动回滚计划，审计跟踪默认启用。没有这些，AI对于原型来说是可以的，但在生产环境中是危险的。

具体来说，如何准备。

检查您的堆栈是否符合这三个组件。每个工具是否暴露API和MCP？它是否与其他工具交谈，还是坐在一个孤岛中？它是否具有安全控制？工具如果失败两项，就会成为短期资产。

现在就开始构建上下文基础设施。以机器可读的格式记录模式、业务定义和架构决策。丰富的上下文不是在一个季度内构建的。2027年拥有上下文的AI团队是那些今天正在记录的团队。

在您认为准备好了之前就将AI投入生产。等待正式“AI战略”才开始交付的团队将会落后于已经从真正的生产故障中学习的团队十八个月。选择一个低风险的用例。交付它。建立肌肉。

今天做出这些决定的团队将定义软件如何在接下来的十年中构建。窗口很窄，现在是开放的。

感谢这次精彩的采访，希望读者能够通过访问德瓦特公司的网站来了解更多信息。