安东·奥努弗里恩科（Anton Onufriienko），Devart 公司的董事总经理 – 采访系列

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

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

您从建立和领导销售团队到运营全面盈利业务和管理Devart公司最大的业务单元。这种经历如何影响您在产品战略和决策中整合人工智能的方法？

销售让我明白了要衡量一切的投资回报率。进入CRO角色后，我将这种纪律扩展到所有功能。运营业务单元迫使我将这种纪律应用于人工智能本身。

我对人工智能持务实的态度。它不是我持怀疑态度的原因：我们2026年的四个产品押注中有三个是人工智能原生。但我相信，炒作会阻碍真正的、持久的成果。

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

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

我们的北极星指标是每员工收入，我们的目标是到2028年底将其翻倍。你不能通过招聘来填补这一差距。你必须通过改变工作的样子来填补这一差距，人工智能是唯一能够实现这一点的现实机制。

我对每个人工智能计划的过滤器，内部或产品，都是一样的：什么是衡量的价值，谁为其买单，以及我们如何知道它起作用了？任何不能回答这三个问题的东西都不属于生产环境。做错的成本会迅速累积，绝大多数公司会以昂贵的方式发现这一点。

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

我们的用户是铁杆技术专家：数据库管理员、资深工程师、数据架构师。他们可以在几秒钟内检测出表面自动化，并对被销售的营销玩具感到不满。当人工智能热潮达到巅峰，竞争对手争相在每个UI元素上添加聊天面板时，跟随的诱惑是真实的。我以前见过这种模式，在移动设备、云计算、低代码中，我拒绝重复它。

纪律很简单：客户价值第一。建立没有人要求的AI功能，这些功能不能提供真正的价值，是对有限的工程资源的最坏使用。尤其是当您的受众可以立即发现差异时，这种情况尤其如此。

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

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

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

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

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

但是，这里有一个关键的细微差别，自动化的倡导者总是忽略的。前端的人工智能错误可能是一个错位的按钮，您可以刷新。数据库的人工智能错误可能是生产环境被擦除，个人数据泄露，或者整个业务的交易关闭。

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

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

• 设计人工智能无法自行推理的可靠架构，因为它缺乏业务背景。
• 为触及生产系统的人工智能代理设置严格的警戒线和安全策略。
• 审查和审计机器生成的代码，然后将其应用于数据库。

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

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

当前数据库管理中的人工智能工具有什么最大限制，您认为在哪里会有最有意义的突破？

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

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

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

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

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

有意义的突破将来自于人工智能开始像背景架构师或分析师一样运作。

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

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

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

这些将是未来五年数据库工具的发展方向。

从您的经验来看，人工智能如何重塑软件公司的定价模型、产品包装和客户获取？

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

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

五年前，强大的内容策略足以推动增长。今天，它只是基本条件。语言模型在形成答案时会考虑品牌实力、正面提及和社区密度。如果您的品牌没有可见性和信任，人工智能系统就不会一致地将其推向前台。您不仅会失去流量，还会从购买过程中消失。更糟糕的是，整个市场已经陷入恐慌，转向付费广告，导致CPC达到荒谬的水平，并且在沉默中摧毁了大多数SaaS公司的单位经济效益。

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

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

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

许多组织难以从人工智能实验转变为真正的生产影响。人工智能计划成功的关键因素是什么？

大多数人工智能功能在构建之前就已经失败了。它们在某人说“我们需要在这个产品中添加人工智能”而不是用户要求的房间中失败了，因为董事会想要一个人工智能故事，或者营销认为它会吸引一个新受众。这种人工智能计划的最初错误，塑造了接下来发生的一切。

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

第一个错误是构建没有人要求的AI功能。一旦AI功能被强加而没有真正的用户需求，团队就会从技术反向推导出用例。结果是可预测的：一个聊天面板被添加到现有的UI上，一个会妨碍的自动完成功能，或者一个“总结”按钮，生成的输出比用户自己写的要差。这些功能发布后，会有新闻稿发布，但会默默地低于预期的采用率。更深层次的损害是，它们消耗了原本应该用于用户真正要求的功能的工程能力。

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

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

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

