# 9 · 讲稿 v2 --- ## P1 · 封面 大家好，我是powellli。 **（故事）十五年前的今晚，我焦虑得睡不着觉** 这个题目——龙虾摊爆火背后的技术解密——起得有点大。这段时间被人问得最多，就顺着这个由头，把后面的技术故事一起串一下。 （切下一页） --- ## P2 · 双画面钩子（龙虾摊 × 奖牌） 先看两张图。 左边是 3 月 6 日下午的腾大广场。我们在楼下摆了一个"龙虾摊"，帮人在自己电脑上装 OpenClaw。原本以为是场小推广，队伍从早上 7 点排到下午 5 点。 右边是这次的奖牌——云服务器高密机型技术突破奖。云服务器这块业务，公司里做了很多年，很少能有让人激动的时刻。这块奖能拿下来，我们自己也有点意外。 两张放一起，第一眼相当割裂。左边烟火气拉满，右边一板一眼。团队里有同事听说我要放一起讲，第一反应是——你确定这两件事有关系？ 我想说的第一件事就是——它们是同一件事，同一个漫长过程里长出来的两个果。 **特别要强调一下的是，本次分享刻意降低了技术占比，有兴趣的同事可以查阅KM文章或者下来再专项交流** **这个奖项是公司内部多个团队共同努力的成果，我所在团队只是其中很小一部分，当然今天我主要从我的切面来看待这个故事** 自我介绍一下。我 2011 年开始做这个产品，2017 年统一负责 CVM 的产品和研发。刚接手那阵子，团队自评四个字：又累，又没故事。9 年过去，一直在做同一件事，一件红海市场下的同质化竞争。做到 2024 年撕开一条缝，做到今年 3 月 6 日，走成了照片里那一幕。 这 90 分钟我尽量把这段路讲清楚。里面有一部分是我们自己想明白的，也有很大一部分是运气、是团队、是外部时机凑到一起。我尽量诚实。 时间够的话，讲这么四件事—— 一，云服务器这门 low 生意，我们当时怎么找到一条差异化路径。 二，9 年长跑踩过的坑，还有一些没预料到的礼物。 三，AI 时代来了以后，"云要被淘汰"这件事我们怎么想过来的。 四，龙虾摊爆火意味着什么，接下来准备怎么走。 好，进第一部分。 --- ## P3 · CVM 三受限：为什么"low" 先讲 CVM 这个产品本身。 **CVM是什么？它的名字就是最大的问题** CVM 就是狭义的云服务器——你在腾讯云买一台机器，能开机、能登录、能装东西。这个产品业界做了近 20 年。这些年整个行业主要在卷三件事：单核性能、带宽、价格。 不管谁在这场里赢输，云服务器长期被三件事卡着。 **一，形态受限，同质化竞争。** CVM 长得就是"一台服务器"的样子——CPU、内存、硬盘、网卡。这套形态是 20 年前定的。想加什么新东西，市场也不认。 **二，目标受限，与用户业务无法贴合。** CVM 的核心目标就一两个：稳、可靠、便宜。你没法跟客户说"我这台 CVM 挺有意思的，你要不要买来看看"。用户在意的只有账单和 SLA。 **三，离用户远，只有故障的时候才被感知。** CVM 卖出去，绝大多数被大客户的运维、SRE 用着。开发者用得到但隔着好几层。普通用户根本感知不到。做得再好，也很难有一个"直接被用户认可"的时刻。 三个卡点凑一起，CVM 就是那种技术不好看、账也不好看的产品。 2017 年刚接手的时候，团队开会挺沉闷。技术同事最想聊的是"这个产品怎么才能有点意思"。聊完还得回来修 bug、盯稳定性、算成本。 业界主流的答案是继续卷。你 CPU 跑分 100，我 105；你带宽 25G，我 100G。这条路走得下去，只是继续卷同一件事。"离用户远"这个问题，一寸都不会动。 从 2017 年开始，我们在琢磨的是——能不能不参加这场军备赛。要走另一条路先得有个抓手，这个抓手是什么，下一页专门讲。 --- ## P4 · Cattle vs Pets（灵魂页 · 全场引用 3 次） 这一页可能得多花几分钟。它不是一张普通的 slide，是我今天整场分享的思想底座。后面还会请大家回头想它。 概念叫 **Cattle vs Pets**——牛群和宠物。不是我们发明的，2012 年 Randy Bias 提出来的，讲云和传统 IT 的区别。 举个例子。 没有云的年代，公司买一台服务器，会给它起名字——阿毛、小强、财务系统、美美的库。它宕机了，管它的人会连夜从床上爬起来修，会心疼，会做体检。这就是 pets——宠物。 云出现以后，服务器不再有名字，只有编号。一台机器坏了，直接下线换一台，不心疼。这是 cattle——牛群。人在意的不是某一头，是牛群整体好不好。 Randy Bias 讲这个概念的时候，他给的结论是——云的本质是把 pets 变成 cattle。 过去这些年做云服务器的过程里，我们慢慢觉得他这个说法方向对，但只到这里会漏掉很重要的一半。团队自己攒了两条更完整的话。 **第一条——所有的牛群，都曾经是宠物。** 一件东西能规模化，最开始一定是从"少数人当宠物养"开始的。云是这样，互联网是这样，移动 App 也是这样。它先在小圈子里被爱、被折腾、被摸透，才有可能规模化下来变成 cattle。 **第二条——创新永远从 pets 起，规模化必然回归 cattle。但 pets 永远不会消失，它是创新的入口。** 传统的二元思维喜欢做选择题——"你到底做 pets 还是做 cattle？"这样想不完整。一家云厂商长期一定是双轨的：cattle 做规模化，pets 留创新入口。少了任何一边，长期都走不远。 后面讲 9 年、讲龙虾摊、讲奖牌、讲 ClawPro，这些看起来独立的事，回过头看都是这条主轴长出来的。 90 分钟只记一件事的话，我希望是这两条。 --- ## P5 · 三方向延展 = CvP 双轨的实践 有这个底座，回过头看 CVM。 CVM 长期被三件事卡着——形态、目标、离用户远。2017 年之后，我们一直在做的一件事就是——在 CVM 之外，用 CvP 这两条腿，长出三个方向的产品线。 三个方向内部简称 CHD——Computing、Hosting、Developing。 这三个属性都是云服务器的重要部分，只是大家往往只关注了Computing，而且还是用户所不需要的Computing需求。根据这三个特性，我们想办法夯实cvm本身的这些能力，并且在这三个属性上延展出了三个新的产品方向。 **Computing** 做异构计算——GPU、DPU、FPGA。给大客户跑训练、跑推理，一开机几百台起步。典型的 cattle。 **Hosting** 做分布式云——让云的能力长到用户机房里去。金融客户、数据不能出机房的行业用得多。给严肃业务用，也是 cattle。 **Developing** 做轻量云 Lighthouse——给个人开发者、创业公司，几十块钱一个月能跑起来的一台"小云服务器"。规模不大、客单价不高，但它是我们进入个人用户圈子唯一的入口。是 pets。 这三件事团队大概花了 5-6 年慢慢做起来，都做到了行业第一梯队。 放一个悬念。 三件事都做成了，但我最开始讲的三个卡点里的第三个——离用户近了一些，但仍然很远。 Computing 的用户是运维和算法工程师，比原来更远了；Hosting 的用户是行业客户 IT 部门，也很远；Developing 稍微近一点，但也就近了半步，还是圈在开发者里。 用 CvP 长出了三条腿，都长得不错，但都没解决那个最根本的问题。 **自下而上的计算能力产品化** 后来我们慢慢意识到——云计算是那种只有保持在最简朴的形态、才会被用户信赖的产品。大多数创新都会让用户担心被特殊形态绑定、担心迁不出来、担心接下来的账单会失控——所以举步维艰。 --- ## P6 · 拒绝军备赛的关键决策 进入第二段。这一段稍微技术一点，尽量讲直白。 业界主流是军备赛——CPU 跑分、带宽、价格。当时内部也讨论过要不要跟。跟的话路径很清楚：多买最新一代 CPU、把网络堆到 100G、把价格再压一压。这条路是很典型的、看得懂的路。 心里不太舒服的地方是——真去看用户账单，用户从来不买跑分，用户买的是用合理成本跑住业务。跑分再高、账单也高，用户不买；跑分低一点、账单也低、稳定性够，用户就买。 这句话说出来大家都觉得对，可要沿着它做产品，就得换个卷法。所以 2017 年内部定了一个方向——不卷单核性能，卷单位空间的算力密度。同一台物理机别人塞 96 个核，我塞 192；同一个机柜别人放 20 台，我放 30 台。这个方向后来我们叫**高密**。 换维度这件事回过头看没那么玄——发现所有人都在卷同一个维度，先停一下问问自己"是不是还有别的维度"。当时我们只是恰好问了这么一句。运气占一部分。 第一款高密机型是 SA1，2017 年选的 AMD Naples 芯片。这一步在当时挺没面子的——AMD 服务器芯片那时候在业界还没什么市场认知度，大家都用 Intel。为什么选 AMD 下一页讲。SA1 上线，是我们高密路线正式启动的时刻。 --- ## P7 · 借势 · AMD chiplet 选 AMD 这件事我先说清楚，我们不是先见之明。是被行业先教了一课才反应过来的。2017 年 AMD 推出 EPYC，做了一件业界当时没人做成的事，叫 **chiplet**——把一个大芯片拆成很多小的 chiplet，用高速总线连起来。同样的工艺，塞得下更多核。同样一块地，别人盖平房，AMD 盖了多层楼。 我们看到这个东西的时候感觉挺清楚——这个方向做得下去，未来 5-10 年 CPU 的核数会一路往上翻。密度这件事会有一个持续的、外部推动的红利。 于是就跟 AMD 走。SA1 用 EPYC Naples，往后 SA2、SA3、SA4 一直到今天 SA9 用 Turin，前后 9 代。这里面团队跟 AMD 的联合开发、故障调试、供应链协同，占了绝大多数辛苦活。 AMD 那个 chiplet 的做法，其实也可以用 cattle 的思维来看——不再追求单个大芯片的极致性能，把很多小 chiplet 组合起来，让整体规模跑赢。一样的路子。 --- ## P8 · 高密六层协同全景 （切图，停两秒） 这一张 slide 有点密。挑三个和后面故事最有关的说一下。 这六层是什么意思——做高密的过程里我们发现，光靠芯片不够。硬件、操作系统、虚拟化、网络、存储、调度，每一层都得动。任何一层不动，密度就堆不上去。一台物理机塞的东西越多，任何一层的短板都会被放大。 9 年就在这六层上一层一层啃。啃出来的东西单看大部分都是很朴素的活。挑三件——每一件都对应到 3 月 6 日龙虾摊那天的一个具体事情。 **一，256 核 → 768 核。** 过去很多年业界云虚拟机能开到多少核，天花板是 256。这个天花板不是虚拟化技术不够，是有一个 8bit 中断路由的历史包袱卡在那儿。我们做了一件事叫 **viommu 软件化**，把这个包袱在软件层解开，从 256 核推到 768 核。这一步业界目前还没有第二家。 **二，热迁移 20 分钟 → 1-3 秒。** 云虚拟机的创建和迁移，业界过去是分钟级——申请一台机器等几分钟。我们做了一个东西叫 **DirectTDP**，加上 shared-container，压到 1 到 3 秒。3 月 6 日现场每个人扫码几秒钟就能拿到自己的 OpenClaw，就是靠它。第四段还会回来讲。 **三，故障率 0.55% → 0.12%。** 高密机型有一个天然问题——密度上去了，一台机器坏，损失就变大。我们花了很长时间做故障拦截、加了 8 根热管做散热、把 MCA Recovery 做到很细的粒度。整体故障率从 0.55% 降到 0.12%，大概是原来的四分之一。 这三件事放到 5 年前看都是很不"性感"的活。做的时候团队也是有情绪的。答案是下一页要讲的：调度。 --- ## P9 · 调度四件事 我个人觉得，这次拿到的奖，最核心的一块工作是调度。前面六层是"局部把密度堆起来"的活，调度是"把整个大盘装得下"的活。 调度做的事——客户来买一台虚拟机，我这个大盘上，成千上万台物理机、上亿的 CPU 核，到底给他哪一个。这个决策要在几十毫秒之内做完，还得让整个大盘的利用率、稳定性都不下降。 调度做了 4 件事，快讲一下。 **一，物理拓扑树。** 原来调度看一台机器就是"这台机器有多少核多少内存"。我们把整个数据中心的物理关系画成一棵树——机架、机柜、pod、region 都在这棵树上。调度做决策就能考虑到"两台虚拟机放得多近、走多少跳"。这一步做完，调度决策耗时从 180 毫秒降到 20 毫秒。 **二，交织装箱。** 原来装箱是很朴素的贪心——先来先装，剩下的空档补不回来。后来做了一个交织装箱的算法：不按到达顺序装，按"哪些实例互相不打架"的关系装。这一步做完，大盘的资源利用率——原来空置率 -16%（有 16% 的资源永远也用不上），做完之后 +25%。一来一回，41 个百分点。 **三，业务画像双塔模型。** 这一件是我们第一次在调度的核心战场上用 AI。做的事是——每个客户的业务都有它的行为特征：CPU 密集？内存密集？网络毛刺多不多？我们做了一个双塔模型（BERT + CNN），给每个业务打了个画像。调度的时候把画像冲突的业务分开，把互补的业务放一起。效果是"两个高峰打架"的场景大幅减少。 **四，时序大模型预测。** 上一件是"当下怎么装"，这一件是"未来会怎么样"。有一个时序大模型，专门预测未来 24 小时、7 天、30 天大盘水位怎么变化。产出——过去一年在存量里挖出 20 万核，同时帮公司少采购 80 万核。 （停一下） AI 我们不是等大模型火了才用的。P9 讲的双塔画像和时序预测一直都是 AI 在做。第三段讲我们对 AI 的态度，其实是有一点底气的——自己产品最核心的地方本来就在跑 AI。 回到这一页最上面那句话——高密调度技术，是让 cattle 更 cattle 的技术。请大家再回想一下 P4 那张宠物和牛群的图。 --- ## P10 · 高密调度如何强化 C/H/D 三方向 讲了这么多技术，得把它拉回产品——高密调度做出来到底给产品带来什么改变。 一句话——在更大的调度域里，提供了更灵活、更稳定的服务能力。因此它能提供更好的 hosting 和 computing，并且也给developing留下了更充足的空间。 拆开讲，请回想 P5 那张三方向图。 **Computing——GPU 混合装箱。** 原来 GPU 服务器难做灵活，通常整机售卖或者按固定倍数切分。GPU 服务器又特别贵，大部分客户其实用不满一整台。高密调度做出来之后，同一台 GPU 服务器可以按客户实际需要拆出各种"不规则"的规格——2 卡 GPU + 32 核 CPU + 200G 内存 + 几张网卡，随便组合。客户不用再买一整台，只买真正用得上的部分。GPU 时代客户成本压力最大，这一步能落地就有人买单。 **Hosting——管控面和执行面分离。** 分布式云原来的痛点是——客户要在自己机房部署一整套云，成本高、运维累。高密调度让我们能做另一件事：调度大脑放在公有云上，执行小脑放在客户机房里，一朵云管到底。客户机房只放一台执行机，复杂的事交给云。 **Developing——海量小规格碎片资源。** 高密走了这么多年，大盘上留下的碎片资源恰好是 Lighthouse 这类产品的天然养料——大量便宜、空闲、可动态回收的小规格资源。Lighthouse 的边际成本几乎降到 0。这一点后面讲 OpenClaw 会派上大用场。 （停一下） 回到最开始 CVM 那三个卡点——形态、目标、离用户远。前面 5 年三方向解决的是形态和目标；到高密调度这一步，"离用户远"这个根问题第一次真的开始动。一朵云可以管到用户机房、GPU 可以按用户实际需求切、Lighthouse 可以做到一杯咖啡钱一个月——这些都是"离用户更近"的动作。 进入第二段的收官——9 年这条路径长跑到今天，长成了什么样。 --- ## P11 · 长跑的礼物 + 帕鲁 pets 首胜 讲一下这 9 年下来大概走到哪里。先说量级。 规模上——2023 年高密机型云上规模 10 万核；2024 年 2500 万核；2025 年 4600 万核。这条曲线不是我们主动规划的，是一直扎着头去做，走到今天回过头才发现的。 成本上——SA1 到 SA9，同样一份算力，单位成本从 100% 降到 20%。 利用率上——端到端资源利用率 90% 以上。业界公开数据里 AWS 大概 80% 一线，阿里云 70% 一线，火山 80% 一线。 （停一下） 补一句——这些数字里，很大一部分是运气。是芯片行业往密度方向的势能给了我们红利，是内部大客户信我们、愿意迁过来，是 9 年间团队核心的一批人没换掉。任何一环没接住，这条曲线可能就是另一个样子。所以我不太愿意讲得太硬。 （切下半屏） 9 年长跑里还有一个我们自己没料到的礼物——2024 年年初的**帕鲁**。 2024 年 1 月一款叫《幻兽帕鲁》的独立游戏突然爆红，全国、全球都在开私服。玩家需要一台"能自己开、开完就自己玩"的小服务器。Lighthouse 团队反应很快，做了一个"一键开帕鲁服"的活，那段时间订单翻了很多倍——pets 这条腿第一次跑出了个漂亮的成绩。 我特别想讲这一点，是因为它印证了 P4 的第二条——创新的入口永远在 pets。cattle 那边规模再大，pets 一旦跑起来就是下一轮的引子。 小红书那个弯路我这里就不展开了——两年攻坚、独家创新者的不信任。总之到 2024 年初的时候局面是——高密走通了、SA9 上线了、大客户开始迁、小红书愿意开始试、帕鲁把 pets 跑出来了。困局撕开了一条缝。 **为什么我们不做黑神话悟空？** 就在这时候，第二次困境降临了。 --- ## P12 · AI 时代第二次困境降临 这一段讲得可能会有一些个人情绪。这段是过去我最难受的一段。 2023 年 ChatGPT 之后整个行业重心转到 AI。2024 年下半年我个人的感受是——过去 9 年攒下的这条路好像又要被推翻一次。 冲击来自三个地方。 **一，业界的质疑。** 那段时间流传的说法是——"云要被 AI 取代"、"CPU 要被 GPU 取代"、"未来是智算中心的天下、公有云是过去时"。这些话在朋友圈里比我们说的话响亮多了。听多了，会开始怀疑自己。 **二，客户预算的调整。** 更实际。绝大多数大客户 2024-2025 年的预算——AI 那部分往上拉，传统云往下压。客户信不信我们没那么重要，他手里那盘钱在往别处走。 **三，友商产品重心的调整。** 过去几年一起卷的那些同业公司，2024 年之后大部分团队 80% 的研发资源压到 GPU 一条腿。CPU 机型不更新、调度器不再演进、Lighthouse 类产品也停滞。业界这条 hosting/computing 的主战场，本来是四五家一起在跑，一年之内变成大家不约而同地放手。 2024 年年底那阵子——刚从第一次困境里探出头一点点，第二次怀疑扑面而来。 下一页想讲我们那阵子的双面情绪。这一部分我尽量说得诚实——那段时间，我们既坚定，也焦虑。 --- ## P13 · 我们的双面回应：坚定 + 焦虑 + 团队自救 先讲坚定。从 CvP 里看得很清楚——AI 和云是互补的。 一，AI 需要长时间稳定的算力，总量、时长、并发只有云才提供得起来。指望每家企业自己建一个智算中心，这条路对绝大多数企业不划算。 二，AI 是一门需要"调度"的生意。你只有一个 GPU 那没什么好说的；100 个 GPU 要跑 500 个 Agent，怎么调度、怎么隔离、怎么恢复——都是云的老本行。 三，AI 需要可组合的基础设施。GPU、CPU、内存、存储、网络，比例每家企业都不一样，还在快速变化。只有云能做到"你想要什么比例，我就切一份给你"。 这三条凑一起，我们心里其实是有底的——AI 兴起从长期看不是威胁。 再说焦虑。那段时间的焦虑不是"方向对不对"，是——我们还没准备好去服务新的 AI 形态。AI 的算力形态、并发形态、生命周期形态跟传统 CVM 差别挺大。方向在，但"我们真的能接住吗"，那阵子没底。 所以团队自己开始救自己。2025 年 4 月开始，内部做了三件事。 一，每两周一次 AI 开放讨论。不汇报、不打分、不立项。就是坐下来聊——最近看了什么、玩了什么、担心什么。这一件看着最没生产力，其实最重要。 二，结合业务场景反复论证。每讨论完一个 AI 想法都拉回自己业务上——如果真做，客户是谁？账怎么算？跟高密调度有什么协同？ 三，自己在云上跑 AI 应用。写代码、跑推理、试 Agent、试各种模型。踩了大量坑，攒了一手经验。 （停一下） 内部有一句话——"我们不是对 AI 反应迅速，我们可能是真的懂 AI。"讲的时候心里其实有点心虚，"懂"是个大词。但至少在自己的战场上，AI 不是从 ChatGPT 才开始做的，从调度那时候就在跑了。 --- ## P14 · CvP × CHD 大 Callback（灵魂页） 现在把 P4 那两个地基和 P5 那三方向请回台前来。 （切图） 请大家看这张 5 行 4 列的表。（停一下） 这张表说的意思是——过去按 CvP 和 CHD 布下的那五条线，到了 AI 时代每一条都被大幅强化了。 一行一行讲。 **Cattle**——2020 年跑的是大客户业务集群。2026 年跑的是 AI Agent 集群，7×24 永远在线。规模和复杂度大幅强化。 **Pets**——2020 年跑的是个人开发者。2026 年跑的是每个人的 Agent 服务器 + 每家企业的试验场。用户群体从"开发者"扩到"每个人"、"每家企业"。大幅强化。 **Computing**——2020 年异构计算给少数客户用。2026 年 GPU 算力机型每一家做 AI 的企业都要。强化。 **Hosting**——2020 年是分布式云的一个特定场景。2026 年是"高密 + 数字身体"的载体——企业内部的 AI Agent、每个员工的 AI 助手，都要在一个地方安身。这个地方就是云。大幅强化。 **Developing**——2020 年 Lighthouse 服务开发者。2026 年 OpenClaw、ClawPro、SkillHub 服务的是从 8 岁小学生到 60 岁工程师，每一个想用 AI 的人。大幅强化。 （停一下） 这张表看完，最后一句话在心里琢磨了很久，不是很确定它有没有一点点夸张，我想诚实讲出来给大家参考—— 云计算不是 AI 时代的旧基建。云计算是 AI 时代的本体。 AI 需要一个身体才能真的跑起来、干活、7×24 服务。这个身体，就是云。 （扫一眼右下） 说一句业界观察——现在业界有相当一批同业公司主动放弃了 Hosting 主战场，把资源全压到 GPU 一条腿。对我们来说是坏消息，也是好消息。坏消息是暂时找不到同伴；好消息是——SA1→SA9 那个剧本很可能还能再演一次。 --- ## P15 · AI 上云的三大差异化优势 翻一页。 这一页讲三件我们比较有把握的事。共同点——都不是 AI 时代才临时搭起来的能力，全都是过去 9 年高密攒下来的家底。 **一，GPU 的混合部署。** 刚才 P10 讲过一半。市面上大部分云厂商卖 GPU 是整机卖——一台 8 卡机器，客户要么整台买、要么按简单倍数切。绝大多数客户其实用不满整台，剩下的算力就是浪费。 我们用高密调度做出来的能力——同一台 GPU 服务器可以拆成不规则的规格。2 卡 GPU + 32 核 CPU + 200G 内存 + 若干张网卡，随便组合。客户按自己真的需要买，账单立刻降下来。GPU 时代客户成本压力最大，这一步落地就有人买单。 **二，海量小规格 Agent 的调度效率。** 未来 AI 生意的一个显著特点——不是 100 台大机器，是 100 万台小实例。一个企业可能同时跑几万个 Agent，每个几核几 G 的小虚机，生命周期几分钟到几小时。 传统调度器面对这种流量装箱决策慢、生命周期切换开销大、资源碎片化严重。我们过去 9 年在物理拓扑树、秒级创建、业务画像上攒的东西恰好就是为这种海量小实例场景准备的。这不是提前预判，是 AI 时代的算力形态刚好落到我们手上。 **三，帕鲁沉淀的 developing 亲和力。** 帕鲁那一战我们打磨出来一整套用户体验——一键开服、几分钟拉起、开箱即用、SkillHub 技能商店、TAT 遥控器、OrcaTerm 监视器、AI 助手做意图识别自动排障——都是那时候攒下来的。 AI 时代最关键的一个变化——用户群体从开发者扩展到普罗大众。8 岁小朋友、60 岁工程师、婴儿车父母都要用。帕鲁沉淀下来的这套亲和力正好派上用场——门槛已经预先降到最低。 （停一下） 9 年前做高密调度，没想过将来能给 AI Agent 用；4 年前做帕鲁，没想过将来能服务小学生和大爷。走到今天这些东西都长成了最好的家底。这就是长跑给我们的礼物。 --- ## P16 · 龙虾之战 进入 3 月 6 日的现场。 先讲这场活动的起因。整件事不是我拍板下来的——是 Lighthouse 团队一线看到、自己判断、自己干起来的。 （切左半屏） 时间是今年 1 月 26 日，年前。团队在一线看到 OpenClaw 开源社区的热度，判断这可能是一个像帕鲁那样的机会。底气来自两个地方——一是帕鲁那次"C 端小规格算力 + 破圈"的完整仗打过，节奏、意外、后备都有本账；二是过去一年做 AI 探索攒下来的认知，看得懂 OpenClaw 不只是一个软件，是"AI Agent 时代每个人的私人服务器"雏形。 看懂的地方意味着：为什么要做帕鲁，为什么不做黑神话悟空，为什么又要做OpenClaw？ 内部当时的争论也挺有意思。几乎没有人反对做，大家争的是它到底能有多火。有人估得保守，有人估得激进。后来的事实证明——它比所有人预想的都火。 2 月 27 日，一个司内 300 人的体验福利放出去，15 秒抢空。这个数字出来内部判断就基本定下来了：这件事必须要走到线下去。而且要用真人、公益的方式做——当时小红书上已经出现了 OpenClaw 装机代跑的黄牛，价格 500-3000 不等。我们不希望一件本来是普惠的事变成收智商税的事。 （切右半屏） 从决定装机到上线只有 4 个工作日。grace 帮我们组织了 7 组分工——场地、产品、培训、秩序、宣发、应急，还有一个特别的：出圈彩蛋和情绪价值组（"小龙虾出生证明"就是他们的创意）。 技术上最惊心动魄的是这两个能力。 3 月 5 日下午，腾讯云 CodingPlan 上线，让每个到现场的人都能有一个免费的领用链路。3 月 6 日凌晨 1 点，QQ 机器人一键配置能力熬夜上线。这一步做完，用户扫完码到 OpenClaw 装完，不用手动填 IP、不用手动改配置，一步到位。团队内部有一句话——这两个能力少上一个，现场每个用户的安装时间直接翻倍。500 人，每人多花 5 分钟，队伍就得从下午 5 点排到晚上 10 点。 人手上，3 月 4 日预告一发出来，立刻发现原本 20 个装机导师根本不够。紧急招募了 33 位主动报名的装机导师、7-8 位专家兜底、2 位"最后兜底"专家，还从长沙"空降"了两位研发到深圳。 （停一下） 细节讲这么多，是想让大家看到这场活动是很多人熬了几个大夜、临时拼出来的。 上现场。 --- 3 月 6 日那天几个数字，让它们本身说话。 - **500 张号码牌** —— 原定放 500 张就停发。 - **早上 7 点** —— 最早一批用户到场排队。11 点才开始装。 - **11 点到 17 点** —— 原定 14 点结束，硬延到 17 点。 - **2 岁到 60 岁** —— 现场有 10 岁小学生，有推婴儿车过来的父母，有 60 岁的退休工程师，还有从泰国过来的 13 岁小朋友。 - **单日净增 5×** —— OpenClaw 单日云上规模是活动前的 5 倍。 - **腾讯股价 +7 个点** —— 当周。 - **48 小时** —— 百度、阿里、火山、京东、天翼都跟进了自己的 XClaw。 - **一周近百家 KA** —— ClawPro 活动之后一周收到近百家企业客户的测试申请。 （切下半屏） 那一天里给我印象最深的一件事——大概下午 4 点左右，队尾还没散，我和几位同事去劝一部分朋友回去，跟他们说今天号码牌全部发完了，下次活动还会办。 一位大爷排在队尾，抬起头，跟我们说—— "没有号码牌？没关系，我可以等。" （停顿） 那天我们提前预备的代金券，本来是准备万一大家等太久拿去道歉的。一张都没发出去。 保安大哥主动过来护场；一位阿姨排队的时候一直问下次什么时候再办。做一件很朴素的事，做着做着突然发现原来它对某些人是有意义的。 --- 看完这些数字，把大家往回拉一步，回到技术。这场活动如果只讲现场只讲情绪，会漏掉一件更重要的事——它凭什么撑下来。 一个下午 500 人集中扫码，同时全网线上因为直播、朋友圈、微博涌进来的量。整个 OpenClaw 申请量是活动前的 5 倍。创建成功率我们那天守住了 99.9%。 99.9% 是三个"底牌"托起来的。这三个底牌不是那 4 天做出来的——全部来自过去 9 年高密的技术积累。 **第一张，秒级创建。** 大家可能以为云厂商把机器创建做到秒级是常态，其实不是。传统 Lighthouse 的创建链路是"现炒现卖"——申请一台，从物理机上分配、走 CVM 全链路、装 CBS、绑网络，全部串起来是分钟级。 帕鲁时期我们把这条链路重构过一次——用算法预测未来水位，底层 CVM + CBS 提前预热到"蓄水池"里。用户扫码那一瞬间只做极速 IP 分配 + 带宽绑定这两步——分钟级压到 1-3 秒。这是让 500 人不排到晚上 10 点的关键。 **第二张，镜像分发。** OpenClaw 是一个几乎每天出新版本的软件。按老办法每次全新构建、全网数百节点重新分发，一次可能就是一整天。在"上午改动、下午到用户手上"的节奏下走不通。 我们做的是分层 + 增量构建——把 OpenClaw 镜像拆成"基础层"和"应用层"，底层不推翻，只更新应用层。镜像分发从天级压到分钟级。这是过去几年在 IaC + 自动化流水线上一点点抠出来的。 **第三张，应用层的一整套用户体验。** 这一件是最不可以短时间砸钱砸出来的。TAT 遥控器（图形化配置）、OrcaTerm 监视器（实时日志排障）、AI 助手（意图识别 + 自动排障）、SkillHub 技能商店。都是 Lighthouse 团队过去一年做帕鲁、做小规格资源体验的时候一件件磨出来的。 把一个原本要打命令行、看 log、调 shell 的过程，变成小学生和大爷都能看懂的图形界面——就是靠这一层。 （停一下） 所以这一页最下面那句话——9 年前那些活如果没做，3 月 6 日那天大概撑不下来。奖牌和龙虾摊，是同一个故事的两面。 --- ## P17 · 龙虾的真正意义 龙虾这件事火了之后，业界普遍两种解读。这两种，我个人觉得都错了。 **第一种是乐观派**——龙虾装机的热度会一直延续，云厂商赶紧上，抢一波流量。 错在把"装机热"当成了"产品热"。装机热是有峰值的——一段时间内愿意亲自跑一趟、或者线上折腾一小时的用户就那么多。峰值一过一定回落。这时候继续按"装机热会延续"投人投钱，就会越投越亏。 **第二种是悲观派**——龙虾就是昙花一现、蹭个热度、没有持续价值、可以不用当回事。 错在把"流量回落"当成了"故事结束"。 我们内部复盘之后看得很清楚——流量在回落，但流量下面涌动的东西，一点都没有过去。 流量下面涌动的是什么？ 一个是全民 AI 焦虑——每个人都在问"AI 会怎么改变我的工作"、"我需不需要提前学"。 一个是普惠 AI 算力的渴求——大家不想只用别人 App 里"给你玩几分钟"的 AI，大家想有一台真的属于自己的、能一直开着的 AI。 这两个东西加在一起，就是那天大爷说"我可以等"的真正原因。峰值过去它们也不会消失，会继续在水面下涌动，等一个更成熟的产品形态来承接。 这个承接的形态是什么？回到 CvP——OpenClaw 是每个人的 pets，pets 跑通了，cattle 一定会到来。cattle 是每一家企业需要的"Agent 集群管控平台"。这个东西我们已经开始做了，就是下一页的 **ClawPro**。 （扫一眼右下） 说一句蝴蝶效应。3 月 6 日之后，央视、财经、深圳卫视循环播了这个素材，OpenClaw 的开源社区创始人在 X 上转发；两会期间有院士和政协委员建议深圳"养小龙虾"走全国最前列；龙岗区落地了"小龙虾市场"和"小龙虾十条"；48 小时内百度、阿里、火山、京东、天翼都跟进了自己的 XClaw；小马哥连发两条朋友圈；股价当周涨 7 个点。 这些都不是我们能规划的。说这些不是想显摆——龙虾的意义是它让我们看清楚了，AI 算力普惠这条路，市场是真的想走的。 --- ## P18 · ClawPro 起源：客户的一句"风险我承担" ClawPro 的起源我一定要讲一下。它的诞生太特别了，过去很多年 ToB 的经验里都没有过这样的开局。 **场景一 · 3 月 6 日现场** 那天下午我们在龙虾摊边上，不止一位企业客户拉着我们说——"你们的龙虾做得真好，能不能做一个面向企业的高级版本？比如叫龙虾 Pro Max？" **场景二 · 我们的疑惑** 第一反应有点疑惑。OpenClaw 是一个非常轻量、非常个人向的产品——权限管控、审计日志、灰度发布、故障回滚，这些企业严肃场景要的东西 OpenClaw 里通通没有。你直接把它推给企业用是有问题的。 想跟客户解释这个复杂性——但客户接下来说了一句话，让我到今天都记得清清楚楚。 **场景三 · 客户的一句话** "你们尽管做，风险我自己承担。" （停一下） 这句话完全超出了我们过去做 ToB 生意的经验。 过去做 CVM 是我们承担风险，给客户提供 SLA。今天客户主动说他承担风险，只求我们赶紧做——背后是真金白银的 AI 焦虑和期待。他不是要跟你砍价，他是知道自己等不起。 回来的路上冷静下来，思路一下打开了——回到那条老规律 CvP。OpenClaw 是 pets——个人的、宠物一般的 AI 服务器。ClawPro 应该是 cattle——企业规模化的、可以管控的 AI 底盘。 我们不做另一个"企业版 OpenClaw"，我们做另一件更根本的事——把 ClawPro 做成一个"Agent 的企业管控平台"。它不是 OpenClaw 的加强版，是 OpenClaw、其他各种 Agent 的上层管控——权限、审计、token、回滚、SkillHub、成本分摊，全部在这一层做。 这个方向做完，一周内收到近百家 KA 客户的测试申请。这个数字对做 ToB 的人来说其实是很吓人的。 诚实说——ClawPro 这个想法是那位说"风险我承担"的客户帮我们想清楚的。回来的路上我们照着这个方向做了。 --- 做 ClawPro 的时候最难拿主意的其实不是"要做什么"，是"不做什么"。面向 B 端做 AI 平台，贪大求全的下场就是又贵又难用又没差异化。所以"要做/不做"我们写得比较硬。 （切上半屏） **要做的三件事——** 一，深入真实工作流 + 真实数据。让 AI 触达客户的运维现场、生产现场、业务现场，做深。 二，标准化交付 + 统一管控。权限、审计、灰度、回滚。企业客户对 AI 的顾虑一大半来自"我怕出事没法追溯"。这一层必须扛住。 三，SkillHub 沉淀企业 know-how。每家企业有自己的运维习惯、代码规范、业务逻辑。SkillHub 让这些沉淀成 Agent 的技能包——用得越多，Agent 越懂这家企业。 **不做的三件事——** 一，不做全权 Agent。B 端要的是可控。花活给个人用户看得爽，给 CIO 看只会更紧张。 二，不给 Shell 授权。一个 Agent 拿到 root shell，出事没法追溯——这在企业客户那里过不了关。所以我们从架构上就不允许这条路径。 三，不做通用 AI。这一点是从 Manus 这类通用 Agent 产品的挫折里学到的。通用是很吸引人的一个词，但意味着"每一件都做得不够好"——放到严肃场景下这个平均水位过不了关。 （切下半屏） 过去半年跟 CIO 客户聊，反复听到两个问题。这两个问题也刚好是我们把 ClawPro 想清楚的过程里一直在自己回答的。 **CIO 问题一：我怎么跟 CEO 讲 AI 和云的关系？** 答案就是刚才 P14 那句话——云是 Agent 的数字身体。没有云，Agent 无处栖身；上了云，AI 才有真正的执行力。CEO 不需要懂技术细节，理解这一句话就够了。 **CIO 问题二：我们企业的 AI 创新下一步该往哪儿走？** 答案是——不是买工具，是治理工作流 + 数据。 企业买 AI 工具的钱其实并不难花——市场上东西多的是。但这些东西买回来能不能长出效果，取决于两件更基础的事：工作流有没有先梳清楚（也就是 SOP）、数据能不能被 AI 用（也就是数据治理）。这两件事没做，工具买再多也白搭。 这两个问题的答案看着朴素，但是我们自己也用了半年多才慢慢想清楚的。 --- ## P19 Skillhub skillhub从2月份开始做，核心目标与clawpro类似，大模型和agent本身有诸多流派，纷繁复杂，而用户对于ai使用的目标往往更加明确，clawpro成为团队管理agent资产的能力，skillhub是用来沉淀工作流和领域知识的地方。 在经历了一些波折，且完全没有做任何宣传的情况下，我们的skillhub已经是国内第一的领先地位。 ## 可选延展 · 组织进化 + Token 治理 从产品往下走一步讲一下组织。这一段有点跑题，但我觉得挺重要——过去一年我在架构师团队上做的事情，跟做 CVM 的思路是一致的。 **个人提效与组织提效** 为什么说个人提效明显，而组织提效困难。我认为逐步拆解是这样的： 1. 很多个人提效其实是严重高估了的。一方面，原来不写页面的人开始写页面，原来不会做ppt的人开始做精美ppt，这些技能是不是他的核心工作，说不定反而带来了心智负担。再举个例子，原来的“一句话需求“也许是高度凝练的真知灼见，而现在的完整版ai辅助需求不仅信息密度低，还可能存在错误。另外一方面，个人提效大多体现在demo上，ai让大部分领域的门槛降低了，让人有一种”我也能行“的感觉，但真正落地仍然存在挑战。 2. 即使是个人真的提效了。组织提效的第一个挑战在于，组织是否真的需要提效？这涉及到组织对于目标的定义，我认为有些组织存在的本质意义其实是不需要考虑效率的。这点不详细展开。 3. 即使个人提效，且组织也需要提效。才进入到了真正的结合点。组织的目标是什么，组织给个人分配的目标是什么，在原有组织形态不发生变化的情况下，通过清晰定义目标和与此目标相关的核心工作流程，做好相关的数据交换和治理，AI能发挥出非常大的作用。比如我们所实践的架构师的AI native转型，以及OpenClaw专项的git管理。 4. 再接下来才是组织如何变得更适合AI。这里就有了两个概念：AI应该是扮演同事，还是扮演系统。扁平化、职责泛化都只是结果。核心还是在于自上而下深入分析对于一个组织的核心目标，人和ai的定位在哪里。人应该走FDE的模式，成为物理世界与数字世界的桥梁，而ai应该是数字世界的”调度者“，它能把一切数据管理好，AI不应该是一个跟人职责相同的”同事“，而是一个大型的高效率智能系统，人是这个系统的操作员，并且不断促进更多数据映射和让渡更多权限给到AI。举个例子，如果一个组织是铁匠铺子，AI不应该是打铁机器人，而是变成机床，铁匠变成机器的操作员。从human in the loop变成 human on the loop 而且，已成型的组织的稳定性往往构建在一些经过历史迭代的非理性结构上，比如对某些员工隐含价值的依赖、信息误差带来的不必要工作内容等，所谓“这是feature，不是bug”，而且处处都是bug，反而拼凑出了“能跑”的体系。 所以，通过AI来“重构组织流程”，其实是以设计论来对抗进化论，看起来非常有理有据，但往往陷入僵局。因为进化论并无目的，只是不断适应的结果，而目的论短期获得的利益不一定能对冲长期的隐患。 架构师团队 AI native 转型分成三个阶段。 **L1 · 个人提效**——每个人自己拿 AI 当工具用，写代码、写方案、做资料。这个阶段大部分公司都能到——给员工发 token、允许他们用，就走完了 L1。 **L2 · 组织提效**——让 AI 在团队和团队之间产生价值——自动生成周报、自动写方案、自动做 code review。这一步大部分公司都卡住。 **L3 · AI 主导**——AI 自己完成绝大部分工作，人只做审阅和最后决策。这一步现在还没有几家公司真到。 我观察到的一个共同现象——绝大多数公司都卡在 L2。 L2 卡在哪儿？两件事。一是**数据治理**——AI 要帮团队做事，得先有干净、结构化、可用的数据。绝大多数公司的数据在 AI 之前是"给人看"的，散落在几十个系统、几百个 Wiki、几千封邮件里。这些数据不整理，L2 走不通。二是**SOP 重写**——过去 SOP 是写给员工看的，文字描述、有默认前提、有隐藏假设。AI 看不懂。SOP 得重新写，写成给 AI 看的指令集。 内部有三句话，想分享一下。 一，SOP 不只是写给人看的，它是写给 AI 看的指令集。（先重写 SOP 再谈 Agent 落地——顺序不能反） 二，工具不需要公约，同事才需要。（AI 变成同事之后，规则得为多方共处而写） 三，人下班了，AI 还在干活。（这是 L3 最直观的一个体感——组织的产能开始溢出个人的工作时间） ---- Token 治理这件事，我想说一句可能有点反直觉的话——Token 是新时代的电，但电不是用来"管"的，电是用来发动机器的。 类似于组织转型，token治理这里的思路如下： 1. 写ppt/写网页的需求本身是否是合理的？如果不是，无论如何都是在浪费token 2. 回到组织的目标和个人的目标，要把员工使用token规范化到标准的sop当中来 3. 通过不同的sop的拆解，建设更工程化的token使用体系。（员工通常不是滥用token，而是没有获得足够的帮助） 4. chatbot永远应该是任何任务的超始，甚至最后你会发现chatbot能胜任大部分任务。（比如我上周有个pdf的修改需求） 5. 如果一定要直接调用llm api，如何选择不同价格的llm也是个关键，正是因为很多任务缺乏评测能力，大家才会只选最贵的llm来确保心里安稳。 6. 对于组织所认定的工作目标，持续建设harness工程，在这个体系当中复用prompt、提示优化建议、路由不同llm，才是难而正确的方向。这其实与我们的装箱调度能力本质是同一回事。 内部对 token 的态度一直是帮助大于管理，做了三件事。 一，双额度体系——探索额度 + 生产额度。探索额度不设 KPI，员工可以试新模型、写实验代码、玩想法；生产额度对应产出和业务。这样员工敢用，也知道边界在哪。 二，不卷 token 消耗，只看产出。内部不排名"谁消耗了多少 token"、不搞"省 token 竞赛"。看的是这个员工用 token 之后解决了什么问题、留下了什么资产。 三，主动降阻力——帮员工选模型、写好 Prompt 模板。我们不希望"学会用 AI"变成员工的另外一个加班项。管理者应该先趟一遍坑，把好用的东西打磨出来再让员工用。 （停一下） 管理者在 AI 时代的角色，从"审批 token"慢慢变成"陪员工用好 token"。这一件事也是我这半年在慢慢学。 --- ## P20 · 谢谢 （切最后一页） 差不多就到这里。 90 分钟其实很短，还有很多细节讲得不到位——比如小红书那两年、龙虾装机 的复盘、AI 提效的度量这些——各位有兴趣会后可以慢慢聊。 最后想说三件事作为收尾。 一，这次拿到的这个奖不是我一个人的。是过去 9 年一批愿意在"不性感"的产品线上熬着的技术同事一起做出来的。他们把每一层技术抠到极致。我今天站在这里，只是把他们的活讲清楚。 二，3 月 6 日的龙虾摊也不是我一个人的。是计算团队，还有那 33 位主动报名的装机导师、7-8 位专家、2 位兜底老兵、从长沙空降来的两位研发一起熬出来的。 三，我今天讲的很多话其实是过去 9 年慢慢想清楚的。里面很大一部分是运气、是时机、是团队。我不是很确定其中每一条都对。听完各位觉得哪一条不对，会后来找我聊——特别希望能被指出问题。 谢谢大家。 总结： 1. 第一性原理：无论大家普遍是怎么想的，还是要回到最终的用户需求上去拆解问题 2. 相信时间的复利：坚持做难而正确的事，想办法做一些投入可控的创新，会更容易找到方向 3. 焦虑就是机会：AI焦虑更多意味着新的机会，在没有找到方向的情况下首先要确保自己在深度使用AI工具 4. 从pets到cattle：深刻理解之后亲自尝试，养好这个pet之后在云上把它变成可复制的产品 5. AI给了我们重新审视每件事并有可能改变的机会，高效的组织协作、高效的token使用都要来自于对于真正问题的拆解上