【AI谈】Elevo，是我对AI认知与思考的具象化表达

最新推荐文章于 2026-07-02 00:08:09 发布

原创最新推荐文章于 2026-07-02 00:08:09 发布 · 616 阅读

18 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

本文不涉及运维，10月上旬我与一朋友做个在线直播，重点谈大模型时代下的运维该怎么理解、怎么做、如何落地！

（以下图片根据本文提示词AI生成）

Elevo产品落地之前的很长一段时间里，我内心其实憋着很多话，表现出来的“话不多”，不是故作深沉，是觉得没跑通的东西，但凡讲出来多少会有点心虚。“大胆假设，小心求证”是我恪守的自律格言，乃至于说团队终于把Elevo真正干出来的早期，我也只是在朋友圈po了几张LOGO图，搞得很多朋友跑来问我：“你那个Elevo到底是个啥？”我的回应是“在AI上做点新的尝试”，因为团队那会正在客户现场真刀真枪，我那会也还需要“求证”，不太好说。

现在不一样了，Elevo不仅跑通了，还跑出了一些我们事先没写在PRD里的意外收获。你看，小米那句印在外包装上的 “永远相信美好的事情即将发生” 的含金量依然还在上升吧？

今天这篇文章，我想基于上一篇文章聊聊一些新的感悟，顺带回答一些朋友对我提出的疑问，也算是给关心和关爱Elevo的朋友一个小小的交代。

AI-Native：

不是「加上AI」，而是『从头就是AI』

其实上次有一点我没说，我们最初对Elevo的想象，仍然没有跳出“工具”的范畴。能响应、能执行、能学点新东西，好像就足够了，很牛逼了。

随着产研的不断碰壁和思考的逐渐深入，后来我才意识到，这个思路还是太“旧”了。

国务院人工智能行动意见中提到“ 智能原生（AI-Native）”，我读了很多遍。这个词不是白叫的。

所谓“智能原生”，不是把大模型接口嵌进原有系统那么简单。它意味着整个系统从数据流动、能力组织到交互方式，都要重新思考——数据不是用来存的，是用来被理解的；能力不是单一服务，是智能体之间的默契配合；应用不是一堆菜单按钮，是接近人类直觉的 value-oriented流程。

我们现在回过头看，Elevo最让我欣慰的点，不是说它有多“聪明”，而是它的“主动感”。我上次也说了，它不再只是一个问答工具，而是一个能提建议、能干活、能预警、甚至能质疑你的伙伴。

有客户跟我说：“你们这个东西最让我觉得不一样的，是它偶尔会反问我——‘你确定要这样做吗？上次类似的操作导致了某某后果。’”我说“这就对了，这就是我们想要赋予Elevo的性格。”

但其实类似这样的产品“特色”往往又不是我们开发团队第一时间get到的，这就映证了我在上篇文章说的“到客户中去”的逻辑自洽！试想一下，如果Elevo到今天还在公司里闭门造车，团队不去客户第一线练兵，我们会面临什么局面？不敢想。

也正是那一刻我明白了：

Elevo智能突破点，是敢和你对话，而不仅仅是回答你，是一种Converstional AI。

去焦虑：

人没被替代，而是在增强人类！

我很清楚这些问题的背后其实藏着某种“被干掉”的焦虑。

我从来不喜欢“AI取代人”那套制造焦虑的话术。但说实在的，AI确实会接替那些重复、规则、依赖记忆的任务——而这恰恰是解绑人的开始。

我说实话，凡是能被现有的AI反驳的问题，你何必要躬身入局内耗自己？以前一个工程师三年才能养成的“手感”，Elevo很快就能学到八成。那人去干嘛？特别是执行层的事务。人必须要去做更有价值的事：业务架构、风险决策、资源协调、创新实验——那些真正依赖人类判断和创造力的事情才是工程师们应该放手一搏的主场。

所以我说Elevo不是来“取代”谁的，它是来当“增强人类的”的，它是你的copilot，你的partner。你仍然是掌舵的那一个，只是现在，多了一个靠谱的导航员罢了。