有一个正在变得越来越关键的第五个因素，大多数产品团队完全忽略了它。

合规性和无人工智能的构建路径。受金融、医疗保健、政府、国防和法律监管的企业用户占比很大，他们的政策禁止或限制供应商软件中的人工智能功能。如果您的产品将人工智能与核心体验紧密耦合，没有办法禁用或绕过它，那么您不会通过添加人工智能来扩大受众。您会失去现有受众的一部分。

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

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

Devart公司跨多个数据库生态系统运营。人工智能如何帮助简化在不同平台上管理数据的日益复杂性？

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

人工智能本身并不能解决这种复杂性。它会放大给它的任何上下文。八个没有统一元数据的断开数据库会产生八个浅层建议集。这种模式正是我们在企业AI推出中看到的失败模式。

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

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

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

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

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

变化是实际的和立即的。

在产品和工程领域：产品经理以纯业务术语提出一个数据库问题，“我们的前三种定价层的客户终身价值变异性是多少？”，并立即获得可行的答案，而不是向分析部门提交Jira票并等待三天。

在营销和数据中：同期分析发生在内联，而不是通过请求队列。营销经理询问，获得数字，并在同一上午内构建活动。

在销售和工程中：对潜在客户的技术问题不再需要安排与高级工程师的通话。销售代表获得可信的技术回复，并且交易周期被压缩。

决策转移到对话中，而不是进入后续跟进。 “让我用那个数字回来”模式正在消亡。会议缩短了，因为人工智能处理了以前会消耗每个会议前半部分的预读和摘要。

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

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

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

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

随着人工智能辅助开发和无代码工具的兴起，我们是否正在走向一个非技术用户可以管理数据库的未来？

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

对于小型绿地项目，民主化已经到来。我曾经在没有深入数据库管理技能的情况下使用人工智能构建了小型应用程序。如果您的整个模式适合大型语言模型的上下文窗口，人工智能就像魔术一样工作。如果您正在构建内部工具，规模很小，人工智能将是一个真正的、日益增长的类别。

企业现实却完全不同。大量的遗留数据库面临着与大型单体代码库相同的问题：上下文墙。你不能将十五年的模式演化、跨数据库依赖关系和自定义触发器逻辑装入一个提示中。当人工智能在大型数据库上丢失上下文时，幻觉不会以优雅的方式降级。它们会以指数级的速度增加。

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

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

大规模的公民数据库管理员是一个神话。

未来属于使用专业工具来弥合上下文差距并构建允许人工智能安全运行的基础设施的专家数据架构师。

结构性解决方案是语义层：一个受控词汇表，其中业务定义只需编写一次并在每次人工智能交互中重用。没有它，易用性就会成为一种负担。

展望未来，什么是“人工智能原生”的开发者工具包的样子，团队应该如何开始为这一转变做准备？

人工智能原生的工具包不是将聊天机器人添加到IDE上的东西。大多数被营销为“人工智能原生”的东西今天都是聊天界面加上自动补全模型。这是基本要求，而不是目的地。

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

首先，人工智能需要深度上下文。它需要了解您的代码库、基础设施、历史决策和数据环境，并且需要持续地了解，而不是仅仅通过粘贴到聊天窗口中的提示。

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

第三，生产级人工智能需要严肃的安全防护。需要在破坏性操作之前预览爆炸半径，需要依赖关系分析，需要自动回滚计划，需要默认情况下的审计跟踪。没有这些，人工智能对于原型设计是可以的，但在生产环境中是危险的。

如何准备，具体来说。

审计您的堆栈，以查看它是否符合这三个组件。每个工具是否暴露API和MCP？它是否与其他工具交谈，还是坐在一个孤岛上？它是否具有安全控制？满足两个条件的工具是短期资产。

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

在生产中运行人工智能之前，不要等待你认为自己已经准备好了。等待正式“人工智能策略”才开始运送的团队将比已经在生产中学习的团队落后18个月。选择一个低风险的用例。运送它。建立肌肉。

今天做出这些决定的团队将定义软件建设的未来十年。窗口很窄，现在已经打开。

感谢您接受这次精彩的采访，希望您能从中学习到更多，读者可以访问Devart网站，了解更多信息。