# 9 · 讲稿 v1 > 基于 `8-分享规划v8.md` 的 23 页 PPT，逐页写现场用讲稿。 > 风格上刻意避免过硬的表达，尽量口语、留一点犹豫和自嘲，让 90 分钟不至于像"念稿子"。 > 讲稿正文里的 —— 是提示可以停顿或换气的地方，不是必须。 > 数字披露口径以 T4 确认为准，正式讲之前请再过一遍。 --- ## P1 · 封面 （进场、鞠躬） 大家好，我是 lili。 今天这场分享，题目上写的是"龙虾摊爆火背后的技术解密"——说实话，这个题目取得稍微有点大。之所以这么起，纯粹是因为，过去这段时间，我们被外面问得最多的就是这一件事。既然大家都想听龙虾的故事，那我就尽量讲清楚，同时把它背后的技术一起串一下。 让各位坐在这里 90 分钟，我尽量对得起这个时间。 那我们开始。 （切下一页） --- ## P2 · 双画面钩子（龙虾摊 × 奖牌） 先看一下屏幕上这两张图。 左边这张，是今年 3 月 6 日，在腾大广场。当时我们摆了一个"龙虾摊"，就是帮大家在自己的电脑上装 OpenClaw。原本以为是一场小小的推广活动，结果队伍从早上7点一直排到了下午 5 点。 右边这张，是我们云服务器高密机型技术突破奖的奖牌。这块奖牌，来自公司里可能算是最"low"的一条产品线——云服务器。做这一块做了很多年，而且这个技术非常复杂，能让评委短时间内理解并评奖，我们自己也有点意外。 坦白讲，这两张图放在一起，第一眼是相当割裂的。左边烟火气拉满，右边非常 nerdy、非常枯燥。这两件事之间有关系吗？ 我今天想跟大家说的第一件事就是——它们是同一件事。而且是同一个非常漫长的过程结的两个果。 自我介绍一下。我是 2011年开始做这个产品，2017 年统一负责 CVM的产品和研发 的。刚接手的那阵子，团队自评——又累又没故事。9 年下来，我们其实一直在做同一件事。做到 2024 年，走通了一个小小的拐点；做到 2026 年 3 月 6 日，才走成了大家在图片里看到的那一幕。 今天这 90 分钟，我想尽量把这 9 年的过程讲清楚。这里面有一部分是我们自己想清楚的，还有很挺大一部分——说实话是运气、是团队、是外部条件凑到一起才发生的。我尽量诚实地讲。 如果时间够，我大概会讲这么 4 件事—— 第一，云服务器这门"low 生意"，我们当时是怎么找到一条差异化路径的； 第二，9 年长跑里踩过的坑，和一些没预料到的礼物； 第三，AI 时代来了之后，我们又一次面对"云要被淘汰"的怀疑，是怎么想过来的； 第四，龙虾摊这场爆火到底意味着什么，以及接下来我们准备怎么走。 好，我们开始第一部分。 --- ## P3 · CVM 三受限：为什么"low" 先花几分钟讲一下 CVM 这个产品本身。 严格意义上，CVM 就是狭义上的"云服务器"——你在腾讯云上买一台机器，能开机、能登录、能装东西的那台机器。这个产品其实业界已经做了近 20 年了。这些年整个行业主要在卷三件事——单核性能、带宽、价格。谁跑分高一点、谁便宜一点、谁网络快一点，谁就能多拿一点订单。 但是这里面有一件我们内部看得很清楚的事——不管谁在卷里赢了输了，云服务器这个产品本身，长期是被三件事卡着的。 **第一件，形态受限，同质化竞争。** 云服务器长的就是"一台服务器"的样子——CPU、内存、硬盘、网卡。这个形态是 20 年前定下来的。你没办法把它做得很有想象力，加了新东西市场也不认。 **第二件，目标受限，与用户业务无法贴合。** CVM 的核心目标就那么一两个——稳、可靠、便宜。它不是一个能"卖情怀"的产品。你没法跟客户说"我这台 CVM 挺有意思的，你要不要买来看看"——用户 care 的只有一件事，能不能跑住我的业务、SLA 达没达标、账单看着心不心疼。 **第三件，离用户远，只有在故障的时候才被感知。** 这一件我到现在还觉得挺遗憾的。CVM 卖出去之后，绝大多数是被大客户的运维、SRE 用；开发者用得到、但隔着好几层；普通用户，是根本感知不到的。做这个产品做得再好，也很难有一个"直接被用户认可"的时刻。 这三件事凑在一起，就变成了一句话——**技术上不性感，经营上产出差**。 （稍微停顿） 我 2017 年刚接手的时候，团队开会挺沉闷的。技术同事最想讨论的话题，其实是"这个产品怎么才能有点意思"。但每次讨论完，都得再回来接着做那些不性感的事——修 bug、盯稳定性、跟供应链算成本。 当时能怎么办呢？业界最主流的答案是——继续参加军备赛。你 CPU 跑分 100，我搞到 105；你带宽 25G，我搞到 100G。这条路能走，走下去的结果是——大家都在卷，而"离用户远"这个根问题，一寸都不会动。 所以从 2017 年开始，我们其实一直在琢磨的是——**能不能不参加这场军备赛，走另外一条路。** 这条"另外一条路"到底是什么，得先有一个思想抓手，不然大家不知道从哪儿下手。这个抓手是什么，我下一页专门讲。 --- ## P4 · Cattle vs Pets（灵魂页 · 全场引用 3 次） 换一页。这张 slide，我可能得多讲两句。 因为它不只是一张纸，它是我今天整场分享的一个思想底座。后面很多次我会请大家回头想这一页。 这上面写的这个概念，叫做 **Cattle vs Pets**——直译过来就是"牛群 vs 宠物"。这个概念不是我们发明的，是 2012 年一个叫 Randy Bias 的人先提出来的。他当时是在讲——云计算这个行业，跟传统 IT 到底有什么本质的不同。 我用一个特别直白的比方讲一下这个东西。 在还没有云的时代，你给自己家或者给公司买一台服务器——你会给它取名字。叫"阿毛"，叫"小强"，叫"财务系统"，叫"美美的库"。它坏了，你不会随手扔掉；你会心疼，会连夜修，会给它做体检。这台服务器就是你的**宠物 (pets)**。 云计算这件事，真正改变的是——它把服务器变成了另外一种东西，叫**牛群 (cattle)**。你不给它取名了，你给它编号；一头牛病了，你不会想着救它，你直接换一头新的上；坏的那头下线就下线了。你 care 的不是单头牛，你 care 的是整个牛群的规模和健康度。 Randy Bias 讲这个概念的时候，他讲的是——"云的本质，是把 pets 变成 cattle"。 但是过去这些年，我们在做云服务器的过程里，慢慢发现——他这个说法，大方向是对的，但如果只到这里，会漏掉很重要的一半。 我们团队自己攒了两条更完整的话。这两条话，是我今天整场分享真正的地基： **第一条——所有的牛群，其实都曾经是宠物。** 任何一个后来跑到规模化的东西，最开始一定是从"少数人把它当宠物养"开始的。云是这样、互联网是这样、移动 App 是这样。它一定先在小圈子里被当宠物养一段时间——被爱、被折腾、被摸透，然后才能规模化下来变成 cattle。 **第二条——创新永远从 pets 起，规模化必然回归 cattle；但 pets 永远不会消失，它是创新的入口。** 这一点，我个人觉得特别重要。 传统的二元思维喜欢做选择题——"你到底是做 pets 的，还是做 cattle 的？"这样想是不完整的。一家成熟的云厂商，长期一定是**双轨**的——你要有 cattle 的规模化能力去把生意做扎实，你也要有 pets 的入口，让下一个创新有地方进来。少了任何一边，长期都走不远。 （稍微停顿） 好，为什么我要花 5 分钟讲这个东西？ 因为——今天我讲云服务器过去 9 年的整个故事、讲龙虾摊、讲奖牌、讲 ClawPro，全部都是这条 CvP 主轴的落地。 后面我讲三方向、讲高密调度、讲 AI 时代第二次困境、讲龙虾摊——这些看起来是一件件独立的事，其实每一件回过头看，都能落回到这两条上面去。 如果今天听完 90 分钟，各位只记得一件事，我希望是这两条。 --- ## P5 · 三方向延展 = CvP 双轨的实践 有了 CvP 这个底座之后，我们回过头来看 CVM。 刚才我说 CVM 长期被三件事卡着——形态、目标、离用户远。我们从 2017 年之后一直在做的一件事，其实就是——**在 CVM 之外，用 CvP 这两条腿，长出三个方向的产品线**。 这三个方向，我们内部简称 CHD——**Computing、Hosting、Developing**。 **Computing** 做的是**异构计算**——GPU、DPU、FPGA 这些非标准 CPU 的算力。这些算力天然是给大客户跑训练、跑推理用的，一开机就是几百台起步。它是典型的 **cattle**。 **Hosting** 做的是**分布式云**——就是让云的能力能长到用户自己的机房里去，比如金融客户，或者一些数据不能出机房的行业。这也是给严肃业务用的，也是 **cattle**。 **Developing** 做的是**轻量云 Lighthouse**——给个人开发者、给创业公司，几十块钱一个月能跑起来的一台"小云服务器"。这一条线明显是 **pets**——用户不多、规模不大、客单价也不高，但它是我们进入到"个人用户"这个圈子里唯一的入口。 这三件事，团队大概花了 5-6 年慢慢做起来，也都做到了行业的第一梯队。异构计算做到了国内 GPU 云的头部；分布式云在很多严肃行业拿到了标杆项目；Lighthouse 也长出了一批开发者用户。 （稍微停顿） 我在这里得放一个小悬念。 这三件事都做成了。可是——我最开始讲的那三个卡点里的第三个，**离用户近了一些，但仍然很远** 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 这件事，我先说清楚，我们不是先见之明。 我们其实是被行业先教了一课，才反应过来的。 **是 AMD 自己**。2017 年 AMD 推出的 EPYC，不是简单的架构升级，它做了一件业界当时没有人真正做成的事，叫 **chiplet**——把一个大芯片，拆成很多小的 chiplet，用高速总线连起来。这个做法带来了一个直接的好处：**同样的工艺，塞得下更多核**。你可以把它理解成——同样大小的一块地，别人盖平房，AMD 盖了个多层楼。 我们当时看到这个东西的时候，感觉很清楚——如果 AMD 这个方向做得下去，未来 5-10 年 CPU 的核数会一路往上翻。也就是说，"密度"这件事，会有一个持续的、外部推动的红利。 于是我们就决定跟 AMD 走。SA1 用了 EPYC Naples，往后 SA2、SA3、SA4……一直到今天的 SA9 用 Turin，我们前后跟了 9 代。这里面团队跟 AMD 的联合开发、故障调试、供应链协同，其实占了绝大多数的辛苦活。 其实AMD这么做，也可以用Cattle的思维来看待。 --- ## P8 · 高密六层协同全景 （切一张有点密的技术图，先给大家看两秒） 不好意思，这一张 slide 稍微有点密。我不打算逐层讲，我就挑几个可能对大家理解后面故事最有用的地方讲一下。 先说一下这张图上的六层是什么意思——我们在做高密的时候发现，你要真把密度堆上去，光靠芯片不够。你要从**硬件**、**操作系统**、**虚拟化**、**网络**、**存储**、**调度**——这六层，每一层都动。任何一层不动，密度就堆不上去。因为一台物理机上你塞的东西越多，任何一层的短板都会被放大。 这九年，我们其实就是在这六层上，一层一层地啃。啃出来一堆技术，坦白讲，其中大部分单看都是很朴素的活。但是我今天想挑三个可能大家有共鸣的说一下——每一个都对应到后面 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 不是等大模型火了之后我们才开始用的。**AI 从很早，就在我们最核心的调度战场上默默出场了。** 后面第三段我讲我们对 AI 的态度，其实是有底气的——不是嘴上说懂 AI，是我们自己的产品最核心的地方，本来就在跑 AI。 回到这一页最上面那句话——**高密调度技术，是让 cattle 更 cattle 的技术。** 请大家再回想一下 P4 那张宠物 vs 牛群的图。 --- ## P10 · 高密调度如何强化 C/H/D 三方向 前面讲了这么多技术层面的事，我在这里得把它拉回到产品层面——**高密调度这么苦地做出来了，到底给产品带来什么改变？** 我用一句话总结高密的整体技术栈——**在更大的调度域里，提供了更灵活、更稳定的服务能力。因此它能提供更好的 hosting 和 computing 能力。** 这句话有点抽象，我拆开讲一下。请大家回想一下 P5 那张三方向图——Computing / Hosting / Developing。 **Computing 那一栏——GPU 混合装箱。** 原来 GPU 服务器很难做灵活，通常是整机售卖，或者按固定倍数切分。但 GPU 服务器又特别贵，大部分客户其实用不满一整台。高密调度做出来之后，我们能在同一台 GPU 服务器上，按客户实际的需要，拆出各种"不规则"的规格——2 卡 GPU + 32 核 CPU + 200G 内存 + 几张网卡，随便组合。**对客户来说，就是不用再买一整台，只买真正用得上的那部分。** 这在 GPU 时代其实算得上一场小小的成本革命。 **Hosting 那一栏——管控面和执行面分离。** 分布式云原来的痛点是——客户要在自己的机房里部署一套完整的云，成本高、运维累。高密调度让我们可以做另外一件事——**云的调度大脑**放在公有云上，**云的执行小脑**放在客户机房里，一朵云管到底。客户机房里就是一台执行机，管控这些复杂的事情放在云上做。 **Developing 那一栏——海量小规格的碎片资源。** 高密走了这么多年，我们大盘上留下的碎片资源，其实是 Lighthouse 这类产品的天然养料——大量便宜、空闲、可动态回收的小规格资源。**Lighthouse 的边际成本几乎降到了 0。** 这一点在后面讲 OpenClaw 的时候会派上大用场。 （稍微停顿） 回到最开始 CVM 那三个卡点——形态、目标、离用户远。前面五年三方向解决的其实只是形态和目标；到了高密调度这一步，**"离用户远"这个根问题**，第一次才真的开始动。因为一朵云可以管到用户机房里去、GPU 可以按用户实际需求切、Lighthouse 可以做到一杯咖啡钱一个月——这些都是"离用户更近"的动作。 这一段结束我们进入第二段的收官——过去 9 年这个路径长跑到今天，长成了什么样。 --- ## P11 · 长跑的礼物 + 帕鲁 pets 首胜 先讲一下这九年下来，我们大概走到了哪里。先讲一下量级—— **规模上**——2023 年高密机型云上规模大概是 10 万核；2024 年到了 2500 万核；2025 年到了 4600 万核。这条曲线不是我们主动规划出来的，是一开始扎着头去做，走到今天回过头看才发现的。 **成本上**——从 SA1 到 SA9，同样一份算力，单位成本大概从 100% 降到了 20%。 **利用率上**——端到端的资源利用率大概到了 90% 以上。业界公开数据里，AWS 大概是 80% 一线，阿里云是 70% 一线，火山是 80% 一线。 （稍微停顿） 我要在这里非常谨慎地补一句——**这些数字里，有很大一部分是运气**。是芯片行业往密度方向的势能给了我们红利，是内部大客户信我们、愿意迁过来，是团队 9 年间没有换掉核心的一批人。任何一环没接住，可能这条曲线就是另外一个样子了。所以我不太愿意把这个数字讲得太硬。 （切换到下半屏，讲帕鲁） 九年长跑里，其实还有一个我们自己没料到的礼物。这个礼物，是 2024 年年初的**帕鲁**。 2024 年 1 月，一款叫《幻兽帕鲁》的独立游戏突然爆红，全国、全球都在开私服。玩家需要一台"能自己开、开完就自己玩"的小服务器。当时 Lighthouse 团队反应非常快，做了一个"一键开帕鲁服"的活，那段时间订单量翻了很多倍——**我们全场跑的 pets 这条腿，第一次跑出了个漂亮的成绩**。 我特别想讲这个点是因为——它验证了 P4 我讲的那两条真相里的第二条：**创新的入口永远在 pets**。你 cattle 那边规模再大，pets 这边一旦做起来，它就是下一轮的引子。 （稍微停顿） 小红书那个弯路我这里就不展开了——两年攻坚、独家创新者的不信任。总之到 2024 年初的时候，这个局面是——高密走通了、SA9 上线了、大客户开始迁、小红书愿意开始试、帕鲁把 pets 这一条腿也跑出来了。困局撕开了一条缝。 ——但是就在这个时候，第二次困境降临了。 --- ## P12 · AI 时代第二次困境降临 这一段，我讲得可能会有一些个人情绪。因为这段是过去我最难受的一段。 大家都知道，从 2023 年 ChatGPT 之后，整个行业的重心转到了 AI。到 2024 年下半年，我个人的感受是——过去这九年我们非常辛苦攒下的这条路，好像**又要被推翻一次**。 具体说，冲击来自三个地方—— **第一个，业界的质疑。** 那段时间大家能听到的说法是——"云要被 AI 取代"、"CPU 要被 GPU 取代"、"未来是智算中心的天下，公有云是过去时"。这些话在朋友圈里流传得比我们说的话响亮多了。而且说实话，你在那个时刻听多了，会开始怀疑自己。 **第二个，客户预算的调整。** 这一件更实际。绝大多数大客户在 2024-2025 年的预算，都是——**AI 那部分往上拉，传统云那部分往下压**。也就是说，客户信不信我们没那么重要，他手里的那盘钱在往别处走了。这是一个真实的、看得见的经营压力。 **第三个，也是最扎心的——友商产品重心的调整。** 我们过去几年一起卷的那些同业公司，2024 年之后大部分团队 80% 的研发资源压到 GPU 一条腿上去了。CPU 机型不更新、调度器不再演进、Lighthouse 这类的产品线也停滞了。也就是说，业界这条 hosting/computing 的主战场，本来是四五家一起在跑，一年之内就变成了大家不约而同地放手了。 （稍微停顿） 到了 2024 年年底那阵子——刚从第一次困境里探出头一点点，第二次怀疑就扑面而来。这就是标题写的那句——"**又一次'云要被淘汰'的怀疑**"。 我在下一页想跟大家分享的，是我们那阵子的双面情绪。这一部分我尽量说得诚实一点，因为我不想装出"我们一直很坚定"的样子。事实是——那段时间，我们既坚定，也焦虑。 --- ## P13 · 我们的双面回应：坚定 + 焦虑 + 团队自救 先讲坚定的那一面，再讲焦虑那一面。这一页我尽量说得实在一点。 **先说坚定。** 我们坚定的地方，其实非常朴素。从 CvP 这个理论里，我们看得很清楚——**AI 和云不是替代关系，是充分互补关系**。 具体讲三个点。 一，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 才开始做的，AI 从调度那时候就在跑了。 --- ## P14 · CvP × CHD 大 Callback（灵魂页） 好，现在我要把 P4 那两个地基和 P5 那三方向，请回台前来了。 （切图，指向大表） 请大家看这张 5 行 4 列的表。这张表是我今天整个分享的一个思想顶峰——也是我最想让在座的各位管理干部一起看看的一张。 这张表说的意思是——**我们过去按 CvP 和 CHD 布下的那五条线，到了 AI 时代，每一条都被大幅强化了，而不是被削弱了。** 一行一行讲。 **Cattle 那一行**——2020 年这条线上跑的是大客户业务集群。到了 2026 年 AI 时代，这条线上跑的是 **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 的身体这件事，接下来一个非常现实的问题是——**别人也做 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 时代每个人的私人服务器"雏形。这个判断是有 AI 视角在里面的。 内部当时争论的东西也挺有意思。团队内部**几乎没有人反对做**，大家争的是——**它到底能有多火**？有的人估得保守一点，有的人估得激进一点。后来的事实证明——**它比所有人预想的都火**。 2 月 27 日，我们放了一个司内 300 人的体验福利——**15 秒抢空**。看到这个数字之后，我们内部的判断就基本定下来了：这件事必须要走到线下去。而且要用真人、公益的方式做，因为当时小红书上已经出现了 OpenClaw 装机代跑的黄牛，价格 500-3000 不等。我们不希望一件本来是普惠的事情，变成收智商税的事情。 （切右半屏 · 4 天筹备） 从决定装机到上线只有 **4 个工作日**。这里面 grace 帮我们组织了 7 组分工——场地、产品、培训、秩序、宣发、应急，还有一个特别的——**出圈彩蛋和情绪价值组**（后来做出来的"小龙虾出生证明"就是他们的创意）。 技术上，最惊心动魄的是这两个能力—— 3 月 5 日下午，**腾讯云 CodingPlan** 上线，让每个人到现场都能有一个免费的领用链路。 3 月 6 日凌晨 1 点，**QQ 机器人一键配置能力**熬夜上线。这一步做完，用户扫完码到 OpenClaw 装完，不用手动填 IP、不用手动改配置，一步到位。 回头复盘，团队内部有一句话是——**这两个能力，少上一个，现场每个用户的安装时间直接翻倍**。500 人的量，如果每人多花 5 分钟，队伍就得从下午 5 点排到晚上 10 点。 人手上，3 月 4 日预告一发出来，我们立刻发现原本 20 个装机导师根本不够用。紧急招募了 **33 位主动报名的装机导师** + **7-8 位专家兜底** + **2 位"最后兜底"专家**。还从长沙"空降"了两位研发到深圳。 （稍微停顿） 这些细节我讲这么多，是想让大家看到——**这不是一场光鲜的活动，这是一场很多人熬了几个大夜、临时拼出来的活动**。 好，我们上现场。 --- ## P17 · 龙虾之战 · 现场 （切数据爆炸页） 给大家看一下 3 月 6 日那一天的几个数字。这些数字我不想一个个解读，就让它们本身说话。 - **500 张号码牌** —— 我们原定放 500 张就停发。 - **早上 7 点** —— 最早一批用户到场排队。11 点才开始装。 - **11 点到 17 点** —— 原定 14 点结束，硬延到 17 点。 - **2 岁到 60 岁** —— 现场有 10 岁的小学生，有推婴儿车过来的父母，有 60 岁的退休工程师，还有从泰国过来的 13 岁小朋友。 - **单日净增 5×** —— OpenClaw 单日云上规模，是活动前的 5 倍。 - **腾讯股价 +7 个点** —— 当周。 - **48 小时** —— 百度、阿里、火山、京东、天翼，都跟进了自己的 XClaw。 - **一周近百家 KA** —— ClawPro（后面 P20 我会讲这个产品）在活动之后一周，收到近百家企业客户的测试申请。 （切下半屏金句） 这一天里给我印象最深的一件事——是我们大概下午 4 点左右，看到队尾还没散，我和几位同事去劝一部分朋友回去，跟他们说——今天的号码牌已经全部发完了，下次活动还会办。 有一位大爷排在队尾。他抬起头，跟我们说—— > **"没有号码牌？没关系，我可以等。"** （停顿） 那天，我们提前预备的代金券——本来是准备万一大家等太久拿去道歉的。**一张都没发出去。** 保安大哥主动过来护场，有一位阿姨排队等的时候一直问我们下次什么时候再办——这些是那天下来我们团队里一直在互相说的小片段。有点像——你做一件很朴素的事情，做着做着突然发现，原来它对某些人是有意义的。 --- ## P18 · 龙虾之战 · 三大技术底牌 看完这些数字之后，我想把大家往回拉一步，回到技术。因为这场活动如果只讲现场，只讲情绪，会漏掉一件更重要的事——**它凭什么撑下来的**。 要知道现场的实际状况是——一个下午 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 日的龙虾摊。** 这不是一句情怀话，这是我们团队复盘出来的技术事实。**奖牌和龙虾摊，就是同一个故事的两面。** --- ## P19 · 龙虾的真正意义 龙虾这件事火了之后，业界普遍出现了两种解读。这两种，我个人觉得，都错了。 **第一种是乐观派**——他们说，龙虾装机的热度会一直延续下去，云厂商赶紧上，抢一波流量。 这一种错在哪儿呢？错在把**"装机热"当成了"产品热"**。但事实上，装机热是有峰值的——一段时间之内，愿意亲自跑一趟或者线上折腾一个小时的用户，就那么多。峰值一过，装机数据一定会回落。这个时候你继续按"装机热会延续"的假设投人投钱，就会越投越亏。 **第二种是悲观派**——他们说，龙虾就是昙花一现、蹭个热度、没有持续价值、可以不用当回事。 这一种错在哪儿？错在把**"流量回落"当成了"故事结束"**。 我们内部复盘之后，看得很清楚——**流量在回落，但流量下面涌动着的东西，一点都没有过去。** 流量下面涌动的是什么？ **一个是全民 AI 焦虑**——每个人都在问"AI 会怎么改变我的工作"、"我需不需要提前学"； **一个是普惠 AI 算力的渴求**——大家不想只用别人 App 里"给你玩几分钟"的 AI，大家想有一台真的属于自己的、能一直开着的 AI。 这两个东西**加在一起**，是那天大爷说"我可以等"的真正原因。它们不会因为峰值过去就消失，它们会继续在水面下涌动，等待一个更成熟的产品形态来承接。 **那么这个承接的形态是什么？** 回到 CvP——OpenClaw 是每个人的 pets。既然 pets 在这里跑通了，**cattle 一定会到来**。cattle 是什么？是每一家企业需要的"Agent 集群管控平台"。这个东西，我们已经开始做了，它就是下一页要讲的 **ClawPro**。 （稍微停顿，扫一眼右下） 我这里附带说一句蝴蝶效应的事情。3 月 6 日那天之后，媒体侧央视、财经、深圳卫视都循环播了这个素材，OpenClaw 的开源社区创始人也在 X 上转发了；两会期间有院士和政协委员建议深圳"养小龙虾"走全国最前列；龙岗区落地了"小龙虾市场"和"小龙虾十条"；48 小时之内，百度、阿里、火山、京东、天翼都跟进了自己的 XClaw 产品；小马哥连发了两条朋友圈；股价当周涨了 7 个点。 这些都不是我们能规划的事情。我说这些不是想显摆——我更想说的是：**这些不是龙虾的意义。龙虾真正的意义是——它让我们看清楚了，AI 算力普惠这条路，市场是真的想走的。** --- ## P20 · ClawPro 起源：客户的一句"风险我承担" （切一张三段分镜的 slide） 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、成本分摊，全部在这一层做。 回过头看，这件事的判断非常准。它**很轻量、非常有效、ROI 非常高**——一周内我们就收到了近百家 KA 客户的测试申请。这个数字对做 ToB 的人来说，其实是很吓人的。 我这里必须诚实说——ClawPro 这一整个想法，是那位说"风险我承担"的客户，在无意间帮我们想清楚的。**我们只是把它接住了。** --- ## P21 · ClawPro 的"要做/不做" + B 端两个真问题 顺着上一页往下讲。 我们在做 ClawPro 的时候，最难拿主意的其实不是"要做什么"，是"不做什么"。因为面向 B 端客户做 AI 平台，你如果贪大求全，最后一定会做成一个又贵又难用又没差异化的产品。所以我们把"要做/不做"写得比较硬。 （切上半屏 · 表格） **要做的三件事——** **一，深入真实工作流 + 真实数据。** 让 AI 不是玩具，是真的能触达客户的运维现场、生产现场、业务现场。这一件是我们唯一想做深的部分。 **二，标准化交付 + 统一管控。** 权限、审计、灰度、回滚——这些不是可选项，是必需品。企业客户对 AI 的顾虑，一大半来自"我怕出事没法追溯"。这一层我们必须扛住。 **三，SkillHub 沉淀企业 know-how。** 每家企业都有自己的运维习惯、代码规范、业务逻辑。SkillHub 让这些东西可以**沉淀成 Agent 的技能包**——用得越多、Agent 越懂这家企业。 **不做的三件事——** **一，不做全权 Agent，不追求"一句话搞定一切"。** B 端要的不是花活，是可控。花活给个人用户看得爽，给企业 CIO 看，只会让他更紧张。 **二，不给 Shell 授权，不做黑盒执行。** 一个 Agent 拿到 root shell，出了事没法追溯——这在企业客户那里是完全过不了关的。所以我们从架构上就不允许这条路径。 **三，不做通用 AI——通用即妥协。** 这一点是从 Manus 这种通用 Agent 产品的挫折里学到的。通用是很吸引人的一个词，但它意味着"每一件都做得不够好"——放到严肃场景下，这个平均水位过不了关。 （切下半屏 · 两个 CIO 问题） 我们这半年在跟 CIO 客户聊的过程里，反复听到两个问题。这两个问题，也刚好是我们把 ClawPro 想清楚的过程里，一直在自己回答的问题—— **CIO 问题一：我怎么跟我们家 CEO 讲 AI 和云的关系？** 我们的答案就是刚才 P14 那句话——**云是 Agent 的数字身体**。没有云，Agent 无处栖身；上了云，AI 才有真正的执行力。CEO 不需要懂技术细节，他只要理解这一句话就够了。 **CIO 问题二：我们企业的 AI 创新下一步该往哪儿走？** 我们的答案是——**不是买工具，是治理工作流 + 数据。** 这是过去半年我们跟很多企业交流之后，慢慢统一起来的一个观点。企业买 AI 工具的钱其实并不难花——市场上东西多的是。但这些东西买回来能不能长出效果，取决于两件更基础的事：**工作流有没有先梳清楚**（也就是 SOP），**数据能不能被 AI 用**（也就是数据治理）。这两件事没做，工具买再多也白搭。 （稍微停顿） 这两个问题的答案，看着朴素，但是——**它们是我们自己也用了半年多才慢慢想清楚的**。 --- ## P22 · 组织进化 + Token 治理 从产品往下走一步，讲一下组织。这一段有点跑题，但我个人觉得挺重要的——因为过去一年，我在架构师团队上做的事情，跟做 CVM 的思路，其实是一致的。 （切左半屏 · 组织进化） **架构师团队 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 是新时代的电，但电不是用来"管"的，电是用来发动机器的。** 我们内部对 token 的态度，一直是**帮助大于管理**。具体做了三件事—— **一，双额度体系——探索额度 + 生产额度。** 探索额度不设 KPI、员工可以用来试新模型、写实验代码、玩想法；生产额度对应产出和业务。这样员工敢用、也知道边界在哪。 **二，不卷 token 消耗，只看产出。** 我们内部不排名"谁消耗了多少 token"、不搞"省 token 竞赛"。看的是这个员工用 token 之后，解决了什么问题、留下了什么资产。 **三，主动降阻力——帮员工选模型、写好 Prompt 模板。** 这件事挺重要的——我们不希望"学会用 AI"变成员工的另外一个加班项目。管理者应该先趟一遍坑，把好用的东西打磨出来，再让员工用。 （稍微停顿） 管理者在 AI 时代的角色，从"审批 token"，慢慢变成"陪员工用好 token"。**这一件事也是我这半年在慢慢学。** --- ## P23 · 谢谢 （切最后一页） 差不多就到这里。 90 分钟其实很短，还有很多细节讲得不到位——比如小红书那两年、Moltbot 的复盘、AI 提效的度量这些——如果各位有兴趣，会后我们可以慢慢聊。 最后我想说三件事，作为收尾—— 一，**这次拿到的这个奖——云服务器高密机型技术突破奖——它不是我一个人的**。它是过去 9 年，一批愿意在"不性感"的产品线上熬着的技术同事一起做出来的。是他们把每一层技术抠到极致。我今天站在这里，只是把他们的活讲清楚而已。 二，**3 月 6 日的龙虾摊，也不是我一个人的**。是 grace、candyxiao、Lighthouse 团队、architect 团队，还有那 33 位主动报名的装机导师、7-8 位专家、2 位兜底的老兵、从长沙空降来的两位研发——一起熬出来的。 三，**我今天讲的很多话，其实是过去 9 年慢慢想清楚的**。这里面有很大一部分是运气、是时机、是团队。我不是很确定其中的每一条都对。如果各位听完之后觉得哪一条不对——欢迎会后来找我聊，我特别希望能被指出问题。 **谢谢大家。** （鞠躬 · 进入 Q&A） ---