没有人会因为多一个能干的帮手而感到沮丧吧，甩手掌柜只是不干端茶倒水的活，但一点不耽误他搞外联、定战略、想出路。

用户洞察：

不要抽象用户，更不要抽象用户问题

你如何找到用户的痛点？如何思考用户的问题所在？如何构建产品的MVP？如何做GTM？这些问题在AI时代构建产品，都有着不一样的逻辑。

如果你没有吧产品的逻辑建立在客户和AI的本质洞察基础之上，这些问题都不会有答案。当下客户也需要AI认知升级，而我们要构建的AI产品解决方案就是用来解决客户问题的。这势必中间存在一个巨大的鸿沟。

不要抽象用户！是指不要把用户泛化，做自我假设，陷入一种自high的情绪之中，认为做了一个非常牛逼的AI产品。其实那个牛逼更多可能是在AI能力之上叠加了一点自high情绪带来的。用户的问题一定是具体的，并且是千变万化的，特别是到企业端，用户问题更是如此，还带着典型的领域特征、组织特征、流程特征等等。更不能泛泛而谈！

用户问题如此多样，那如何找到产品落脚点？我的答案是先有一个基本的逻辑，然后在客户侧落地后，快速闭环验证，修正。Elevo开始的定位就是要做“运维专家型”助手，必须要借助大模型的智能化能力来实现，但随着我们实践，通用大模型能力愈发不足，就自己训练运维领域专家精调模型.....。这是一个边实践，边认知刷新、再实践的过程。

Agent元认知：

Agent系统不是简单的Agent堆砌，而是一个精确的技术系统。

顺便提一句，行业总爱说“RAG已死”、“微服务杀死单体”、“DevOps干掉ITIL”……我从入行就不信这套非黑即白的叙事逻辑，太粗暴了，粗暴得近乎抽象。

做Elevo这大半年，我越来越清楚：

技术没有所谓“死活”，很多技术在不同的场景下找到他的价值。

RAG有没有用？有。在一些简单的场景中，RAG构建规则库，能够把AI能力快速落地。

随着在Agent系统的实践深入，他好像是一个老师傅精确控制的技术系统，而不是一个工具平台。“三个Agent，顶上一个诸葛亮”“网上开源的Agent好厉害，拿过来就可以用了”....很多这类的言论。其实，多Agent系统比微服务系统都要脆弱，你去看看传统分布式系统的构建原则，“Design for failure”一定是其中一条。Agent系统可不是这么说的，一定是奔着成果而去的。往深了说，多Agent系统之间的协调配合，有点“一个管理者带着一批人”干活的感觉，组织上下文和Agent系统的上下文原理类似！

但在真实的企业环境中，你光“生成”是远远不够的，还得能理解上下文、保持上下文、甚至跨越会话的记忆障碍——我认为这才是Elevo发力的核心。

它不是来“回答一个问题”的，它是来“理解一整件事”，并需要对它逻辑化表达的。

独立性：

「EasyOps + AI」是对AI的认知缺位

很多客户朋友问过我：你们明明有现成的运维平台，为什么还要从头写一个Elevo？

我的答案是：AI不是工具不是技术，是新质生产力要素。因此它不能是EasyOps的AI化，更不是简单的能力叠加。

如果你只是在老系统里接个API、加个聊天入口，那只是“功能增强”，功能偏离了，AI就更偏离了，一种带路人有问题的感觉。我们需要AI的智能涌现带来“物种进化”。Elevo从第一天起要的就是独立架构——数据、算法、交互，全部重建。我们不背历史包袱、也不做技术妥协，我们要构建的是面向下一个时代的智能体。

这不是偏执，是认知差。这也不是标新立异、装X，只是想让我们一整个团队的思考不会白白浪费在认知的鸿沟里，必须倒逼自己跨过去，大家都要有不成功便成仁的思想觉悟，不然我们投入那么多人力和时间干嘛？

EasyOps很好，它是执行层的好帮手。但我们不想在AI这个事情上做一个很easy的加法，我们必须要做相对hard的乘法，于是有了Elevo。

它如果有人格思想，一定会为自己代言：我就是我，不是另一个EasyOps！

Elevo到底是什么？

我认为是新质生产力的某种具象化。