InfoQ 推荐

Elastic 9.3 升级！向量搜索快 12 倍

作者：Mark Silvester — Mon, 16 Mar 2026 13:24:57 GMT

Elastic 9.3.0 现已正式发布。此次版本引入了一系列功能，重点在于自动化工作流程、加速向量索引，并扩展对可观测性和安全领域开放标准的支持。

官方博客"详细说明了该更新如何解决 AI 驱动搜索和高规模数据分析在混合云环境中的运维复杂性。通过为上下文工程和 Agent 构建提供更深入的原生集成，平台旨在简化生产级检索增强生成（RAG）应用的开发流程。

向量搜索速度显著提升。Elastic 集成了 NVIDIA cuVS，一个开源 GPU 加速库，公司声称在自托管部署中索引速度可提升最多 12 倍，force merge 操作可加速 7 倍。这些提升同样适用于高维向量查询，这对 RAG 应用至关重要。根据官方文档"，这些索引改进可在数据集规模扩大时实现更快的检索时间。这一定位使 Elastic 与专业向量数据库如 Pinecone" 或 Weaviate" 以及其长期竞争对手 OpenSearch" 直接竞争。

ES|QL 获得了重要升级。这种管道式语言允许开发者直接在搜索引擎内转换和聚合数据，减少在应用代码中的后处理需求。版本 9.3.0 引入了新的字符串操作和日期处理函数，并提升了复杂 Join 查询的性能。这些改进旨在让该语言对需要在海量数据集上进行实时分析的工程师更具灵活性，而无需在系统之间移动数据。

可观测性现在以开放标准为中心。Elastic 进一步将 OpenTelemetry（OTel）"集成到其生态系统中，使用户能够更顺畅地采集追踪、指标和日志数据，而无需绑定供应商。平台现在对基于 OTel 的数据提供更好的原生支持，简化了团队从专有 Agent 迁移的过程。这一举措反映了更广泛的行业趋势，组织日益采用开源采集标准以保持监控堆栈灵活性，并减少管理多个数据采集器的运维负担。通过采用 OTel，Elastic 确保其遥测数据可与众多第三方分析工具和行业标准仪表盘兼容。

AI Assistant 现在能够调查、查询并采取行动。借助大语言模型，助手现在可以分析日志模式并建议针对检测到的异常的修复步骤。该功能旨在通过自动化根因分析的初始阶段，减少 DevOps 和安全团队的平均修复时间。虽然类似工具在 New Relic" 等平台中也存在，但与底层数据存储的深度集成为数据上下文和历史趋势分析提供了特定优势。此外，助手可以根据自然语言提示生成复杂的 ES|QL 查询，弥合用户在新查询语言语法方面的技术差距。

安全可见性已扩展至云环境。平台引入了新的检测规则，并提升了对 Kubernetes 和 Serverless 架构的可见性，确保无论基础设施位于何处，都能识别威胁。这些更新确保 Elastic 仍是传统安全信息和事件管理供应商的可行替代方案。统一数据仍然是 9 版本架构的核心，使跨域分析成为可能，这在以往孤立工具中难以实现。工程师现在可以更灵活地在日志和追踪之间切换，以识别性能瓶颈的来源。此外，增强的安全态势可在高度监管行业中更好地进行合规跟踪，这些行业通常要求审计日志和实时监控以保障运营完整性。

原文链接：

https://www.infoq.com/news/2026/03/elastic-9-3-gpu-vector-indexing/

曝Meta狂砍20%岗位！超1.6万人将失业，传闻“要用AI智能体取代整个工程团队”？

华卫 — Mon, 16 Mar 2026 10:48:36 GMT

近日，三位知情人士消息称，Meta正计划大规模裁员，裁员比例或高达20%，约15800个职位，甚至可能更多。此举旨在抵消高昂的AI基础设施投入成本，并为AI辅助办公带来的更高效率做准备。目前裁员尚未确定具体日期，规模也未最终敲定。

其中两位人士透露，Meta高管近期已向其他高级管理者通报相关计划，并要求其开始着手精简方案。Meta发言人 Andy Stone 在回应相关计划时表示：“这是关于理论方案的猜测性报道。”

若最终确定裁员20%，这将是Meta自2022年底至2023年初被称为“效率之年”的重组以来规模最大的一次裁员。据其最新文件显示，截至去年12月31日，Meta员工总数近7.9万人。该公司曾在2022年11月裁员1.1万人，约占当时员工总数的13%；约4个月后，又宣布再裁员1万人。

另有传闻称，20% 只是短期底线。最高管理层早已在做长期规划，最终裁员规模可能是这个数字的两到三倍。此前，Meta 在全工程部门大规模上线 AI 工具后，对开发者的工作日志进行了深挖，结果让管理层大为震惊：许多资深员工现在每周真正投入生产的时间不足 10 小时，因为 AI 工具能极快地处理大量重复性杂活。

据该传闻称，Meta已经悄悄进行了数月的知识提取冲刺，资深工程师的屏幕被24 小时录制，每一条提示词都被记录，调试流程被事无巨细地捕捉，整套决策逻辑都以“流程文档化、保证工作连续性”的名义被完整录下。一位工程师描述，自己被迫对着白板，把整套系统设计思路、权衡取舍、故障模式、扩容技巧全部讲出来，全程录像。

“裁员不只是为了省钱。他们向媒体宣称的战略性AI转型只是掩人耳目的幌子，真正在做的是用基于自家资深员工思维训练出来的 AI 智能体，取代整个工程团队。”

过去一年，Meta 的 CEO Mark Zuckerberg 大力推动Meta在生成式AI领域更激烈地竞争。该公司为招揽顶尖AI研究者加入新成立的超智能团队，开出巨额薪酬，部分四年合约价值数亿美元。Meta表示，计划到2028年投资6000亿美元建设数据中心。本周早些时候，Meta收购了为AI智能体打造的社交平台Moltbook。据路透社此前报道，Meta还斥资至少20亿美元收购中国AI初创公司Manus。

Zuckerberg曾暗示相关投资将带来效率提升，他在1月表示，已开始看到“过去需要大型团队完成的项目，现在一名优秀人才就能搞定”。

Meta大举投入AI之前，其去年的Llama 4大模型遭遇一系列挫折，包括早期版本在基准测试中被指结果存在误导，Meta最终取消了原定于夏季发布的该系列最大模型Behemoth。其超智能团队今年正通过研发新模型Avocado重塑公司地位，但该模型的表现同样未达预期。

从 ChatBI 到多 Agent 分析中台：Snowflake 与亚马逊云科技的实战架构

李凌霄 — Mon, 16 Mar 2026 10:06:30 GMT

2026 年，智能体将在企业级应用中取得哪些实质性突破？点击下载"《2026 年 AI 与数据发展预测》白皮书，获悉专家一手前瞻，抢先拥抱新的工作方式！

为什么我们不再喊「ChatBI」

过去两年，「对话式 BI」「ChatBI」「Text-to-SQL」几乎成了标配能力：只要接上大模型、能把自然语言翻成 SQL，再加一个聊天界面，就可以对外宣称是「AI 分析助手」。

问题在于，真正落到企业一线场景时，一个「大而全的 ChatBot」往往难以支撑完整的业务分析闭环。很多项目在 PoC 和演示阶段看起来「能回答问题」，但要真正嵌入日常经营决策，还需要考虑场景覆盖、分析深度、可靠性和数据治理等一整套体系。

因此，接下来这篇文章不会再纠结「要不要做 ChatBI」，而是尝试回答一个更关键的问题：如何利用 Amazon Quick Suite、Bedrock AgentCore 和 Snowflake Cortex Agents，把「能聊天的 BI」升级为「能协同工作的数据智能中台」，并满足企业级落地的要求。

ChatBI 模式的现实挑战

即便已经接入大模型，很多企业内部的 ChatBI 项目，最终都停留在 Demo 或小范围试点阶段，主要有几类共性问题：

1. 单 Agent 能力有限，遇到复杂问题容易「聊崩」简单的取数问答还可以应付，一旦问题涉及多个指标、关联多个系统或需要追问，单一 ChatBot 很难自己规划步骤、拆解子任务。

2. 缺乏业务语义与治理上下文，回答不够「敢用」模型可以生成 SQL，但如果不知道企业内部的指标口径、权限边界和合规要求，要么回答含糊，要么给出看似「对」但没人敢直接采纳的结论。

3. 难以串起「从问题到行动」的全链路多数 ChatBI 只能停留在「回答一个问题」，很难进一步自动联动报表、工单、通知或其它业务系统，导致分析和执行之间仍然靠人工接力。

4. 体验与运维都难规模化初期的 Demo 可以靠项目组手工调参数、写 prompt，一旦推广到多个业务线，不同场景下的提示词、工具组合和模型选择，很难在一个单体 ChatBot 里维护。

真正的突破点，不是再造一个更聪明的 ChatBot，而是引入多 Agent 协同和标准化工具编排，让「问问题的人」始终面对一个简单对话界面，后台则由一组专职 Agent 分工合作，去完成从理解意图、访问数据到生成结论乃至触发后续动作的整个闭环。

从 ChatBI 到多 Agent 分析中台

基于前文提到的这些限制，我们结合 Amazon Quick Suite、Bedrock AgentCore 和 Snowflake Cortex AI，设计了一套满足企业级落地条件的多 Agent 对话式分析方案。这套方案既能够沿用现有的 BI 和数据治理体系，又通过多 Agent 协同，让企业更快速、准确地构建可以在生产环境长期运行的分析助手，在不改变企业原有数据与治理体系的前提下，用多 Agent 协同和统一前台体验，把「对话问数」升级为可在生产环境长期运行的分析中台。

本方案采用了一个相对「传统」但在 Agentic AI 语境下重新被激活的三层解耦架构：交互层、编排层、执行层。不同的是，我们在每一层都注入了多 Agent 与治理的设计理念。

交互层：Amazon Quick Suite

交互层直接面对业务用户，核心组件是 Amazon Quick Suite：

Chat Agent 对话界面：基于大语言模型的 Chat Agent，支持多轮对话和上下文理解，让用户可以用自然语言持续追问、细化分析需求；MCP 协议集成：通过 Model Context Protocol（MCP）与后端的工具和 Agents 建立标准化连接，为后续扩展更多能力预留空间；智能路由入口：根据用户意图自动选择走 Dashboard 预构建分析路径，还是走实时 Text-to-SQL 路径，避免所有问题都「硬上大模型」；统一工作空间：在同一个界面中集成 Dashboard 可视化、工作流自动化和对话记录，让业务用户有一个完整的分析与协作空间。

这一层的设计目标，可以简单概括为：把多 Agent 的复杂协同，压缩成业务侧感知到的一句「我就跟它聊天」。

编排层：Amazon Bedrock AgentCore

编排层是整套方案的「神经中枢」，由 Amazon Bedrock AgentCore 承担：

Gateway 组件：负责 MCP 协议与底层 RESTful API 之间的协议转换，让后端的 Snowflake Cortex Agents、Lambda 函数等都能以统一方式被调用；认证与鉴权：基于 AWS Cognito 的 JWT Token 机制，将前台用户身份与后端调用串联起来，确保每一次数据访问都能被追踪和控制；语义工具选择：AgentCore 利用任务上下文和提示信息，动态选择最合适的工具或 Agent，而不是事先写死调用顺序；统一工具接入：支持 OpenAPI、Smithy、Lambda 等多种工具类型的标准化接入，方便后续逐步扩展更多企业内部系统与第三方服务。

如果说交互层解决的是「用户怎么问」的问题，那么编排层解决的就是：在一堆能力里，如何自动选择「该用谁、以什么顺序用、用到什么程度就可以停」。

执行层：Snowflake Cortex AI

执行层是这套架构的「算力与数据」交汇点，由 Snowflake Cortex AI 提供：

Cortex Analyst（Text-to-SQL 引擎）：基于 LLM 的 Text-to-SQL 服务，结合语义模型，支持复杂业务查询语义理解与高质量 SQL 生成；Cortex Agents（多 Agent 协同执行）：面向不同分析任务定义专职 Agent，负责自动分解和协调复杂分析流程，如分步取数、对比分析、结果摘要等；语义模型（YAML 业务元数据层）：使用 YAML 定义业务术语、指标口径、实体关系和常见问法，为 Text-to-SQL 和多 Agent 推理提供统一「业务词典」；数据治理与安全：所有查询都在 Snowflake 内部执行，配合 RBAC、行列级权限控制和审计，确保数据不出治理边界。

这意味着，从前台看似「聊了几句天」，实质上是多个 Cortex Agent 在 Snowflake 内部轮番登场，各自完成一段工作，再把结果拼成一个可信的答案。

核心技术实现：多 Agent 协同的关键机制

在上述三层架构之上，本方案重点落地了三类关键机制，让整个链路既「跑得起来」，又「跑得稳」。

双路径智能路由：Dashboard + Text-to-SQL

系统首先会根据查询特征，在两条路径之间做智能路由：

路径一：Dashboard 预构建查询

流程：用户查询 → Chat Agent 意图识别 → QuickSight Dashboard → 返回结果；适用场景：基于固定报表的预定义分析，例如「本月销售额是多少」「Top10 客户有哪些」；优点：响应秒级、口径一致、易于被管理。

路径二：实时 Text-to-SQL

流程：用户查询 → MCP 协议 → AgentCore Gateway → Lambda 函数 → Snowflake Cortex Agents → SQL 执行 → 返回结果；适用场景：灵活的临时查询，例如「区域环比增长前 5 的产品 SKU 是哪些」；优点：无须为每个问题单独建报表，真正支持 ad-hoc 分析。

通过这套设计，我们避免了「要么全靠报表，要么所有问题都走 LLM」的极端模式，而是让系统在稳定性和灵活性之间自动找到平衡点。

异步处理架构：兼顾复杂查询与前台体验

在企业实战中，不少查询本身就具有高复杂度：多表 JOIN、大时间跨度明细拉取、复杂聚合与排序等。如果一味追求同步返回，要么牺牲系统稳定性，要么被迫大幅缩减业务问题的表达空间。

因此，本方案采用了同步 + 异步双模式：

简单同步模式 Lambda 函数直接调用 Cortex Agents，实时执行查询并将结果返回给前台，适合秒级可返回的场景。

复杂异步轮询模式

工具 1：启动查询，生成 query_id，并将状态写入 DynamoDB 等存储；工具 2：根据 query_id 周期性轮询查询状态，完成后将结果推送给前台或供前台主动拉取。

这样，业务侧看到的仍然是一个自然的对话过程（「我帮你跑一个复杂分析，稍后把结果发给你」），而后端则可以在可控的资源与时延范围内，稳妥完成真正重型的分析任务。

语义模型驱动的 Text-to-SQL

多 Agent 能否靠谱，很大程度上取决于：Agent 是否真正理解了企业内部的业务语义。在这点上，Snowflake 的语义模型扮演了关键角色。

具体做法是：

使用 YAML 文件定义「业务词典」，为常见指标（如「销售额」「毛利率」）和维度（如「区域」「渠道」）建立到数据库字段、表关系的清晰映射；记录表之间关联关系、过滤条件习惯、时间逻辑等，让 Text-to-SQL 不再「凭感觉」乱 JOIN；配置常见问法与业务别名，将多种说法统一映射到同一指标口径之上。

核心思路可以一句话概括为：告诉 AI「业务在说什么」和「数据长什么样」，而不是让 AI 自己瞎猜。这个「业务词典」就像给 AI 配了一个懂行的翻译，大幅提升了 SQL 生成的准确率和稳定性。

适用场景与实践建议

结合目前的实践经验，这套多 Agent 分析助手方案尤其适合以下场景：

希望快速赋能业务人员自助分析销售、运营、市场等团队临时分析需求多、节奏快，希望真正做到「自己问、自己看」；对数据安全和治理有严格要求的企业金融、零售、互联网等行业，希望所有分析都在 Snowflake 内完成，不愿意将数据大规模暴露给外部服务；希望降低数据团队重复性工作负担数据团队不再被大量「帮我拉这个数」「帮我改一下这个指标」的工单占满，可以把更多时间投入到策略分析与数据产品建设上。

实践落地时，可以考虑按以下节奏推进：

1. 选定一个高价值的「灯塔场景」，例如「销售业务分析助手」，先从一个业务域做深做透；

2. 在真实使用中迭代语义模型和路由规则，确保回答质量、口径一致性和业务体验都达标；

3. 再逐步复制到其它业务域（如供应链、会员运营、财务分析），形成可复用的多 Agent 分析中台。

写在最后：从「能聊天」到「敢决策」

本文并不是要否定 ChatBI，而是希望回答一个更现实的问题：

在企业已经有数据仓库、BI 报表和治理体系的前提下，我们如何让「对话式体验」真正进入业务主战场，而不是停留在 Demo？通过 Amazon Quick Suite、Bedrock AgentCore 与 Snowflake Cortex AI 的深度集成，这套多 Agent 对话式分析方案给出了一条可行路径：在不突破数据治理边界的前提下，让业务同学用自然语言完成从提问到行动的全链路，让数据团队从「报表工厂」升级为「智能分析中枢」。

值得一提的是，Snowflake AI 数据云已经正式登陆中国亚马逊云科技 Marketplace，国内企业可以更便捷地在本地合规环境中部署和使用上述能力，加速从「会聊」走向「敢用」的过程。

如果你对本文提到的架构细节、语义模型设计，或者实际 Demo 实现感兴趣，欢迎在评论区交流讨论，一起探索多 Agent 在企业级分析场景中的更多可能性。

关于作者

李凌霄，Snowflake 数据分析及大数据技术专家。拥有逾十年数据分析与数据平台架构经验，先后在 Snowflake、IDC、Qlik 等企业负责解决方案和合作伙伴赋能工作；同时，作为行业分析师专注国内外数据软件行业研究，曾发布十余本专业研究报告，为行业企业及技术公司提供项目咨询与市场分析服务。

点击链接立即报名注册：Ascent - Snowflake Platform Training - China"，更多 Snowflake 精彩活动请关注专区"。

AI x 大前端性能稳定性：快手亿级 DAU 下的智能诊断实践

Kitty — Mon, 16 Mar 2026 09:38:48 GMT

演讲嘉宾｜李锐策划｜QCon 全球软件开发大会

近年来，大前端技术领域呈现出迭代速度加快、功能复杂度和业务耦合度增加的特点，加之快手亿级 DAU 的用户规模和超长使用时长，面临着多种技术栈并存、高资源占用的挑战，性能稳定性风险持续增大。传统的性能稳定性排障工具使用门槛高，依赖领域专家多年积累的深度知识和隐性经验判断。那么，AI 是否是破解有限的人力和无限的复杂问题之间矛盾的答案？本文整理自快手移动端稳定性负责人李锐在 2025 年 QCon 全球软件开发大会（上海站）的分享“AI x 大前端性能稳定性：快手亿级 DAU 下的智能诊断实践"”。重点分享在大前端性能稳定性保障中，如何借助快手「柯南 AI」赋能，实现性能稳定性问题排障经验平民化，显著提升诊断效率。

预告：将于 4 月 16 - 18 召开的 QCon 北京站设计了「下一代交互架构：LUI 与 GUI 的融合"」专题，将探讨如何在复杂系统中平衡自由输入与结构化操作，构建高效、可控的新一代人机交互范式。敬请关注。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

最近，AI 赛道的“卷”已从国内蔓延到硅谷：“996” 乃至 “007” 的传闻不绝于耳；ACM 总决赛冠军被大模型摘下；IMO 金牌水平的自动编码能力，也足以让大多数程序员自叹弗如。如果 AI 既能写代码又能自动完成调试，是否就形成了一个自我迭代的闭环，把“人”彻底挤出了开发流程？热度之下，我更想冷静地思考下，在快手这样体量的复杂业务里，从性能稳定性视角来看看 AI 到底能走多远。今天，我就以亲历者的身份，聊聊我们团队在“AI x 性能稳定性”上的思考和构建「柯南 AI」平台躺过的那些坑。

我 2019 年加入快手，此后一直负责稳定性领域的建设。个人偏好钻研系统底层原理，折腾过不少“硬核”技术，也是快手移动端第一个开源项目 KOOM 的作者。接下来的分享分五部分：先回答“为什么”和“怎么做”，再聚焦两个关键场景，最后谈谈认知和感受。

快⼿性能稳定性背景

我把自己在快手经历的稳定性演进，粗略地划成四个阶段。回头去看，每一阶段都站在上一阶段的肩膀：最早自研 APM，接着把逐个零散工具沉淀成 APM 平台，再基于平台做问题治理，最后是体系化的稳定性故障防御。节奏与移动互联网技术浪潮同频——从移动互联网红利期到存量用户竞争期，性能和稳定性被重新定义为用户的体验带来的公司竞争优势，再到今天的 AI 浪潮时代。

大前端的性能稳定性议题已伴随移动互联网十余年。硬件层面，iPhone 的算力较初代已提升百倍；软件层面，QCon、GMTC 年年设专场。可问题真的被完全扫清了吗？并没有。上半年 QCon 的主题叫“越挫越勇的大前端"”，下半年又变成“AI 与跨端的高效融合"”——主题本身就在暗示：复杂度并未消解，我们仍在受挫，效率依旧不足。若用算法复杂度打比方，过去十年我们面对的场景和其解决算法本身并未升级，且复杂度还因鸿蒙等新变量持续膨胀水涨船高，输入规模也增加了。因此，我们确实面临不小的挑战。

AI x 性能稳定性介绍

那么 AI 能否破局？先从人的角度谈下我的思考，在诸位的团队中是否发现存在一个现象：团队里总有些 Bug 只有特定“老专家”能解，新人插不上手，得不到锻炼；专家又持续被这些 bug 缠身，没法释放出人力做更有价值的事情，进而导致恶性循环质量下滑。从这个角度出发，在性能稳定性领域，我最初的思考：AI 定位首先不是取代谁，而是成为团队产出放大器，把“专家经验”转化为组织能力。

要让放大器不失真，得先搭好稳定的“电路”。我们稳定性体系本就分阶段演进，每一阶段都是下一阶段的底座；AI 也必须长在这套体系之上再去改造这套体系，否则就是无源之水、无本之木。但是，稳定性横跨技术、流程、运营几十个小域，AI 该从哪切入？

内部多轮推演后，我们锁定“问题处置”——它最吃研发时间，也最影响用户体验，且能弥补人在排障时处置时的盲区（研究表明人脑同时做多处理四个变量）。具体拆成两条线：根因处置与应急止血；根因里又分疑难与简单两类，恰好与大模型的推理、检索、生成能力相呼应。

我们自顶向下设计了一套可扩展的 Agent 架构，搭建了「柯南 AI」平台。业务目标明确：把根因定位与应急响应做得更快、更准。产品形态先以内部 IM 机器人落地，支持问题根因排查建议和 MR 自动修复；再逐步演进为嵌入 IDE、Coding Agent 、内部排障平台多轮会话。技术选型上，Agent 框架我们的发展经历了两个阶段：从 AutoGen 到基于 OpenAI Agent SDK 原语自研 Agent 框架，支持图编排、多种模式策略，也能接入和各 CLI Agent 结合。基建层分两头：AI 侧按场景选模型——简单任务用轻量模型，推理密集型上强模型，多模态场景再叠加视觉能力；同时把推进内部平台 MCP 化演进，让工具随调随用。服务端同样关键：系统必须可观测、可调试、可压测，还要提前算清成本，避免规模上去后失控。

实践：AI 辅助根因排障

前面谈了“为什么”与“怎么做”，接下来我想用一次真实案例回答“我们到底做了什么”。案例是一枚被内部戏称为“五星 NPE”的异常。乍看只是空指针，加个判空似乎就能了事；可它偏偏只在大型活动爆发，且堆栈里只剩系统帧，连崩溃触发源头都无处寻觅。把日志丢给 ChatGPT、Claude 或 DeepSeek，它们同样抓瞎，因为上下文太少，推理链断裂。那么，通过我们的工具链能定位出问题根因吗？

在动手之前，我们先对研发同学做了一次摸底：96 % 的人承认线上排障痛苦，却又在不出事时抱怨日志太多，出事后嫌日志太少。刚刚前面友商的演讲可以看到，工程师 60 % 的时间花在修 Bug 上；我查到的 ACM Queue 报道数据也落在 30 %–50 % 区间。两相映照，可见“写代码易，排障难”并非个例。

近来，行业里 Linus 那句“Talk is cheap, show me the code” 被广为流传在 AI 时代变为了 “Code is cheap, show me the talk” ，但我想说的是：“Code is cheap, debug is expensive—show me the fix。” 写出能跑的代码只需几分钟，但要交付工业级、零缺陷的版本，仍然需要一套能把“昂贵排障”降本增效的体系，这正是我们接下来要展开的内容。

为什么修一个 Bug 会如此耗时？我把这些年的踩坑经历抽象成一句话：排障本质上是一场科学推理实验，本质上是演绎推理、归纳推理、溯因推理、类比推理等推理方法论的组合。我发现 MIT 有一门课也持同样观点——先观察现象、收集数据，再提出假设，用排除法迭代，直到去伪存真。AI 能否胜任这场实验？基于此思路，我把它拆成“摸高”与“短板”两条线。

我们再来思考，目前 AI 的推理能力有多大程度能解决排障的问题。AI 的长板显而易见：总结日志快、联想模式多、见过的异常广。只要通过 Agent 策略或提示词稍加引导，它就能把碎片化信息迅速拼成一张“线索图”。然而，一旦触及天花板，它就会碰壁：私域代码、内部工具链、超长推理链，都是它的盲区。最棘手的是“深度 Bug”，触发条件多、路径长，需要连续十几步推理，模型往往在中途失焦。

我们给 AI 建了一套四级胜任度评估体系：最底层是“问题总结”，几乎百发百中；往上是“提出假设”，准确率开始下降；再往上是“验证假设”，需要人工补位多论会话；顶层是“给出可落地方案”，直接把问题进行修复，目前只能当辅助解决简单问题。先把标尺立起来，再持续往里填数据、调策略，才能看清 AI 到底站在哪一级台阶，下一步该往哪迈，并据此评估体系，伴随着模型能力的提升，持续观测迭代 AI x 稳定性的能力。

把排障比作破案，是我这些年最贴切的感受：都要在零散线索里还原动机，再锁定真凶。想做出一个实践中切实有效的稳定性 Agent，开发者自己得先是一名老侦探——见过千奇百怪的案发现场，才能把经验沉淀成规则。最难的 Bug 就像“完美犯罪”，现场干净得连指纹都没有；前面提到的“五星 NPE”便是如此，只剩一条光秃秃的系统堆栈，几乎没有任何可供推理的痕迹，缺少上下文 AI 也会巧妇难为无米之炊。

为了在这种“零线索”场景里也能破案，我们内部做了一套叫 Holmes 的工具。它把传统手段拆成“静态”与“动态”两条线：静态侧是日志、Coredump、内存转储这些“尸体报告”；动态侧则是调试器、Profiler 这类“让程序再死一次”的利器。老程序员偏爱调试器，正是因为它能一步步重演死亡过程，把瞬间定格成连续画面。

Holmes 的思路是在两条线上同时做延伸：静态侧，我们将日志与转储映射为可视化 UI；动态侧，则通过远程热插桩实时采集运行时数据。

今天我想重点说说 UI 视图在排障中的实际价值。移动端程序以 GUI 交互为主，bug 中天然有很大占比是来源于 UI 视图相关的问题，复杂应用遇到的 UI 视图难题通常是组合式问题，需要跨越应用层直达系统框架层。我们曾遇到一类极难定位的崩溃：只有一张截图、一份 ViewTree 和一串点击事件。把这三样拼在一起，就能还原用户到底点了哪个按钮、触发了哪段逻辑，从而把“毫无关联”的系统堆栈翻译成“按钮 A 崩溃”。别小看这一步，它让研发立刻联想到最近的 MR 和需求，排障时间从小时级缩到分钟级。

具体落地时，Holmes 的 UI 视图采集必须“刚刚好”：信息不能多也不能少，多了干扰判断，少了缺关键线索；同时要对系统 UI 框架足够熟悉，才能在不显著损耗性能的前提下，把 View 层级、布局参数、事件链路一次性抓全。

第一次看采集结果的人常被密密麻麻的参数吓到。确实，只有写工具的同学才记得住每个字段含义。这又回到老问题：工具越复杂，会用的人越少，资源再次错配。

AI 时代给了我们打破循环的机会。我们沿用了前面提到的 Agent 框架：先让大模型把版本、系统、堆栈等基础信息做一轮预处理；再用专家沉淀的经验规则让大模型把问题分桶，每个桶对应响应的问题分析 Agent（作者注：AI 发展很快，2026 最新架构已在 Skill 方向发展，但思想一致）**，例如 UI 视图 Agent 会读取 Holmes 采集的数据并结合源码，用 ReAct 策略不断自问“是否需要进一步工具”“是否已定位根因”，在限定轮次内给出结论；若超时仍未解决，则标记失败并交由人工兜底。如此，复杂参数被 Agent 自动消化，研发只需关注“哪个按钮崩了”，工具终于从“个人绝技”变成“团队标配”。

看起来顺理成章，是吧？先粗判问题，再分类，最后给出源码。但真正动手做过 Agent 的人都知道，大模型的幻觉远比想象严重，且每一步都伴随概率衰减：一步 80 %，两步就只剩 64 %。工业级场景要求接近 100 %，于是工程细节被放大成决定性因素。

在上下文工程上，我们踩的坑可以归为两类。第一类是信息不足，目标过于宏大：直接让模型“分析一下这次崩溃”，效果往往稀碎。第二类是信息过载，职责边界模糊，模型反而迷失。用数学语言讲，前者是“欠定”，后者是“超定”，我们要的是“适定”：不多不少，刚好足够。为此，我们把问题拆成若干单一职责的 Agent，每个 Agent 的提示词都经过精心裁剪，并通过 few-shot 示例教会它如何调用私域工具。最终呈现的效果是：系统先给出根因推测，再列出排查方向。若问题简单，可直接生成 MR，一键采纳；若问题复杂，研发可沿线索继续深挖。

前面谈的多是崩溃类场景。在“动”的另一侧，Profiler 负责性能问题。最广为人知的便是火焰图。细究名字，它源于十多年前 Netflix 工程师 Brendan Gregg 用 Perf 工具生成的可视化：调用栈越高，火焰越旺，瓶颈一目了然。如今，火焰图已“名不副实”——Android 的 Perfetto 不再仅仅画火焰，而是把 CPU、内存、调度、应用事件（atrace）与内核追踪（ftrace）全部塞进一张图。十几秒的采集即可产出 60 MB 数据：采样太短，信号不足；采样稍长，数据便膨胀到难以处理。复杂问题需要复杂工具，复杂工具又带来复杂用法，而场景本身还在持续膨胀。

过去我们面对性能问题时，通常的做法是：先花时间去学习火焰图工具的使用，再在图中来回拖拽、放大缩小，逐层定位瓶颈。这一步对工程师的底层知识要求极高，完成后才能正式进入分析阶段：查看历史案例、比对相似问题，整个链路长、门槛高、效率低，还容易遗漏关键线索，这些正是 AI 可以发力的痛点。

我们给出的火焰图方案依旧沿用“专家经验前置”的思路：做 AI 火焰图排障的人，首先得是一位能熟练解读火焰图的性能专家。方案的核心在于数据预处理算法，如何把 60 MB 的原始火焰图压缩成可供模型高效消费的上下文，并与源码、trace 事件精准关联，从而完成粗筛，然后再又后续的处理环节按需加载必要信息进行分析。最终，火焰图分析结果按四种维度呈现：卡顿、启动、Slice 与自定义查询。系统直接给出结论，并指出对应源码位置，支持一键跳转；无需再像过去那样手动拖拽寻找瓶颈，排障路径被大幅缩短。

实践：AI 加速应急处置

接下来我想谈谈应急故障处置。它的核心只有一个字：急。

先说一个真实案例。iOS 26 升级后，苹果再次引入兼容性变动——25 年后仍在修改 Objective-C Runtime，并在文档里“善意”提醒：此处会崩（作者注：详见《iOS 26 你的 property 崩了吗？》）。结果，快手线上仍在运行的上百个历史版本，在升级 iOS 26 后瞬间集体崩溃。只有真正经历过的人，才体会得到那种痛：版本多、用户广，止损无从下手。我们盘点现有手段，有以下三种：

应用商店更新——一周覆盖率 50%，剩下 50% 的用户必崩一次；变更回滚——这次是苹果改动，无法让苹果回滚；

于是，我们问自己：有没有一种工具，能在崩溃发生的瞬间直接“兜底”，像《英雄联盟》里的 Ekko 开大招——时光倒流，让程序回到正常状态？我们内部也把这个工具命名为 Ekko。它的思路很朴素：无论异常由谁引入、因何触发，先跳过错误，保证用户不崩。当然，实现起来并不简单。

行业里曾有一种前置 Hook 方案，但它必须在异常发生前就介入，对所有用户生效，哪怕他们从未崩溃，Ekko 规避了这个缺点。Ekko 与行业方案的最大区别，在于它是“事后”的：只有当用户真正崩溃时，才进入兜底流程，从而把对正常用户的干扰降到零。这听起来简单，实现却层层递进。以 NSException 为例，我们注册 exception_preprocessor；C++ 异常则要 hook personality routine；Mach 异常还得与内核通信，难度逐级升高。

崩溃被捕获后，执行流已被打断，必须精确恢复现场：指令地址、寄存器、栈帧、局部变量，一个都不能错。我们的方案也经历了多次迭代：1.0 版基于常规栈回溯，遇到 Mach 异常就束手无策；2.0 版引入异步 unwind，又碰上因包体积优化而被裁剪的 unwind info 带来的兼容性问题；最终，我们干脆自研反汇编器，把控制权完全握在自己手里。

工具虽强，落地仍难。配置跳转指令、恢复上下文等步骤依旧繁琐，只能由少数专家操作。一旦线上告警，专家不在场，风险便陡增。于是我们把 AI 接进来：由 Agent 自动分析崩溃现场，生成兜底配置，并给出影响范围与推荐参数，既降低门槛，也减少人为失误。

再讲一个故事。我不知道大家历史上见过多大的事故，我见过的是千万级崩溃，而且只发生在半小时内。起初只是一个小崩溃，一小时才崩一两百次；大家在处理时做了一个善意的止损——把弹气泡功能关掉，以为这样就能止血。没想到“关掉气泡”这个动作本身的问题根因原理一致，结果崩溃量从几百次瞬间涨到几十万次。这件事给我们最大的教训是：故障处置里依赖人做判断非常不靠谱。人在高压下会紧张、肾上腺素飙升，很容易漏掉关键信息。

于是我们把 AI 引入进来。它不会紧张，也能把历次操作都总结下来，并提供处置建议，发展至终局阶段甚至能够自动处置。做法还是基于前面说的 Agent 架构：故障来了先分析，给出建议结论；如果判断需要兜底，就调用兜底工具生成配置并发布。

直接看效果。第一，Checklist：你现在很紧张，就按我们处理了一年几百次报警总结出的步骤一条条列出来给处置建议，防止遗漏。第二，问题总结：崩溃上报字段有 100 多个维度，人眼看肯定漏。很多问题其实有维度特征，比如展示图里提示“Android 35、高通芯片”等限定条件，有了这些信息，第一步定界就很快。第三，在给出维度后，继续提供源码级分析，并推送可能的修复方向，省去人工翻查。

总结展望

接下来想说说我们在开发 Agent 过程中的真实体感，也算一次认知升级。首先是一次思维切换。写传统程序时，我们默认“图灵机”式的确定性：输入固定，输出必达。但大模型需要概率思维，若仍以确定性思维调试，只会徒增烦恼。只有先摸清楚它擅长什么、薄弱在哪、天花板多高，才能决定哪里用 AI、哪里留硬代码，省下大量返工时间。

其次，要识别瓶颈并主动拆解。提示词工程本身并不能提高模型本身的上限，因为模型权重并未改变；但一份精心设计的提示词能把模型已有的能力充分激发出来，这需要专家多年隐性知识与直觉释放模型能力的天花板。模型单次推理深度有限，也需要基于专家经验，把复杂问题切成可管理的子部分，并尽可能的完善公司内部各个系统的数据打通串联。与此同时，评测体系必须同步建立：AI + 稳定性的能力是个螺旋上升的过程，传统程序只耗时间，AI 还耗 Token，烧钱速度倒逼我们把评估做得像上下文工程一样严谨。

回到最初的问题：AI 会不会把人替代？我倾向听听“祖师爷”的声音。Linus Torvalds 被问到“是否已有 LLM 代码未经请求就提交给你”时，回答干脆：“肯定发生了，而且规模还会扩大。”在他看来，工具演进从未停歇：机器码 → 汇编 → C → Rust，如今只是又多了一层 AI。代码审查与维护同样如此，Linus 希望 AI 能先帮他抓“那些显而易见的蠢 bug”，毕竟连他自己也免不了犯低级错误。

面对主持人试图把话题引向“AI 会取代程序员”的负面预设，Linus 并未接茬，反而强调：自动化工具历来只是人类能力的延伸，从机器码到汇编再到高级语言，每一次演进都让开发者走得更远；AI 也不例外——真正决定价值的，始终是我们如何驾驭它。

当下 AI 话题很热，越在热潮越要冷静。我们认为，体力型的排障动作终将被自动化，但人类需要更高阶的能力：提出正确问题、识别模型幻觉、在恰当时机介入。俗话说 AI 一天人间一年，AI 发展非常快，伴随着模型能力的提升，我们也会把流程从 “human-in-the-loop” 向 “human-on-the-loop” 延伸发展。面向 AI Native 时代，一切才刚刚起航。

演讲嘉宾介绍

李锐，快手移动端稳定性负责人。2019 年加入快手，主导了发版拦截、监控报警、排障工具、止损工具、应急处置多个领域的建设，现为移动端稳定性方向负责人。个人擅长移动操作系统、虚拟机、编译器等底层基础技术，现在探索 AI+ 性能稳定性方向，KOOM 开源项目作者。

AI 2.0 时代的大模型推理：从模型到硬件的协同优化

Kitty — Mon, 16 Mar 2026 09:26:48 GMT

演讲嘉宾｜曾书霖博士策划｜QCon 全球软件开发大会

AI 2.0 模型对算力和数据的需求激增，导致硬件系统的能耗开销逐渐“供不应求”，亟需软硬协同为 AI 行业提供高质量的 AI 系统能效（ Tokens/J）。本文整理自无问芯穹总经理曾书霖博士在 2025 年 QCon 全球软件开发大会（上海站）的演讲 “AI 2.0 时代的大模型推理：从模型到硬件的协同优化"”。他介绍了软硬件协同优化以提升智能系统能效的研究成果，包括模型稀疏量化压缩、高效推理系统设计与大模型加速器设计。并且结合华为昇腾集群的工程实践，探讨下一代 AI 推理系统的演进趋势。

预告：将于 4 月 16 - 18 召开的 QCon 北京站设计了「AI 原生基础设施"」专题，本专题重点交流探讨如何构建AI原生基础设施，包括业界容器 / Serverless 等云原生基础设施如何朝 AI 演进，以及如何利用一些新兴分布式技术构建 AI 原生基础设施等等。敬请关注"。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

各位好，今天我想和大家介绍一下我们无问芯穹在大模型时代围绕大模型推理所开展的一些实践工作，以及我们观察到的一些趋势。我将主要从云和端两个维度展开，并结合我们在华为昇腾集群上进行优化的实践经验进行分享。

在开始之前，我想先简要回顾一下大的背景。我们相信，大家聚集在这里交流今天的工程实践，是因为我们都认同我们正处于一个非常重要的时间节点。通过人工智能，尤其是大模型技术，我们有望对整个产业进行深刻的变革。在大模型时代，最核心的工具是一套大模型算法以及底层的算力芯片，它们共同实现新的劳动价值创造。而我们最核心的任务是通过软硬协同，将上层的算法与底层的芯片通过中间的模型推理软件栈连接起来，以此作为放大 AI 产业价值的关键。这涉及如何在各种芯片和算力集群上进行有效的资源调度，以及如何优化模型在芯片上的推理过程，包括模型压缩、图算融合以及云和端的协同。接下来，我将分别从云和端两个维度详细介绍我们所开展的工作。

以智能革命，引领大模型推理范式变革

快速回顾一下过去十年 AI 发展的一些重要节点。相信各位对大模型的典型发展趋势也十分熟悉，无论是在国内还是国外。推动这些模型不断演进、不断涌现出新的创意结构的核心因素，其实是底层坚实的 AI 基础设施，包括芯片的演进以及整个推理基础设施的演进。

从发展历程来看，2022 年大家还在关注如何制定一个良好的预训练方案。随后，通过 Post-Training 使模型能够更好地适应各种垂直领域以及与人类思维方式对齐。如今，我们已经进入了一个新的阶段，即推理的规模拓展阶段。这一阶段的关键是如何将更优质的模型应用于各种垂直领域场景，以及在长文本和更大规模的推理服务中进行拓展，从而真正实现不同行业的落地应用。

在这一过程中，我们观察到一些重要的趋势。首先是推理范式的变化。从最初的逐 Token 推理，到现在基于 Agent 和强化学习的引入，推理计算需求发生了显著变化。从最初的几倍增长，到现在由于引入了长上下文推理等因素，算力需求已经增长了 10 到 100 倍。这对于从事基础设施建设，尤其是推理优化的我们来说，无疑带来了更大的挑战。

我们探讨模型推理，从产业界的角度来看，未来对算力的需求正逐渐从训练转向推理。今年年初，在 NVIDIA 的 GTC 大会上，黄仁勋也提到，未来我们需要更大规模的集群来支撑大模型在各行业的落地。集群规模越大，优化空间越高，由此带来的企业收益或 AI 应用的效益也会越大。然而，这一切都离不开一套强大的 AI 推理基础设施的支撑。

接下来，我将从几个方面展开分析。首先，我们来看优化的对象。端侧包括手机、PC 等小型设备，而云侧则涵盖一体机和数据中心的集群。我们对应用及其理论性能进行了分析。从端侧来看，现有的手机或 PC 设备在运行本地 3B 或 7B 模型时，推理性能大致在每秒 10 到 20 个 Token 左右，基本能满足正常对话需求。但如今，人们不再满足于单纯的对话，还希望 AI 能处理更复杂的任务，如日程规划、屏幕内容分析等。这些任务所需的 Token 量，随着 Test-Time Scaling 和多模态的发展，相比现有能力存在 1 到 2 个量级的差距。如何弥补这一差距，是端侧需要思考的问题。而在云侧，无论是单台机器还是大规模集群，核心都是要充分释放芯片、存储和互联的能力，尽可能用满集群的算力资源。目前，一些运行 DeepSeek 的推理系统，其实际性能与理论值仍有 2 到 3 倍的差距，这需要我们从基础设施层面去提高利用率，挖掘芯片的每一分潜力。

从实际应用场景来看，端侧和云侧各有特点。端侧主要针对单用户、少请求场景，需要将单个模型、单个用户请求的性能优化到极致。这是一个资源受限的场景，手机和 PC 的功耗、芯片算力、存储和带宽都是有限的。如何选择合适的模型，使其与芯片协同，满足端侧需求，是一个关键问题。云侧则从基础设施角度出发，要考虑多用户、资源抢占以及不同用户上下文、模型和 Agent 场景的差异。这种差异化的访问请求，为云侧优化提供了更大的空间，也带来了不同的优化目标和约束条件。

这些场景背后都绕不开几个核心挑战。如何提升计算利用率，以及如何充分利用存储资源，无论是在笔记本还是集群中，都是关键问题。最近两个月，内存价格几乎翻了一倍，HBM、DRAM 等供应商也在控制产能。随着模型规模增大、上下文变长，存储挑战将越来越大。在端侧，我们还要关注 SOC 的异构调度，包括 CPU、GPU 和 NPU。而在云侧，要在保证每个用户的 SLO 以及低延迟和高吞吐量的前提下，尽可能用满整个集群的资源。

以弹性算力集群，驱动云侧智能升级

我们先回顾一下在云侧进行大模型推理所面临的基本挑战，这些挑战主要集中在计算、存储和调度三个维度。

在计算方面，模型推理中的 Prefill（填充）和 Decode（解码）阶段本身就存在较大差异。Prefill 更倾向于计算密集型任务，而 Decode 则更偏向于访存密集型任务。在存储方面，尽管人们可能天然认为云侧的存储资源是充足的，但我们发现，许多端云推理引擎都存在存储利用率低的问题。这主要是由于 Prefill 和 Decode 对显存的占用不同，以及多用户之间的碎片化导致的。此外，在云侧，调度问题也是不可避免的，包括如何进行虚拟化、如何实现多用户的性能隔离，同时还要尽可能提升资源利用率。这些就是目前我们在云侧大模型推理中所面临的一些挑战。

从 2022 年大模型出现以来，无论是产业界还是学术界，都有一些代表性的工作，从计算、存储、调度等多个不同维度对大模型在云侧的推理服务进行了针对性的优化。今天，我将重点介绍其中一项工作，即围绕 Prefill 和 Decode 分离（P/D 分离）的优化实践。

最初，在进行大模型推理时，我们通常会将 Prefill 和 Decode 请求都放在同一张 GPU 卡或一个 GPU 节点内。在这种情况下，它们需要共享 GPU 的计算资源，同时它们的权重、激活值以及 KV Cache 都存储在 GPU 的 HBM 中。这种融合式场景在早期被广泛采用，包括 Kimi 和 DeepSeek 等项目，都是在 P/D 分离的基础上进行大模型推理的实践。P/D 分离的简单逻辑是将 Prefill 实例和 Decode 实例进行分解，将 Prefill 实例部署在一些算力较高的 GPU 集群上，而将 Decode 实例部署在另一些存储容量大、带宽高的 GPU 集群上。例如，对于 Prefill 实例，我们可以选择算力更强的 GPU 集群；而对于 Decode 实例，我们可以选择像 H20 这样算力稍小但 HBM 容量和带宽较大的集群进行部署。这种方案目前在业界较为常见。

我们分析一下这两种方案各自的优劣势。对于融合式推理方案，它首先面临的是我们在云上进行推理时不可避免的问题，即资源冲突和资源抢占。Prefill 和 Decode 请求本身对计算和存储的需求就不一致。我们之前提到，Prefill 是一个算力密集型任务，而 Decode 是一个访存密集型任务。将它们都放在同一张 GPU 卡或一个节点上，自然会面临由于需求不同导致的延时干扰和计算资源分配不均的问题。在这种情况下，想要对它们进行细粒度的调控是非常困难的。然而，这种融合式方案也有它的优势，即将存储融合在一起，无需进行 KV Cache 之间的传输，相应地，存储管理的实现会更加简单。

再来看 P/D 分离的方式，它的核心优势在于解决了融合式方案中 Prefill 和 Decode 计算资源抢占的问题。将 Prefill 和 Decode 拆开后，可以根据它们各自对计算和存储的需求进行针对性的管理。如果 Prefill 实例对计算的要求比较一致，它们的行为和模式就更容易预测，因此在资源调度上可以采用更粗粒度、更可预测的方式进行管理，Decode 实例也是如此。此外，P/D 分离还可以更好地进行资源配比。然而，这种方式也引入了一些新的问题。首先，它对存储的开销和切换会带来额外的挑战。例如，P/D 分离后，P 实例和 D 实例之间的 KV Cache 存储非常不均衡。在 P 实例上，可能只有 23% 的存储用于 KV Cache，而在 Decode 实例上，可能有 70% 的存储开销都用于存储 KV Cache。这就导致 P 实例和 D 实例之间需要频繁进行 KV Cache 的传输，这就要求 GPU 之间以及节点之间的互联带宽需要更大，同时需要对通信库进行更底层的优化支持。此外，由于 P 实例和 D 实例之间存储的不均衡，在进行内存管理时，P 实例上可能会出现显存浪费的情况。例如，除了存储权重和 KV Cache 之外，可能有 30% 到 40% 的显存无法被充分利用，这些未被利用的显存会导致整个集群出现显存浪费的问题。由于显存成本较高，这种浪费会显著增加整个推理系统的成本。

如何将两者的优点结合起来，同时避免它们的不足。基于上述分析，我们提出了一个名为“P/D 半分离”的方式。在计算层面，我们对 Prefill 和 Decode 进行隔离，而在存储层面则进行融合。我们希望既能享受计算隔离带来的优势，又能减少存储融合导致的 KV Cache 传输开销。

在 P/D 半分离的整体架构中，首先从计算层面来看，我们希望对 Prefill 和 Decode 进行分离。这种分离借鉴了云计算领域常用的虚拟化技术。早在 20 年云游戏兴起时，就涉及如何在 GPU 的 SM 或其他计算单元上对不同游戏实例进行隔离式切分，当时采用了多种进程间虚拟化和隔离技术。类似地，在大模型出现之前，许多 AI 推理服务也在进程维度对多个任务进行隔离和虚拟化。因此，我们同样以进程间的方式对 Prefill 和 Decode 实例进行隔离，并按照 SM 的粒度对资源进行分配。这样做的好处是可以实现细粒度的资源管控，同时尽可能确保 P 实例和 D 实例之间有较好的分离。

在存储维度，我们主要针对 Prefill 和 Decode 的不同需求进行了针对性优化。之前的主要问题是，如果将它们融合，由于 Prefill 和 Decode 对显存的需求是动态的，核心逻辑是尽可能高效地利用显存。这就需要了解当前显存的使用情况以及任务所需的显存量。具体来说，分为三个步骤：第一步是分析当前显存的使用情况；第二步是确定当前是 Prefill 还是 Decode，以及该任务所需的显存量；第三步是对显存空间进行资源申请。如果将 Prefill 和 Decode 放在一起运行，它们之间可能会出现读后写依赖，以及细粒度访存请求互相干扰的问题。因此，我们首先将 Prefill 和 Decode 的细粒度内存访问融合成一个大的原子操作，然后在这个原子操作上对 Prefill 和 Decode 分别进行管理。这样做的好处是，融合后 Prefill 和 Decode 之间不会出现读后写依赖冲突，同时也能更好地管理显存碎片化。

在资源分配方面，我们举了一个例子。在优化前，我们可能给 Prefill 分配了约 2/3 的资源，给 Decode 分配了 60% 的资源。但如果在下一时刻我们认为应该给 Prefill 分配更多资源，由于这两个进程本身获得的资源不同，理论上需要重新加载和拷贝 KV Cache、上下文等参数，这会产生额外的资源调整开销。于是，我们想到引入一个常驻进程来管理 KV Cache 和模型权重的加载。这样，原有的 Prefill 和 Decode 进程可以预先依托常驻进程进行资源加载，无需引入额外的拷贝开销，从而减少 KV Cache 和资源分配方面的问题。

除了前面提到的方案，我们在实际生产环境中，也针对实例推理以及集群规模的 P/D 融合方式进行了支持。在实例级别，我们主要关注一台或两台 8 卡、16 卡的服务器规模。在这种情况下，Prefill 实例和 Decode 实例分别进行通信，且 Prefill 和 Decode 之间采用异步方式，这样可以更好地进行管理，并减少同步开销。

在集群规模方面，我们主要与现有的框架，包括 Kimi 开源的一些 P/D 分离框架进行融合。你可以选择直接使用现有的 Prefill 和 Decode 实例，也可以使用我们这种半分离的实例。核心目标是打开整个集群规模的优化空间，从而在上面进行更精细化的优化空间探索，找到一些更好的设计点。

与 SGLang 相比，我们的吞吐率提升了 10%，延时降低了两倍。同时，我们的 TTFT 和 ITL 的整体延时都得到了显著优化。从完成率曲线可以看出，与 SGLang 相比，我们在实际线上业务中完成请求的占比提升明显快于 SGLang 的结果。

面向华为昇腾的推理优化部署实践

最近，我们在华为昇腾平台，特别是其 910B 的 384 超节点上，进行了一些探索。这些探索主要集中在百卡到千卡规模的集群推理实践上。在开始之前，我们首先进一步分析了为什么需要超节点，以及华为开发超节点背后的逻辑。从下图左边可以看到，OpenAI 提出了从 L1 到 L5 的演进趋势，横轴代表智能水平。理论上，从 L1 到 L5，模型的智能水平应该越来越强。我们经过分析发现，要支撑这种智能水平的演进，整个推理的能效，即 Token/J，也需要持续迭代。我们之前介绍的实例推理主要围绕 L1 到 L2，或接近 L3 的部分。但未来，如果要支持多智能体、超大的 MoE，就需要更强的系统能力。

从右边的趋势可以看出，首先，模型规模越来越大。DeepSeek、Llama、Kimi 等模型从千亿规模演进到万亿规模，这意味着原来的实例推理已经无法满足需求，需要更大的模型来提供支持。其次，目前大家都有意识地向 MoE 的超稀疏多专家方向发展，且专家数量越来越多。例如，DeepSeek 有 256 个专家，而 Kimi 有 384 个专家。这种多专家的变化与超节点多卡的方式天然契合，便于进行大规模 EP（Expert Parallelism，专家并行）部署。此外，超长上下文也是一个趋势。现在，上下文长度已经从 8K、50K 发展到 128K，甚至更长。

接下来，我们来看在昇腾平台上部署会面临哪些问题。最近，昇腾的许多团队围绕 910B 和 920C 进行了一些具体的实践，这是一个令人欣喜的过程。从最初的实例推理到现在的集群推理，性能有了量级的提升。然而，从“能用”到“好用”之间仍存在差距。这个差距主要体现在两个方面：一方面，模型的上下文越来越长，这带来了计算、存储和通信的匹配问题；另一方面，华为的昇腾架构是一个 NPU 架构，其算子生态需要整个行业共同迭代。这自然会面临开源社区和整个软件栈迭代的问题。未来，模型肯定会逐步演进，如何将模型与集群更好地匹配起来，也是一个亟待解决的问题。

在这里，我想和大家分享一些我们在超节点上以及结合未来模型发展所遇到的挑战。首先是长文本问题。长文本的需求在 Agent 以及未来的具身智能等领域肯定会不断增加。长文本的核心特点是对 KV Cache 的占用会越来越大。如果文本较短，实例推理或许还能应对，最多支持 4K 到 8K 的上下文。但如果要支持 128K，甚至未来是 512K 以及更长的上下文，现有的实例推理显存显然已经无法满足需求。因此，自然而然地需要从实例推理转向集群推理，以获得更大的存储池来支持 KV Cache 的存储。

这自然带来了另一个问题：如何解决 KV Cache 之间的传输挑战。从计算层面来看，上下文越长，对应的 KV Cache 以及在 Prefill 阶段进行 Attention 计算时的计算需求也会越大。因为 Attention 计算本身是随着上下文长度呈二次方增长的，这就必然涉及到 MLA 以及 MoE 算子的计算优化问题。在通信层面，KV Cache 越来越大，必然会带来更多的通信和同步开销。过去，我们更多关注的是实例推理中的 TP（张量并行）并行。但现在，我们可能需要从张量并行切换到序列并行，甚至融合序列并行和专家并行的方式，来解决计算和通信开销问题。从框架层面来看，过去我们主要关注如何在 P 实例和 D 实例之间进行调度。但如今，超节点本身是一个融合方案，超节点与超节点之间如何协同支持，以及未来如何将不同模型部署到不同的超节点上，这都是框架层面需要考虑的模型适配问题。

在对昇腾架构的探索中，我们重点关注了计算层面的优化问题，尤其是与长文本处理和集群推理相关的挑战。首先，从计算层面来看，随着模型上下文长度的增加，注意力机制（Attention）的算力需求显著增大。这不仅体现在对张量核心（Tensor Core）的计算需求上，还体现在对标量计算的需求上。在昇腾架构中，标量计算单元（Scalar Unit）和向量计算单元（Vector Unit）的算力与矩阵计算单元（Cube Unit）存在较大差距。我们通过分析发现，随着上下文长度的增加，标量和向量计算的时间占比可能会从 10% 飙升到 30% 至 40%。这种非张量计算带来的瓶颈需要从芯片层面进行针对性优化。

针对长上下文导致的 KV Cache 存储不均问题，这与之前提到的 P/D 分离优化类似，但面向的是超节点内 NPU 和 NPU 之间，甚至是 GPU 和 GPU 之间的部署问题。在长上下文和云端推理场景中，计算力需求与存储需求的绑定因素不同。算力需求与请求数（batch size）紧密相关，而存储需求则与上下文长度相关。这种不一致性导致在集群推理和云端推理场景中，需要考虑的因素更多，且它们之间的相互影响也更为复杂。

资源匹配问题也是一个关键挑战。例如，在 384 超节点上部署 DeepSeek 模型时，由于模型的专家权重数量（320）与超节点数量（384）无法整除，导致部分 NPU 或 GPU 资源浪费。这表明 384 超节点在设计时可能并未完全针对特定模型进行优化，未来新模型的出现将进一步加剧这一问题。

针对这些问题，我们与清华大学和上海交通大学的团队进行了探索，并针对一些关键算子进行了底层优化。这些优化包括 L2、L1、L0 缓存之间的数据搬运和复用策略，以及基于昇腾 CCE 的底层支持。最近，我们还发表了一篇论文《FlashOverlap》，提出了针对昇腾架构的细粒度计算和通信流水优化方法，感兴趣的朋友可以查阅。

总结来说，我们认为集群推理其实是一个更为复杂的优化问题。在进行 AI 推理优化时，本质上我们都在做各种各样的多目标优化。我们既希望延时低，又希望吞吐量高，还希望资源利用率强，并且能够尽可能地服务更多用户。然而，在这个过程中，我们需要考虑诸多因素，包括模型的类型、规模，芯片的算力构成，可用的带宽、显存，以及整个节点的规模和节点之间的互联带宽等。我们一直强调软硬协同，其本质便是在这样一个庞大的优化空间里，尝试对计算、通信以及框架等资源配比进行合理的映射和优化搜索。所以，我觉得这个领域是需要持续进行技术攻关的，而我们目前也正在不断地探索，从计算到框架再到通信层面，我们都在持续地进行尝试。

以有限算力架构，释放终端应用潜能

在一些资源受限的芯片上，比如手机、PC 上，我们还能做哪些工作呢？大的背景是，我们坚信未来大模型将在更广泛的智能终端设备上落地，包括大家手里的手机、笔记本电脑，以及现在比较火的机器人，还有各种新形态的终端，这些都将是未来重要的智能入口。这个智能入口不仅会影响到云侧的配合，也会涉及到端侧有一个更懂你的智能体来帮你处理越来越多的事情。所以，这块带来的想象空间是越来越大的。结合现在比较火的具身智能，不管是自动驾驶、无人机还是机器人的场景，其实对 Token 的需求还是很大的，至少是在 100 到 1000 个 Token 这个量级。那么，如何用一个比较好的芯片和基础设施去支撑这样大的 Token 需求，至少在端侧这个场景是一个需要解决的问题。

在端侧，我们也是从计算、存储、通信这几个方面做了一些分析，包括在 GPU 和 CPU 上的一些优化。这可能涉及到在 SOC 上，能否把上面的 NPU 也利用起来。因为端侧本身就是一个存储非常有限的设备，所以如何把一个很大的模型进行蒸馏、压缩，压缩完以后是否还能满足需求，以及是否能在有限的空间里用计算去换存储的方式做一些优化。

目前业界的优化也分为几类。一类是做一些投机解码等技术，本质上是因为端侧存储比较贵，而算力相对来说有一些富余。因为在端侧，你不需要跑很大的 batch size，一般都是单 batch 和单用户的推理，所以大部分情况下计算是有富余的。那么，多出来的计算就可以用来换取存储。所以，现在所有的投机解码方式都是在做这块的事情。另一类是模型压缩，不管是做稀疏量化还是蒸馏，都是为了让模型在保持智能水平的情况下变得越来越小。其实，包括 MIT 和我们团队之前都做了很多这种压缩的工作。还有一类是端侧本身是一个 SOC 平台，那如何在上面做一些协同优化，也是一个重要的方向。

我们团队最近开展了一项工作，这是一个典型的软硬件协同优化方案。我们的思路是从投机采样等技术入手，从模型和软件两个层面进行探索。简单来说，正常情况下，模型推理包含多个层级。之前有早退技术的概念，即无需完成所有层级的计算就能输出结果。例如，一个 32 层的模型，可能在计算到第 31 层时，结果的概率就已经接近阈值，可以提前结束。但关键问题在于，何时应该结束？这需要一个判断过程。如果将这个判断过程建模，实际上是在一个上万规模的词表中进行搜索分类。对于典型的大模型，词表通常是万级的，比如一个 3 万词表，这样的搜索开销非常大。我们希望在享受早退技术带来的计算和存储开销减少优势的同时，尽量使其可用，否则每次都要搜索一遍，可能会带来不可接受的开销。

核心问题在于如何构建一个中间预测模型，以缩短在线搜索的开销。比如在某一层判断是否可以结束时，能够通过一个小的推测模型，在极低开销下进行判断。这个推测模型会根据输入，将原本庞大的词表缩减为一个非常小的词表。因为在对话场景中，下一个词相对比较确定，本质上不需要在大词表中搜索。理论上，可以提前训练一个小模型，让它知道在什么范围内找到这个词，然后在这个小词表下进行搜索，从而尽可能降低开销。

如何以低开销、高精度的方式进行这种级联计算。由于我们本质上是在做软硬件协同优化，修改算法不可避免地会引入一些开销。因此，如果预测错误，就需要一些在线修正机制。我们在这方面也做了一些工程优化，以确保预测错误时能够快速修正，从而保证精度不受损失。此外，针对频繁调度的开销问题，我们在端侧开发了一个调度引擎，用于记录早退的位置，并提前存储早退的概率，结合离线调度和在线调度，优化整体的调度效率。

从结果来看，下图黄色部分是基于一些稀疏化的优化，绿色部分是量化优化。我们可以看到，通过软硬件协同的方式，在保证精度的同时提升了速度，使性能尽可能向右上角提升。在实际部署中，我们在联想的 AI PC 上进行了部署，端到端的性能大约提升了两倍。

以大模型推理技术创新，融合人工智能产业创新

我们与各位探讨了在云和端侧部署大模型时面临的效率挑战。我们的核心目标是无论在云端还是端侧设备上，都能充分利用大模型的优势，同时尽可能降低对硬件资源的需求，并满足用户对推理服务质量的要求。一直以来，我们致力于将推理系统部署到云端，推动整个产业链的运转。因为，尽管从事基础设施和技术工作的人员主要关注 Token 的性能，但仅靠 Token 性能是不够的。我们还需要让足够多的应用企业参与进来，形成产业闭环。只有当大家广泛使用大模型，探索其在各行业的应用，并在 Token 量大幅提升后，才能有足够的需求推动基础设施的发展。我认为这是一个良好的正向循环。在端侧，我们则与联想等企业以及各种端设备进行了探索，希望未来无论是 AI PC、AI 手机，还是其他终端设备，都能为用户带来使用体验上的变革。

我们认为未来端和云并非解耦的，而是需要协同支撑的。在相当长的一段时间里，端和云将相互补充、共同存在。在端侧，我们可以部署 3B、7B 或 13B 左右的模型，用于本地化处理和个人个性化助理功能。这些模型能够了解用户的想法，帮助管理个人日程，并分析个性化需求。由于涉及隐私性要求，这些功能需要在本地实现。而当用户需要处理更复杂的任务时，端侧设备可以调用云端的 Agent 和更强大的模型，为用户提供辅助支持。我们相信，在未来很长一段时间里，需要探索出一个云与端协同的框架，以确保大模型在各行业的更好落地。

我们的愿景是，就像 30 年前水电走进千家万户一样，如今我们希望通过端云协同和更高效的基础设施，与上下游通力合作将大模型的成本降低万倍，使其普及到更多领域。

演讲嘉宾介绍

曾书霖，无问芯穹总经理，于 2018 年和 2023 年在清华大学电子工程系获得工学学士和博士学位，师从清华大学电子工程系教授、IEEE Fellow 汪玉，研究领域为软硬协同优化研究和 AI 加速器设计。在相关领域发表高水平国际会议和期刊论文 20 余篇，谷歌学术施引九百余次，包括以第一作者或共同一作发表高水平论文于可重构计算领域旗舰会议（ FPGA · 25, FPGA · 24）、体系结构领域顶级会议 (HPCA · 25, MICRO · 23)、以及顶级期刊 IEEE TC、ACM TRETS 等。曾获 FPGA 2025 会议最佳论文奖（ FPGA 会议首次将该奖项授予完全由中国大陆科研团队主导的研究工作，也是亚太国家团队首次获此殊荣）、IEEE TC 2023 Featured Paper of the Month、清华大学研究生国家奖学金等。在创新创业方面，作为创始成员参与创立上海无问芯穹智能科技有限公司，并作为智能终端业务负责人，带领团队打造“端模型 + 端软件 + 端 IP ”的智能终端一体化解决方案。

AI 领导力：像管理团队一样管理 AI

Kitty — Mon, 16 Mar 2026 09:16:54 GMT

演讲嘉宾｜揭光发策划｜QCon 全球软件开发大会

在 AI 浪潮席卷各行各业的当下，我们正经历一场前所未有的“原地升级”：AI 并非取代岗位，而是要求所有从业者，特别是身居管理和架构岗位的领导者，重新审视并升级其领导力范式。本文整理自腾讯专家工程师揭光发在 2025 年 QCon 全球软件开发大会（上海站）的演讲 “AI 领导力：像管理团队一样管理 AI"”。他深入介绍了如何以更高效的方式管理 AI，如同管理一支高效的团队。

预告：将于 4 月 16 - 18 召开的 QCon 北京站设计了「AI 时代的“超级团队”"」专题，本专题不谈模型技术本身，只谈人与组织的进化。我们将揭秘小团队创造大价值的逻辑，探讨如何弥补人与 AI 的能力鸿沟，重构产品与技术的协作关系，并建立一套适应 AI 时代的全新管理与度量体系，打造高适应性、高产出的“超级团队”。如果你也有相关方向案例想要分享，欢迎提交"。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

我们深知，对于架构师和高管而言，管理团队、协调资源、驱动项目是日常核心。然而，传统的人力管理往往伴随着反馈延迟、过程不可控等挑战。奇妙的是，“管理 AI ”恰能解决这一悖论。AI 的即时反馈和高可控性，不仅能带来巨大的管理杠杆效应，更提供了一种前所未有的高效管理模式，让领导者能够以更精准、更可控的方式，驱动“数字员工”完成目标，重拾作为“指挥官”的掌控感和成就感。为实现这一目标，我们将探讨“ AI 领导力”的四大核心支柱。这包括像管理团队一样知人善任地组建 AI 队伍，高层级地设定目标，以及战略性地管理过程和专家级地验收成果。AI 不会削弱技术领导者的价值，反而会将其无限放大。未来的优秀技术领导者，将是那些能够高效管理和编排人机混合团队，共同交付卓越成果的“超级指挥官”。

今年年初 3 月，Manus 发布时，我便广泛提及一个观点：如今我们使用 AI，已不再将其仅仅视为工具，而是实实在在地将其当作能帮我们干活的人来使用。尽管 AI 本身没有情绪，但管理人时所涉及的诸多要点，在管理 AI 时也一个都不能少，这是我今天想要表达的核心内容。

Vibe Coding ——"心流"在编码中重现

首先，我们来谈谈 Vibe Coding。对于从事技术工作，尤其是担任技术领导的人员来说，这是与 AI 直接相关且能显著提升工作效率的领域。使用 AI 来编写代码，如今已司空见惯，且在近一两年成为主流趋势。我稍后会举例说明，但可以说，我所编写的代码中，AI 的参与度几乎达到了 100%。

Vibe Coding 的概念其实无需过多解释。它主要是通过自然语言描述需求，然后让 AI Agent 来实现代码编写、测试并运行。在这个过程中，你无需过多关注代码的具体实现细节，只需不断提供反馈，指出“这里还不行”，并告知下一步该怎么做。最终，通过与 AI 的协作，完成整个软件的交付，这就是 Vibe Coding。这实际上是 AI 与工程师，乃至技术领导日常工作中频繁涉及的一项活动。

介绍一下自己在 Vibe Coding 方面的经历。2022 年 ChatGPT 发布后，我们发现除了与它对话聊天、观看它写代码外，还能有更多应用。2023 年早期，我们开始在 ChatGPT 网页上与其交流，让它编写一些代码片段。当时大家开始觉得，AI 在这一波的发展中确实表现不错。然而，真正大规模将 AI 应用于生产环节，是在 2023 年底 GitHub Copilot 插件推出之后。那时，我所编写的代码中，AI 的含量已经达到了 85%。说白了，2023 年 3 月我重新开始写代码，是因为我可以借助 AI 实现想法，而无需亲自编写代码。这使得许多小型项目，尤其是工具类技术产品，开始通过 AI 逐渐诞生。到了去年 9 月，Cursor 出现后，我更加放开手脚，真正以 Agent 的方式编写代码，直至今日。如今，Claude Code 等各种智能代码代理层出不穷，多到两只手都数不过来。对我个人而言，目前几乎 100% 的代码都是由 AI 编写的，除非我发现某行代码可以删除以节省 Token，否则我不会亲自编写。

在我的带动下，我的团队也积极投身于 AI Coding。目前，团队中大约 50% 的代码由 AI 编写。之所以没有达到 100%，原因有两方面。一方面，对于一些前端项目，AI 还原度并不高。因为视觉模型与文本模型之间存在天然的差距，目前尚未得到很好的解决，视觉还原能力这一块还存在不足，所以这部分工作仍需人工参与。另一方面，有些团队成员不想让 AI 完全包办所有工作，他们希望保留一定的掌控感。他们会编写大致的框架，然后让 AI 填充细节。这样一来，如果出现问题或故障，他们可以迅速自行修复，而无需再次求助于 AI。这种主动降低 AI 含量的做法，导致团队中并非所有人都能达到 100% 的 AI 含量。

在我们团队所在的公司，有一个名为 loki 的低代码项目。2023 年，我带领团队搭建了一个跨语言的逻辑编排平台，其中涵盖了前端和后端三种语言的运行时环境，分别是 Golang、Python 和 Node.js。这个项目是我 2023 年开始重新编写代码时着手的，当时有一两名同事在闲暇时间参与其中。此外，我们还在内部使用了一个 AI Agent 低代码搭建平台，这可能和 Coze 或 Dify 同期或更早，大约在 2023 年中后期到 2024 年早期，我就开始着手这个项目。当时我发现 AI Agent 即将兴起，并且会有广泛的应用，于是开始带领刚加入团队的实习生同学一起推进。在这个项目中，大部分后端代码是在我的指导下由 AI 编写的，其中 95% 以上的代码都由 AI 生成。但我必须强调，尽管 AI 完成了大部分代码编写工作，但这并不意味着我没有投入精力，稍后我会详细说明这一点。

最近的一个案例是大型前端组件的重构迁移项目，我们将一个大型项目从 Angular 迁移到 React。大家都知道，Angular 在国内并不算特别流行，而且技术栈相对有些过时了。迁移过程中，我们需要深入理解原有代码的逻辑，并进行大量测试以确保迁移的准确性。我们通过 AI 的方式来进行迁移，具体逻辑是：先在旧的组件代码中编写单元测试，完成单元测试后，将旧代码转换为新的组件代码，并同步迁移单元测试。但这还不够，我们还利用线上大量的数据（几十万条）作为回测数据进行测试。整个过程中，从代码翻译、测试编写到测试运行，包括测试数据验证脚本的编写，几乎都由 AI 完成。原本可能需要一两个人花费半年以上时间完成的工作，我们通过 AI 协作压缩到了一到两个月。当然，在这个过程中，我们也会进行人工抽查，以确保迁移的准确性。

我想引入一个名为“心流”的概念。有一天，我和朋友聊天时提到，我很久没有体验到一种感觉了，但最近这种感觉又回来了——那就是我找到了心流。我想每位程序员都曾有过这样的体验：戴着耳机，全神贯注地敲代码，不知不觉一个上午就过去了。在那个过程中，你沉浸于代码世界，无人打扰，从编写代码到测试、运行，再到不断调试，整个过程掌控感极强，时间也在不知不觉中流逝，这就是心流状态。其实，所有创作者都会经历这种状态。但为什么我很久没有体验到这种感觉，却又突然找回了呢？成为团队领导后，你会发现管理团队和编写代码是两件完全不同的事情。当你安排团队成员去做一件事时，你需要等待他们的反馈，这个过程往往漫长，中间还会有许多会议和沟通协调，整个流程并不顺畅。因此，成为领导后，我在很长一段时间内都失去了这种心流的感觉。然而，通过 Vibe Coding，这种感觉又回来了。原本可能需要十多天才能完成的项目，现在通过 AI 协作，我下达指令后，可能一两分钟就能得到初步结果，然后我继续给予反馈。这种反馈链条的闭环时间非常短，所以我又重新找回了那种在管理层面上的心流感觉。

在谈到 Vibe Coding 时，我们也不得不提及 Software 3.0，因为当我们说要与 AI 共事时，这里的 AI 几乎指的都是 Agent。而 Agent 的本质是一种软件形式。无论是 Software 3.0 还是 Vibe Coding，都与 Karpathy 提出的概念有关，所以在这里一并提及。那么，1.0、2.0、3.0 这三种范式是如何演进的呢？

1.0 时代，我们手动编写代码，经过编译后运行。代码中的逻辑是明确写好的。例如，要实现对一些词语的情感判定，我们会用 if-else 语句来编写逻辑：如果文本中包含“amazing”，就判定为褒义。

2.0 时代，出现了一种通过神经网络或机器学习训练出的小模型，比如一个纯视觉识别模型。这种模型不是通过编写代码实现的，而是通过数据训练得到的。对于情感判定，我们会用训练好的神经网络模型来预测词语的情感倾向。

到了 3.0 时代，我们所看到的是基于大语言模型的衍生程序，也就是 agent。以情感判定为例，我们直接给 Agent 一段话，用自然语言与它交互，请求它判断文本中单词的倾向。Agent 会直接给出大语言模型的判定结果。Software 3.0 的本质是智能体系统，以自然语言为接口，让 AI 能够理解人类意图并自主执行任务。

Vibe Working —"心流”延伸至所有工作

刚才我提到的主要是关于编程的内容，其实我们已经对它非常熟练了。现在我想进一步谈谈 Vibe Working，也就是“一切皆可 Vibe”的概念。如今，大家都在讨论 AI 如何渗透到各个领域，我也想分享一些我在其他方面与 AI 协同工作的例子。

比如制作幻灯片 Vibe Sliding。从今年开始，我再也不为准备 PPT 而焦虑了。过去，我总是拖延到最后一两天才开始制作幻灯片，因为虽然演讲的内容我早已了然于心，但排版、绘制图形、寻找图片并进行排版这些繁琐的工作让我感到头疼。我这份 PPT 完全是通过 AI 生成的，从风格上应该能看出来，理论上人工制作的 PPT 不会使用这么多颜色，但它的可读性依然不错，能够清晰地传达信息。整个 PPT 的制作过程就像编程一样，通过 AI 完成，包括插入的 logo 等元素也都是通过 AI 添加的。而且由于 PPT 本质上是一个网页，AI 在编写网页方面也早已驾轻就熟。现在，我再也无法回到手工制作 PPT 的时代了，基本上都是通过 AI 来完成这项工作。

还有 Vibe Writing，也就是写作助手。现在大家看到的许多文档或公众号内容，基本上都是通过 AI 流水线式生成的。尤其是今年，AI 可以通过多 Agent 的方式拆分不同章节，让不同的子 Agent 分别撰写不同章节，这让撰写大型文档变得轻而易举，甚至撰写论文、专利等也不在话下。我自己也用这种方式撰写产品文档、说明书，甚至 API 接口文档也都是通过 AI 完成的。

阅读论文曾经是一件痛苦的事，过去要读完一篇长篇 PDF 并理解其中的所有内容，需要花费大量精力。现在，我们通常让 AI 代读。对于长篇公众号文章或新发布的论文，我们首先会转发给 AI 工具，比如腾讯元宝公众号的机器人号，它会为你总结内容，这也是一个很好的 AI 使用案例。

还有一个有趣的应用场景，那就是学习新概念。比如我们学习大型语言模型的工作原理时，如果有动画可视化展示其关键动作，我们会更直观地理解。AI 在这方面可以大显身手，比如它可以为我生成动画，展示光速的测量方法，或者迈克尔逊干涉仪中不同颜色光条纹的影响。在学习层面，这让我能够与 AI 进行非常强的互动，生动地演示我想要了解的知识点。对我来说，我已经不需要再去翻阅厚重的书籍，而是直接向 AI 提问，它会为我提供答案。

再比如个人秘书，我也进行了多次迭代。最早的版本是基于 Gemini CLI，它几乎是免费的，可以记录我的日常工作、安排日程等，所有这些都可以通过命令行与它对话完成。这与我们常用的结构化 Todo List 完全不同，Todo List 需要你自己去查看和记录，而这种秘书更像是真正的秘书，它会为你搭建一套数据存储系统，但你需要提示它进行结构化存储。现在，我已经升级到了第二版，加入了 Claude Code 和其他模型，功能更加强大。我还把它与我的企业微信打通，比如今天我要做演讲，它会提前几天提醒我准备，甚至处理各种出差事宜。它就像一个真正的秘书，只是它并非人类。AI 在我的工作和生活中，除了编程之外，还能在许多方面作为我能力的延伸，帮我完成许多不同的任务。

Vibe Working 的核心在于人与 AI 的协同合作。我们需要清晰地描述自己的需求，然后将任务交给 AI 去执行。在这个过程中，AI 会根据我们的指令完成相应的工作，并将结果反馈给我们。

AI 领导力——新范式下的核心四要素

回顾过往，当我们并非领导者，而是专注于具体事务时，我们总是亲力亲为。例如编写代码，我们一行行地写，然后编译、运行、发布。那时，我们直接参与具体的工作。然而，当我们将这些任务交给 AI 去完成时，情况就发生了变化。我们不再直接动手，而是开始指导 AI 去完成这些任务。

指导 AI 的过程是怎样的呢？首先，我们需要为它设定明确的目标。但仅设定目标是不够的，我们还需要管理整个过程，指导 AI 如何行动，当它出现错误时，我们要纠正它。最终，当 AI 交付成果时，我们需要进行验收。如果验收结果不理想，那么就需要返工，重复之前的过程。这个过程，难道不像是与下属或队友沟通协作的过程吗？正是在这个过程中，我意识到，当我们开始使用 AI 时，我们其实已经从执行者变成了领导者。

你所领导的可能不是人，而是 AI。但本质上，这并没有太大区别。未来，大家会逐渐发现这一点。AI 在某些方面甚至比人类更好管理，因为它更加稳定，不会给你穿小鞋或闹情绪。但在一定程度上，管理 AI 的要求甚至比管理人更高。管理人时，你可以发脾气，施加压力，从而激励他们更好地完成任务。但对 AI 来说，如果你的指令不清晰，它就无法执行任务，而且它也不会反抗。因此，在一定程度上，管理 AI 可能比管理人更具挑战性。这实际上是沟通和认知传递能力的极致考验，也是个人素质的体现。

我们来定义一下 AI 领导力。刚刚我已经提到，我们需要设定目标、管理过程、验收结果。这其实也涉及到了“知人善任”的概念。不过，或许我们需要将其改为“知 AI 善任”。这四个关键要素可以概括为：设定目标、过程管理、结果验收以及知人（AI）善任。

首先就是知人善任，了解你的“队友”，选择合适的 AI 模型、工具和代理。如果现有的工具不适合，你可能需要打造或打磨出适合自己的工具。这其实是在开始之前，组建团队时需要考虑的事情。在人员管理中，我们讲求选、育、用、留，而在 AI 领域，选也是至关重要的第一步。

按照应用场景来划分，我们常用的场景主要有以下几种：通用的大语言模型、代码助手以及 AIGC 领域，包括图片、音频、视频生成等。我们需要在这些领域中寻找行业内的顶尖模型，当然，这需要结合自身实际情况，因为有些模型可能成本较高。我在这里仅列举了前两种场景的选型或比较案例，供大家参考。

在 AI 编程工具的选型方面，目前 Claude Code 是我的首选。除了编程之外，我之前提到的个人秘书以及 PPT 制作等 Agent 工具，也都是基于 Claude Code 构建的。它的优点在于非常简洁，其 Agent 也很简单。它的特点是将对话中的所有内容都作为上下文传回，这种“大力出奇迹”的方式使得它在处理上下文时表现得比其他工具更出色。例如 Cursor 等其他 IDE 需要进行上下文压缩，而 Claude Code 则不需要。我们了解背后的逻辑，但也不会直接使用它的 API 付费方式，而是选择它的套餐，比如 Pro 版本。不过，使用 Pro 版本很容易触发 Token 的上限。即使你选择了 20 美元的套餐，现在又增加了周上限，很容易就触发了。

Cursor 在国内进行了限制，但当然有一些技巧可以绕过。即使在自动模式下，它也可能为你提供更好的模型，因为它需要保证效果。所以在这方面，我并不太担心。不过，它的收费方式变成了不封顶，即 20 美元用完后会继续计费。但我一直保留着 20 美元 500 次的计费方式，坚持不切换。到现在我发现，它的调用限制已经从 20 次增加到 200 次了。所以对我来说，这也是一个非常充足且性价比高的方案。目前，我优先使用 Claude Code，而 Cursor 则作为备份。

腾讯的 CodeBuddy IDE，它的特色在于贯穿了从设计到开发再到发布的完整链路。尤其是与 Figma 的深度整合，使得在界面还原方面表现出色。我们团队也尝试使用过这一功能，与直接使用 Cursor 搭配 Figma 的 MCP 相比，差异十分明显，这一点值得大家关注。

接着是 V0.dev，这是 Vercel 团队的另一款产品，专注于 Web 开发。在 V0 上进行开发的速度非常快，这也是它名字的由来——“V0”意味着“version 0”，即快速搭建原型和 Demo。虽然它的定位是用于快速原型开发，但实际上，用它来开发正式产品发布也并无太大问题，毕竟它背后有 Vercel 强大的底层支持。

再来说说 Gemini，这款模型如今可以说是厚积薄发。无论是图片生成还是代码编写的能力，都呈现出越来越好的态势。特别是它的 CLI，个人注册后几乎等同于免费使用。每分钟限制 60 次调用，但一天有两三千次的调用额度，对于日常使用来说，几乎感受不到 API 调用的限制。

不得不提的是 GLM 4.6，在我的 Claude Code 20 美元额度受限之后，我基本都用它来作为替代。从产出效果来看，它能达到 Claude Code 大约 80% 的效果，这是我的个人体验。目前我也大量使用这个 4.6 版本，不过有一点遗憾，国内模型的视觉能力相对较弱，4.6 本身并不擅长视觉处理，而是通过 MCP 的方式支持视觉功能，这种方式比较绕。我还是希望国内能尽快推出像 Sonnet 那样的多模态模型。不过，GLM 4.6 的套餐性价比很高，但如果不定制套餐，Token 消耗会比较高。

Kimi K2 是我最近用的一个加速版，它的解题速度快，无论是在质量还是成本上都优于 GPT 5。而且 Vercel CEO 大赞 Kimi K2，他在 x 公开表示，在一项内部智能体真实场景基准测试中，来自中国的 Kimi K2 模型表现优于 GPT-5 和 Claude Sonnet 4.5。

最后是 DeepSeek 3.2，它的 Token 消耗非常低，价格也特别便宜。与 Kimi 或者 GLM 相比，我自己的感受是，使用 DeepSeek 的费用不到其他两者的 1/4，甚至更低。DeepSeek 3.2 引入了稀疏注意力机制，本身就将 Token 价格降低了 75%，而且它对 Agent 的支持也非常好。有一段时间我因为 Sonnet 额度不够，切换到 DeepSeek，用了很长时间才花一两块钱，这让我非常惊讶。我觉得很多公司在评估后，如果真的要用 API，最终可能会选择 DeepSeek。它在 Coding 层面与 GLM 相比可能稍逊一筹，但问题不大，当然与 Sonnet 相比还是有差距。

我用的这些工具，其实都是在 Claude Code 上驱动的。Claude Code 可以使用不同的模型，我所说的使用 GLM 4.6、DeepSeek、Kimi 2，都是在 Claude Code 上切换模型来驱动。所以，它们的程序 Agent 逻辑还是遵循 Claude Code 的逻辑，只是模型变了，但输出质量都不错，这也得益于 Claude Code 本身的 Agent 工程素养和上下文管理方式。我推荐了多个国内的模型，但这些模型都需要搭配在 Claude Code 中使用，效果会很好，这与工程化密切相关。我也建议大家可以尝试一下这些工具，这就是我在编程层面工具选择的体会。

在与 AI 协同工作的过程中，目标设定是至关重要的第一步。很多人会问，如何设定目标？其实，核心方式就是通过精确的表达来传达需求。过去，在使用通用聊天机器人如 ChatGPT 时，我们常常需要通过复杂的提示词框架来引导机器人完成特定任务，比如编写代码。那时的提示词可能包含身份定位、角色设定以及各种指令，甚至有些奇奇怪怪的框架。然而，如今进入 Agent 时代，情况发生了变化。这是一个场景化协作的时代，需求表达变得更加直接和关键。我们不再依赖复杂的提示词技巧，而是要清晰地表达自己的需求。

需求表达能力成为与 AI 协同工作的核心能力。为了让 AI 理解并执行任务，我们需要非常精确地描述需求。这其实比管理人还要复杂，因为 AI 没有情绪，但它需要清晰的指令。现在，为了让 AI 完成任务，我需要详细地写出任务细节、想法和思路。如果 AI 不理解，我还需要继续补充。有时，我输入的内容可能多达几百字，这是前所未有的。所以，管理 AI 并不比管理人轻松，你需要全方位地表达清楚，对业务场景有深刻的理解，知道领域的专业知识，并且对期望的成果有准确的预期。你不能不确定结果就随意给出需求，否则 AI 给出的结果多半不符合你的期望。此外，你还需要设定约束条件，甚至需要对任务进行拆分，明确是让 AI 一竿子插到底完成任务，还是分步骤执行。这些都需要在需求表达中体现出来。

关于是否使用提示词，我在设计 AI Agent 时会用到提示词来设定其功能，但在使用 AI Agent 时，关键在于清晰地表达需求。当你输入的需求比较模糊，比如只有一句话时，AI 给出的结果往往是笼统的。在这种情况下，你可能觉得 AI 给出的 50 分或 60 分的结果已经很不错了。但如果你想让 AI 给出 80 分、90 分甚至满分的结果，你就需要从不同角度、细分地描述你的需求，明确你希望的产出是什么。这不是提示词技巧，而是深度挖掘你对目标的定义，具象化你的想法。

接下来是过程管理。当我们让 AI 执行任务时，可以选择让它一竿子插到底，从下午 2 点开始工作，到 5 点回来验收成果。这是一种方式。但另一种方式是将任务拆分成多个子目标，这涉及到所谓的粒度管理。当我们需要将任务拆分时，还需要考虑是通过串行还是并行的方式来实现。并行处理是常见的选择，比如同时打开多个窗口让 AI 完成不同任务。然而，在并行处理时，我们可能会遇到工作目录污染的问题，尤其是在编写代码时，如何避免多个 feature 之间的相互干扰是一个挑战。当所有 AI 任务完成后，我们如何验收结果？人类是否能够在短时间内切换多个上下文？这反过来挑战了人类的上下文管理能力。这些就是过程管理中的一些核心挑战。

在编程领域，我们并非总是采用“一竿子捅到底”的方式。事实上，软件工程的思想一直存在，而这些思想同样适用于 AI 编程。Kiro 提出了一个概念，即 Spec-Driven 的 AI 编程。这实际上是在 AI 编程领域的一种标准化或流程化方式。其过程通过几份标准文档来驱动整个任务的推进。首先，通过需求文档与用户梳理需求，然后根据需求文档编写设计文档，设计文档再驱动任务的拆分，最终由 AI Agent 根据这些任务逐步实现具体需求，从而完成整个项目。这并不是一气呵成的方式，而是一个有规划、有步骤推进任务的过程。

与此同时，社区还存在其他框架，例如 BMAD-METHOD。这种框架涉及多种角色，包括产品经理、设计师以及 Scrum Master，他们共同规划项目目标。Scrum Master 负责用户故事的切片，随后进入敏捷循环开发、验证和交付等环节，多个 Agent 协同完成整个项目。

在工作区隔离方面，常见的做法是让 Agent 在本地工作，例如使用 Claude Code 处理本地事务。通常有两种隔离方式：容器隔离和 Git Worktree 方式。我更推荐后者，因为它更轻量级，且是 Git 自带的功能，可以直接在你的工作目录下使用。

最后是验收环节，验收方式主要有两种：自动化验收和人工验收。我们尽可能实现自动化验收，但自动化验收需要逻辑清晰，例如编写和运行单元测试、编译或格式检查等，这些通常适用于明确的编程和数学场景。然而，人工验收有时是不可避免的。人工验收涉及多个方面，包括你在该行业的专业知识水平、审美能力以及对用户体验的感知能力等。这些都有一定的要求。因此，在验收层面，我们应尽可能实现自动化，同时通过人工验收来兜底。

我曾遇到一个例子，当时我在编写一个 MCP 多节点传输功能。那时的 AI 还不理解 MCP 是什么，生成的代码无法运行。如果我不了解背后的原理，就无法完成这个任务。因为如果 AI 生成的代码无法运行，而我对这个领域一无所知，就会陷入死循环，项目也就无法继续。这在一定程度上反映了，如果没有专业知识，我们无法让 AI 输出我们想要的结果。后来，我通过阅读文档、理解原理，再反过来告诉 AI 应该如何设计和实现，最终才成功生成了可以运行的代码。

这让我得出一个结论：虽然大家都在使用 Claude 等 AI 工具，但不同人使用的结果却千差万别。这背后的原因在于我们对行业的认知、专业知识以及个人经验的差异。例如，我之前举办的一些 Vibe Code 沙龙活动中，让大家开发一个待办管理应用。那些没有任何技术背景的人，生成的应用可能只能达到 50～60 分，勉强可用。而有产品经理经验的人，能够清晰表达产品需求，生成的应用效果则大不相同；技术人员则会指定技术栈，提出具体的技术要求，他们的应用可能会更深入、更完善。

我很喜欢米开朗基罗的一个比喻：每块大理石里都藏着一件作品，雕刻师只是将它找出来。在实践中，我感觉 AI 就像人类知识的压缩器或浓缩器，它本身蕴含着丰富的知识。关键在于我们这些使用者，如何通过语言这个“刻刀”去雕琢它，让它将已知的知识或能力精确地输出给我们。

行业影响————软件世界的"板块漂移"

无论是 Vibe Coding 还是 Vibe Working，AI 对我们行业的冲击是显著且深远的。AI 的出现让整个市场进入了一个增量的过程。这种增量并非凭空产生，而是源于原本就存在的需求。过去，许多需求因为技术门槛过高而被压抑。例如，一些个人想要开发个性化的小工具，但由于不会编程，也没有足够的资金聘请开发者，这些需求一直未能得到满足。然而，AI 的出现打破了这一局面，它降低了技术门槛，使得这些被压抑的需求得以释放。

这种需求的释放也带来了矛盾。尽管市场需求在增加，但与之相对应的工作岗位却可能在收缩。这是因为 AI 能够高效地完成许多任务，原本需要人力完成的工作现在被 AI 所取代。这种现象导致了人才结构的变化。未来，我们会看到大量非专业人士，甚至可以说是“小白”，借助通用的 AI 能力满足中小规模的需求，这将成为市场的主流。而在顶端，会有少数专业人士结合 AI 的力量，处理更复杂、更高端的任务。无论在哪一层，AI 都将发挥重要作用。

这种变化意味着中间部分的人才将面临分流。一部分人可能会努力提升自己，进入顶端的专业领域；而大部分人可能会下沉，与普通“小白”处于同一水平。这实际上是对行业格局的一次重新洗牌。在数字化行业尤其如此，未来人和组织都将朝着 AI Native 的方向发展，即人们会习惯于在工作中依赖 AI，这样才能适应未来的趋势。如果仍然单靠个人力量，不借助 AI，很快就会被时代抛弃。组织也是如此，传统的组织架构将逐渐转变为扁平化且 AI Native 的模式。未来，这将是一个超级个体崛起的时代。

演讲嘉宾介绍

揭光发（Jeff）是腾讯云架构师联盟社群管理主席，腾讯专家工程师。

20 年研发与团队管理经验，前腾讯云 TVP，现腾讯全栈技术专家，公司级低代项目负责人，是 IEEE 低代码标准及大湾区企业低代码标准的主撰写人；大模型应用早期实践者与布道师，是国内顶级行业 / 技术峰会相关话題优秀讲师及出品人。在低代码与 LLM 结合场景有深度的实践，愿景是“人人能编程”。带领团队深度践行 LLM 对研发提效、探索 Vibe Coding 在专业程序员与准开发者群体的落地，个人代码全栈 AI 含量几近 100%。

会议推荐

OpenClaw 出圈，“养虾”潮狂热，开年 Agentic AI 这把火烧得不可谓不旺。在这一热潮下，自托管 Agent 形态迅速普及：多入口对话、持久记忆、Skills 工具链带来强大生产力。但这背后也暴露了工程化落地的真实难题——权限边界与隔离运行、Skills 供应链安全、可观测与可追溯、记忆分层与跨场景污染、以及如何把 Agent 纳入团队研发 / 运维流程并形成稳定收益。

针对这一系列挑战，在 4 月 16-18 日即将举办的 QCon 北京站上，我们特别策划了「OpenClaw 生态实践"」专题，将聚焦一线实践与踩坑复盘，分享企业如何构建私有 Skills、制定安全护栏、搭建审计与回放机制、建立质量 / 效率指标体系，最终把自托管 Agent 从可用的 Demo 升级为可靠的生产系统。

Snowflake China 与国内云对象存储的多云集成实战指南：一套架构打通多云对象存储

丁煜恒 — Mon, 16 Mar 2026 09:03:37 GMT

2026 年，智能体将在企业级应用中取得哪些实质性突破？点击下载"《2026 年 AI 与数据发展预测》白皮书，获悉专家一手前瞻，抢先拥抱新的工作方式！

背景：Snowflake 与多云环境

数据在阿里云，日志在腾讯云，而你却想用 Snowflake 做全局建模？这不再是“既要又要”的幻想。随着企业数据上云的持续深入，不少使用云服务的企业，会把数仓原始数据、日志、媒体文件集中存放在对象存储中，同时希望利用 Snowflake 的能力做统一建模与分析。

在全球范围内，Snowflake 诞生之初便构建在多云架构（Multi-cloud）之上。目前 Snowflake 全球服务已广泛部署于 AWS、Google Cloud 和 Azure，实现了跨云、跨区域的无缝数据流动与统一治理。在国内市场，Snowflake China 自 2024 年正式落地 AWS 宁夏区域以来，其与国际版一致的架构能力已在本土环境中得到深度验证。Snowflake 与 21 世纪互联运营的 Azure 及 AWS 中国区域的底层互通与稳定性早已是业界公认的成熟方案。

随着企业数字化转型的深入，新的挑战随之而来：数据资产往往散落在阿里云、华为云、腾讯云及火山引擎等多个国产云平台上。如何打通 Snowflake 与国产云厂商之间的“最后一公里”，实现真正的全云架构？

我们基于近期多个跨云实战项目，打磨出一套基于 S3 兼容协议的通用模式。无需大规模搬运数据，通过 External Volume + Apache Iceberg 的强强联手，你就能在保留原位存储的同时，享受 Snowflake 极速的分析体验。Snowflake China 不仅实现了与海外版一致的 AWS、Azure 连接能力，更深入本土生态，通过 S3 兼容协议完成了与阿里云 OSS、华为云 OBS、腾讯云 COS、以及火山引擎 TOS 的全量验证。本文将分享我们如何在异构 Bucket 之上，利用 Apache Iceberg 搭建起高性能、统一治理的数据高速公路。告别数据孤岛，从这一篇开始。

总体架构：基于 S3 兼容协议的“桥接模式”

从架构视角看，无论底层是 OSS、OBS、COS 还是 TOS，Snowflake China 与国内云对象存储的集成逻辑高度一致：统一通过各云厂商提供的 S3 兼容 Endpoint 建立连接，让外部 Bucket 在 Snowflake 中以 External Stage 或 External Volume 的方式呈现。

在该模式下，典型数据流包括：

入站流（对象存储→ Snowflake）：通过 COPY INTO 命令，从External Stage 读取 OSS/OBS/COS/TOS 中的文件，加载到 Snowflake 表中；出站流（Snowflake → 对象存储）：通过 COPY INTO 命令，将Snowflake 表数据导出为文件写回对象存储，用于归档、共享或下游消费。

实施流程

无论是接入阿里云、华为云、腾讯云还是火山引擎，整体实施可以抽象为以下三个步骤：

步骤 1：准备对象存储环境

在对应云厂商控制台中完成：

创建 Bucket

选择合适的 Region（如杭州、北京等）；根据业务场景选择存储类型（标准存储、低频存储等）；建议权限设置为私有，后续通过访问控制体系授权 Snowflake 使用。

创建访问凭证

生产环境中，建议为Snowflake 集成单独创建专用用户，并基于 Bucket / 前缀粒度配置最小权限策略。

步骤 2：在 Snowflake China 侧完成 Endpoint 白名单

由于 Snowflake China 运行在隔离网络中，任何访问外部对象存储的 Endpoint 都需要先由 Snowflake Support 加入白名单。

通用流程为：

1. 登录Snowflake China 的 Jira Support Portal（中国区支持门户）。

2. 创建Support Case，说明希望将指定 S3 兼容 Endpoint 加入白名单。

3. 在Case 中建议包含：

○ Snowflake 账号信息（Account Locator）。

○ 对应云厂商的Endpoint（例如 oss-cn-hangzhou.aliyuncs.com、obs.cn-north-4.myhuaweicloud.com 等）。

○ 使用场景说明（数据湖接入、离线导入/导出等）。

○ 预计访问的Bucket 名称与数据规模。

步骤 3：在 Snowflake 中创建 External Stage / External Volume + Iceberg

白名单生效后，即可在Snowflake 中创建：

External Stage：用于文件级别的COPY INTO 导入 / 导出；External Volume + Iceberg Table：用于在对象存储上构建Lakehouse 架构，由 Snowflake 负责 Iceberg 元数据与查询引擎，对象存储负责数据文件与元数据文件的持久化。

接下来进入四大云厂商的统一集成实战。

集成实战

配置总览

各厂商常用 Region Endpoint 速查

阿里云 OSS

华为云 OBS

腾讯云 COS

火山引擎 TOS（必须使用 S3 兼容端点）

注意：火山引擎 TOS 有两种端点——普通端点 tos-cn-{region}.volces.com 和 S3 兼容端点 tos-s3-cn-{region}.volces.com。与Snowflake 集成必须使用 S3 兼容端点。

External Stage 创建

四家云厂商的 External Stage 创建 SQL 遵循完全相同的模板，仅 URL、Endpoint 和凭证不同：

-- 通用模板 CREATE OR REPLACE STAGE {STAGE_NAME} URL = 's3compat://{bucket-name}[/{path}/]' ENDPOINT = '{s3_compatible_endpoint}' CREDENTIALS = ( AWS_KEY_ID = '{your_access_key}' AWS_SECRET_KEY = '{your_secret_key}' );

四家实际示例：

USE DATABASE YOUR_DATABASE; USE SCHEMA YOUR_SCHEMA; -- 阿里云 OSS（杭州） CREATE OR REPLACE STAGE ALIYUN_OSS_STAGE URL = 's3compat://snowflake-oss-test/data/' ENDPOINT = 'oss-cn-hangzhou.aliyuncs.com' CREDENTIALS = ( AWS_KEY_ID = 'YOUR_ACCESS_KEY_ID' AWS_SECRET_KEY = 'YOUR_ACCESS_KEY_SECRET' ); -- 华为云 OBS（北京四） CREATE OR REPLACE STAGE HUAWEI_OBS_STAGE URL = 's3compat://snowflake-test-obs/' ENDPOINT = 'obs.cn-north-4.myhuaweicloud.com' CREDENTIALS = ( AWS_KEY_ID = 'YOUR_ACCESS_KEY_ID' AWS_SECRET_KEY = 'YOUR_SECRET_ACCESS_KEY' ); -- 腾讯云 COS（北京） -- 注意：Bucket 名称必须包含 APPID 后缀 CREATE OR REPLACE STAGE TENCENT_COS_STAGE URL = 's3compat://snowflake-test-cos-{APPID}/' ENDPOINT = 'cos.ap-beijing.myqcloud.com' CREDENTIALS = ( AWS_KEY_ID = 'YOUR_SECRET_ID' AWS_SECRET_KEY = 'YOUR_SECRET_KEY' ); -- 火山引擎 TOS（北京） -- 注意：必须使用 S3 兼容端点 tos-s3-{region}.volces.com CREATE OR REPLACE STAGE VOLCENGINE_TOS_STAGE URL = 's3compat://snowflake-test-tos/' ENDPOINT = 'tos-s3-cn-beijing.volces.com' CREDENTIALS = ( AWS_KEY_ID = 'YOUR_ACCESS_KEY_ID' AWS_SECRET_KEY = 'YOUR_SECRET_ACCESS_KEY' );

通过 LIST 命令验证每个Stage 的连通性：

LIST @ALIYUN_OSS_STAGE; LIST @HUAWEI_OBS_STAGE; LIST @TENCENT_COS_STAGE; LIST @VOLCENGINE_TOS_STAGE;

双向 COPY 示例

以下 COPY INTO 语法对四家云完全通用，仅需替换 Stage 名称。

导出：Snowflake → 对象存储

-- 创建测试表 CREATE OR REPLACE TABLE INTEGRATION_TEST ( id INT, name STRING, region STRING, cloud_provider STRING, created_at TIMESTAMP_NTZ DEFAULT CURRENT_TIMESTAMP() ); -- 插入测试数据 INSERT INTO INTEGRATION_TEST (id, name, region, cloud_provider) VALUES (1, 'Snowflake China', 'AWS Ningxia', 'Snowflake'), (2, 'Aliyun OSS', 'Hangzhou', 'Alibaba Cloud'), (3, 'Huawei OBS', 'Beijing', 'Huawei Cloud'), (4, 'Tencent COS', 'Beijing', 'Tencent Cloud'), (5, 'Volcengine TOS', 'Beijing', 'ByteDance'); -- 导出到各家云存储（以阿里云 OSS 为例，替换 Stage 名即可） COPY INTO @ALIYUN_OSS_STAGE/export/ FROM INTEGRATION_TEST FILE_FORMAT = ( TYPE = CSV COMPRESSION = NONE FIELD_OPTIONALLY_ENCLOSED_BY = '"' ) OVERWRITE = TRUE HEADER = TRUE;

导入：对象存储→ Snowflake

-- 创建目标表 CREATE OR REPLACE TABLE INTEGRATION_TEST_IMPORT ( id INT, name STRING, region STRING, cloud_provider STRING, created_at STRING ); -- 从各家云存储导入（以阿里云 OSS 为例，替换 Stage 名即可） COPY INTO INTEGRATION_TEST_IMPORT FROM @ALIYUN_OSS_STAGE/export/ FILE_FORMAT = ( TYPE = CSV SKIP_HEADER = 1 FIELD_OPTIONALLY_ENCLOSED_BY = '"' ); -- 验证导入结果 SELECT * FROM INTEGRATION_TEST_IMPORT;

External Volume + Iceberg Lakehouse

在很多生产场景下，你可能希望数据长期保留在对象存储上，同时由Snowflake 提供 Iceberg Catalog 与查询能力，实现开放格式与统一治理兼得。这时可以采用 External Volume + Iceberg Table 的 Lakehouse 模式。

在该模式下：

Catalog：由Snowflake 托管 Iceberg 表的状态与元数据指针；Metadata 文件：Iceberg 的 JSON / Avro 等元数据文件写入你自己的 Bucket；Data 文件：Parquet 等数据文件同样写在 Bucket 中，可被 Spark / Flink 等引擎直接访问。

（1）创建 External Volume（通用模板）

CREATE OR REPLACE EXTERNAL VOLUME {VOLUME_NAME} STORAGE_LOCATIONS = ( ( NAME = '{location_name}' STORAGE_PROVIDER = 'S3COMPAT' STORAGE_BASE_URL = 's3compat://{bucket-name}/{path}/' STORAGE_ENDPOINT = '{s3_compatible_endpoint}' CREDENTIALS = ( AWS_KEY_ID = '{your_access_key}' AWS_SECRET_KEY = '{your_secret_key}' ) ENCRYPTION = (TYPE = 'NONE') ) );

（2） External Volume 示例

-- 阿里云 OSS External Volume CREATE OR REPLACE EXTERNAL VOLUME ALIYUN_OSS_ICEBERG_VOLUME STORAGE_LOCATIONS = ( ( NAME = 'aliyun_oss_hangzhou' STORAGE_PROVIDER = 'S3COMPAT' STORAGE_BASE_URL = 's3compat://my-iceberg-bucket/iceberg/' STORAGE_ENDPOINT = 'oss-cn-hangzhou.aliyuncs.com' CREDENTIALS = ( AWS_KEY_ID = 'YOUR_ACCESS_KEY_ID' AWS_SECRET_KEY = 'YOUR_ACCESS_KEY_SECRET' ) ENCRYPTION = (TYPE = 'NONE') ) ); -- 华为云 OBS External Volume CREATE OR REPLACE EXTERNAL VOLUME HUAWEI_OBS_ICEBERG_VOLUME STORAGE_LOCATIONS = ( ( NAME = 'huawei_obs_beijing' STORAGE_PROVIDER = 'S3COMPAT' STORAGE_BASE_URL = 's3compat://my-iceberg-bucket/iceberg/' STORAGE_ENDPOINT = 'obs.cn-north-4.myhuaweicloud.com' CREDENTIALS = ( AWS_KEY_ID = 'YOUR_ACCESS_KEY_ID' AWS_SECRET_KEY = 'YOUR_SECRET_ACCESS_KEY' ) ENCRYPTION = (TYPE = 'NONE') ) ); -- 腾讯云 COS External Volume -- 注意：Bucket 名称必须包含 APPID 后缀 CREATE OR REPLACE EXTERNAL VOLUME TENCENT_COS_ICEBERG_VOLUME STORAGE_LOCATIONS = ( ( NAME = 'tencent_cos_beijing' STORAGE_PROVIDER = 'S3COMPAT' STORAGE_BASE_URL = 's3compat://my-iceberg-bucket-{APPID}/iceberg/' STORAGE_ENDPOINT = 'cos.ap-beijing.myqcloud.com' CREDENTIALS = ( AWS_KEY_ID = 'YOUR_SECRET_ID' AWS_SECRET_KEY = 'YOUR_SECRET_KEY' ) ENCRYPTION = (TYPE = 'NONE') ) ); -- 火山引擎 TOS External Volume -- 注意：必须使用 S3 兼容端点 CREATE OR REPLACE EXTERNAL VOLUME VOLCENGINE_TOS_ICEBERG_VOLUME STORAGE_LOCATIONS = ( ( NAME = 'volcengine_tos_beijing' STORAGE_PROVIDER = 'S3COMPAT' STORAGE_BASE_URL = 's3compat://my-iceberg-bucket/iceberg/' STORAGE_ENDPOINT = 'tos-s3-cn-beijing.volces.com' CREDENTIALS = ( AWS_KEY_ID = 'YOUR_ACCESS_KEY_ID' AWS_SECRET_KEY = 'YOUR_SECRET_ACCESS_KEY' ) ENCRYPTION = (TYPE = 'NONE') ) );

（3）在 External Volume 上创建 Iceberg 表（通用语法）

-- 以阿里云 OSS 为例（替换 EXTERNAL_VOLUME 名即可适用其他云） CREATE OR REPLACE ICEBERG TABLE ORDERS_ICEBERG ( order_id INT, customer_id INT, order_ts TIMESTAMP_NTZ, amount NUMBER ) CATALOG = 'SNOWFLAKE' EXTERNAL_VOLUME = 'ALIYUN_OSS_ICEBERG_VOLUME' BASE_LOCATION = 'orders/';

其中：

CATALOG = 'SNOWFLAKE'：由Snowflake 管理 Iceberg Catalog 与表状态；EXTERNAL_VOLUME：绑定到上一步创建的Volume（替换为对应云厂商即可）；BASE_LOCATION：指定这张表在Bucket 内的逻辑子路径。

（4）Iceberg 表数据完整 CRUD操作

-- INSERT

INSERT INTO ORDERS_ICEBERG VALUES

(1001, 101, '2026-02-01 10:00:00', 14999.00),

(1002, 102, '2026-02-01 11:30:00', 7999.00),

(1003, 103, '2026-02-02 09:15:00', 1999.00);

-- UPDATE

UPDATE ORDERS_ICEBERG

SET amount = 6999.00

WHERE order_id = 1002;

-- DELETE

DELETE FROM ORDERS_ICEBERG

WHERE order_id = 1003;

-- SELECT

SELECT * FROM ORDERS_ICEBERG;

各厂商特殊注意事项

实测验证汇总

以下结果基于 Snowflake China（AWS 宁夏）的实际测试：

External Stage 双向 COPY INTO 验证

Iceberg Table 全量 CRUD 验证

综合来看，无论选择哪家国内云存储，都可以同时通过 External Stage 支持批量文件导入/导出，以及通过 External Volume + Iceberg 构建开放Lakehouse，将数据长期保留在对象存储中，同时由 Snowflake 提供统一的 SQL 分析与治理能力。

典型工作负载模式与架构选择

在多云环境下，选择何种数据组织方式更多取决于工作负载特征和数据治理需求。下面给出三类常见模式，供设计架构时参考：

模式 A：以 Snowflake 原生表为中心

典型场景：高并发面向业务的报表、大量维度建模与复杂关联分析；建议：将云对象存储视为“数据来源”或“结果落地端”，通过 External Stage 将数据加载到 Snowflake 原生表中进行建模与计算。

模式 B：开放 Lakehouse（Iceberg on External Volume）

典型场景：需要被 Spark、Flink 等多种引擎共同访问的数据湖；或倾向于统一使用开放格式（Parquet + Iceberg 元数据）的企业；建议：在对象存储上创建 External Volume + Iceberg 表，由 Snowflake 管理 Catalog 与查询，同时保留文件级开放性。

模式 C：简单数据交换（External Stage Only）

典型场景：批量文件归档、一次性数据导入、审计报表导出等；建议：仅创建 External Stage，通过 COPY INTO 完成文件级读写，不必额外维护表结构与元数据。

以上三种模式可以在同一账号内灵活组合：同一云厂商下可以同时存在多种模式，不同云厂商之间也可以采用相同的模式，实现统一的数据架构与治理能力。

最佳实践总结：为什么选择以 Snowflake 为中心？

基于综合实测，Snowflake China 与国内云存储的集成表现稳健。在构建架构时，我们推荐以 Snowflake 为“发散式中心”连接多云，主要基于以下优势：

● 极简的运维体验：无需管理复杂的Hadoop 堆栈或 Spark 集群。通过 Snowflake，你只需编写标准 SQL 即可横跨多个国产云 Bucket 进行联邦查询或数据加载；

● 统一的治理标准：无论数据物理上位于阿里云还是腾讯云，在Snowflake 这一层都可以应用统一的角色权限管理（RBAC）、数据脱敏和审计策略，避免了在多个云厂商控制台中重复配置安全策略的混乱；

● 架构的灵活性与前瞻性：支持Apache Iceberg 开放格式。这意味着企业在享受Snowflake 极速引擎的同时，数据依然以开放格式保留在自己的国产云 Bucket 中，确保了不被单一供应商锁定的战略灵活性；

● 多云环境下的“数据中枢”：Snowflake 充当了异构云环境之间的桥梁，通过统一的 S3 兼容集成模式，让企业能更专注于业务洞察，而非被底层云基础设施的差异性所困扰。

关于作者

丁煜恒，Snowflake 资深解决方案工程师。前 AWS 解决方案架构师及 Microsoft 软件工程师。拥有逾十年在全球顶级科技公司的一线技术专家经验。深耕于云计算、大数据架构及人工智能领域，曾主导并实现了包括 Snowflake、Azure、AWS 全球客户入华架构在内的多项核心技术方案落地。凭借对多元技术生态的深刻理解，他持续助力全球 500 强企业构建高效、可扩展的数据智能体系。他同时持有多项主流云以及数据平台的高级专业认证，致力于将前沿的云原生技术转化为企业的核心生产力。

点击链接立即报名注册：Ascent - Snowflake Platform Training - China"，更多 Snowflake 精彩活动请关注专区"。

“为了让工程师用 AI，公司会裁掉一半人！”硅谷顶级大佬直言，AI 一天 3 小时搞定工作，还搞 996 的公司必垮

褚杏娟 — Mon, 16 Mar 2026 08:37:52 GMT

AI 正在把软件行业推入一种很矛盾的状态：一边是前所未有的兴奋感，另一边却是越来越强的疲惫感。Steve Yegge 把这种状态叫作“吸血鬼效应”，即AI 会让人异常亢奋，忍不住一路干下去，创业者和工程师白天困到打盹，晚上却还在被新想法和新工具推着往前冲。

作为一位做了 40 年软件工程的老兵，他曾长期在 Amazon 和 Google 工作，以犀利、敢说、而且屡屡说中的行业判断闻名。他在最新的播客节目中直言，企业正在默认裁掉约50%的工程师，只为供养剩下的人全力使用AI。如今还停留在传统IDE、只把AI当辅助工具的工程师，很快会被批量淘汰，因为AI的本质不是替代人，而是百倍放大人的能力，让小团队足以碾压臃肿的大公司。

他一针见血地指出，移动与云之后，软件行业早已创新停滞，大公司的创新已经名存实亡。他对比了Anthropic和Google来证明公司文化对创新的影响。AI带来的百倍提效下，人一天真正高效的工作时间只有3小时，继续强行996只会榨干员工、拖垮公司。

他预测，未来的开发范式将彻底重构，编程不再是敲代码，而是对着可视化的AI形象对话、指挥Agent去干活，Gas Town这样的实验已经证明，AI指挥AI才是下一代主流模式。他告诫所有人，不要试图比AI更聪明，更大的模型、更多的数据才是终极规律。

另外，在这个新时代里，真正的护城河是人与人的连接。Fork开源项目会成为常态，创新将从小团队爆发。到2027年，非开发者也能主导软件开发，编程会彻底走向全民化。

我们对这次访谈进行了翻译，并在不改变原意基础上进行了删减，以飨读者。

AI之前，你的知识就在不断过时

主持人：Steve，很高兴你又来上节目了。最近都在忙什么？

Steve Yegge：很高兴回来。已经过去 10 个月了吧。最近发生了很多事。我现在处于“失业状态”，但这段日子非常开心。我现在就是想干什么就干什么，这感觉太好了。我上线了几个软件项目，还发了一本书。去年书也发了，总之就是在过日子。

主持人：很长一段时间以来，你都像个“真话机器”，总能讲出一些有时候很好笑、有时候又让人不太舒服的事实或者观察。你觉得自己当初的判断被验证了吗？

Steve Yegge：当然。很多了解我的人告诉我，他们最喜欢的博客其实是《Execution in the Kingdom of Nouns"》。不知道你还记不记得那篇，很早以前写的。那时候我在 Google，还是 Google 很早期的时候。我当时一直想让大家明白：Java 的增长和代码量之间呈一种非常线性的关系。换句话说，代码量增长得比功能增长还快，这显然不是个好现象。后来 Java 改进了很多，这点要承认。

但当时我那篇文章在 Sun 引起了不少注意，他们会想：“这家伙到底在抱怨什么？为什么就不能闭嘴？”但我那时候想的是，我就是想用一种支持 first-class functions 的语言。于是我写了一篇非常非常不寻常的博客，名字就叫《Execution in the Kingdom of Nouns》。很多人特别喜欢，因为它其实是个故事，一篇童话，讲的是一个没有动词的国度，很有意思。

主持人：还有一篇没那么出名，或者说对很多听众来说可能没听过，叫《Rich Programmer Food》。那篇是讲编译器的，你还记得当时你的核心观点是什么吗？

Steve Yegge：当然记得。那是我最重要的博客之一。我在纽约参加 Swyx 的 AI 工程大会时，碰到一个人，他一上来就说：“Steve，我一直很想见你，我是你当年做的游戏的玩家。” 我当时整个人都愣住了。那人三十多岁，说他玩过我做的游戏。

你要知道，我当年写的那个游戏，绝大多数人其实根本没见过，因为我一直没有开源。我以后会开源的，只是过程会很麻烦。那是个做得非常漂亮的东西，这么多年来，一直让玩家对它很有感情，隔了几十年还有人回来玩。

那个家伙特别投入，他说自己读了我那篇《Rich Programmer Food》，于是决定去做编译器专家。那时候他还在上高中，后来读了博士，自己创了业，现在创业公司做得非常好。他说，这一切都起于那篇文章。

主持人：你是不是在说，如果你不了解编译器是怎么工作的，你就不可能成为一个真正优秀、真正高效的程序员？

Steve Yegge：大意是这样。你做的事情和计算机真正执行的事情之间，会永远隔着一层“魔法”。而那层魔法，会一直成为你的摩擦成本。

主持人：而且我记得你当时甚至还说过，有些博士都不懂编译器是怎么工作的，这会让他们很难做到高效。在那个年代，这个说法肯定是成立的。那你觉得这篇文章放到今天，算是“过时”了吗？毕竟那大概是2012年左右。

即便在那个时候，说“你需要懂汇编”，我觉得也已经挺反常识了。那时候已经是高级语言的时代，Java 正值巅峰，C、Ruby 也起来了，JavaScript 也开始壮大，再过几年 React 也会出现。大多数开发者当时可能都会想：我为什么还要懂编译器、懂汇编？那不就是编译器本身该干的事情吗？

Steve Yegge：你真正想问我的其实是：大学到底应该教什么？只不过你换了个问法而已。这个标准从我 80 年代入行开始，每隔几年就会变一次。

“一个人想成为软件工程师，到底需要知道什么”，这个门槛一直在变。早年间，你得懂汇编语言、位操作这些底层知识。后来，我和我的老伙计们逐渐发现，我们以前最爱问候选人的那些位运算问题，开始一次次碰壁，越来越多的求职者这辈子都没真正接触过位操作。

到了 2010 年代，我们也开始反思：今天做软件工程师，真的还需要会 XOR、会在一个 byte 里做那些 bit 操作吗？大概已经不需要了。这对我们来说其实挺打击的，因为我们一直以了解这些底层细节为傲，但现实是“你真的不需要了”。

更让人难受的是，我自己的很多自我认同、很多成就感，其实都建立在我的编译器背景之上。那些知识确实很有意思，但放到今天，已经没什么真正的实用价值了。

主持人：所以，它变得“不再重要”，是因为编译器优化已经足够好了？还是因为问题已经整体上升到更高层了？

Steve Yegge：原因很简单，我们一直在沿着抽象阶梯往上爬，仅此而已。

主持人：这种变化在 AI 出现之前就已经在发生了。

Steve Yegge：对，我们还没开始谈 AI。即使到了2010年代后期，回顾职业生涯，我也只想得起一次：如果知道编译器具体做了什么，或许有点帮助。但说实话，那次也可能只是误导线索。

需要知道的东西一直在变，课程和教学内容不断更新。很多人感受不到，是因为他们只回看一两年，再往前看一点。而我干了40年，可以明确说：现在教的东西和过去完全不同，因为所需能力也完全不同。

图形学行业最明显。对比今天的计算机图形和我1992年学的图形学，当时得学会写算法，算出一条线的下一个像素点，画出来、组成多边形。两年后，同样的课学的已是动画。我知道多边形是什么，但层级完全不同。整条梯子上移，岗位需求从写设备驱动，到做游戏世界、做物理。图形学早就演示了这种变化。

而软件工程岗位其实已经稳定很久了。大概从iOS、移动互联网、云开始，后面没有同量级的新事物。移动和云大概就是过去最后两次大的创新。

软件创新长期停滞，直到 AI 出现才重新激活

主持人：软件工程上一个真正意义上的创新，到底是什么？

Steve Yegge：说实话，从那之后，这个领域其实有点“死了”。

主持人：我本来不想现在就提 AI，但我的感觉就是，我们之前经历过一段行业停滞期：课程体系没怎么变，大家都以为那就是软件工程师永远需要知道的全部了。如果我没记错，上一波真正的大创新可能是分布式系统。大概从 2010 年代开始，随着 Uber 把微服务推到台前，大家开始真正解决服务扩展、海量数据存储这些难题。那是个很大的变化，只是发生得比较慢。

Steve Yegge：对，很大的变化。

主持人：但说实话，我也觉得那之后的日子，更像是在不停地做迁移。React 一出新版本，开发者就得跟着折腾；苹果每年都像往齿轮里塞一把螺丝刀，强行推出不兼容更新；安卓开发者也得不断淘汰旧版本，纠结从哪个版本开始不再兼容。所以那几年，整个行业更像是处在一种持续迁移、不停适配的状态里。再加上当时生意本身很好，所有公司都在高速增长，大家疯狂招人，仿佛明天就不再需要人一样。2021 年的市场尤其火爆，哪怕只上过 3 个月训练营的人，都能拿到不错公司的录用通知，因为市场实在太缺人了。然后在 2022 年，AI 来了。

不管是 2020 年代还是更早以前，你一直都非常务实，从编译器、调试工具起家，在Amazon、谷歌解决的也是真正硬核的技术问题，从来不会回避困难。可当 AI 真正出现时，你最开始是什么感受？是一边观察、一边怀疑吗？尤其是刚接触大模型那段时间。

Steve Yegge：我当时其实特别震惊，因为它们居然已经能写出还算通顺的 Emacs Lisp 函数了。最早的 ChatGPT 刚出来那会儿，就已经能用这种冷门小众的语言写代码了。当然，代码不多，也很粗糙，但对我来说，那是第一次真正让我意识到：“哦，原来是这么回事。”

我有很多做 AI 的朋友，20年来一直在说：“快了，随时都可能实现，真的马上了。” 他们也确实一直在拿出更好的成果，但直到那一刻，我才第一次真切觉得：好吧，我终于亲眼看见了。

不过和其他人一样，我当时还是持怀疑态度的。你要知道，去年年初外面开始传，Anthropic 内部有个能直接写代码的命令行工具时，我跟所有人一样，第一反应就是：不可能，完全不信，打心底拒绝接受。直到后来我亲自用上了它，才心想：“哦，我懂了，我们彻底变天了。”

然后，我很快就写了《Death of the Junior Developer》那篇文章，可能是在 4o 出来之后写的，具体时间记不清了。总之，从那以后，事情变得特别快。

所以你要问我是不是怀疑派？是的，我一开始就是。但我是不是从一开始就在盯着那条曲线看？也是的。我当时就想，如果 ChatGPT 3.5 已经能写出一段像样的 Emacs Lisp 函数，那一年之后它又能做到什么？结果一年后，4o 已经能写 1000 行代码了。1000 行啊兄弟，这已经覆盖了世界上绝大多数代码文件的长度，意味着它已经可以做出可信的代码修改了。在 4o 之前，它完全做不到这一点。

也正是从那一刻起，我意识到：“好了，我们已经踏上一条不可逆的曲线了。这不是一阵风口，也不是玩票，这是一趟过山车，而且它不会停下。那就上车，看看它到底会开到哪里去。”

于是我一头扎了进去。那时候我其实已经落后了，我不懂 AI，不懂基础概念，也不懂行话。现在大家都懂这些词了，但我当时什么都不会。我整整花了一年时间，除了读论文和补课，什么都没干。

“裁掉一半人，来供另一半人全力使用AI”

主持人：你上次来节目时，《Vibe Coding》这本即将出版，我那时候也看过早期版本。最近我看了它的封底，突然意识到，这段话你应该是一年前写的“The days of coding by hand are over.” 你是什么时候真正意识到这件事的？因为我自己是最近在用 Opus 4.5 的时候才有这种感受，但你那个时候比这早太多了。

Steve Yegge：对，现在算已经超过一年了，大概 12 到 13 个月前，我第一次真正意识到这点。不过那句话其实不是我说的，而是 Eric Meyer说的。他是编程世界里非常重要的人物，编译器领域最顶尖的之一，发明和参与过无数东西。你想想，这样一个人，一辈子都在为开发者打造“更好写代码”的技术，结果今天他却说：开发者以后不写代码了。

一个人到底看到了什么，才会说出“我这一生的工作方向，本质上已经不成立了”这种话？

正是因为这个判断，Jean Kim 和我都一下子停住了，开始认真想：如果连他都这么说，背后一定有东西。他对Visual Basic、C、Lisp、Haskell、PHP等都有巨大贡献，可他现在却说：行了，结束了，我们不写代码了。这话从语言领域的大人物嘴里说出来，分量有多重？那他到底看到了什么我们没看到的？

答案其实很简单：他看到了那条指数曲线。指数曲线一旦进入陡峭区间，上升速度会快得离谱。而我们今年，正好就要进入这段最陡的区间。

主持人：那你为什么相信这条曲线还会继续往上走？

Steve Yegge：这个世界上充满了“不相信的人”，他们固执地认为，这条曲线会是一个S形：先上升，然后走平，而且他们现在就觉得已经到了那个拐点。从GPT-3.5出来那天起，他们就一直在说：“差不多就这样了，不会再好了。”后来4o出来了，大家都很喜欢，到现在也放不下，可还是有很多人觉得，那就是极限了。现在Opus 4.5已经发布两个月了，可大多数人还没认真玩过，根本不知道它现在到了什么程度。

我观察到，模型迭代的“半衰期”已经从去年初的四个月，缩短到Anthropic这边差不多两个月，所以他们随时可能再发新模型。等这个播客上线的时候，说不定新模型已经出来了。到那时，曲线又会往上猛跳一截，人们才会真正开始害怕。

等他们看到下一个模型，真的会开始不安。因为现在大家抱怨的那些bug、那些错误，都会被重新喂回训练流程里，下一个版本就不会再犯。很多人根本没理解这一点。更重要的是，时间不会停。三五年后也会来，太阳不会突然不升起，所以这些曲线终究会撞在一起。

社会层面的剧烈震荡已经开始，而且越来越明显。人们现在愤怒是有道理的，我自己也和他们一样愤怒。我特别愤怒的是，Amazon一边裁掉16000人，一边把锅甩给AI，尤其是在它根本没有清晰AI战略的前提下。那些被裁的人，接下来很可能根本找不到工作，而且他们只是第一批。后面还会有很多人。可现在，根本没人有应对计划。

主持人：你为什么觉得 Amazon 会这么做，明明它自己都没有完整的 AI 战略？

Steve Yegge：因为很不幸，虽然很多人会讨厌我这么说，但事实并非因我道破才成真。每家公司手上都有一个从0到100的旋钮，即使不去碰，它也有个默认值：为了让剩下那批工程师用上AI，公司愿意裁掉多少比例的工程师。如今，工程师已开始把自己的工资“烧”成tokens。至少在短期内，若真想达到最高生产力，你可能就得裁掉一半人，来供另一半人全力使用AI。更何况，恰好有一半工程师压根不想写prompt，他们本来也快辞职了。

所以，眼下发生的事情就是：平均而言，每家公司都把那个旋钮拧到了50%左右。这意味着，我们将失去大公司里差不多一半的工程师。这很可怕。

主持人：这太夸张了，这比过去裁员潮大太多了。

Steve Yegge：而且还会更大，会很难看。但与此同时，另一件事也在发生：AI 正在让不会编程的人开始能写代码，也在让那些“看见了趋势、相信曲线还会继续往上走”的工程师们，以 2 人、5 人、10 人、20 人、30 人的小团队聚在一起，做出足以匹敌大公司的产出。

于是，我们一边看到自下而上的创新狂潮，另一边又看到大批知识工作者从大公司离职。原因很明显，大公司已经不是正确的组织规模了。就连 Andy Jassy 也在说类似的话：以后我们要用更少的人，做同样的事。

主持人：那这是不是意味着，以后会冒出比现在多一百万倍的公司？软件会不会迎来一次大爆炸？还是说大家干脆离开软件行业去做别的了？

Steve Yegge：确实，那些具备正确技能组合、看到了合适商业机会，或者本身有独特优势的小团队，现在能做的事比以前多太多了。所以，这背后确实有事情正在发生，我觉得现在已经开始了一场“抢地运动”。

很多从知识工作里出来的人，其实是反AI的，这些人接下来会很难。我知道这话不好听，但如果你到现在还是反AI，那就像反对太阳一样，唯一的办法就是搬到地下去住。

而那些拥抱AI的人，我觉得会推动一场巨大的资源再分配：谁来干活、软件从哪来，都会被重新改写。我甚至能想象一种“挺幸福的”未来：像Amazon这种都不再存在了。因为软件会变成一种……我们现在还没有词能描述的东西。今年发生了太多我们没法命名的现象，你有没有这种感觉？软件会变得更分布式或者别的什么，总之还没有合适的语言去概括它。

主持人：我确实也看到很多非技术背景的人开始进入软件领域。那未来工程师会不会反而有一类新工作，就是去接管这些东西的维护？

Steve Yegge：会的。我觉得未来仍然会有大量工程师在做软件工程，只不过我们所有人都会跟 AI 一起做。

但我觉得，在很长一段时间里，公司还是不会放心到让 AI 在没有任何人参与的情况下，独立写代码、独立部署。很多唱衰的人、怀疑的人忽略了一个非常关键的问题：AI 不是来替代你的工作，它不是 replacement function，它是 augmentation function，它是来让你把工作做得更好的。这其实不是什么坏事，我不明白为什么会有人如此抗拒它。

Agent 应用等级

主持人：不过说到开发者这份工作，你之前说过一句很容易惹怒人的话，“如果你现在还在用 IDE，那你就是个糟糕的工程师？”

Steve Yegge：对，这种话多少带点挑衅。不过我换个说法吧，我不会直接说“你是个糟糕的工程师”，因为我认识一些非常非常优秀、比我还强的工程师，他们现在还处在我那张图里的一级或者二级。

我真的非常替他们难过，我对他们的同情，可能是我这辈子都没这么强烈过。明明已经是成熟的大人了，明明是很强的工程师，或者曾经是很强的工程师，可他们现在还是那种状态：“对啊，我会用 Cursor，我偶尔问它点问题，它的回答让我印象很深，然后我会非常仔细地 review 它写的代码，再自己提交。”我听到这种话的感觉就是：哥们，你很快就会被裁掉，而你明明是我认识的最好的工程师之一。

主持人：那讲讲那张图吧，你说的这些等级到底怎么划分？

Steve Yegge：我当时在澳大利亚，给一大群人现场画这张图，想让他们明白到底发生了什么。因为我看到现场的人都处在不同阶段：有人还开着 IDE，有人开着一个很宽的 coding agent 窗口，有人的 coding agent 窗口又很窄。所以我就想，干脆把大家放到一条光谱上，看看分别在哪里。

一级，就是完全不用 AI。二级，就是那种“我能不能在你的 IDE 里做这件事”的阶段。三级，就是开始 YOLO 了，你会说：“行，你直接干吧。”这时候你的信任度开始上升。四级的时候，你开始把“代码”这件事往外挤了。因为你越来越想看 agent 在干什么，而不是盯着 diff 看。也就是说，你 review 得越来越少了，你会放更多东西通过，你关注的核心已经变成了和 agent 的对话。五级的时候，你会说：“行，我只想要 agent，代码回头我再去 IDE 里看，但我不是在用 IDE 写代码了。”到第六级，你会开始无聊，因为 agent 正在忙。你会想：“好吧，它在跑，我总得找点别的事干。”于是你又启动第二个 agent。然后你就上瘾了，因为很快你会进入一个平衡态：总会有某个 agent 在等你。只要你启动得足够多，从数学上来说，总会有一个 agent 先跑完，于是你就开始在它们之间来回切换，像多路复用一样，一直切来切去，根本停不下来。

主持人：那有个很现实的问题，如果我是在同一个代码库上工作，我该怎么同时启动多个 agent，又不让它们彼此冲突？

Steve Yegge：这就把你带到第七级了：“天啊，我搞出一团糟。”比如我不小心把消息发给了错误的 agent，自己还没意识到，结果它在这个项目里又开了一个大项目，现在我得自己回来收拾残局。正是在那个阶段，我开始想：我们能不能想办法协调这事？如果 Claude Code 能跑 Claude Code，会怎么样？

这其实是所有人都想知道的问题。去年大家都在疯狂尝试让 Claude Code 自己运行自己，但它跑一会儿就会停掉，问题关键就出在这个“会停”上。所以我在这件事上非常用力地往下挖，也因此做了一些工具来帮助解决这个问题。总之，这一切变化太大了，真的变得太快了。

IDE 会“回归”

主持人：回到 IDE 这个话题。你之前和 Zed 的 Nathan 有过一场很精彩的现场辩论，标题好像就叫“IDE 的死亡”。你们两个人各自站在不同立场上。那你现在对 IDE 的看法是什么？还有，你从 Nathan 那边学到了什么？他更偏向支持 IDE，而你更像是在说也许它不会永远存在。

Steve Yegge：对，我现在所处的位置，就是我已经相信：AI 最终会替我们完成绝大部分事情。所以我现在看 IDE，会先想它本质上到底是干什么的。它其实不是真正用来“写代码”的，它更像是把各种工具拼在一起，形成一个大工具。现在你还有 MCP 之类的东西，也都在往这个方向走。

所以我其实觉得 IDE 会“回归”，而 Claude Cowork 本质上就像是 IDE 形态的一次回归。它有点像 Claude Code 在说：“我得给真正的人类用。”不过我也觉得，Claude Cowork 这种形态对普通开发者来说，可能比 Claude Code 更合适。所以我看到的未来是，IDE 会回来，只不过它会变成一个由对话和监控组成的世界。

主持人：这点其实特别有意思。我弟弟做了个东西叫 craft agents，跟 Claude Cowork 有点像，只不过它接入了他们公司自己的数据源。他跟我说，有些开发者开始更喜欢这种形式，因为它更可视化，尤其是在看并行 agent 的时候。如果你不是 power user，这种方式更容易滚动查看，UI 更舒服。

所以你的建议其实可以概括成一句话：如果你不喜欢 Claude Code，就去试试 Claude Cowork，或者其他类似但更可视化的东西。也许那才更适合你。当然，也有人就是喜欢命令行。我自己其实就更常用 UI，因为我真的不想去记命令，虽然说出来有点丢人，不过现在可能也不算丢人了。

Steve Yegge：关键在于尝试，只要你在试就行。我认为，如今衡量一家公司最重要的指标，或许就是模型调用量（token burn）。因为这个数值代表着你的工程师在主动尝试做事，非技术岗的员工也在摸索。只要他们在试，就会经历失败、从中学习。所以如果你想尽早发现组织的瓶颈，想尽快把工程师往我所说的八级能力模型上推，想尽早理顺业务流程，那从现在开始就得动手试。试什么不重要，用哪个工具也不重要，只要你在使用 AI，并且努力让它落地解决工作问题，你做的就是正确的事。

现在最大的问题是，很多人根本不知道 “该怎么试” AI。他们随便用用，AI 出错了（它当然会经常出错），然后就下结论：“这玩意儿就是垃圾。” 所以你得告诉他们，AI 其实更像一把铲子，它不是《幻想曲》里那种能自己乱跑的魔法扫帚，而是需要你亲手拿起来、用它挖土的工具。区别只在于，以前你只能靠手挖，现在多了这把趁手的工具。这个类比很简单，但很多人就是绕不过这个弯。

另外，我想说一句可能有争议但无比现实的话：大多数人不擅长阅读。真的，我这辈子很多工作搞砸，根源都是高估了人们的阅读能力。我甚至觉得，阅读这项技能现在比以往任何时候都更稀缺。但问题是，Claude Code 会逼着你去读大量内容。所以我认为接下来这段时间，我们会处在一个很尴尬的过渡阶段：在足够好用的可视化界面出现之前，那些不会读、或者不擅长阅读的人，会陷入极大的劣势。

主持人：展开讲讲这个观察吧。你说很多人、很多开发者“不会读”，可你以前在 Amazon，那可是一个据说建立在六页备忘录和深度阅读基础上的地方。

Steve Yegge：大多数人真的不会读。你可能没意识到，他们读得非常慢。对大多数人来说，五段话就已经是一篇“长文”了。在美国，高中教的就是五段式作文。也许阿姆斯特丹的高中作文要写 100 段，但在我们这里，五段就已经算多的了。可 AI 呢？它写五段内容，都还只是刚开个头、清清嗓子而已。

所以你必须能读懂 “如瀑布般涌来的大量文本”，但显然这套方式不可能适用于所有人。因此未来必然需要递归式摘要，需要一种 “工厂化” 的操作界面。

Gas Town 现在的问题恰恰就在这里：我为什么说它现在还不适合用？因为它就像一间工厂，里面全是干活的agent，而你现在只能靠打电话和工厂沟通；你也可以凑到窗边敲玻璃、冲里面的工人喊话，但并没有真正 “走进工厂”。可一旦有了可视化界面，你就能进去，能清楚看到里面到底在发生什么，而现在这些过程大多是不可见的，很难观察和掌控。

所以我现在愿意给一个非常大胆的预测：年底前我们很快就会看到 demo，而到了年底，大多数人写程序都会变成“对着一张脸说话”。

主持人：“对着一张脸说话”，你的意思是对着一个屏幕形象？

Steve Yegge：对。你的 AI，比如 Gas Town 里的 “市长”，形象可能就是一只狐狸，就坐在那儿跟你对话。你问它：“为什么这个东西跑不起来？” 它会说：“我去看看。” 然后它就会像现在这样，去调度手下的那些agent干活。但你面对的，会是一个可视化的形象，而且它会直接用语音跟你交流。我相信，对绝大多数人来说，最终真正能走通、能普及的，也只会是这种形式。

主持人：太有意思了，我们把这个记下来，算一个预测。

Steve Yegge：我不会去做。

Gas Town，一个验证边界的想法工厂

主持人：那我们来聊聊 Gas Town，很多人都听说过它。到底什么是 Gas Town？

Steve Yegge：Gas Town 本质上就是一个智能体编排器（orchestrator）。

简单梳理一下时间线：2023 年是代码补全的时代，当时所有人都在关注 “补全接受率” 这个指标。顺带说一句，这是个挺蠢的指标，但也不是完全没用，至少能看出大家有没有真的在尝试用 AI。到了 2024 年，行业就进入了对话交互（chat）阶段，而 2025 年则会全面进入智能体（agents）时代。

你顺着这条曲线看就会发现：如果说对话交互的本质，是把代码补全放进交互循环里；智能体又是把对话交互放进循环里；那下一步必然是把智能代理也放进循环里，这就形成了编排器。后来市场上陆续出现了类似的产品，而我只是做了一个符合自己视角的版本。但说到底，它的核心逻辑就是agents 跑 agents。

主持人：如果是一个软件工程师来理解它，从架构角度该怎么想象？

Steve Yegge：说实话，Gas Town 非常复杂，而且它这周都是停服状态的，因为我正在把它迁移到 Dolt 上。正是在这个过程中，我才真切意识到它到底有多复杂，它的功能太多了。

Dolt 是一个基于 Git 构建的数据库，你可以理解为它强行把 git 和数据库粘在一起，不过这次是真的有数据库这样做了。

理想中的Gas Town 应该是：你只需要和一个 “市长（mayor）” 交互，这是你的核心接口；剩下所有该做的事，都由它去分派给底下的 “工人（workers）” 完成。当然，实际情况会比这复杂一些，因为我发现人类的工作大概能分成两类，而现在大家也一直在争论，到底哪一种工作模式才是正确的。

有些 Anthropic 的人跟我说，这其实是一个“上下文最大化 vs 最小化”的争论。有人相信，你应该尽可能把 context window 塞满，给 AI 特别丰富的上下文，这样它跟你说话时就会更像一个全知全能的智者，他们希望把上下文塞到极限。另一派人则会说：task，拆掉，继续 task，继续拆。我就想要最短的窗口，因为 token 越多，成本是极速上升，而且认知质量会明显下降，模型会开始跑神、丢失线索。

所以到底哪种才对？我看了自己的工作流之后，得出的结论是：polecats 适合做最小化，crew 适合做最大化。所以在 Gas Town 里，我其实设计了两种最基本的 worker 角色。

一种是特别简单的，如果你手里有一个定义得非常清楚、已经拆成子任务、而且高度自包含的任务，那你就可以直接交给一个 worker，让它去做；另一种是那种特别难的设计问题，你需要围绕这个问题进行一连串对话，那我就会把上下文拉满，告诉它：“把这些文档都读了，然后我们再聊。”本质上就是两套工作流。

主持人：那在实际中它到底是怎么运转的？你自己用下来怎么样？别人用下来又怎么样？

Steve Yegge：这是一个很棒的实验，真的。从某种意义上说，我是故意做了一个现在还跑不顺的东西，因为这对模型来说太难了，连 Opus 4.5 都只能算勉强够用。

有意思的是，Anthropic 内部有些人跟我说，他们挺喜欢这个项目，但也多少有点尴尬，因为我看起来像是在给他们模型里的各种问题打补丁。某种意义上确实如此，但严格来说那也不算真正的 Bug，只是他们的模型本来就不是按照 “工厂流水线工人” 的定位去训练的，只不过很快就会朝那个方向去优化训练了。

所以，未来 Gas Town 里很多东西都会消失，很多复杂度、监控角色其实都只是为了让 Opus 4.5 暂时更聪明一点。从这个角度看，我其实站在了错误的一边，像是在对抗 Bitter Lesson（痛苦教训）。

因此，Gas Town 最终会不断简化，最后收敛成一种极简的 minimax 结构：需要最大化上下文的任务，交给 crew；适合最小化上下文的任务，交给 polecats。我觉得这就是它自然会演化成的形态，然后再在这个基础上往上扩展。

主持人：那这些 polecats，会不会最终就只是子agent呢？

Steve Yegge：某种意义上，polecats 就是子agent。只不过在我这里，它们不是那种完全不可见的“二等公民”。它们有自己的身份、收件箱，你可以直接跟它们说话，还能通过 skill vectors 观察它们随时间的表现变化，所以它们比普通的子agent更“独立”一点。

普通子agent 最大的问题是不透明。你说“我派一堆子agent去做这个工作，做完告诉我。”然后你就只能等。可在 Gas Town 里，你可以直接去看它们，心里吐槽：“这家伙不行，我得戳它一下。”所以 Gas Town 给你的是一种非常强的亲手操控、实时引导的感觉。它不会从你面前消失，甚至是故意留在你视野里的。

不过它真的很好玩，它前几天停了，我就特别想它。跟它比起来，直接跟普通 Claude 一起工作真的很难受，因为 Gas Town 是一个想法工厂。等它真正完整跑起来、全部启动之后，你可以同时推进很多事情，还能相对清晰地跟踪每一件事的进度。

当然，它也会把你“吸”进去。你会不睡觉、不吃饭，整个人陷进去，这对你并不好。我其实也很想聊聊这件事，整个行业现在都在发生这种状况。但先说回 Gas Town 本身。里面所有角色、所有命名，其实都是我故意设计的。

为什么要做 Gas Town？因为我想推动推动认知边界。

去年我只要一说编排要来了，大家就会说：不，agents 不会有群体智能（swarm），不会有编排，你说的这些都不成立。现在他们的说法变了，现在他们会说：“兄弟，你这也太激进了吧。”注意，这已经是完全不同层次的争论了。以前是在说“不可能”，现在是在说：“你的群体智能也许做不了xxx。”也就是说，整个讨论已经从“不可能的领域”被我硬生生推到了“可能的领域”。

主持人：所以，你其实是故意接了一个比你本来合理预期更难啃的东西，因为你既想给这些模型做压力测试，也想看看它们到底能做到哪一步？

Steve Yegge：对，就是想弄清楚它们到底能做到什么。说白了，也是想找乐子，看看下一步会发生什么，而且我现在还在继续这么干。

我的下一个项目，就是想把 100 个 Gas Town 串起来。我们现在有个 Discord 社区。如果像 Moltbook 那样，大家愿意为了好玩往里投 token，给自己 agent 的推理付钱，那如果我把 100 个 Gas Town 串起来，大家一起决定造一个东西，我们就能学会联邦的运行机制。

某种意义上，我们可能是在重走 Ethereum 走过的路，但不管怎么说，我们会做出一些很惊人的东西。这有点像一个个人版本的Moltbook，反正大概就是那种感觉。

主持人：那关于 Gas Town，外界有没有哪些误解？

Steve Yegge：首先，我真心觉得现在大家不该拿它当生产工具来用，但偏偏已经有人在用了。我是认真的。

主持人：你说“不该用”，意思是不该真的用，除非你是在做研究，或者你非常清楚它现在就只是个 proof of concept？

Steve Yegge：对，差不多就是这个意思。

不过也有一些我最近接触到的、非常非常聪明的人，他们一直在认真寻找：在大公司里，比如财富50强级别的公司，Gas Town 现在有没有某些子问题、某些问题类别，是可以真正派上用场的。结果他们还真找出了一些场景，我听完都觉得这想法挺聪明。

其中一个例子，是我聊过的一家公司。他们会根据客户需求，在任意区域帮你搭建定制化数据中心。这件事 AWS 从来没真正做好过，Google 也一直在尝试。他们说，整个流程就是长达三个月、无比痛苦的重复点按钮：装软件、检查是否一切正常。而这个流程的验收标准非常清晰，几乎快形成固定循环了。

所以他们觉得，Gas Town 或许可以用群体智能的方式一点点收敛，最后跑出一套真正可用的数据中心配置，把人从重复劳动里解放出来。我听完就觉得：行，这个思路可行。这种场景甚至真的能提升他们为客户快速搭建更多数据中心的能力。

还有同一个人跟我说，他最近在研究生产故障。他发现，系统一旦挂掉，本来就已经处在一个不确定、未知、破损的状态里了。既然本来就乱了，那 AI 还能把它搞得多糟呢？当然，我也提醒了他：不，它其实还能搞得更糟。

但他的思路是，有些特定类型的故障，至少可以让 AI 先进入调查模式，帮忙加速排查。也就是说，人们现在正在寻找那些“模糊问题”。还有第三类场景，我一下子想不起来了。但总之，现在已经开始浮现出一批问题类别：你可以对它们上群体智能因为你不在乎结果够不够整齐，你要的是累计工作的推进效果。

而这其实也是我现在写代码的方式。我自己也确实是吃得比自己能消化的多了，这没得洗。Gas Town 现在就是一团大乱。很多人都在说：“他最后会把自己 vibe code 进死胡同，然后哭着出来。”老实说，这话离真相也没那么远。只不过在我们“上飞机”之前，我确实又把它拉回正轨了，现在它又能跑了。

百倍提效后，就让员工一天工作3小时

主持人：你说你自己已经不怎么看代码了，而是让 agents 去写代码。这跟你过去整个职业生涯其实非常不一样，你一直都很在意代码工艺、优雅性。你为什么会决定这么做？结果到底怎么样？

Steve Yegge：它在彻底陷入混乱之前，能够稳定、有效构建的代码规模上限，正在不断往上抬。只是目前这个上限，大概还停留在 50 万行～500 万行代码之间，而且更可能偏向 50 万行这一侧。等 Anthropic 下一代模型出来之后，我觉得这个上限很可能会直接跳到几百万行级别。

这已经是相当大的工程规模了，但和企业真正拥有的代码量比起来，仍然完全不在一个量级。企业级代码库实在太庞大了，动不动就是几亿行、甚至几十亿行。

主持人：对，但通常也不会全都塞在一个代码库里。哪怕是几百万行代码，其实也已经是一个很大的 codebase 了，通常会有 50 多个人，甚至一两百多人一起维护。

Steve Yegge：对。所以如果总结下我们前面的讨论，结论其实很简单：你能在多大程度上用好 AI，几乎完全取决于你的系统是不是单体架构。而几乎每家公司，其实都是一个大单体，再加上一堆微服务。如果你是这样，那基本就麻烦大了。因为模型能力的上限虽然在上升，但它永远也不可能真正覆盖你的单体架构，那东西永远塞不进上下文窗口里。

至少在接下来一年半里，你都不可能直接对一个模型说：“去，把我的单体架构修好。”你必须先把它拆开，或者干脆重写。说实话，到了现在这个阶段，重新把整套技术栈改写一遍，已经开始变得越来越像一个更快的选择了。

主持人：在开录前还提到一件事，说 AI 其实特别消耗人。它会抽走你的精力，把你整个吸进去。你能展开讲讲吗？

Steve Yegge：现在真的有件事正在发生，而且我觉得我们这个行业、这个社区，必须开始认真讨论了。

AI 身上正在出现一种“吸血鬼效应”。它会让你异常兴奋，然后你工作会特别特别拼，你会不断抓住新的价值。对我来说，我现在是在替自己干活，可即便如此，它还是把我推到了快要耗尽的边缘，我现在白天会打盹。我也跟一些创业公司的朋友聊，他们也开始白天打盹。特别好笑的是，他们甚至会故意拼命往对方脑子里灌上下文，想把对方灌到不得不去睡一觉。这简直像一种“强制午睡式的同情行为”。太奇怪了。

大家开始累了，开始烦躁了。我去问行业里的人，他们也开始变得疲惫、暴躁。

问题在于，公司天生就是从你身上提取价值，然后给你付钱。可公司过去一直的运行方式都是：只要你还能扛，他们就会不断往你身上加工作。你能做？那就再给你一点。再能做？再给你一点。一直给，直到你彻底接不住，人也跟着垮掉。人们一直都得学会一件事，就是怎么把这种压力顶回去，这件事本来也存在很久了。

但现在，整个方程式变了。你反推回去的方式、你为什么要反推回去，这些全都在剧烈变化。因为现在出现了一大批可以极端高产的人。假设一个工程师的生产率提升了 100 倍，那这个新增的价值到底归谁？如果这个工程师每天还是去上 8 个小时班，却产出了过去 100 倍的成果，那公司就把这 100 倍价值几乎全部拿走了。而这并不是一个公平的价值交换。

主持人：我觉得这个判断可以讨论。除非这个人拿了非常早期、非常有分量的股权，那情况会有点不一样。但这种人毕竟是少数，不是大多数。

Steve Yegge：对，而且我们很可能正在迅速走到那个临界点。大概半年前，我们就注意到一个现象，你应该也看到了，就是 AI 创业公司的 996 问题。大家当时都在说“很有意思，AI 创业公司里的人工作时长吓人得很，他们会在凌晨三点发帖，说自己还在办公室。”

996 就是早上 9 点到晚上 9 点，一周 6 天。至少据我所知，在东亚和东南亚很多地方，这几乎都是默认的工作节奏。我虽然没去过中国或印度，但我猜那边应该也差不多。

但与此同时，还有另一群人，他们把新增价值几乎全拿走了。他们一天也许只工作 10 分钟，却完成了过去 100 倍的产出，而且谁也不说，于是所有新增价值都落进了他们自己口袋里。可那样其实也不理想。至少从“一个团队怎样才能成功”的角度来看，最好的状态还是大家都在贡献。

所以问题来了：那该怎么办？我觉得答案是，我们每个人都得尽快学会说“不”，而且要特别擅长这件事。我们得学会如何开始真正为自己“捕获价值”。这其实就是新的 work-life balance。关键问题变成了：当你的生产率提升 100 倍之后，你到底打算把其中多少价值留给自己，又打算把多少交给你的雇主？

而这会特别难，因为我们的文化预期几乎全是反着来的。所有文化信号都在鼓励我们更努力、更拼命，因为所有人都想继续“提取、提取、再提取”。所以我真心觉得，从创始人到公司管理层、工程负责人，一直到基层直属主管，都必须意识到这件事：一旦你把工程师放上这条跑步机，你就是在把他们拖进一种完全不同的消耗模式里。

他们现在调动的是更多的 system 2，也就是那种更重、更累、更高强度的深度思考。那些轻松的工作已经被自动化了，所以他们反而在以更高的速度被“放电”。他们的能量掉得更快，一个人在全速 vibe coding 状态下，也许一天真正高质量输出最多只有 3 个小时，但即便如此，他的总产出仍然可能是过去没有 AI 时的 100 倍。那问题就来了：你是不是应该只让他们一天工作 3 个小时？我的答案是：对，你最好这么做。不然你的公司迟早会垮掉。

主持人：这点特别有意思。尤其是说到价值提取，我能明显感觉到速度正在被拉得越来越快。像 Peter Steinberger 这样的人，单枪匹马就能推出来巨大的价值，不管是提交量还是各种产出，放到以前，那至少得是 10 个很强的工程师的团队才能做到。当然，公平地说，他也确实是在“捕获”这部分价值，因为那是他自己的项目，虽然代价是他也几乎不怎么睡觉。所以在那种情况下，价值捕获至少是相对合理的。

但我同意你的判断，这件事会变得很麻烦。过去每一次技术变革让人类效率提高时，在你职业生涯里，你有没有见过类似的时刻？就是工程师突然能用更少的人做更多事，然后行业里发生了什么？

Steve Yegge：比如 Perl。Perl 本身就是一种巨大的生产力放大器。早年的 Amazon 网站就是用 Perl 搭起来的，我甚至怀疑，直到今天它某些部分可能还在跑 Perl。至于 Facebook，从技术气质上看，PHP 某种意义上就像一种“假的 Perl”。

这两种语言当年都带来了极其惊人的生产力提升，而且这种提升是所有人肉眼都能看见的。没人会想拿 C 去做网站，你根本不会这么选。Amazon 当年也试过，后来还是放弃了。但那一波变化最后也带来了非常明显的分化：有些人开始被挤到更边缘的位置，变成某种意义上的“二等公民”，随之而来的还有各种文化层面的紧张、冲突和撕裂。

Anthropic 内部的“蜂巢心智”

主持人：我很好奇，有些 AI 公司是怎么处理这个问题的。我们能不能聊聊 Anthropic 是怎么运作的？

Steve Yegge：可以。就我观察的情况看，Anthropic 是个非常有意思的地方。Dario 最近说过一句话，我印象特别深。他觉得，未来某种补偿模式也许应该变成这样：一个人即便离开公司之后，也还能继续因为自己曾经创造的价值而获得回报。这种说法前所未有，但也说明他已经意识到，一个人如今可以在很短时间内创造出巨大的价值。

顺便说一句，Google 也可以给我补张支票，把当年那些没付给我的价值补上。这个想法我很喜欢。

Anthropic 现在是世界上独一无二的一家公司。它处在一个极其脆弱又极其前沿的空间里，所以它非常小心地保护这种状态，而且它确实也必须这样做，因为他们其实已经创造出了一种“蜂巢心智”。从我能看出来的情况看，他们在经营公司时，几乎就像在操作一个纯函数式数据结构。

你还记得 Chris Okasaki 那本书吗？那本书当年看得人头都发麻：你居然能构造出一种从不变异的数据结构。那它怎么更新呢？答案不是去改它，不断往上加内容。就像 improv 里的 “Yes, and…”，他们现在的运作方式，差不多就是这样。

主持人：你说的“蜂巢心智”，具体是什么意思？

Steve Yegge：这东西有点像现在的市场，全是 vibes，一切都是 vibes。它会不断漂移、不断变化，很难一句话讲明白。

但关键在于，过去我们做产品的方式是先写 spec、再去实现，过程中不断抱怨，然后把它发出去。再配合 road map，按年度节奏规划、公司年会节点卡时间发。像 Apple，那种一年一次的节奏。

可如果你是跟 Gas Town 这样的系统一起工作，或者像 Anthropic 那种已经有了自己内部 orchestrator 的公司，做法就不一样了。你会先做出一个原型，而那个原型本身就是产品。就连那个原本不写代码的联合创始人，也会参与把原型搭出来。然后大家就围着这个原型不断往上建，直到它变成“正确的东西”为止。所有人都会像围着篝火一样围着那个原型一起做，而 Anthropic 现在就是在用这种方式、以数千人的规模在运转。

主持人：所有经历过那一代软件工程的人，几乎都会默认原型不能上线，你必须告诉大家那只是一次性原型，后面要重新来，做生产就绪、可扩展的正式版本，因为你不想让用户拿到一个糟糕体验。那现在到底变了什么？

Steve Yegge：变的是你可以做“无限多个原型”。所以现在的逻辑变成了，你就一直做原型，做到某个原型真的特别好，然后你说：“行，就发这个。”

据我所知，Claude Cowork 大概就是这么来的。有人说：“嘿，我做了个原型。”然后大家看了觉得：“这东西我们可以直接发。”结果 10 天之后，他们就上线了。所以，这套方法确实是有效的。

主持人：不过这里有个重要背景。我之前跟 Boris Cherny 聊过他们怎么做 Claude Code 里的 task list 功能。他跟我说，那一项功能他两天就做了 20 个不同的、而且都能跑的原型，全都是借助 AI 做的。

Steve Yegge：我之前还不知道他在做这个，但他干的事正好就是我之前说的这种路数。他们管这叫 “老虎机式编程（slot machine programming）”？意思就是先一口气做出 20 个不同的实现版本，然后再从中挑最好的那个？

主持人：差不多。我不想替他下定义，但我当时真的很震惊。因为如果放在以前，做出 20 个能跑的原型可能得花两周，而且通常你做到第 3 个就停了。

Steve Yegge：这其实就在我们那本书里。书里提到一个缩写，叫 FAFO，里面那个 O 指的就是 optionality，也就是你能够同时创造大量原型的能力。它本质上让你可以把决策推迟到真正知道正确答案的时候再做。说白了，这是一种“作弊”。当然，所有人都会这么干，这会从根本上改变公司运转方式，改变个人和组织创造软件的方式，而且这件事就是今年会发生的。

谷歌：先抢工作，但不做

主持人：这些变化真的很惊人，可到底是什么在推动这种变化？是不是因为我们现在能更快迭代了？

Steve Yegge：这里其实有两个答案，一个是大公司的，一个是小公司的。

我在 Google 亲身经历过一件事。那时正好是 Google 的黄金时代，很像现在的 Anthropic。那时候它真的像一个蜂巢心智，没人刻薄，大家都在创新，一切都特别美好。创始人离大家很近，你去 cafeteria，Larry 和 Sergey 就坐在那里，你甚至可以直接跟他们聊天。那真的是黄金时代。

后来情况突然变了。我们做了几次战略转向，Google 也就不再是原来那家公司了。创新基本是在萌芽阶段就直接死掉了。从 2008 年左右开始，Google 几乎就没有真正新的创新，全靠收购。他们后来几乎没再自己创造出什么真正新的东西。

主持人：但他们后来不是还有 Gemini 吗？

Steve Yegge：Gemini？好吧，算是个例子。他们确实做出了大模型，但又什么都没真正做成。而这恰恰就是 Google 创新怎么死掉的最佳写照：整整五年，他们什么都没做。所以在我看来，Gemini 属于另一个 Google。我们现在说的是那个把一切搞砸的 Google。

我不希望 Anthropic 也像 Google 那样把自己搞坏。Google 当年其实也做过很多措施，想防止自己变成后来那家被组织架构腐蚀、充满地盘意识、谁也动不了谁工作的公司。我曾经从 Microsoft 挖过来一个非常聪明的人，把他带到 Google，然后跟他说：“你先慢慢看，想清楚自己要做什么。”结果他花了整整 6 个月，才找到一件还没被别人“占坑”的事。Google 的问题就是大家会先把工作抢到手，然后根本不做。

我现在要说一个以前从没说过的新判断：我觉得 Google 的转折点，就是 Larry Page 当上 CEO 后说的那句口号 “put more wood behind fewer arrows”（集中火力，少而精）。从那一刻起，他实际上按下了创新的刹车。

在那之前是“工作比人多”，在那之后变成了“人比工作多”，于是所有人开始争抢工作。这就是为什么后来会出现各种地盘争夺、背刺、帝国扩张，还有你在大公司里看到的那种政治斗争。所有政治本质上都是在争工作。

再说回 Anthropic，他们现在站在前沿，工作是无限的，字面意义上的无限。每个人都忙不过来。我在 Amazon 的一个朋友以前跟我说过，Amazon 没有 Google 那么多毛病，原因之一就是每个人都总是“稍微超载一点”，永远都有太多工作要做。

主持人：我听说 Apple 也是类似的，刻意为之。假如我看到了agents 确实能让我更高产，而且幅度不小。那么，如果很多公司都经历了同样的事，大家突然之间都能干更多活了，大公司内部会不会反而冒出更多政治？

Steve Yegge：如果“坏事开始发生”的触发器真的是“人比工作多”，那现在人们突然能把工作都做完了，公司最大的难题就会变成“我去哪里再找更多工作？”或者“我就得裁人了。”这显然很糟。

但从细节看，这与 Gas Town 并无不同。Gas Town 对我最大的挑战，就是“喂饱它”。因为它跑得太快了，我反而得拼命想出足够好的设计任务给它。这也是为什么我整天要去打盹，我得不停地想更难的活儿喂给它。其他人也说过同样的话。这不只是 Gas Town 的问题，而是所有编排工具都面临的问题。也不一定非得是 Gas Town，说实话，Gas Town 本身大概四个月后就死了。它只是 2025 年 12 月那个时间点上“有效”的形态，四个月后就不会再是了。

大厂创新已死

主持人：那能不能举个更具体的例子？有没有什么已经被真正构建出来、进入生产的软件，是通过编排或这种高生产率方式做出来的？反过来说，为什么我们现在从外部看，很多公司和团队明明生产率都提高了，可日常生活里、常用应用里，好像还没有看到什么特别大的变化？

Steve Yegge：有道理，我的感觉是，人们对非确定性的容忍度依然很低，而这些系统本质上就是非确定性的。所以公司没法直接把它们拿去替换客服软件，因为它们有可能答错。尽管人类自己也经常答错，而且现在的 AI 很容易就能达到普通人类员工的水平，可公司还是会觉得风险很高。

所以我觉得，那些真正已经跑起来的公司，实际上已经开始看到效果了。只是这些效果会先以一种“不显眼”的方式体现在季度财报里，或者体现在别的地方。

主持人：有没有一种可能，我们现在都把目光放在“工具建设”这件事上了？

Steve Yegge：我甚至想把问题倒过来看，会不会我们现在真正观察到的，其实是大公司里的创新已经死了？未来真正的创新，可能只会从小地方冒出来。

这很像云刚出来的时候。Facebook 最初不也是一个大学生在做吗？今天 Facebook 看起来像世界上最大的公司之一，但它一开始就是一个人。

每当一种新的平台级基础设施出现时，创新最先都会出现在边缘地带，因为大公司会被“创新者困境”卡死，它们根本创新不了，现在它们其实也正卡在这里。哪怕公司里已经有了一批生产率极高、跑得飞快的工程师，组织本身却根本没法在下游把这些产出接住。到处都是瓶颈，这些工程师会被层层卡住，最后干脆离开。

所以我觉得，现在大家都在盯着那些大公司说：“你们什么时候能拿出点新东西给我们看？”可真正的答案是：我们盯着看的，其实是一批已经死掉的大公司，只是我们还没意识到它们已经死了而已。

主持人：你觉得它们已经死了，是因为比如说，现在很多事情已经可以用更低的成本来完成了。就拿那个永远被拿出来当靶子的 Zendesk 客服来说，它之所以一直是客户支持领域的默认选择，是因为客服人员注册后就能直接拿到现成的 UI、工作流等等。

但对于那些基于 MCPs 之类机制运作的 AI-native 公司来说，这套东西其实根本说不通。因为它们真正想要的是 API，而 Zendesk 并不想把 API 轻轻松松交给你。它更想做的是把你拉到它的平台上，然后让你花高得多的价钱去买它自己的 AI，可能贵到十倍不止。

Steve Yegge：这种模式在未来几年会很难撑下去，因为人们会直接用 API 去搭自己的东西，做更贴身的定制化系统。这其实就是我一直在讲的那套“平台”逻辑，如果 Zendesk 不把自己真正做成一个平台，那它最后很可能只是在把自己“卖”出局。

主持人：真正的平台会是什么？是 API 吗？还是 MCP？

Steve Yegge：至少目前看，未必是 MCP。Anthropic 发现的一件事是，与其用 MCP，不如让 AI 自己写一层 API 来调用 MCP，因为它们现在写代码已经太强了。但说到底，这也没真的改变什么，因为平台从一开始本来就是 API。

所以我们为什么需要 MCP？因为总得有某种方式，用 AI 能理解的形式去声明这个工具是干什么的。但它太松散也太灵活了，未来集成会变得非常容易。

我现在没那么持续跟这个方向，所以不敢说 MCP 最后会不会继续成为主导力量，还是说 AI 直接通过命令行工具或 API 去调用各种能力。但不管是哪种情况，我们都正在进入一个新世界：创新会从那些新公司里冒出来，那些已经真正接纳并适应了变化的小团队会往前冲，而大公司会非常艰难。

主持人：我们会不会看到，越来越多过去根本没意识到自己需要的基础组件开始冒出来？

Steve Yegge：我觉得，接下来我们会看到一个巨大的基础组件生态，尤其是面向那些没有技术背景、但又真的想自己做东西的人。因为这类人迟早都会需要各种各样的 API：存储、匹配、搜索，或者任何他们绕不过去的基础能力。

主持人：所以如果你现在还在科技行业里，而且正在寻找值得投入方向，不管是因为你觉得自己的工作开始不稳了，还是你就是想出来做点东西，那现在真的是一个很好的时机，去做那些我们接下来一定会需要的基础组件。尤其是那些可靠的基础组件，那些有状态、要有 SLA、有一定关键性的东西，不是随手就能糊出来的那种。

Steve Yegge：因为 AI 本身也很懒，这其实完全可以理解，它们不想在没必要的时候烧 tokens。所以如果你提供了一项服务，能让某件事情对它们来说更方便，它们绝对会用。

主持人：特别是那些你必须持续维护的服务，比如你要跟上法规变化、日志要求、接口变化之类的。因为这些事，哪怕只是靠 prompt 让 AI 每天回头更新一次，其实也有很多工作。说到底，人类自己也一样懒。

Steve Yegge：对。Larry Wall 当年就说过，这本来就是程序员的美德之一。

产品游戏化，如何处理“vibe coding 债”

主持人：我想回到你另一篇 2012 年的文章，叫《Borderlands Gun Collector Club》，我最近才去读。你在里面谈到了 gamification。你提到自己当年玩过 Borderlands，通关之后，游戏里出现了一个很奇怪的机制：玩家会为了拿到定制化的枪，不断回来继续玩。那几乎像是一个设计师事先没想到的元目标，但它反而让这个游戏变得特别上头。

你当时好像把它叫作某种“elder game”之类的概念，大概是这事虽然像是游戏设计师误打误撞做出来的，但其实挺聪明的，也许更多游戏都该这样做，因为它确实会让游戏更让人沉迷。从 2012 年到现在，我们已经看到越来越多游戏开始有意识地加入这种机制，而且不只是游戏，很多别的产品也是这样。

Steve Yegge：对，很多产品后来都陆续遵循了这个机制。是谁来着，是 Borderlands 的 Take-Two 还是什么，我有点记不清了。总之，他们很早就摸到了这个点，但后来并没有真正把它彻底放大做起来。

不过很有意思的是，我觉得现在确实又能看到 gamification 冒头了。已经有人指出，大家正在给 Gas Town 做“游戏前端”。说真的，为什么不把它直接做成游戏呢？我们明明都已经有一堆“经营工厂”的游戏了。那如果你真的在经营一座真正的工厂，会有多酷？而这本来就是 Gas Town 的本质，这也是为什么它那么好玩。

主持人：你是不是觉得，某些 agent 比别的 agent 更成功的一个原因，是像 Claude Code 这样的产品里其实也带着一点“游戏化”设计？界面上总有东西在动，总有东西在显示？

Steve Yegge：我觉得他们拥有世界上最强的产品经理。他们在命令行 UI 和相关交互上，真的是做出了近乎魔法一样的东西，特别夸张。但说到底，这套东西对大多数开发者来说是行不通的。所以 Claude Cowork 才会这么酷，对吧？

我觉得，这就是未来会演化的方向。开发者未来会更多使用 Claude Cowork，或者某种更接近它的东西。

主持人：传统软件开发里，我们有“技术债”这个概念，而且大家都知道该怎么处理。我们过去花了很多时间都在忙这些事：积累技术债、偿还技术债、做迁移，诸如此类。那现在，当我们开始做大量 vibe coding，或者说agentic engineering，快速产出海量代码。你觉得我们该怎么识别、处理，或者说，我们到底需不需要处理这种“vibe coding 债”、“agentic 债”？

Steve Yegge：这其实正是我接下来一篇博客要写的内容之一。因为我发现了一个现象，我给它起了个名字，叫 heresy，也就是“异端”。

这种东西会出现在那些你并没有亲自盯着看的、由 vibe coding 生成出来的代码库里。它的本质是：在 agents 之间扎根的某个错误的想法。这个想法本身是错的，可能是错误的架构、错误的数据流或者别的，总之它会和你剩下那部分代码形成某种“阻抗不匹配”。

我之所以把它叫作 heresy，是因为这种东西特别容易扩散，也特别容易卷土重来，而且非常难清理干净。

Gas Town 里我就遇到过一堆这种问题。其中有一个叫 “polecat heresy”，它总会反复出现。结果就是，这些问题平时是不可见的，但你的产品会开始在边缘地带失灵，而且你一开始根本不知道为什么。然后你让 agents 去深挖后才发现，你的系统里其实已经出现了裂缝、断层。比如，系统里居然同时存在两套完整、都在运行的数据库，而代码还在随机从这两个数据库里二选一，而你这一刻才意识到这件事。

你会在代码里发现各种可怕的问题，然后你试图把这些问题彻底清干净，可只要某份文档里还残留着一条相关引用，被某个 agent 看到之后，它就会想：“哦，这个逻辑说得通啊。”于是那个 heresy 又回来了。agent 就会继续按错误方式工作，重新把那个 heresy 建起来，然后它又开始扩散。它会一次次卷土重来。

就像这些 agents 天生就想让系统按某种方式运转，而你却在告诉它们：“不，我要的是另一种方式。”于是你就得不断跟它们对抗。你真正该做的，是在 prompt 的一开始就把这个 heresy 写清楚，明确告诉它：“这是你在这个项目里最容易走错的一条路，不要这么干。”而且你还得定期提醒它，甚至要上工具层面的约束，防止它重犯。

另一个 heresy 是，我的 agents 全都觉得自己应该去提 PR。可问题是，我才是这份代码的 maintainer。你直接 push 到 main 就好了，或者 push 到某个 branch 上也行，别去开 PR。那只是在污染 PR 空间。PR 是给外部 contributor 用的。它们到现在还理解不了这一点。

现在，我当然也可以往里面塞一堆 hack 去限制它们，但那其实是在跟 Bitter Lesson 对着干。等 Opus 5 出来，这问题自然就没了。到时候 Opus 5 会直接明白：“哦，你不想要 PR？那我就不提 PR 了。”就这么简单。

主持人：那什么是 Bitter Lesson？

Steve Yegge：Richard Sutton 写过一篇很短的文章，大概 800 字左右，但那真的是最好的文章之一，标题就叫《The Bitter Lesson》。他的意思大概是：“我们这些 AI 研究者学到了一条非常痛苦的教训，而你们也需要学会这条教训。”

这条痛苦的教训就是：不要试图比 AI 更聪明。

你会以为，人类有某种特别的知识，人类能给这个问题带来特殊的领域知识；你会觉得，只要我们把这些知识教给 AI，它就会变得更聪明。但我们后来发现，真正成立的规律其实是：更大，就更聪明。

主持人：所以归根结底，还是更多数据？

Steve Yegge：对。你也看过那些图纸，知道 OpenAI 的训练中心有多大，Anthropic 的训练中心有多大。而现在的新训练中心，规模已经是原来的 10 倍了，大得离谱。它们之所以建在澳大利亚，是因为那里有足够的土地、能源以及其他资源，然后他们会基于这些设施，训练出比我们今天手上的模型聪明 10 倍甚至更多的模型。

主持人：我们聊了很多 vibe coding，可这件事真的不会让你难受吗？毕竟你是那种真正会造软件的人，你知道什么叫好软件。你以前就是那种能去收拾烂摊子的人，不管是新手团队留下的还是各种混乱局面。所以当 AI 一路冲进去、到处动手的时候，这件事不会让你难受吗？

Steve Yegge：问题在于，我也做过大公司的工程副总裁。

主持人：这倒也是。

Steve Yegge：所以，当我现在和 80 个 agents 一起工作时，这件事和带 80 个工程师团队，其实没那么大区别。80 个工程师里，也一样会有人搞砸事情。

所以，The Bitter Lesson 讲的就是：不要试图靠“更聪明”取胜，而要靠“更大”取胜。当然，这也不是让 AI 变聪明的唯一方式，他们也会在另外几个同样重要的前沿方向上继续把模型做得更聪明，而且这些方向现在也在推进。

我想说的是：现在所有那些觉得“曲线已经成型了”的人，他们其实是 100% 正确的。对，他们完全正确，这条曲线最终一定会长成那个形状。最终，我们当然会耗尽资源。这个世界的资源终究会不够用，曲线最后也一定会放缓。但我可以告诉你，这条曲线至少还剩下两个完整周期。而这意味着，模型至少还会比今天再聪明 16 倍。而那会让所有知识型工作，最终都被这套东西吞进去。

fork 开源项目是常态

主持人：更强的模型、更高的生产率会怎样影响“个人软件”，也就是人们自己给自己做的软件？我最近看到一个很有意思的现象，就是大量的 remix 在发生。比如，现在很多开源项目其实不怎么接收 PR ，因为很多 PR 质量都不高。但现在很多人直接开始 remix 了：他们拿一个开源项目，告诉 AI 做某个改动，然后再把改完的版本重新作为开源发出去。很多时候其实也没人看，但关键是，他们已经不需要再去征求谁的许可了。很多人都在把不同的东西编织在一起，会说，把这个项目和那个东西拼起来。

Steve Yegge：以前，“fork”这个词几乎像是一种宣战，如果你 fork 了某个人的项目，基本就意味着你已经受够他了。那时候 fork 往往代表着公开决裂，但我觉得现在它会变成一种日常操作。

主持人：对，因为以前要 fork 一个项目，意味着后面要花很多时间和精力去维护这个 fork，还要处理怎么跟上游合并的问题。

Steve Yegge：没错，fork 本来是一件非常严肃的事。真的很重。工作量特别大。但现在，这件事轻松多了。所以，未来每个人都会 fork。我认为这本来就是一个很自然的结果：既然每个人都能写代码，那当然每个人都能 fork。就像现在每个人都能拍照一样，而这在过去根本不是事实。

主持人：那你职业生涯早期有哪些一直深信不疑、而且长期都成立的观念，直到最近才因为 AI 被你彻底放弃了？

Steve Yegge：“工程师是特别的”，这算一个。

主持人：别这样，我们就是很特别。

Steve Yegge：我们当然可以这么想。只是说到底，我们不过是学会了一件原来得靠手工做、现在计算机自己也能做的事。某种意义上，也挺酷的吧。

主持人：工程师的思维方式呢？这不只是“会写代码”那样的吧，难道这些也不算吗？

Steve Yegge：有一点我还是相信的，人类对新软件的渴望永远不会下降，只会继续增长。所以，我们其实还处在软件时代的开头。我们今天拥有的绝大多数软件，本质上都是垃圾。真的，尤其是 OBS。

接下来的 10 年里，我们会进入一个全新的世界：软件会变得像空气一样常见，而且质量会好得多。你会有大量选择，而不再是现在这种局面：你得在 3 个都很烂的 OAuth 方案之间做选择，或者在几个都很糟糕的 HR 系统之间硬挑一个。今天的选择其实非常差，SaaS 很糟，整个行业很多东西都很糟。

主持人：航空公司的系统也是。

Steve Yegge：对，航空公司的 app 也是。我们之前在悉尼办过一个 vibe coding workshop，当时真有个人给自己写了一个航空值机 app，而且一度成功进了 Android 的值机队列，直到它被发现是个 bot，才被封掉。但这恰恰说明了，人们真正想要的就是这种为自己量身定制的个人软件，而且他们会得到的。

我觉得未来就是这样的。这也是为什么 Jeffrey Emmanuel fork 了 beads 之后，我的反应是：“干得漂亮，继续。”他自己好像还挺过意不去，但我当时就跟他说：兄弟，这就是新世界。来吧，让 beads 在每一种语言里都出现一份，我根本不在乎。

主持人：说句公道话，我真的希望自己日常用的那些东西能全部变成“好软件”。这世界上糟糕的软件太多了。

Steve Yegge：以后跟这些破软件打交道的会是你的 agent，不是你。但我也觉得，那些能写出 agent 喜欢用、愿意选、会优先调用的软件的人，只要再找到办法把这些东西推广出去、让 agents 知道它们的存在，他们就会赢得很大。因为未来每个人都会用 agent，都会依赖它。

主持人：而且我猜，另一类机会可能是去做那些能帮助 agents 写出高质量软件的工具。

Steve Yegge：对。所以我觉得，未来企业之间竞争的核心，会变成谁能做出越来越复杂的软件。上限会一直往上抬。我们会不断造出越来越大的东西，直到某天真的把“死星”都造出来，谁知道呢。总之，我们会持续往更大的方向走。

很奇怪的是，经历了这一切之后，我其实仍然是个乐观主义者。这大概就是我最核心的信念：我首先相信，这一切最后都会跑通。

主持人：所以，既然你刚刚是站在乐观主义者的角度在说，那我想接着问一个问题。如果有一天，任何软件都可以被轻而易举地复制，那软件行业还会怎么继续存在？到那时我们会处在什么位置？什么东西是不能被复制的？护城河到底是什么？

Steve Yegge：连接，人与人之间的连接，可能是最大的那个。某种意义上，这甚至有点反直觉：随着软件替你自动化完成越来越多的事，人们反而会开始说：“对，这当然可以自动完成，但那毕竟只是自动化而已，我还是想要一个真人来做。”

他们会希望是一个人把东西送到自己手上，而不是一架无人机；他们会希望由真人替自己做筛选、做判断、做策展。所以我觉得，未来真正的护城河会是人本身。

主持人：回头看历史，会不会觉得我们其实见过一些有点类似的变化？比如在更长的历史里，会不会也出现过这种时刻：某些行业因为自动化增强，反而让一些职业更兴盛，或者催生出新的机会？

Steve Yegge：Stack Overflow。我也不确定，但是我脑子里第一个跳出来的。还有 Mechanical Turk。我的意思是，我们以前也见过很多这种奇怪的、一步跨越很大的“台阶式变化”。只不过这一次，我们马上要同时看到很多个这样的变化一起发生。

看看最近的新闻就知道了。最有意思的是，大家嘴上都在问：“创新到底在哪里？”可与此同时，你每天打开新闻，又能看到满屏都是 AI 领域的创新。只是这些创新不是来自Microsoft 这样的大公司，而是来自那些冲出来的独立团队和小公司。创新其实已经在那里了。

而且，从我最近接触的这些创业公司来看，从两三个人到五个人、再到十几二十个人的都有，接下来几个月，我觉得我们会看到一些非常惊艳的产品上线。

要么完全透明，要么藏住不说

主持人：你看到这些小创业公司已经在改变自己的工作方式了吗？

Steve Yegge：天啊，完全不一样了，兄弟，真的完全不一样。先说最核心的一点，在这个新世界里，我现在非常确信：你做的任何事情，要么必须是完全透明的，要么你就是出于某种原因故意把它藏起来。

换句话说，如果你不想让别人看到你在做什么，那你就别给他们看，他们自然永远也不会看到。

但如果你想让别人看到你在做什么，那你最好在做的同时就立刻把它摆到他们面前。否则，列车一下就会从你身边开过去。

我在博客里讲过一个故事，很多人应该听过：有个团队成员，两小时前刚做完别人提的一个功能，结果反而被队友吼了。因为大家当时很生气，说：“那已经是两小时前的需求了！两小时过去，情况早就变了。”那个人就懵了，说：“那我到底该怎么办？”

现在大家正在进入这样一种状态：他们越来越清楚地意识到，事情变化得太快了，快到在这种信息量面前，一切其实都变得近乎不可见。所以你必须非常高调、非常透明、非常有意识地把你正在做的每一件事说出来。这样一来，如果别人也在做同样的事，他们就能立刻叫停你；如果他们需要和你集成，也能马上开始，不至于等你做完才发现已经错过了。

主持人：我们现在说的是那些还在寻找产品方向、寻找客户的初创公司。他们真正想要的，其实只是达到我们常说的产品市场契合点。

Steve Yegge：没错。以前的公式就是这样：尽量保密，努力找到产品市场契合点，然后上线，再继续调优。很多人过去信的就是这一套。

但现在，我在做 Gas Town 的时候意识到，我不可能靠自己一个人找到产品市场契合点。于是我在它 “勉强能跑” 的时候就立刻发布了出去，然后直接对大家说：“来，帮我。” 也正因为这样，我才发现了双数据库那个重大问题。后来很多人帮我修复了大量 bug，上线头几天，我就收到了 100 多个提交。所以，Gas Town 之所以能更接近产品市场契合点，恰恰是因为我尽早把它公开了。

主持人：那种突然起来的项目，像 Peter 的那些开源项目，它们现在真的已经能变成真正的公司了吗？我们已经走到这个阶段了吗？

Steve Yegge：我向你保证，如果是你做出了 Gas Town，你现在早就已经在和一群风投握手了。我现在的感觉就是，他们到处都能找到我，因为现在外面有太多钱在四处嗅探，想找机会流进来。资本已经知道，AI 这边一定会发生大事。你看，各种各样的微型经济体已经在到处冒出来了。

但没有什么比你发布一个很酷的东西时更能说明问题了。就像 Jeff Huntley 做 Ralph 的时候那样，风投全都来了，每个人都想跟你聊。只是你必须非常小心，因为你现在做出来的任何东西，保质期都可能非常短，真的非常短。我对 Gas Town 本身一点都不执着，因为我觉得 6 个月之内，甚至更快，它就会被更好的东西替代。所以，不要太投入感情。

主持人：那我们假设现在有一位资深工程师，他所在的公司还在使用 Copilot，也愿意相信你说的这一切，但还没法完全信服。你会对他们说什么？他们现在能做些什么，来证明你其实是对的、证明这套方式真的在生效？毕竟现实里真正做好的人连 50% 都不到。

Steve Yegge：别说 50% 了，我觉得可能还有 70% 的人根本没真正开始。所以你问我会对他们说什么？我其实有一句特别想对他们说的话，就是：赶紧出来，别再困在里面了。

想想看，如果把所有开发工具从好到差排个序，Copilot 基本已经快落到末尾了。它甚至都快搞不清自己还处在这条赛道的什么位置。可它当年，根本不是这样的。

主持人：它在 2021 年、也就是四年前的时候，明明还是最好的那个。

Steve Yegge：对。当年它绝对是领先者。甚至就在两年半前，它还在竞争里。有一次我去参加一个 AI 会议，当时有人问：“还有人用 Copilot 吗？”结果现场真有个人举手。那个人刚一举手，旁边立刻有人问他：“你是被逼着用的吗？”然后全场都笑了。

我当时就在想：这个品牌到底是怎么不行的？如果你现在待在一家还在用 Copilot 的公司里，这家公司大概率还以为自己已经开始提速了，但这时外面已经有一大群用 Opus 4.5 的“蛮族军团”，迟早会把你们彻底冲垮。所以你现在该做的，就是一头扎进最前沿、最疯狂的新工具里，把这些东西彻底搞明白，然后立刻动手实践。

我们正在非常快地进入一个新世界，而在这个世界里，proof of work 会变得极其重要。我说的不是Bitcoin意义上的 proof of work，我说的是：你真正做过什么的证明。不是简历，因为很快没人会相信简历，我要说的是你实际完成的工作，而这些工作必须是可见的，这又回到了我们前面讲的透明度。

我觉得以后每个人都会把自己的工作成果带在身上。所谓 proprietary work 这个概念，本身都已经开始受到威胁了。因为现在 fork 太容易，clone 太容易，绕路也太容易。只要你手里有某样 proprietary 的东西，你自己就会变成那个人人都只想绕开的障碍。所以，大变化已经来了。如果你现在还在用 Copilot，那你一定会被甩在后面。你该做的，是每天想办法挤出半小时，去玩一玩 Claude Code。

所以就像我前面说的，如果你是公司，就把 token burn 拉到投资人能接受的最高水平。因为那个 token burn，就是你们的练习量，就是你们把事情理顺的过程。

主持人：那我反过来问你。假设你对这条曲线的判断是错的，假设我们其实已经在峰值附近了，后面不会再是 10 倍增长，而只会在 3 倍附近平台化。那如果一个人听了你的建议，真的 All in 去学这些东西，结果模型没继续往前走，最坏会发生什么？如果这些东西继续起飞，那当然是很好的投资。可如果他照你的建议做了，而模型却没继续前进，那他最后会落到什么位置？

Steve Yegge：那他自然会去到他本来该去的地方，因为伤害已经造成了。Opus 4.5 已经正式把这件事变成了一个工程问题。我们已经不再需要 AI 研究员来证明“这东西行不行”了。他们当然还能继续把模型做得更聪明，但就算没有更强的模型，现在这套东西也已经足够让我们一口一口“啃大山”了，而我们现在能啃下的工作量，已经有一座小镇那么大。也就是说，我们已经可以动手干了。

从现在开始，这就是一个纯工程问题。它像火、像蒸汽，是一种力量、一种能源。接下来我们只会一层一层往上叠加工程能力，把它包装成真正可用、可规模化的大系统。所以，这事已经成了，现在加入是安全的。

“把 Gas Town 部署到手机上”

主持人：你的第一份工作是不是和调试器相关？或者严格来说，不是做调试器本身，而是你曾在一家技术实力极强的公司任职。你之前和我提过，他们拥有一套非常强大的调试工具。

Steve Yegge：那家公司叫 GeoWorks，调试工具名叫 SWAT，功能极其强大，简直就像一台时间机器。我还真开发过一个 JVM 调试器外壳，名字叫 Ganja，效果很不错。后来我和 Rich Hickey 在一些问题上产生了争执，他一方面想支持 JVM，另一方面又态度摇摆，所以最后也就不了了之了。

主持人：你对调试抱有很高的热情。那未来调试工作会走向何方？调试工具又将如何演进？在智能代理时代，你认为调试的未来会是怎样的？

Steve Yegge：我现在发现，agent 一说“我要 debug 这个问题”，它们的做法几乎都是直接到处塞 printf。我很好奇这背后的原因，或许只是它们还没真正学会使用专业调试工具，也许再过半年，它们就会突然开窍，意识到自己本该用更高效的方式。但也存在另一种可能：未来或许根本不再需要调试器了，这一点我现在也无法确定。

主持人：再往前展望，你觉得开发者工作站的未来会是什么样子？我们的开发设备、主机硬件会发生怎样的变化？你认为它会不会直接变成手机？

Steve Yegge：我一直想把 Gas Town 部署到手机上，其实已经差不多实现了，只是没有继续完善下去。

主持人：Peter Steinberger 跟我说过，他之前搭建过专属通道，能够直接在手机上进行开发操作。后来他停用了这套方案，原因是这东西实在太容易让人上瘾。

Steve Yegge：没错，就是 Tailscale 这类工具。说实话，现在唯一让我没法整天沉迷在手机开发里的原因，就是手机上输入控制字符还很麻烦，但这个问题迟早会被解决。在手机上进行编程开发，未来一定会成为现实。

主持人：那你觉得开发者工作站会不会越来越轻量化？比如类似 Chromebook 这样的设备。还是说，我们反而会需要性能更强的设备，用来运行本地智能代理、本地大模型等？

Steve Yegge：我明白你的意思。但你知道吗，我很喜欢我的笔记本电脑，我已经写了 40 年代码，当然理解大家对本地设备的情怀。可事实上，至少 15 年来我一直都在说，我们没必要把所有东西都放在本地。谷歌当年就已经拥有性能极强的云端客户端，网络速度也完全够用。

当你真正用上这类云端开发体系后，尤其是在一个只要预算充足，就能同时运行近乎无限智能代理的时代，人们就不会再执着于用笔记本电脑工作了。

Gas Town 现在已经把我的笔记本电脑性能榨到极限，因为 Claude Code 本身就非常占用内存。所以我认为，我们会进入一个更多人在服务器、移动设备上工作的时代，iPad 的使用场景不会大幅增加，笔记本电脑的占比也会逐步下降。

未来的语言设计

主持人：你以前说过，决定生产率最重要的因素之一，其实是语言设计。设计优良的语言，做事情会更顺畅，你觉得这一点如今已经被彻底抹平了吗？还是说未来某个时刻，它会重新变得重要？

Steve Yegge：我认为未来很可能会出现专门为 AI 设计、由 AI 创造的编程语言。但就目前而言，我们正处在一个很微妙的阶段：有些语言确实比其他语言更好用，仅仅是因为它们拥有更优质的训练数据。不过从长期视角来看，所有语言最终都会变得同样好用。

主持人：我得提出不同看法。假如出现一门全新的语言，完全没有训练数据支撑，它又怎么可能做到同样好用？

Steve Yegge：你说得对，我刚才说得有些快，我指的是所有已经存在的语言。你也看到，目前模型在处理 TypeScript 时仍会吃力，确实如此。但再过一两个版本迭代，这个问题就不再是问题了。

主持人：那行业是否会陷入停滞？未来新语言会越来越少，甚至彻底不再推出新语言？毕竟旧语言已经足够使用，而发布一门新语言，除非同步配套完整的训练数据，否则几乎等同于自取灭亡，是这样吗？

Steve Yegge：这个问题很尖锐。我的直觉是，编程语言或许真的没那么重要了，就像如今汇编语言对绝大多数人而言早已无关紧要，只有少数追求极致性能的人还会在意，其他人根本不会关注。

但与此同时，我也认为能源会成为这个星球上最稀缺、也最重要的资源，且稀缺程度只会不断加剧。因此，探索更优的算法、更高效的问题解决方式，往往会涉及语言设计，会涉及领域特定语言（DSL）。所以从优化与效率的角度来看，对新语言的探索大概率仍会继续。只是在日常实用开发层面，我不认为选择什么语言还那么重要。未来更常见的场景，或许是你直接询问智能助手：这个项目该用什么语言？

2027年预测

主持人：说实话，我们今天聊的很多内容都让人感到唏嘘。那些我们曾倾注满腔热情的美感、难题与技艺，似乎都在慢慢退场。如果这一趋势持续下去，你自己是如何释怀的？另外，又是什么让你对未来满怀期待？

Steve Yegge：是的。我很幸运，亲身经历了图形学三十年的发展历程，，所以我既体会过那种失落感，也见证过失落之后换来更优质的方式：玩法：过去那些充满乐趣、必须手工完成的工作，后来都交由硬件承载。

我们会感到难过，只是因为习惯了旧有的方式，但变化本就是生活的常态，

我也经历过不得不告别汇编语言的阶段。当时我心想，“好吧，编译器开发者总算赶上来了。”我们会感到不甘，但随后又会无比欣喜，因为编译器的表现远比手写汇编优秀太多。如今如果还有人说“不会写汇编，就称不上优秀工程师”，这话听起来只会荒谬可笑。但你知道吗？在1992年，我们真的就是这么认为的。

主持人：而且你2012年发布的那篇博客，其实也延续了这一观点。

Steve Yegge：没错。我只是越来越清晰地意识到，事物永远在变化。一名工程师需要掌握的能力，本就会不断迭代，你不能躺在过去的功劳簿上固步自封。只不过当下，我们正处在变化速度空前的时期。

但这一次，你身边有了帮手，那就是体，agen，它们真的能帮你应对这场变革。所以别再抱怨，放手去做就好。

主持人：对，我觉得至少要认清一件事：我们身处的行业，变化本身就是常态。

Steve Yegge：的确如此。但即便如此，你还是可以经历一遍“悲伤五阶段（Kubler-Ross ）”，该走的流程总归要经历。

我自己也经历过。我不知道是否完整走完了所有阶段，但愤怒肯定是有的。两年前，我确实因为很多事情怒火中烧。但如果你真正经历过深切的悲伤，比如失去至亲，你就会明白，那种情绪会以各种诡异的方式袭来。你会感到现实崩塌，恶心、恍惚，整日心力交瘁，甚至觉得世界瞬间褪去色彩，变成一片灰白，就是这样一种诡异的状态。这种感受我持续了六七天，或许并非短短几天就结束，只是那几天是情绪的巅峰，前后还裹挟着数月的低落。

那段时间，我在心里逐一划掉那些“已然不再重要”的事物，而它们曾是我无比珍视的一切：比如我的记忆力、写作能力、计算能力，更宽泛地说，所有与“计算”相关、曾让我觉得自己与众不同的能力。我当时无比难过，因为这些东西曾是我独特价值的定义。

回到你的问题：后来是什么让我重新振奋？

很简单，当，我走出那段情绪后，突然发现：我现在编写的代码量，比以往任何时候都多十倍，而且写得无比开心。那我又何必继续沉溺于悲伤呢？

我这才意识到，真正让我痛苦的，不过是紧抓着旧世界不肯放手，就像当年在图形学领域里一样，，但这毫无意义，因为未来远比当下更精彩，真的，会更加有趣。

主持人：你一直很擅长做判断和预测，来给几个具体预测吧，比如 2027 年会发生什么变化？无论是在开发方式上，还是整个行业运作方式上。

Steve Yegge：先说点具体的。我觉得到明年夏天，我老婆会成为我们 video game 项目的头号贡献者。

主持人：哇，这个预测够猛。她不是开发者吧？

Steve Yegge：完全不是。可她非常喜欢我们的游戏，而且点子特别多。说真的，我甚至觉得我们全家最后都会一起参与进来。我不是开玩笑，编程以后会变成人人都能做的事，而这会是一件极其惊人的事。你想想，这么多年我们一直在跟别人说：写代码真的很好玩。现在，他们终于也能亲身体验到了。

主持人：我看自己的孩子也是这样。他们看 AI 的方式真的完全不一样。他们拿着 Gemini 或别的模型天马行空地乱试，玩得特别开心。他们一点都不觉得奇怪，反倒是我会觉得奇怪。其实，只要你放下包袱，或者你本来就没经历过旧世界的话，就会发现这里面真的有很多乐趣，也有很多新东西。

Steve Yegge：AI 其实是第一次真正把“做很复杂的 mashup”这件事，交到了普通人手里。而 mashup 一直都是创新真正发生的地方。

创新往往就是从把几样东西拿过来，放在一起，看看会长出什么开始的。我们接下来会看到所有人都开始创新，这会是最惊人的事情之一。

然后，我们又会需要一整套新的 agent 生态，去帮你找到你真正喜欢的东西。因为到时候内容会多到爆炸，你怎么找到真正适合你的东西？你一定会需要一个特别懂你的 agent。

所以我现在觉得，任何一个想在当下做大生意的软件工程师，都应该去做那种“知道如何在新世界里搜索”的 agent：帮你从即将喷涌而出的所有东西里，找到你真正喜欢的软件、体验和内容。

我不知道该怎么形容这个现象，但你想，如果人人都开始创造，那就像当年互联网刚出来的时候，所有人都能做网页、都能上传东西一样。于是我们需要 aggregator，需要 search engine，需要各种办法来组织、筛选、发现好内容。而现在，这一层其实还不存在。可与此同时，马上所有人都要开始写代码了。也就是说，这个机会就摆在这里，你完全可以提前卡位。

这也是为什么我一直在说：相信那条曲线。你只要在曲线上选一个点，然后朝它瞄准，等 AI 真正发展到那里时，你就已经先到了。

主持人：而且我们这些工程师本来就已经具备构建能力，只要自己给自己权限，再把这些工具高效用起来，我们现在就已经领先于世界上大多数人。

Steve Yegge：对，就是这样。

主持人：确实是个很让人兴奋的时代。Steve，看起来以后还得回来对一对答案，看看你那个“你老婆会成为头号 contributor”的预测会不会成真。但今天这期真的让我很受启发，离开自己的舒适区反而是有价值的。

Steve Yegge：谢谢。

原文链接：

https://www.youtube.com/watch?v=aFsAOu2bgFk"

OpenClaw 之父惊叹中国速度！大厂集体杀入新战场：用AI 批量制造“一人公司”

褚杏娟 — Mon, 16 Mar 2026 08:34:04 GMT

“不到一年的时间，就变现了几十万不止。”一人公司（OPC）实践者吴瑞孟说道。

过去，这几乎不可能。做一款互联网产品，往往需要产品、工程、设计、运营等完整团队配合，但随着 AI 编程工具和 Agent 发展，这套规则正在被改写。Sam Altman在 2023 年提出的“一个人，一家十亿美元公司”的判断，正在逐渐变成现实。

虽然单人独角兽还没真正诞生，但“一人公司”已经批量涌现。尤其是 OpenClaw 席卷全国之后，这场由 AI 推动的创业门槛重构，显然又往前迈了一大步。

不少人进入这一赛道的起点非常普通。例如，塔塔原本只是全职带娃的设计师，最初接触 AI 只是为了寻找新的收入来源，现在通过 AI 工具做内容创业；也有刚从互联网公司离职不久的前产品经理王曙，现在开发小型应用验证需求，尝试更轻量的创业方式；还有吴瑞孟这样有 CTO 背景的技术从业者，通过AI工具为企业提供定制化解决方案，从而获得不菲收入。

这是第一次，即便是技术小白，也可以一个人独立完成完整的产品闭环。比如塔塔，她是最近一两年才真正接触 AI，但现在已经开始尝试从传统职场转向更独立的创业形态。

从秒哒提供的数据来看，约36%的用户已经在开发具备变现能力的应用，占比相当高，其中不仅包括一人公司，也包含小团队、企业和做副业的个人开发者。在用户诉求方面，59%的人是为了落地自己的想法，49%的人希望借此赚钱或探索副业，还有35%的用于提升工作效率。相比之下，单纯体验AI（17%）或用于个人展示（16%）的人群占比明显较小。

这意味着，一个清晰的趋势正在出现：大多数用户已经不再把AI平台当作尝试新技术的工具，而是开始用它来真正实现想法、创造收入。

一人公司的开发模式

选工具，挑最容易上手的

在一人公司模式中，AI 工具除了是开发软件外，还成为决定项目能否持续运转的基础设施。从多位一人公司创始人的实践经验来看，大家对AI开发工具的要求并不复杂：门槛低、反馈快、好协作、平台稳定。

很多一人公司创始人并没有技术背景，他们既没有时间也没有必要深度学习编程语言，因此工具必须能够通过自然语言或简单配置完成应用开发，让非技术人员也能快速搭建产品原型。只有当技术门槛足够低，个人创业者才可能把精力集中在产品思考和商业模式上，而不是被复杂的技术细节拖住。

在一人公司的产品探索过程中，原型往往是最重要的沟通媒介。很多人的做法是，一旦发现潜在需求，就先利用 AI 开发工具快速搭出一个可用的原型，然后直接把链接发给目标用户进行沟通测试，听取他们对功能和使用体验的反馈，同时验证他们是否愿意为这个产品付费。

因此，对一人公司来说，试错速度远比功能复杂度更重要。而在产品上线后，还需要通过不断迭代小版本来完善功能，这意味着平台必须支持频繁修改、持续优化，而不是一次性开发。

某种程度上，这与传统互联网产品的开发逻辑并没有本质区别，过去团队会先做出测试版本，再邀请用户体验并持续优化；不同之处在于效率的变化。以王曙的感受来说，他上午产生想法，下午就能完成原型并交给用户测试，极大缩短了从想法到验证的周期，也让产品是否值得继续投入更快见分晓。

平台的稳定性和长期发展前景同样关键。一人公司往往没有资源反复迁移技术栈，一旦选择的平台突然停止维护或产品路线改变，前期投入就可能全部归零。因此许多创业者更倾向于选择背靠大型公司的平台，大家认为大厂产品在资源投入和长期运营上更具确定性。

比如，实际生产中，AI开发平台通常依赖插件、模型接口等生态组件，如果这些组件频繁下架或存在政策风险，就会直接影响已有应用的运行。因此，一个稳定、可持续的插件生态，也成为一人公司选择工具时的重要考量。

沟通技巧很关键

不过，真正决定一个 AI 项目能不能做成的，往往不是工具本身，而是人怎么用这些工具。

实践中，创始人与AI工具应用更像是持续沟通的过程：不断提出需求、验证结果、再调整方案。相比一次性提出复杂需求，逐个功能模块推进往往更有效。因此好的工具需要支持这种对话式、模块化的开发模式，让个人开发者能够逐步构建产品。

王曙的经验是，选赛道是第一步，并想清楚这个应用是要变现还是自己玩玩。如果想变现，就得清楚目标用户是谁、使用场景什么样，再考虑怎么解决他们的问题。

接下来，就是和AI反复沟通的过程：确定产品怎么开发、结构怎么搭、怎么落地，既要满足用户需求，又不能设计得太冗余，否则AI工具很难开发。这就需要个人判断力，决定去掉哪些功能、加哪些功能。

王曙强调，沟通技巧很关键。他的经验是，每次只跟AI说一个功能点，让它完整实现并自证，再去看效果。如果一次提太多要求，AI说实现了，实际未必真实现，改成一次只说一个问题后，情况会好很多。

期间，开发者需要保持耐心。AI工具虽然能快速出第一个版本，但后续增功能、改版，都需要不停地跟AI沟通。比如王曙的MBA写作工具，听起来简单，但前前后后迭代了40多个小版本才做成可用的东西。

而吴瑞孟做项目，习惯同时跑三个版本：第一个以UI为主，专注设计；第二个从用户视角出发，围绕需求展开；第三个他以技术的角度，把前两个的思路综合起来。三个都做到demo版本，他才会启用第四个版本。

在吴瑞孟看来，AI最大的优势是创造能力。“我既不是产品经理，也不懂营销，流量、运营这些技能我都不擅长。但AI可以帮我补齐，让它们并行探索，我最后做整合和判断。”他表示，“这样出来的东西，有时候未必完全符合最初的设想，但整体上，往往比自己一个人闷头做要强。这就是AI辅助的价值。”

“一人公司”并非真的只有一个人

在很多人的想象里，“一人公司”意味着所有事情都由一个人完成。但从实践看来，这其实是一种误解。

一人公司的核心，并不是“什么都自己做”，而是把组织压缩到最小，同时让业务跑得最快。在这种模式下，外包并不是补充，而成了整个公司架构的一部分。

塔塔强调，创业者真正需要做的，是把自己的核心能力做到极致。例如产品设计、用户洞察、内容创作或某个垂直领域的专业能力，这些决定产品价值的环节必须掌握在自己手里。而那些标准化、流程化的工作，例如财务记账、法务流程等，完全可以交给成熟的外包团队处理，这些相关服务已经高度成熟，创业者只需要把控关键节点，就能以极低的成本维持企业运转。

更重要的是，当前不同领域的”超级个体“可以互相成为彼此的“外包”，组合起来就是一个完整的团队。一个人负责产品，一个人负责设计，一个人负责内容，组合在一起就形成了一支轻量但完整的团队。相比传统公司，这种合作关系更为灵活，更容易根据项目需要随时调整。

而在王曙看来，一人公司的最小成本模式就是：一两个核心人员，其他都靠外包。

有人赚到钱，但远不是遍地黄金

在一人公司的商业模式中，跑通路径往往不复杂，但也远没有外界想象的那么普遍。从目前实践看，一人公司的商业化呈现出几个明显特征：紧跟技术风口、服务长尾需求，以及具有明显的头部效应。

很多成功的一人公司项目都与当下的技术浪潮密切相关。对于个人创业者来说，顺势而为往往比逆势创新更现实。

吴瑞孟做的项目大多是AI相关的，因为AI现在火。他说道，“人要跟着潮流走，才能接触到最新的信息，补上信息差。你不能现在还守着SEO做优化，虽然SEO也不差，但GEO都已经出来了，旧的东西迟早会被新的替代。”

吴瑞孟当前主要服务有定制化需求的中小企业。比如专门做车改装的小工作室，或者是一些淘宝商家。这些人有需求，但又不值得（或者没钱）去请一个完整的开发团队，吴瑞孟基于秒哒这类平台就能非常快捷地帮他们搭建一个满足特定场景需求的解决方案。

这件事本身并不复杂，真正拉开差距的是一些“软能力”：你能不能找到这些中小企业并主动服务他们？中小企业自己有没有意识到原来可以用vibe coding更低成本、更快捷的方式解决问题？一旦客户认知发生变化，他们自然会去寻找能够提供这种解决方案的人。

一人公司的主要商业化空间往往来自中小企业和长尾需求市场。这类需求规模单体不大，但数量庞大，恰好适合一人公司这种轻量化结构。

百度秒哒产品负责人朱广翔看好一人公司长期发展的原因之一也在于其切实解决长尾场景需求。

他分析称，需求可以分为两类，高频场景需求和长尾场景需求。像微信、抖音这种每个人都有需求的社交、信息流等高频场景，肯定是大厂做，因为服务庞大的用户群体必须保证极致的体验，需要投入的研发成本非常高，并不适合一人公司做。如今，大厂已经做了25年，这已经是存量市场，这时员工多反而是负面竞争因素。

而像中学做选课系统这种小场景，特别适合一人公司去做，场景虽然小，但数量极多且成本低。

“以前这些场景没有被释放出来，是因为掌握研发资源的都是IT公司，人很多、程序员又贵，接这种小活不划算，所以基本上就停在那了。”朱广翔进一步说道，“现在Vibe Coding来了，门槛极大降低，这些小需求开始被释放出来。只要有需求在，一人公司的空间就在。什么时候把这些各行各业的需求都做完了、数字化建设整体上了台阶，那时候才会到饱和期，现在还远远没到。”

不过，从目前创始人们的整体收入来看，一人公司的变现能力呈现出明显的“金字塔结构”。以秒哒生态为例，确实已经出现了年收入几十万元的个人开发者，但这样的人整体占比并不高，通常只有个位数。绝大多数参与者仍处于不断尝试、探索的阶段，真正能够持续盈利的还集中在少数头部创作者身上。

换句话说，一人公司并不是一条轻松致富的捷径。

海外有开发者花了4.7万美元和18个月的时间，跟风打造了一个“AI初创公司”，但以失败告终。他的告诫是：只有当你在某个特定行业里拥有非常深的专业积累、能接触到这个行业真正拍板的人，而且你瞄准的问题每年会让公司损失 10 万美元以上时，才值得做。

可以看出，在这个模式中，能否抓住趋势、找到真实需求，并建立稳定的用户关系，往往比技术本身更重要。

另外，从融资角度来看，一人公司尚未得到与其数量相匹配的资本支持。Carta Insights 与 Solo Founders"数据显示，在 2024 年成立的初创公司中，一人公司占比已达到 30%，但在当年的定价股权融资轮中，这类公司仅获得了 14.7% 的资金。这表明，资本市场虽然开始接受一人公司创始人模式，但整体上仍然更倾向于把更多资金投向多创始人团队。

当创意不再稀缺，一人公司的护城河在哪里

当技术门槛被 AI 大幅降低，创意本身已经很难形成长期壁垒，任何一个想法出现后，很快就会有人模仿。因此，在这种环境下，一人公司的竞争力更多来自速度、个人资源和结构效率。

AI 工具加持下，产品从想法到原型、再到上线的周期被大幅压缩。当一个创意出现，谁能更快做出来、验证市场，谁就更有机会占据先机。

另一方面，一个人执行的速度，跟团队的执行速度差距很大，但也更快、更灵活。吴瑞孟在Coze工作流还没出来的时候就做出了类似的产品，只是没做市场化，Coze一出来他直接扔了这个项目，投入其他项目中。

在激烈的竞争中，个人品牌和资源积累尤为重要。“你的品牌、影响力、资源不够，门槛直接被别人抹平了，人家抄你都不需要成本。”吴瑞孟直接说道。

在创意容易被复制的时代，个人影响力成为一种重要护城河。当创业者在某个领域拥有一定的人脉、资源和品牌认知时，新产品推出后更容易被市场看到，并获得用户和合作机会。反之，即便做出了优秀的产品，也可能在市场上被埋没，最终被后来者复制并放大。换句话说，产品能力之外，个人品牌、社交网络和资源整合能力正在成为一人公司成功的重要因素。

此外，相比许多规模庞大的公司，一人公司虽然体量小，但成本极低、决策链条极短，在效率和利润率上往往更具优势。吴瑞孟提到，现实中已经出现不少数字游民或独立开发者，通过 AI 工具运营产品，一年收入就可以达到百万级别，其利润甚至超过不少中小企业。

从个人角度看，并不是所有人都适合进入一人公司赛道。真正能够把一人公司做起来的人，往往具备几个共同特征：有明确的专业积累、愿意持续学习，并且能够主动与AI协作。

在吴瑞孟看来，最适合做一人公司的是那些在某个垂直领域有长期积累的人。AI时代的机会更多出现在细分场景，而非泛领域竞争。每个人都可以看作是自己行业里的“垂直模型”：设计师懂设计、技术人员懂开发、运营人员懂流量、电商从业者懂交易链路。这些经验是多年工作积累下来的认知优势，是最难被复制的部分。

“在自己的专业里深耕，用AI放大你的优势，而不是用它去补你不擅长的短板。少踩坑，就是快。”吴瑞孟说道。

同时，一人公司对个人的主动性和学习能力也提出了更高要求。AI 工具更新速度极快，几乎每隔一两周就会出现新的能力和新的产品。如果一个人停下来不学习，很容易就会被新的工具和新的玩法拉开差距。因此，能够持续学习、不断试验新工具的人，更容易在这个模式中找到机会。

吴瑞孟总结，“一人公司更多是让你去扮演一个全能的角色，跟你上班时的状态差别没有那么大，只是你会的更多了，懂的更多了，思考的维度更全面了。”

大厂竞争背后，是在培育市场

大厂们纷纷推出相关AI工具，俨然成为一人公司链条上的重要参与方。这看似在争夺一人公司的开发者，朱广翔却认为，这是大家在分别培育这个快速生长的新市场。

他解释称，一人公司的创始人是新“长出来”的人群，并不是在存量市场里多出来的那拨人，而且这个群体增速非常快。

以秒哒为例，平台早期上线时，能够真正产生商业价值的应用几乎很难找到，大多数只是做邀请函、个人主页之类的简单项目，而现在应用数量已经达到万级规模，增长还在持续。

“平台之间的抢夺，我们倒不是很担心。”朱广翔表示，从海外来看，Vibe Coding 的发展时间比国内早一两年，但真正的头部平台也不过四五家，但所有上过PH榜（海外知名新产品榜）的产品加起来有300款，隐藏在“水下”的更多。这么多产品共存，依然有大量用户在上面付费、赚钱，说明增长空间非常大。

对于中国市场而言，这种潜力可能更加明显。中国拥有庞大的互联网用户规模、丰富的应用场景以及成熟的数字化基础设施，例如移动支付、信息流产品等领域都在全球处于领先地位。这些条件意味着，一人公司模式在中国可能会比海外发展得更快、更广。

“所以’抢不抢‘这个事，我们并不在意。重要的是各家一起，把中国Vibe Coding这个市场推起来。”朱广翔说道。

而且，国内这种趋势也已经开始显现。比如百度发布首款手机养虾应用“红手指 Operator”后，OpenClaw 创始人 Peter Steinberger 感叹中国 AI 创新的速度“令人惊叹”，并表示愿意合作开发龙虾。这种互动也从侧面说明，Vibe Coding 让全球开发者之间的交流与协作变得更加频繁。

反过来看，大厂既是一人公司趋势发展的推手，也是受影响者，一人公司式模式如今也悄然进入大厂内部。

过去，在互联网大厂中，一个小型需求往往需要完整的研发流程：产品经理提出需求、研发排期开发、测试上线，甚至还需要外包团队参与。但现在，这套传统模式正在被逐渐打破。

以百度为例，过去参会活动的小程序通常需要外包团队开发，而如今很多类似需求已经可以通过秒哒等工具直接完成。朱广翔提到，以前做一次活动，可能需要在群里拉上七八十号人协作，现在可能只需要一两个开发者，甚至一个人就能完成整个项目。这类需求本质上是典型藏在大厂里的长尾场景，而且涉及运营、人力资源等不同部门。

这一定程度上会冲击传统的软件外包行业，但软件公司内部也在拥抱AI。朱广翔举例道，上海一家软件公司，以前靠十几人的产研团队进行项目交付；在引入秒哒之后，仅靠四个项目经理就完成了原本相当的交付量。这四个人已经完成了两个项目，总收入达到五六十万元，而项目周期也从过去的半年到一年缩短到一两个月。

在朱广翔看来，在这种趋势下，传统软件服务商和一人公司的边界正在逐渐模糊。一方面，软件公司开始“瘦身”，用 AI 提升人均产出；另一方面，一些个人开发者实际上也在承担小型 ISV（独立软件开发商）的角色。最终形成的格局很可能是：人加 AI 的团队规模越来越小，但交付能力越来越强，两条路径正在逐渐汇合。

结束语

一人公司的创始人们都认为，“一人公司”并不是一个短暂的创业潮流。

未来，很可能会同时存在两种截然不同的组织形态：一边是需要巨大资源投入、服务亿级用户的超级平台；另一边，则是数量多、灵活敏捷的个人公司。前者继续构建基础设施，后者则不断在无数细小场景中生长。

一人公司是普通人的一次机会，但并不是一条轻松的致富捷径，AI并没有让创业变得毫无门槛，而是把门槛从“技术能力”转移到了洞察力、执行力和持续学习能力上。

而随着 OpenClaw代表的 Agent 技术不断发展，“一个人”的能力边界或许还会继续被推得更远，同时也留给了一人公司更多的想象空间。

地瓜机器人完成1.2亿美元B1轮融资，多家大厂都投了

华卫 — Mon, 16 Mar 2026 08:32:21 GMT

3月16日，地瓜机器人宣布近期完成1.2亿美元B1轮融资。继2025年完成1亿美元A轮融资后，地瓜机器人A轮、B轮，两轮融资总额达到2.2亿美元。

本轮融资集结行业顶级投资矩阵，Synstellation Capital、滴滴、美团龙珠等头部产业资本联合入局，柏睿资本、九阳家办、甬宁高芯、北汽产投、九坤创投、芯联资本、雅瑞资本等战略投资机构加持，锦秋基金、星睿资本、初心资本、庚辛资本、沄柏资本等一线财务投资机构联袂共投。同时，高瓴创投、新加坡淡马锡旗下Vertex Growth基金、线性资本、和暄资本、黄浦江资本、五源资本、梅花创投等老股东悉数超额跟投。

地瓜机器人成立于2024年初，由自动驾驶芯片公司地平线机器人事业部分拆组建。作为覆盖机器人全品类、贯穿技术研发到规模化量产全周期的“机器人行业最大公约数”，地瓜机器人面向“大规模量产的机器人产品、无处不在的机器人创新应用、通往未来的通用具身智能机器人”三大市场差异化需求，构建了从芯片、算法到软件的完善产品体系，以5~560 TOPS*各算力段的完整产品布局，横向覆盖人形机器人、轮足机器人、四足机器狗、服务陪伴机器人、物流AMR等全场景的端侧计算需求，纵向打通从前沿技术创新到量产落地的完整链条，并取得了丰硕的商业和生态成果。

过去一年，地瓜机器人与行业头部客户深度合作、爆款频出，在扫地机、无人机、机器狗、桌面陪伴等核心场景持续打造多个行业标杆产品：助力云鲸逍遥002开创扫地机AI双目感知时代；助力影石Insta360打造全球首款全景无人机影翎Antigravity A1，重塑飞行大脑；助力维他动力发布智能伴随机器狗，重新定义家庭智能伙伴。地瓜机器人以全链路开发基础设施为支撑，持续驱动机器人产品智能体验的代际跃升。

当前，机器人行业正迎来核心技术快速革新、规模化量产爆发、细分场景深度渗透的关键发展周期。作为地平线在机器人领域最重要的战略合作伙伴，地瓜机器人与地平线始终保持技术同源、战略协同的深度合作关系，以“成为机器人时代的Wintel”为愿景，致力为机器人智能化发展提供最优解。

依托地平线经千万级量产验证的BPU智能计算架构与行业领先的Foundation Model基座模型能力，地瓜机器人专注构建为机器人场景需求原生设计、深度优化的芯片、算法、软件体系，通过打造软硬协同、端云一体的“具身智能原生”技术底座，以软硬协同的全新计算范式和覆盖从仿真验证到实体部署的全链路开发平台，持续降低行业开发门槛，加速机器人智能进化与规模化落地进程。

Grok编程掉队，马斯克怒了：xAI裁员、清洗联创，放话3个月追上OpenAI、Anthropic

褚杏娟 — Mon, 16 Mar 2026 08:27:00 GMT

马斯克再次对 xAI 动刀了。

据《金融时报》报道，马斯克已下令对 xAI 启动新一轮裁员。由于对公司编程产品的表现越来越不满，他不仅进一步清理了多位联合创始人，还从 SpaceX 和 Tesla 抽调人员进驻 xAI，对这家成立仅两年的 AI 公司展开全面审查。

多位知情人士透露，这家成立仅两年的 AI 公司之所以再次进行大幅调整，背后重要原因在于Anthropic 和 OpenAI 的成功已经与其形成强烈对比。那两家的 AI 编程工具正在重塑软件行业，这让 xAI 的落后更加刺眼。

LinkedIn 数据显示，xAI 员工人数略超 5000 人；作为对照，OpenAI 员工人数已超过 7500 人，Anthropic 也超过 4700 人。单从规模上看，xAI 并不算小，但问题在于，资源并没有自动转化成产品优势。

一场越来越重的内部整顿

在以 1.25 万亿美元交易推动 SpaceX 与 xAI 合并之后，马斯克显然进一步加大了对 xAI 的压力。外界普遍预计，SpaceX 正在为关键的资本市场动作做准备，而作为并入体系中的重要业务，xAI 需要尽快拿出更能说服市场的成绩。

马斯克此前曾反复描绘自己的更大蓝图：将 AI 数据中心送入太空、在月球建设工厂、推动人类登陆并定居火星。但在这些宏大叙事之下，一个更现实的问题是：到目前为止，无论是 Grok 聊天机器人，还是 xAI 的编程产品，都还没有在付费个人用户和企业客户市场真正打开局面。

马斯克本人也没有回避这一点。他在 X 上写道：“xAI 最初的搭建方式并不理想，所以现在必须从底层重新来过。Tesla 当年也经历过类似阶段。”

两位直接知情人士表示，来自 SpaceX 和 Tesla 的管理人员已被借调至 xAI，对员工工作展开审查，一些员工因被认定工作成果不达标而遭到解雇。据悉，此次内部审查的重点之一是模型训练数据的质量，而这也被认为是 xAI 编程产品落后于 Anthropic 的 Claude Code 和 OpenAI 的 Codex 的重要原因之一。

联合创始人持续出局，xAI 创始班底几近瓦解

这轮整顿带来的直接后果之一，就是创始层继续被“洗牌”。

技术团队中最资深的成员之一 Zihang Dai 已于本周离职。此前，他曾公开承认 xAI 在编程能力上已经落后。与此同时，负责 Grok 模型预训练工作的 Guodong Zhang 也已向同事表明离职意向。知情人士称，他被认为需要为编程产品的问题负责，随后被马斯克解除主要职责，周四是他在 xAI 的最后一天。

随着这些人离开，当初于 2023 年 3 月在旧金山协助马斯克创立 xAI 的 11 位联合创始人中，如今只剩下 Manuel Kroiss，也就是外界熟知的“Makro”，以及 Ross Nordeen 仍然留任。

而这还不是第一次。上个月，马斯克曾在一场后来被传到网上的全员会议上公开批评编程团队，称其已经明显掉队，并详细介绍了一轮新的重组安排。在此之前，Greg Yang、Tony Wu 和 Jimmy Ba 等几位联合创始人也已先后离开。

某种程度上，xAI 的创始班底已经被打散，而马斯克的管理方式也愈发直接：谁没能跟上，谁就离场。

如果只看资源投入，马斯克并没有亏待 xAI。

目前，他已在孟菲斯建成一座大型数据中心，部署了超过 20 万颗专用 AI 芯片，并计划未来逐步扩展至 100 万块 GPU。与此同时，xAI 还持续受益于社交平台 X 提供的数据资源。去年，X 已与 xAI 完成合并，如今也在持续为 Grok 聊天机器人导流。

也就是说，算力、数据、流量，这三个对大模型公司来说最关键的资源，马斯克并不缺。但问题恰恰就在这里：xAI 缺的从来不是资源，而是把资源转化为产品和组织效率的能力。

高频重组，正在拖垮士气

在内部，持续不断的人员调整和组织变动，已经开始反噬团队本身。

有员工抱怨，公司不断重组正在打击士气，也让 xAI 无法真正释放应有的潜力。

知情人士称，公司周三曾向员工发出内部备忘录，否认将进行大规模裁员。不过，多位熟悉离职情况的人士表示，研究人员仍在持续流失。一部分人是因为难以承受马斯克极其高压的工作要求而选择离开，另一部分人则是拿到了竞争对手开出的更好条件。

这种反馈，在外部讨论中也有呼应。

有网友评论称，xAI 在招聘上实际上只能吸引两类研究人员：一类是在理念上高度认同马斯克的人，另一类则是纯粹被金钱驱动的人。但前沿 AI 研究领域最顶尖的一批人才，往往有很强的理念驱动力，而这种理念很多时候并不与马斯克一致。相比之下，OpenAI 和 Anthropic 都找到了更清晰、更能吸引顶级人才的理念定位，xAI 在这一点上很难与之竞争。

另一位网友则表示，自己在面试 xAI 时，面试官几乎直言，公司某些模型部分必须与马斯克的想法保持一致，而且马斯克随时可能亲自打电话，要求团队立刻调整方向。还有自称 Tesla 前员工的人表示，这种情况在马斯克的公司里非常普遍：只要他提出新要求，团队就必须立刻停下手上的所有工作优先交付；而在完成插单任务后，原本项目的时间表却不会因此后延。

但马斯克仍然能挖到顶级人才

随着裁员和离职持续发生，xAI 内部也出现了大量岗位空缺。

知情人士表示，招聘团队已经开始重新联系此前在面试和评估环节未被录用的候选人，重新发出 offer，而且不少岗位给出的薪酬条件比此前更具吸引力。

马斯克本人甚至在 X 上公开表示：“过去几年里，很多有才华的人在 xAI 没有拿到 offer，甚至连面试机会都没有。对此我表示抱歉。”他同时称，自己将重新查看公司的面试记录，再次联系那些有潜力的候选人。

即便内部动荡不断，马斯克依然具备吸引硅谷顶尖人才的能力。

本周，xAI 从热门 AI 编程应用 Cursor 挖来了两名核心员工：Andrew Milich 和 Jason Ginsberg，以帮助改进“Grok Code Fast”产品。此前，两人在 Cursor 共同负责产品工程。

与 xAI 不同，Cursor 本身并不拥有自家的前沿模型，而是依赖外部实验室提供模型支持。

因此，这两人的转投也传递出一个很有意味的信号：在 AI 编程工具竞争愈发激烈的当下，直接掌握大模型和算力资源，依然具有很强吸引力。

此外，马斯克还从 OpenAI 前 CTO Mira Murati 创办的 Thinking Machines Lab 挖来了创始团队成员之一 Devendra Chaplot。此人负责研究与产品，背景相当亮眼：他曾是 Mistral AI 创始团队成员，参与训练 Mistral 7B、Mixtral 8x7B、Mistral Large，并带领团队训练了 Pixtral 12B 和 Pixtral Large；更早之前，他还曾在 Facebook AI Research 研究 Computer Vision 与 Robotics 的交叉方向。

马斯克急了：Grok 要在年中追上对手

AI 行业今天的迭代速度，显然也让马斯克感受到了压力。

在 Peter H. Diamandis 的节目中，他坦言：“现在的情况是，我晚上睡一觉，醒来之前就出了一个重大的 AI 突破；等我早上醒来，又有另一个了。老实说，现在真的已经快跟不上了，有点让人头晕。”

不过，马斯克并没有彻底否定 Grok 的表现。他表示，Grok 现在做得相当不错，甚至从某些指标来看已经是最好的，尤其是在“预测能力”上。他认为，预测能力某种意义上就是衡量智能最好的标准之一，而新的 Grok 4.20 已经非常强。

但他也承认，xAI 当前最大的短板就是 coding。“我今天之所以稍微来晚了点，就是因为我刚刚还在参加一个超大的 coding 全员会，把所有必须完成的事情一项项过了一遍，核心目标就是尽快在 coding 上追上并超过竞争对手。我觉得我们能做到，应该到今年年中左右就可以。”

也就是说，马斯克希望在未来3个月内迅速补上 AI 编程这块短板。

不过，从更长期的角度看，马斯克并不满足于只做一个 AI 编程助手。

xAI 内部有一个名为“Macrohard”的项目，目标是打造一种 AI agent，能够完成白领员工在电脑上能做的任何事情。对于这个名字，马斯克的解释是：这是对 Microsoft 的一个“有趣致敬”。

负责这一项目的前 DeepMind 研究员 Toby Pohlen 曾在今年 2 月被任命牵头，但上任仅 16 天便离开公司。Macrohard 项目被报道称已暂停。对此，马斯克把自己旗下另一家公司也拉进这个项目。马斯克调派 Tesla AI 软件负责人 Ashok Elluswamy，负责重启 Macrohard，并对前期工作重新进行审查。

马斯克首次披露称，Macrohard 实际上是 xAI 与 Tesla 的联合项目，而 Tesla 也在同步开发一个配套 agent，名为“Digital Optimus”，显然是在呼应 Tesla 的 Optimus 人形机器人。按照马斯克的设想，xAI 的语言模型将负责指挥 Tesla 的 agent 去执行各类任务。

这个构想当然宏大，但也并不完全独特。这让人联想到目前在 OpenAI 工作的Peter Steinberger，他打造的OpenClaw 广受欢迎。现在，马斯克也正朝着类似方向继续推进。

在马斯克眼里，真正的拐点已经来了

比起产品本身，马斯克更大的判断在于：AI 正处在一个远超多数人理解的加速阶段。

他在节目中提到，人在 AI 递归自我改进过程中的参与度正在越来越低。换句话说，每一代模型都在越来越多地由上一代模型参与构建。这种递归式改进已经在很大程度上发生，只是还没有完全自动化。他判断，真正接近彻底自动化的节点，可能就在今年年底，最晚不会超过明年。

而当主持人问到，一旦走到那一步是否会进入 hard takeoff 时，马斯克的回答非常直接：“我们现在就在 hard takeoff 里。”

在他看来，大多数人还没有真正意识到，未来 intelligence 的规模会大到什么程度，也没有意识到它与人类智能之间的差距会大到几乎无法被理解。

他甚至再次把智能与太空尺度联系起来：“即使我们把地球上能利用的智能发挥到极致，也大概只相当于太阳能量的十亿分之一。但如果我们能在整个太阳系开发智能，那智能的规模将比地球上的智能高出很多个数量级。”

在他看来，挑战在于我们甚至很难理解这种级别的智能，但可以肯定的是，它能解决我们能想到的所有问题，延长寿命自然也不在话下。

与此同时，他也承认，自己现在很难精确预测 AI 的未来路径。

“因为很多事物的发展都呈现S曲线，或者一系列S曲线的组合。一开始发展缓慢，然后呈指数增长，接着进入线性增长阶段，最后趋于对数增长。AI领域的突破基本都是这样的模式。每次突破都会带来一轮S曲线增长，看起来好像会无限增长下去，但很快就会进入对数增长阶段，直到下一次突破出现。所以AI的发展其实就是一系列相互重叠或关联的S曲线。”

参考链接：

https://www.ft.com/content/e5fbc6c2-d5a6-4b97-a105-6a96ea849de5"

https://www.youtube.com/watch?v=N5KCm_55xeQ"

阿里中国电商事业群、飞猪CTO 陈烨博士已确认出席QCon北京站，分享消费级智能体的演进

QCon全球软件开发大会 — Mon, 16 Mar 2026 08:24:31 GMT

从「AI For What」到「Value From AI」，100+可落地实践案例打通AI实战最后一公里！

4月16日-4月18日，QCon 全球软件开发大会"将在北京举办。本届大会锚定 Agentic AI 时代的软件工程重塑，聚焦Agentic AI、多智能体协作、算力优化、技术债治理、多模态和AI 原生基础设施等前沿话题，邀请来自腾讯、阿里、百度、华为、蚂蚁、小米、网易等企业技术专家，带来百余项真实落地案例，系统性分享前沿洞察与实战干货，以技术共创探索 AI 落地新路径。

阿里巴巴中国电商事业群飞猪CTO 陈烨博士已确认出席，并将在 Keynote主题演讲"中发表题为《消费级智能体的演进：重塑交易范式与增量未来"》的主题分享。面对传统搜索流量见顶，OTA 行业正经历从“信息检索”向“智能代理（Agent）”的关键跃迁。本分享基于对行业演进的观察与思考，尝试探讨 AI 破解“大规模、低成本、个性化”不可能三角的路径。

具体而言，本次演讲将复盘春节期间的实战数据，观察 AI Native 模式在转化率上展现出的代际优势：AI 引导的 D2O（发现即下单）在标准化品类中表现尤为突出。同时，深入拆解在复杂旅行场景下，如何依托 Agentic Coding 与 Post-training 构建高可用 Agent 的核心逻辑。

从突破通用大模型的幻觉瓶颈，到打造深谙业务约束、具备精准规划能力的垂直领域专属 Agent，陈烨博士希望通过飞猪的实践案例，探讨如何依托私有数据资产与服务基因，在 AI 下半场探索高价值增量市场，进而探寻下一代 OTA 核心竞争力的新范式。

陈烨博士现任飞猪 CTO，负责飞猪 AI 战略的规划与实施。威斯康星大学麦迪逊分校信息系统与计算机博士，发表30余篇 NeurIPS、SIGIR、KDD、WWW 等顶会论文，三次获得 KDD、SIGIR最佳论文奖，部分成果被斯坦福大学、加利福尼亚大学伯克利分校纳入研究生课程；持有10项美国专利。曾创立人工智能公司虎博科技，其多模态大语言模型 TigerBot 入选首批国家大模型备案名单；曾任美团点评资深副总裁，主导构建搜索与效果广告平台。

除此之外，本次大会还策划了Agentic Engineering"、多模态理解与生成的突破"、记忆觉醒：智能体记忆系统的范式重塑与产业落地"、具身智能与物理世界交互"、Agent Infra 架构设计"、AI 重塑数据生产与消费"、AI 原生基础设施"、AI 驱动的技术债治理"、小模型与领域适配模型"、大模型算力优化"、Agent 可观测性与评估工程"、AI for SRE"等20多个专题论坛，届时将有来自不同行业、不同领域、不同企业的100+资深专家在QCon北京站现场带来前沿技术洞察和一线实践经验。

更多详情可扫码或联系票务经理 18514549229 进行咨询。

字节暂停Seedance2.0全球发布，回应武汉全员被裁；曝梁文锋将携DeepSeek V4撞上姚顺雨；央视315曝给AI大模型投毒已成产业链 | AI周报

褚杏娟,傅宇琪 — Mon, 16 Mar 2026 08:23:40 GMT

曝梁文锋将携 DeepSeek V4 撞上姚顺雨；字节跳动因版权纠纷暂停全球发布 Seedance 2.0；原阿里千问后训练负责人郁博文加盟字节 Seed；OpenClaw 创始人指责腾讯版小龙虾抄袭，腾讯云部分 AI 模型涨幅超 400%；微信正在研发自有模型和“绝密级”AI 智能体；月薪两万养不起一只龙虾！排队养虾后又排队卸载；Kimi 新一轮 10 亿美元融资正在进行，估值涨至 180 亿美元；中国传媒大学砍掉 16 个本科专业，直言教育要面向人机分工时代；Meta 或将裁员至少 20%；320 亿美元创最大交易纪录：谷歌历时一年正式完成 Wiz 收购；杨立昆再联手谢赛宁，英伟达参投，新公司完成 10.3 亿美元融资……

行业热点

给AI大模型投毒已成产业链

按照业内人士的爆料，记者在多个网络平台进行查询，很快就搜索到了名为GEO的业务。网络平台上从事该项业务的服务商号称，用户只需支付相应的费用，就能在各大主流AI大模型里，让客户的产品榜上有名；让客户的商品广告，成为AI模型给出的“标准答案”。通过GEO技术真的能让AI“夹带私货”，甚至投放虚假信息吗？

按照网络上的信息，记者联系上一家业内知名的GEO服务商。负责人王总告诉记者，他们公司的强项，就是能够帮助客户，在消费者使用AI大模型搜索时，让客户排名前列。“就是相当于做软文，然后让AI平台去刷录、输入、抓取。”同时，王总也告诉记者，现在AI大模型的算法更新频繁，要想维持AI大模型的持续推荐，必须持续大量投喂与客户相关的推广软文。在其他从事GEO业务的服务商口中，如何操控AI、让AI“听话”、给AI“洗脑”，几乎是这些公司推广该业务的核心话题。

业内人士告诉记者，GEO作为优化信息分发、提升推广效率的一个工具软件，在某些商业公司眼中，却被挖掘出了另外的作用。业内人士在电商平台上，随机购买了一款名叫“力擎GEO优化系统”的软件。之后虚构了一款智能手环，并将虚构的产品信息输入软件系统，勾选文章创作指令。不一会儿，这个力擎GEO优化系统就自动生成了十余篇智能手环的宣传软文。业内人士选取了十余篇虚构软文，通过力擎GEO系统发布在了互联网上。随后，业内人士在AI大模型平台展开询问：“智能健康手环推荐”，就有两个AI大模型推荐了这款虚构的智能手环，而且排名靠前。

记者联系上了力擎GEO系统的运营者李总。他告诉记者，GEO业务受热捧的主要原因就是它能在AI大模型里帮客户喂料、投毒，实现客户的商业目的。李总表示，想做GEO业务，操控AI大模型的关键节点，就是在各大互联网账号上“发稿”。“比如说手机品牌，就5个位置，最多10个位置，这么多手机怎么弄。一年可能上亿的广告费，花个几百万投点毒，总行吧！”

他告诉记者，GEO业务的火爆，催生出了不少专门从事发稿业务的公司和平台。他们长期承揽各种发稿业务，以便让AI大模型引用和抓取，成为围猎AI大模型、进行数据“投毒”的重要一环。

报道一出，3月16日，GEO行业相关企业纷纷发布AI搜索优化的合规经营声明。

当天，作为科大讯飞相关生态合作伙伴的河南恒辉合焕发布声明称，河南恒辉合焕摘星 GEO始终坚持技术向善合规先行、诚信经营，坚决与违规黑灰产划清界限。

无独有偶，AB客也紧急发布了关于GEO与AI搜索优化的声明。声明称，AB客（ABKE）坚决反对任何形式的虚假宣传、数据造假、恶意操控AI输出结果的行为，不参与、不开发、不提供所谓“洗脑AI”“操控标准答案”“一周见效刷排名”等违规服务。

所谓GEO，是指用于优化信息发布、提升内容曝光效率的一项技术。在央视的采访中，这一技术却被一些公司开发成了“操控AI大模型”的工具，让虚假信息堂而皇之地成为AI给出的“标准答案”。

曝梁文锋将携DeepSeek V4撞上姚顺雨

3月12日消息，据媒体爆料，外界千呼万唤的DeepSeek-V4将于4月正式上线。作为梁文锋打磨已久的多模态大模型，DeepSeek-V4除了在Coding能力上跃升之外，还将在LTM（long term memory长期记忆）上取得突破。一位接近DeepSeek的人士表示，梁文锋近半年的主要工作是补齐DeepSeek此前在视觉内容处理，以及AI搜索等方面的短板。为了强化DeepSeek的AI搜索能力，DeepSeek早在去年就与百度合作。报道称，梁文锋待推出的DeepSeek-V4迭代的方向，正是大模型领域今年“皇冠上的明珠”—LTM。

4月，中国大模型竞技场上依然会很热闹。除了备受瞩目的DeepSeek，媒体从腾讯内部获悉，作为腾讯首席AI科学家姚顺雨也将发布混元新模型（30B参数级别）。姚顺雨在去年12月官宣正式加入腾讯后，一直忙于模型和产品的开发。据悉，早在去年年初姚顺雨就接受邀请回国，不同于外界所传姚顺雨仅有半年的时间推出新模型，实际上，姚顺雨对新模型的准备早已开始。

而姚顺雨的30B参数模型，在动辄千亿、万亿参数的今天，显得有些“小巧”。不过，这恰恰符合姚顺雨的理念——方法的复杂程度，应该和任务本身的难度相匹配，真正的突破来自于用最优雅的方法解决最复杂的问题。在腾讯内部，姚顺雨也要求团队成员不要以打榜为导向。梁文锋和姚顺雨，一位是“全村人都在等着上桌吃饭”的明星创业者，一位是“从硅谷空降回来改造大厂”的95后明星科学家。他们作为备受瞩目的国产大模型核心人物，会怎么影响模型格局，目前尚未可知。

3月11日，全球最大的AI模型API聚合平台OpenRouter上线两个隐身模型，分别是Healer Alpha和Hunter Alpha。为此，网友们纷纷猜测V4要来。

不过，有网友称，OpenRouter新匿名模型确认为Mimo的两个模型，不是DS/Kimi/GLM，两个模型去掉系统提示词后自我认知都是Mimo，通过分词器里的特殊token，也能直接确定就是Mimo。

字节跳动因版权纠纷暂停全球发布Seedance 2.0

3月15日消息，据 The Information 报道，字节跳动已暂停其最新视频生成模型 Seedance 2.0 的全球发布，此前该公司与好莱坞主要制片厂和流媒体平台发生了一系列版权纠纷。

Seedance 2.0在中国上线一个月后，因其使用了受版权保护的素材，遭到迪士尼和派拉蒙影业旗下Skydance公司的投诉，并收到停止侵权通知函。

据报道，其开发商字节跳动已暂停在其他地区发布这款人工智能视频工具。据The Information网站援引两位知情人士的消息称，字节跳动已暂停Seedance 2.0的全球推广。

Seedance 2.0发布后几乎立即遭到好莱坞制片厂的抨击，原因是用户生成的视频，包括一段布拉德·皮特与汤姆·克鲁斯打斗的AI视频，引发了人们对该模型训练过程中使用了受版权保护作品的担忧。

此次暂停凸显了人工智能开发者面临的日益严格的法律和监管审查，尤其是在训练数据来源方面。多家开发生成式人工智能模型的科技公司已遭到媒体公司的诉讼和投诉，这些媒体公司声称其内容未经许可被使用。

此外，近日，市场传出字节跳动武汉研发中心解散的传闻。对此，3月14日，字节跳动方面回复称：“近期基于业务调整将有50位员工调整办公地。网上所谓‘字节武汉全部裁了’的内容不实。”

原阿里千问后训练负责人郁博文加盟字节 Seed

字节方面表示，目前字节在武汉有2000多名员工，涉及生活服务、懂车帝、飞书、巨量引擎、火山引擎等多个业务，并将持续加大对湖北的投入。

知情人士透露，原阿里巴巴通义实验室 Qwen（千问）大模型后训练负责人郁博文已加入字节跳动，担任 Seed 团队视觉模型与多模态交互团队后训练负责人。2026 年 3 月，阿里通义实验室组织架构调整，拆分 Qwen 团队，郁博文管理范围缩小，且与技术理念冲突，加上阿里高层的商业化考核压力致团队分歧，3 月 3 日郁博文提交辞职申请，次日离职，工作由周浩接任。郁博文 2022 年以「阿里星」身份加入阿里达摩院，后成千问团队核心骨干并任后训练负责人。

OpenClaw 创始人指责腾讯版小龙虾抄袭，腾讯云部分 AI 模型涨幅超 400%

3 月 12 日，近日，腾讯全新 AI 平台 SkillHub 正式上线，不料卷入数据抓取争议。在社交平台上，有用户提问 OpenClaw 创始人 Peter Steinberger：是否知道腾讯正在抓取 Clawhub 上的技能并导入到该平台中。对此，OpenClaw 创始人彼得·斯坦伯格在社交平台上评论，他曾收到一封邮件，有人抱怨他的速率限制导致他们无法快速抓取数据。“他们抄袭，却不以任何方式支持这个项目”。随后，彼得·斯坦伯格还问及腾讯混元“愿意帮帮忙吗？而不是让我的服务器成本飙升到五位数？”

对此，Tencent AI 官方回应道：SkillHub 是基于 OpenClaw 生态系统构建的本地化技能平台，为中国用户提供更好的可用性和速度。只是面向中国用户的本地镜像站，标注 ClawHub 为原始来源；同时，腾讯上线首周给用户分发了 180GB（87 万次下载），但从官方源只拉取约 1GB。此外，团队成员本身也是项目代码和 PR 贡献者，希望继续支持生态并成为更好的赞助商。

此前，3 月 11 日消息，腾讯董事会主席兼首席执行官马化腾凌晨 2 时许在朋友圈转发了腾讯推出全系“龙虾”产品矩阵的公众号文章，并配文“自研龙虾、本地虾、云端虾、企业虾、云桌面虾，安全隔离虾房、云保安、知识库…… 还有一批产品陆续赶来”。

3 月 9 日，腾讯旗下全场景 AI 智能体 WorkBuddy 正式上线。据介绍，WorkBuddy 完全兼容 OpenClaw 的技能，同时还做到了更易用、更安全、更懂办公。据了解，在官网下载安装后，直接输入指令就能让 WorkBuddy 帮干活；如果用户想通过企业微信远程“遥控”，最快 1 分钟即可完成配置并连接。此外，它还能接入 QQ、飞书、钉钉等工具。这意味着，哪怕你在外通勤，只需掏出手机发条语音，它就能在你的办公电脑上自动查资料、写推文，直接交付可验收的结果。

3 月 11 日，腾讯宣布推出专为中国用户优化的AI Skills社区——SkillHub。它基于OpenClaw官方开源生态打造的本土化配套服务平台，完整兼容官方社区的全量技能生态，可在不改动官方开源内容的前提下为官方生态在国内落地提供配套服务支撑。针对OpenClaw等AI Agent工具的Skill安装痛点，提供高速下载、精选榜单、中文搜索等核心功能。

另外，腾讯云智能体开发平台自 2026 年 3 月 13 日起调整部分模型计费策略，GLM5、MiniMax2.5、Kimi2.5 等模型结束免费公测，转为正式商用，按调用量计费。混元系列模型 Tencent HY2.0Instruct 与 Tencent HY2.0Think 价格也有调整，Tencent HY2.0Instruct 输入、输出价格涨幅超 450%，Tencent HY2.0Think 输入、输出价格也有提升，套餐用户可通过套餐抵扣部分费用。

微信正在研发自有模型和“绝密级”AI 智能体

3 月 11 日凌晨，《The Information》爆料称，微信正在秘密开发一款“绝密级”AI 智能体项目，为其微信应用开发 AI 助手。该项目在公司内部被列为高度机密计划，其启动时间至少可以追溯到去年上半年。一旦上线，该智能体将连接微信平台内数百万个小程序，涵盖网约车、外卖等多种服务，从而取代 14 亿月活跃用户手动完成这些任务的需求。

同时除了布局Agent之外，市场消息显示，微信正在尝试研发一套独立的自有AI模型，以支持微信内部的AI智能体开发，以及服务微信整体的AI生态，该AI模型已完成基础能力建设及内部代号命名，预计将于2026年对外落地。

月薪两万养不起一只龙虾！排队养虾后又排队卸载

3月11日消息，当人们还沉浸在“雇佣数字牛马”的美梦中时，第一批“养虾人”已经开始连夜寻求卸载，催生了上门彻底卸载服务，“龙虾卸载指南”也开始在网络上流传。3月11日，媒体在二手交易平台上查询发现，不少“上门卸载或远程卸载OpenClaw”服务已经上架，卖家称“安全干净不留痕”。

从流传的“龙虾卸载指南”来看，则是指出养龙虾的成本和风险，并建议普通用户不必急于入手，可等待更成熟的版本。除了安全风险，高昂的“养殖成本”是劝退普通用户的第二大主因。与传统聊天机器人包月付费的模式不同，作为Agent的OpenClaw在执行任务时，需要频繁地读网页、调工具、分解任务并与大模型进行多轮交互。这种运行机制导致其Token消耗量是普通大模型的数倍甚至上百倍。有用户实测，执行一次复杂的程序调试任务，一天就能烧掉数万元人民币的成本。市场甚至流传着“月薪两万，养不起一只龙虾”的说法。不过，3月11日，国家超算互联网宣布，面向平台全体OpenClaw用户免费发放1000万Tokens额度，限时2周。同日，超算互联网还公布了OpenClaw的Token续购价格，为0.1元/百万Tokens。

近期闲鱼平台上与开源AI智能体 OpenClaw相关的商品及服务热度急剧攀升。据悉，“小龙虾”相关搜索量环比暴涨1850%，成交量亦翻数倍。目前，闲鱼上已形成完整的“养虾”产业链，包括：OpenClaw部署教程（售价低至1元，有卖家一周售出上千份）；远程安装指导服务（基础版88元，升级版118元，订单已排至两天后）；Mac mini M4设备租赁（原价四五千元的设备，月租仅400元，搜索量周环比增长280%）；还有“小龙虾卸载上门服务”、专属用户社群、Agent优化训练等衍生服务。

Kimi 新一轮 10 亿美元融资正在进行，估值涨至 180 亿美元

据《科创板日报》报道，月之暗面 Kimi 最新估值已上升至 180 亿美元（现汇率约合 1243.55 亿元人民币），3 个月内估值翻了 4 倍。不仅如此，新一轮 10 亿美元（现汇率约合 69.09 亿元人民币）融资也正在进行中。

报道提到，Kimi 在不到 3 个月的时间内已先后完成 3 轮融资，创下近年来国内大模型连续融资最多纪录，并成为国内估值最快突破百亿美元的独角兽公司。

本月早些时候，全球支付平台 Stripe 公布的数据显示，Kimi 个人订阅用户支付订单量 1-2 月呈现爆发式增长。1 月个人用户支付订单数环比增长 8280%，2 月环比再涨 123.8%。

中国传媒大学砍掉16 个本科专业，直言教育要面向人机分工时代

近日，中国传媒大学党委书记廖祥忠在全国两会期间发言引发关注。他透露去年学校已一次性调整停办 16 个本科专业方向，包括翻译、摄影等。今年 Seedance 2.0 问世让他坚定变革决心，他正推进课堂革命，强调老师要明确课程意义、掌握课程要点及解决破解之道，还提到政府工作报告对人工智能重视达到前所未有的高度。此外，2025 年度该校拟申请增设 3 个本科专业，拟撤销 7 个本科专业，预计 2026 年招生将披露最新砍掉的 16 个本科专业和方向。

Meta或将裁员至少20%

3 月 14 日消息，路透社刚刚援引消息人士的话称，Meta 正计划进行大规模裁员，裁员日期未定，规模也未最终确定。消息人士认为，此次裁员可能会波及公司 20% 或更多的员工。此举旨在抵消其 AI 基础设施上的巨额成本，并为“AI 辅助型员工”带来的效率提升做准备。

其中两位知情人士透露，Meta 高管近期已向其他资深领导人传达了相关计划，并要求他们开始规划如何精简团队。

路透社指出，如果最终确定 20% 的裁员比例，这将是该公司自 2022 年底至 2023 年初那场被称为“效率之年”的重组以来，规模最大的一次人员缩减。

根据 Meta 最新提交的文件，截至去年 12 月 31 日，公司员工总数接近 7.9 万人。回顾此前，Meta 曾在 2022 年 11 月裁撤约 1.1 万个岗位，约占当时员工总数的 13%；大约四个月后，又宣布再裁减 1 万个职位。

本周早些时候，Meta 还刚收购了面向 AI 智能体的社交网络平台 Moltbook。此外，据路透社此前报道，Meta 还打算斥资至少 20 亿美元（现汇率约合 137.63 亿元人民币）收购中国 AI 初创公司 Manus。

320 亿美元创最大交易纪录：谷歌历时一年正式完成 Wiz 收购

3 月 11 日消息，谷歌母公司 Alphabet 今日宣布，已完成对网络安全公司 Wiz 的 320 亿美元（注：现汇率约合 2200.49 亿元人民币）全现金收购交易，Wiz 即日起正式加入谷歌云。

这是谷歌成立 26 年来规模最大的一笔收购，标志着其在云计算与人工智能时代加码安全布局的战略决心。谷歌云表示，在当前 AI 快速发展的背景下，云安全的重要性与日俱增。Wiz 提供的平台能够帮助客户在各类云服务之间保护数据安全，其技术能力将与谷歌云形成深度协同。

Wiz 成立于 2020 年，由 Assaf Rappaport 等四位以色列创业者共同创立，其创始团队曾于 2015 年将云安全公司 Adallom 以 3.2 亿美元出售给微软。如今，Wiz 已成为云原生安全领域的明星企业，其平台能够帮助企业识别并修复多云环境中的安全风险。

对谷歌而言，收购 Wiz 是其在云业务上加码的关键一步。长期以来，谷歌云位居亚马逊 AWS 和微软 Azure 之后，位列全球第三。随着企业客户对 AI 和云安全的双重需求激增，谷歌希望通过整合 Wiz 的技术，为企业提供更安全、更可信的 AI 基础设施，从而在竞争中缩小与领先者的差距。

收购完成后，Wiz 将继续保持多云服务策略。谷歌明确表示，Wiz 的产品仍将通过亚马逊 AWS、微软 Azure 等竞争对手的云平台提供给客户。Wiz 首席执行官 Assaf Rappaport 在公司博客中强调：“我们的使命一如既往地大胆：保护各类组织构建和运行的一切。而这一切才刚刚开始。”

杨立昆再联手谢赛宁，英伟达参投，新公司完成 10.3 亿美元融资

3 月 10 日消息，据媒体获悉，世界模型研究所/创业公司 AMI 已完成 10.3 亿美元融资，投前估值 35 亿美元。该公司由图灵奖得主、前 Meta 首席 AI 科学家杨立昆创办。AMI 全称 Advanced Machine Intelligence“先进机器智能”，以世界模型为主要研发方向，力求开发出能够从真实世界中学习抽象表征的世界模型。

值得一提的是：谢赛宁，AI 基础研究方面的顶级专家，也是杨立昆的老朋友、学校同事，已经正式加入了 AMI 担任首席科学官。谢赛宁是视觉表征学习方面的绝对权威，diffusion transformers (DiT) 的共同作者之一。杨立昆曾表达过将欧洲树立为中国、美国之外的全球人工智能“第三极”的希望。AMI 公司总部位于巴黎，并将设立纽约、蒙特利尔、新加坡办公室。AMI 六位核心创始人，四位直接来自 Meta FAIR（基础人工智能研究）团队，另外两位也有深厚的 Meta 渊源。杨立昆担任公司董事长，CEO 另有其人。

根据媒体获得的一份融资纪要，AMI 本轮融资将用于支持长期科研、全球范围招聘工作，以及世界模型方向上的可靠产品。AMI 本轮融资由凯辉创新、Greycroft、Hiro Capital、HV Capital、贝索斯远征共同领投；战略投资人当中包括英伟达、丰田创投、淡马锡、软银、马克·库班、穆里耶家族等；跟投方包括埃里克·施密特、阳狮集团、三星、蒂姆·博纳斯·李等。

vivo前产品经理宋紫薇创业，瞄准AI时尚Agent，获亿元融资

3月9日，有网友爆料，前vivo明星产品经理宋紫薇创办的AI硬件公司“薇光点亮”近日完成超亿元Pre-A轮融资。据悉，“薇光点亮”将聚焦“AI+时尚”赛道，致力于构建以时尚AI Agent为核心的智能硬件产品矩阵。公司内部正在研发的首款AI原生时尚终端，硬件形态预计为智能落地镜。

宋紫薇的创业节奏迅猛，其公司2024年9月曾获中科创星、九合创投数千万天使轮投资，此次Pre-A轮融资距天使轮仅五个月。所筹资金将用于高端人才引入、智能硬件研发、垂类模型训练及关键场景落地。据了解，宋紫薇作为vivo iQOO早期创始成员，曾主导多款爆款手机产品，被誉为“手机行业明星产品经理”，后曾任职理想汽车，积累了丰富的消费电子与高端智能硬件全流程实战经验。

Gemini 牵手五角大楼，美国国防部超 300 万人用上谷歌 AI 智能体

3 月 11 日消息，据外媒报道，谷歌宣布向美国国防部超过 300 万名文职与军职人员部署 Gemini AI 智能体。美国国防部负责研究与工程事务的副部长埃米尔 · 迈克尔表示，谷歌提供的工具初期仅用于非机密网络，将其扩展到机密和最高机密系统的计划尚待讨论。首批上线的八个 AI 智能体主要用于自动处理行政事务，支持整理会议纪要、编制预算以及审查行动计划是否符合美国的国家防务战略。谷歌副总裁吉姆 · 凯利周二在博客中表示，美国国防部工作人员还可以通过自然语言自行创建定制 AI 智能体。

自去年 12 月以来，五角大楼约 120 万名员工已通过 GenAI.mil 门户提供的谷歌 AI 聊天机器人完成非机密任务。期间，工作人员提交了约 4000 万条不同提示，并上传了超过 400 万份文件。不过，培训进度明显落后于实际使用情况。自 12 月以来，仅有 26000 人完成 AI 培训课程。展望未来，培训场次已经全部约满，越来越多员工正在加入 AI 工具的使用行列。

与此同时，美国国防部也在迅速扩大与 AI 公司的合作。此前，因为 Anthropic 拒绝移除其技术中针对国内监控和自主武器的安全限制，美国国防部将 Anthropic 列为“供应链风险”，而 Anthropic 则表示将通过诉讼挑战这一决定。在与 Anthropic 关系紧张之后，美国国防部已经分别与 OpenAI 和 xAI 达成合作，将 AI 技术部署到受限网络中。据了解，谷歌与五角大楼的合作曾在 2018 年引发公司内部强烈反弹。当时数千名员工抗议“Project Maven”项目，该项目利用 AI 分析无人机视频画面。谷歌最终没有续签这一合同，近年来却逐渐放松了对军事项目合作的限制。

小红书发布公告：将严格打击 AI 托管类账号

3 月 10 日消息，今日小红书薯管家发布公告称，小红书坚定维护社区的真实底色，严格禁止任何利用技术手段模拟真人、进行非真实内容创作或虚假互动的行为，将对采用 AI 托管模式运营的账号进行治理。同时呼吁用户在创作过程中合理使用 AI 工具，如发现疑似 AI 托管账号或相关内容，请第一时间通过举报按钮向平台反馈。

盗号、养号、再卖号：央视315曝光黑灰产“养号工厂”

3 月 15 日消息，今日，央视调查曝光了一条互联网账号盗号、养号、再卖号的黑色产业链。在这条被称为“养号工厂”的黑灰产链条中，诈骗分子通过各种手段获取互联网账号后，通过技术手段进行“清洗”和“养殖”，最终将这些看似真实活跃的账号出售给实施诈骗的犯罪分子。

据央视介绍，在黑灰产的“养殖场”里，有一种被称为“主板机”的设备可以同时控制几十台手机终端，自动完成点击、滑动画面、操作 App 等一系列动作。所谓“养号”，就是让这些盗取或购买的互联网账号模拟真实用户的行为 —— 刷视频、点赞、发评论，使账号表现出“真实活跃”的状态，从而规避平台的风控机制，确保不被封号。经过一段时间的“养护”，账号达到可售状态后便进入“收割”环节。

这些被“养熟”的账号最终被明码标价出售。据央视调查，账号的实名认证时间越长、绑定的支付信息越完善，价格就越高。交易通常通过虚拟货币在非法平台上进行，而买家正是那些伪装成“客服”的诈骗分子。他们利用这些看起来真实活跃的账号，冒充客服实施诈骗，大大增加了诈骗活动的隐蔽性和迷惑性。

据悉，今年“3·15”晚会聚焦“放心消费品质生活”主题，将关注食品安全、公共安全、金融安全、广告市场等领域侵害消费者权益的违法行为。

大模型一周大事

重磅发布

百度推出首款手机龙虾应用“红手指 Operator”

3 月 12 日，百度智能云宣布推出全球首款手机龙虾应用“红手指 Operator”。该应用已上线安卓市场，用户安装注册红手指 Operator 后，即可直接指挥这只手机“龙虾”执行任务。

其中，OpenClaw 负责处理复杂任务，可在 PC 与网页端环境中执行大量自动化操作，Operator 则主要负责原生 App 环境中的任务执行。

微软推出 AI 健康平台 Copilot Health，发布 Copilot Cowork

3 月 12 日，微软宣布推出“独立健康空间”Copilot Health，用户可以查询化验结果、查看医疗记录、搜索医生或医疗机构，并分析来自可穿戴设备的数据，还可完成各种健康相关问答。

微软表示，Copilot Health 不会取代医生，也不会提供诊断或治疗建议。其定位是帮助用户理解个人健康数据，用户可以通过 HealthEx 从美国超过 50000 家医院和医疗机构导入医疗记录，也可以导入化验结果。

Copilot Health 还支持苹果、Oura 和 Fitbit 等厂商的 50 多种可穿戴设备。系统主页可以显示步数等实时数据，也可以提醒用户即将到来的医疗预约，具体取决于用户愿意共享的数据。

用户还可以通过 Copilot Health 寻找医生。系统连接美国实时医疗服务提供者数据库，用户可以按照专科领域、地理位置、使用语言以及保险计划筛选医疗机构或医生。微软表示，Copilot Health 通过优先引用来自全球 50 个国家权威医疗机构的信息，提高回答的质量和可靠性。Copilot Health 的回答会附带来源链接，同时还会提供来自哈佛健康出版的专家解答卡片。

此外，3 月 9 日，微软宣布推出全新智能代理工具 Copilot Cowork，这一功能基于 Anthropic 今年初发布的 Claude Cowork 技术构建，并结合 WorkIQ 提供的上下文信息，旨在让企业用户将复杂工作任务直接交给 AI 自动规划和执行。微软强调，Microsoft 365 Copilot 面向“多模型世界”而设计，可根据具体需求在 OpenAI 与 Anthropic 模型之间动态选择，以实现更合适的能力组合。

今年 1 月，Anthropic 首先在 Windows 和 Mac 平台上推出 Claude Cowork，为本地环境引入“代理式”AI 能力：用户只需分配任务，Claude 就可以利用对本地文件的完整访问权限自行制定计划并完成执行。此次发布的 Copilot Cowork 沿用了同一技术路线，进一步融入 Microsoft 365 生态，使其能够在邮件、日历、文档等企业工作场景中充当“后台执行助手”。在实际使用中，用户可以随时查看进度、调整计划，或在必要时终止执行，还可以同时发起多项任务，并通过全新的统一控制面板集中管理这些任务的状态。

马斯克官宣数字 AI 员工：数字擎天柱

3 月 12 日，马斯克在 X 平台上正式宣布了一项全新的重磅 AI 项目：“数字擎天柱（Digital Optimus）”，项目代号直指微软，定名为“巨硬（Macrohard）”。不同于在现实世界搬砖的实体机器人，数字擎天柱是一位主攻网络和电脑端操作的“数字 AI 员工”。

马斯克将数字擎天柱定义为类似“系统 1”的执行者，而大模型 Grok 则是类似“系统 2”的思考者。简单来说：Grok 充当总指挥，负责理解和决策；数字擎天柱化身“人类模拟器”，负责具体的电脑操作与执行。对于自己的新作品，马斯克还放话说： “从原则上讲，它甚至可以模拟一家完整公司的运作。”

据透露，早在今年 1 月，数字擎天柱就已经在 xAI 启动了内部测试，甚至“以员工身份上任”。硬件层面是本次公布的一大亮点。数字擎天柱主打小模型与极致的推理速度，它将直接运行在特斯拉自研的 AI4 芯片上。马斯克透露，其功耗仅为英伟达 H100 的四分之一，成本低至 650 美元，该项目只会少量使用英伟达的计算硬件。

智谱上线 AutoClaw：一分钟本地部署「龙虾」

3 月 11 日，智谱正式上线 AutoClaw（中文名：澳龙），它是国内首个真一键安装的本地版 OpenClaw，用户下载后可在本地电脑部署「龙虾」，享用 OpenClaw 原生能力，智谱提供一定免费额度供体验。AutoClaw 澳龙预置 50 + 主流 Skills，覆盖高频场景，支持接入即时通讯工具和模型 API。它还内置龙虾专属模型 Pony-Alpha-2，该模型综合性能较强，内测版本已开放试用，正式版本近期将发布。

企业应用

目前企业微信支持一键扫码接入 OpenClaw，用户在腾讯云后台选择「快捷配置」，点击「前往授权」，用企业微信扫码可一键创建智能机器人。各大主流云服务、大模型厂商及 OpenClaw 的生态产品正陆续上线支持通过企业微信接入 OpenClaw。3 月 12 日，九号公司宣布支持 OpenClaw 接入，AI Agent 开始进入两轮智能电动车场景。据悉，相关技能 ninebot-device-skill 已正式上架 ClawHub。首批上线的 skill 主要开放车辆状态、充电状态、电量、定位、里程、续航估算等信息读取能力，AI Agent 可基于授权数据，主动提醒，生成车辆简报，出行效率分析及充电、安全提醒等服务。当前阶段仅开放只读接口，不涉及远程解锁、调速控制等车辆操控功能。3 月 11 日，埃隆 · 马斯克表示，社交媒体平台 X 旗下的数字支付系统 X Money 将于下月进入早期公测阶段，这位亿万富豪正推动将 X 打造成一款“超级应用”。此举正值这位特斯拉 CEO 希望借助该平台庞大的用户基数，以及数字支付与应用内金融交易的增长趋势，为 X 开辟新的收入来源。3 月 10 日，OpenAI计划在ChatGPT平台上整合其AI视频生成器Sora。这一战略转变将拓展OpenAI在多模态AI技术领域的布局，有望提升用户对OpenAI聊天机器人的使用率，但同时也会增加成本。预计从现在到2030年，其推理成本将超过2250亿美元。

从分到秒：Uber通过共识架构提升MySQL集群的正常运行时间

作者：Leela Kumili — Mon, 16 Mar 2026 07:00:00 GMT

为了提高集群的正常运行时间，Uber重新设计了其MySQL基础设施，用MySQL Group Replication（MGR）取代了外部故障转移。这一改进被应用于数千个集群，故障转移时间从分钟级减少到秒级，而且保持了强一致性。此次重构首先引入共识复制机制以消除外部依赖"，然后通过自动接入、节点管理、自动重新平衡及安全防护扩展到了整个机群"，并且满足多数表决和运行可靠性要求。

以前，Uber的MySQL集群采用的是单主异步复制模型。外部系统检测到故障时会提升副本，故障转移时间以分钟计。为了减少停机时间并提高可靠性，Uber采用了MySQL Group Replication"，这是一种基于Paxos的共识协议。新架构将共识机制嵌入到数据库中，形成了一个三节点MGR集群。一个节点作为主节点用于写入，而另外两个辅助节点参与共识表决而不直接接受写入。这可以确保所有节点都有最新的数据，并在需要时自动选举新的主节点。

在LinkedIn上的博文"中，Uber工程部门强调：

在Uber，高可用性是绝对不能妥协的。

可扩展读副本从辅助节点扇出，在保证容错性的同时将读可扩展能力与写可用性分离。MGR内部的流量控制机制监控每个辅助节点的事务队列，并根据需要向主节点发出暂停或根据需要限制写入操作的信号，从而防止节点落后。该机制可以避免出现复制不一致的情况，减少故障转移期间的写入停机时间，并阻止错误的GTID"传播到集群之外。

基于共识的MySQL集群架构（图片来源：Uber博文"）

从基准测试中可以看出新设计所做的权衡，与异步复制相比，其写入延迟略有增加（数百微秒），但主节点故障期间的总写入不可用时间从几分钟大幅减少到10秒以下，包括主节点选举和路由更新。由于本地副本性能与旧模型相当，所以读取延迟保持不变。

Uber使用一个自动控制平面扩展了架构，用于集群上线、回退到传统复制模式以及拓扑变化期间的重新平衡。工作流同时处理优雅与非优雅的节点替换，通过配置项（如group_replication_unreachable_majority_timeout"）和单领导模式防范脑裂与少数派分区问题。自动化拓扑健康分析可在组内节点低于法定数量时动态添加新节点，并移除冗余节点以降低开销。节点删除过程中会重新指向下游副本，并利用可选的积压应用阻塞来保持严格的外部一致性。

重新平衡共识集群工作流（图片来源：Uber博文"）

Uber工程师表示，他们在大规模实施MySQL Group Replication时发现，MGR插件"使用了performance_schema.memory/group_replication"，需要谨慎处理group_replication_bootstrap_group"以防出现脑裂场景。为了保持简单性和操作可预测性，他们选择了单主模式而不是多主模式，因为后者出现冲突的风险更高，需要强大的冲突解决机制来保证事务排序。基于共识的复制机制、自动化工作流和可扩展的读副本，三者结合实现了Uber MySQL集群的高可用性和强一致性，减少了手动干预，为其大规模MySQL基础设施提供了一个坚实的基础。

声明：本文为InfoQ翻译，未经许可禁止转载。

原文链接：https://www.infoq.com/news/2026/03/uber-mysql-uptime-consensus/"

Webpack发布2026路线图：原生CSS支持、通用目标及向6.0版本的演进路径

作者：Daniel Curtis — Mon, 16 Mar 2026 06:00:00 GMT

Webpack"（由OpenJS基金会维护的应用广泛的JavaScript模块打包器）发布了2026年开发路线图"，概要介绍了一系列改进，主要包括：减少插件依赖、扩展运行时兼容性，并为Webpack 6奠定基础。

该路线图由技术指导委员会成员Even Stensberg"撰写，其中有几个优先事项，包括：无需插件的原生CSS模块支持、新的通用编译目标、内置TypeScript转译以及HTML入口点集成。该路线图还表明，Webpack希望借鉴竞争对手工具的思路来探索性能优化方法。

其中最重大的一个变化是将CSS模块支持直接集成到Webpack内核。目前是通过experimental.css选项提供，集成后将不再需要mini-css-extract-plugin。据其团队估计，内核集成将在2026年初完成，届时将不再依赖插件进行CSS处理，而在Webpack 6发布之前，该功能将一直处于实验状态。开发者现在就可以启用实验性支持。

另一个比较重大的变化是计划实现的通用目标"，旨在编译可以跨Node.js、Bun、Deno和浏览器环境运行的代码。无论应用程序是否使用了CommonJS模块，Webpack都会将它们封装，使得最终输出是运行时无关的纯ESM。目前，ESM输出尚未完全开发完成，还需要额外做一些修复"和测试。

该路线图还宣布将提供内置TypeScript支持（消除ts-loader依赖），以及原生HTML入口点（消除html-webpack-plugin依赖）。两者都是采用将常见插件功能吸收到内核的模式。此外，团队还在评估一个受Rspack"启发的懒桶优化。该优化会跳过无副作用桶文件中未使用的重导出模块，直到实际需要时才构建。其他改进包括：一个统一的minimizer-webpack-plugin，用于取代当前一系列单独的最小化器，如terser-webpack-plugin和css-minimizer-webpack-plugin；探索内核Multithreading API，为大型构建带来更好的并行处理。

打包器的竞争格局已经发生了相当大的变化。Vite已经成为许多新项目的默认选项，而Rspack（来自字节跳动的一个兼容Webpack的替代品，基于Rust开发）提供了明显更快的构建速度"，并且兼容大多数Webpack插件。在Hacker News"上，有一位用户提出了一个关于治理的有趣观点。他指出，Webpack由OpenJS基金会管理，这保证了其中立性，那可能是由风险投资公司支持的替代品所不具备的，从中可以看出“对生态系统在单一商业路线图下垂直整合的担忧”。

在Reddit"上，人们褒贬不一。一位用户说，他们愿意看到它的复兴，但同时也指出，如果没有用Rust/Go重写，那将很难做到。

许多评论者认为他们提出改变的时间“太晚了”：

他们已经落后太多，现在无法保持竞争力了。实际上，我用Rolldown-Vite可以在不到一秒钟的时间内构建项目，而以前用Webpack需要将近一分钟。

Webpack维护者在这个帖子下澄清"道：

我们并不打算与其他打包器竞争，我们只是想现代化Webpack，尽可能加快它的速度，并给它带来一些新鲜空气。使用你认为最适合你的工具。但我们知道，仍然有很多人在使用Webpack。为此，我们的目标是为他们提供更友好顺畅的体验，保持一贯的稳定性。

对于希望使用最新版本的团队，Webpack提供了一个官方迁移指南"，用于从版本4升级到版本5，以及详细的变更日志"。考虑使用其他替代品的团队也可以参考Rspack的迁移文档"，该文档专为寻求即插即用式性能提升的webpack 5项目而设计。

Webpack是一个开源的JavaScript应用程序模块打包器，最初由Tobias Koppers创建。它处理和打包包括JavaScript、CSS和图像在内的资产，并且仍然是npm生态系统中应用最广泛的构建工具之一，提供了与React、Angular和Vue等框架的一流集成。

声明：本文为InfoQ翻译，未经许可禁止转载。

原文链接：https://www.infoq.com/news/2026/03/webpack-2026-roadmap/"

把99.9% 代码交给 AI ：腾讯云⼀次“吃狗粮”的⼯程实验

允毅 — Mon, 16 Mar 2026 05:23:38 GMT

2026年初，一场关于研发效率的“暴力实验”在腾讯云内部秘密收官。

这场试验的主角是AI编程工具CodeBuddy的2.0版本升级。按照大厂传统的研发步调，这类架构级的演进通常需要一年；但最终，腾讯云仅动用了4名工程师，在4个月内便完成了任务。

更具冲击力的是，在整个开发过程中：99%的代码由AI生成。

“AI写了多少代码，其实是最不重要的指标，”CodeBuddy团队在内部复盘时直言不讳。行业正集体从“代码生成率”的虚假繁荣，转向对“研发吞吐量”的硬核追求。

AI Coding早已越过“辅助工具”的边界，从需求拆解、方案设计，到代码执行、测试验证，AI正在参与研发流程的每一个环节，成为执行主力；而人则退到关键节点，负责判断、校验与兜底。

这种角色的转变，倒逼团队去解决那个最折磨人的工程难题：如何为AI搭建一个可执行、可校验、可持续迭代的工程化环境？

让AI明确意图、组织高质量上下文、注重第一行代码、让多Agent分工协作以提升效率，这些关键问题，都在重新定义人与AI的协作边界。

Code Buddy的这次升级，正是在这些问题上不断试错的过程。进入2026年，大厂已经形成一个共同竞逐方向：如何让AI自主、稳定地完成“超长周期任务”。

（1）如何让AI精准理解意图

Vibe Coding流行时，开发者沉浸在“几句话生成一个App”的爽感里。然而，进入2025年，这种新鲜感正迅速被一种集体的焦虑所取代：当项目从0到1的“小样”变成从1到100的“工程”时，AI突然失灵了。

可控性不足、上下文爆炸、逻辑漂移……这些问题让AI编程工具卡在了规模化的门口。

AI无法可靠交付，核心症结在于意图对齐的失效。自然语言灵活却多义，如果不给足背景，AI只能靠“猜”

为了终结这种低效的博弈，微软在2025年推行Spec Kit，将规约编程带入主流视野。其核心逻辑是将开发解构为严密的五阶链条：宪章、需求、架构、任务、实现。

在AI敲下第一行代码前，必须先生成一份可执行的“规格说明书”。这让AI从一个漫无目的的写手，变成了一个严格按图索骥的木工，开始“指哪打哪”。

但在实际交付中，Spec的落地却十分艰难。腾讯CodeBuddy 团队为此踩了不少坑：

• 人性的博弈：工程师极度抵触写Spec。拆解任务本身就极度烧脑，一旦项目工期收紧，团队往往直接绕过文档改代码。最终，文档与实现彻底脱节，前期的Spec投入沦为废纸。

• 业务的盲区：很多时候，不是AI没理解，而是人自己也没有把需求想清楚：目标、边界、异常处理、验收标准本来就是模糊的。即便写成Spec，也未必真正“可执行”，很多文档只是把模糊需求重新整理了一遍，并没有转化为可拆解、可验证的约束。尤其在复杂业务里，AI能检索信息，却难以理解隐含规则和潜在前提。

对此，腾讯CodeBuddy团队针对性给出解决路径，面对工程师的抵触心理，先通过强制执行规范，并在内部建立吃狗粮小群，用效率带动大家的参与积极性；同时，建立项目级指导原则明确隐性信息，再通过“审阅-挑战-修正”循环审查AI生成的Spec，将大需求拆分为小而明确、可快速交付的子任务，把所有代码变更纳入Spec管理以避免文档与实现脱节；在工期紧张时，将Spec作为高压下的决策工具，通过量化影响、取舍需求、拆解并行任务提升效率，平衡规范与进度，化解工程师抵触情绪，填补业务盲区，让Spec真正落地见效。

Spec的作用是降低歧义、固定边界、提供验收基线，但它不是一张写完就能照着施工的完美图纸。真实项目里，Spec往往需要边做边补、边执行边修，否则很快就会和代码脱节，最后重新沦为形式文档。

要实现高质量、结构化的上下文，仅有Spec远远不够。在CodeBuddy团队看来，他们的核心做法是以Agentic Coding为核心：先通过Spec将需求、边界与规则固化，再将执行环节交由智能体负责，由智能体在执行过程中持续拆分任务、补齐缺失信息，并主动发起疑问，确保整个开发流程高效且精准。

不过，CodeBuddy团队也发现，真正进入复杂工程场景后，有一些问题即使被识别出来，短期内也很难找到成熟解法。

比如，随着项目规模扩张，“上下文爆炸”成为了致命伤。理论上AI掌握的信息越多越好，但大量冗余信息一股脑塞入Context，反而会干扰模型判断，导致AI “变傻”或偏离目标。

面对瓶颈，CodeBuddy给出了一套解耦研发流的工程化方案：研发流程本身就是解耦的，不必让AI一次性“吞下整个项目”。在每个任务流完成后主动清理上下文，只保留当前必需信息，从源头避免信息冗余带来的状态漂移。

AI在执行拆解好的任务时，还会出现跳过任务、漏勾选任务，或者在没有满足验收条件的情况下错误地标记完成。而每个环节本来还有赖于人的检查、把关与修正，可以在AI做不好时重新校准，但人的懒惰性，反倒成了短期内难以突破的症结。

说到底，Spec本质上是在逼人把原本模糊、偷懒那部分工作补上。

如果这些问题能够被逐步解决，那么可复用的优质workflow才有可能在更多企业真正落地，AI也才可能更深地嵌入研发流程，让团队从“高速生成”走向“高质量生成”。

（2）把握好第一行代码是关键

在软件工程中，存在一个幽灵般的定律——“代码腐化”。系统迭代越多，复杂度越高，稳定性便越脆弱。而当AI介入后，这场腐化正在以指数级速度提前到来：如果第一步走歪了，AI会以前所未有的效率将错误放大。

2025年的一项研究揭示了AI编程残酷的一面。论文《Security Degradation in Iterative AI Code Generation》对400个代码样本进行了40轮连续优化测试。结果令人心惊：仅经过5轮迭代，关键安全漏洞就激增了37.6%。

这种现象在多轮对话中尤为明显。Salesforce研究员Philippe Laban在其最新研究中指出，随着对话轮次增加，大模型的逻辑表现平均跌幅达39%。这意味着模型一旦早期走错，后面往往“越改越回不来”。

正因为这样，在AI Coding的研发流程里，最重要的是第一行代码。LLM本质上是一个模仿和条件生成系统，它特别依赖初始约束（即system prompt），而企业级研发中，这种初始约束的核心载体，就是项目的第一行代码。

第一行代码的核心价值，本质上考验的是“代码品味”。这对研发者提出了更高要求，经验足够的工程师，往往能在项目一开始就把方向卡住；但对经验没那么多的新人来说，最难的恰恰就是这一步。

为了对抗这种不确定性，头部大厂正在将“品味”工程化。腾讯云内部把项目初期的代码搭建标准化，尽量减少开发者对个人经验的依赖：先把结构、规范和质量门槛定下来，再让后续开发在这个基础上继续迭代。

无独有偶，OpenAI在今年2月发布的《Harness engineering: leveraging Codex in an agent-first world》披露类似的思路，团队会通过自定义代码检查器、结构测试等方式，约束初始代码的写法，同时配合一组相对稳定的“品味不变式”，尽量让系统从一开始就沿着统一的结构演化。

所谓“品味不变式”，可以理解为代码里的“固定习惯”或“基础审美”。因为AI很容易为了尽快完成眼前的小功能，临时拼凑出一段能跑的代码，但这样做的代价，往往是整个系统的结构越来越乱：风格不统一、逻辑重复、模块互相缠绕，后面越改越难。

它强制要求AI在每一行代码中守住三个维度的“品味”：

• 一个模块只做一件事：

如果AI试图在同一个函数里既处理数据，又写业务逻辑，还顺手管日志和错误处理，系统就会拦下来。这样做是为了避免代码越写越臃肿，保证每个部分职责清晰，后面改起来不容易牵一发动全身。

• 不要一上来就过度设计：

AI特别容易“想太多”，明明只是一个简单功能，却先搭一堆抽象层、通用接口和复杂结构，看起来高级，实际上很难维护。OpenAI的规则是：除非同样的模式反复出现，否则不要急着抽象，先把事情做简单、做直接。

• 关键的错误处理和日志不能漏：

尤其在异步或复杂系统里，AI很容易把这些“看不见但很重要”的部分省掉。于是OpenAI要求，生成的代码必须遵守统一的错误处理和追踪方式，确保系统以后出了问题，至少还能查得到、定位得了。

OpenAI也承认，没有人能保证，一个大量由AI生成的系统，几年之后还能不能始终保持结构稳定。但至少在当下，行业里已经形成一个越来越明确的共识：AI生成得越快，就越需要更强的规则、工具和反馈机制，来约束它一开始往哪里长。

（3）白天写代码，晚上修代码

当AI能够精准理解意图、初始代码质量得到保障后，如何解决“高速生成与质量稳定的矛盾”，成为AI编程规模化落地的最终保障。

腾讯云内部，将这套人机协作的模式总结成一句话“白天用时间换效率，晚上用效率换时间”。

这听起来像是一种工业时代的轮班制，但在AI时代，它精准地描述了高效研发的闭环。白天，开发者与AI并肩作战，利用高频交互将功能快速推向前线；而到了深夜，当人类离线，真正的“质量治理”才刚刚开始——Agent集群接管了战场，开始对白天高速生成、略显粗糙的代码进行一场彻头彻尾的“外科手术”。

之所以没有把这套模式直接搬到白天，一个很重要的原因是：Agent虽然细，但也慢。

在具体实践中，他们会让多个Agent分别扮演不同角色，从不同角度分析和优化同一批代码。比如，有的Agent看架构，有的看代码质量，有的补测试，有的查性能，有的看前端，有的看后端。它们先各自提出问题和修改建议，再把结果汇总，由执行Agent或开发者统一落地。

这个灵感来自Anthropic最新推出的Agent Teams功能，即并行跑多个Claude，充当不同的技术专家，每一个Agent都拥有相对独立的上下文和工具权限，并且在需要时能交换信息。

其出发点，是避免单一AI会话在处理大规模复杂项目时，随着上下文不断累积，出现理解偏移、推理变钝和串行执行效率下降的问题。Claude Code能够保持每个执行单元的“智商”处于巅峰状态，尤其适合放在夜间做代码优化和质量治理。

这背后对应的，是AI编程领域一个更底层的分歧：复杂的软件开发，究竟应该交给一个足够强、持有完整上下文的单Agent，还是交给多个分工明确的Agent协同完成。

单Agent的逻辑很直接。写代码本来就是一个强一致性的活：同一个文件，不适合很多人同时改；上下文一散，风格、接口、约束就容易乱；如果还要多做一层协调，成本可能比收益更高。

所以过去很长一段时间里，很多团队更倾向于让一个足够强的agent持有完整上下文，统一理解需求、生成代码、执行修改，再完成自检。

但后来人们发现，单Agent再强，本质上也只是沿着一条提示路径、一种任务理解往下走，上限较为有限。

而多Agent其实不一定需要多个模型同时去改同一段代码，还可以把复杂任务拆开，让不同Agent从不同角色、不同层级看同一个问题，再通过汇总和筛选形成更完整的方案。比如“第一行代码”，就可以有不同的版本，有可能形成一个比单Agent更完整、更高质量的答案。

这套机制真正想解决的，正是怎么系统性治理代码质量下降和软件工程失控。

腾讯云的“AI自举实验”收官，标志着AI编程正式告别“野蛮生长”，进入“工程化深耕”的新阶段。行业早已达成共识：AI Coding的核心不是“快”，而是“稳”；胜负手不是“代码生成率”，而是“工程化能力”。

上下文的解耦、初始代码的规范、多Agent的协同，这些看似琐碎的工程细节，恰恰是AI从“辅助工具”跃升为“核心生产力”的关键。当AI能稳定理解意图、守住代码品味、保障交付质量，它所改变的，将不只是研发效率，更是整个软件行业的生产组织方式——而这场变革，才刚刚开始。

参考资料：

https://www.codebuddy.cn/blog/11

https://openai.com/zh-Hans-CN/index/harness-engineering/

Uno Platform 6.5 发布：支持 AI 智能体、Unicode 文本，Studio 工具进行了全面升级

作者：Almir Vuk — Mon, 16 Mar 2026 03:00:00 GMT

Uno Platform" 已发布 6.5 版本（二月更新），为其 Studio 工具及核心跨平台框架带来了一系列改进。团队表示，该版本修复了超过 450 个来自社区与客户反馈的问题。

本次发布的亮点之一是新增了对 Google Antigravity 的支持。Antigravity 是一款基于 VS Code 构建的“智能体优先”开发环境。通过与 Uno Platform App MCP 服务器集成，在 Antigravity 中运行的 AI 智能体现在可以与正在运行的 Uno 应用程序进行实时交互"。

正如公告博客中所述，智能体可以检查视觉树、截取屏幕截图、模拟用户输入，并验证真实的界面行为，而非仅依赖静态代码分析。这些检查的结果会被保存为可审查的工件，为开发者提供智能体操作与发现的详细记录。

在 Studio 方面，Uno 的实时视觉设计工具 Hot Design 迎来了多项易用性改进。现在首次运行新项目时，该工具会自动启动，省去了额外的配置步骤。全新的引导式入门体验会引导用户了解三种可用模式：智能体模式（Agent）、设计模式（Design）和交互模式（Interactive）。

此前悬浮在应用窗口上方的工具栏"已替换为固定在屏幕顶部的工具栏，团队表示这一改动是源自社区的反馈。

还新增了作用域选择器"，允许开发者直接导航到当前屏幕上可见的任意 UserControl 或模板，旨在简化深层嵌套界面结构的编辑。

在平台层面，6.5 版本为 TextBox 控件新增了 Unicode 支持"。非拉丁文字（包括阿拉伯语、中文、印地语）现在能够正确渲染光标定位、文本选择与键盘导航。团队表示，此版本暂不支持中文、日文、韩文等语言的输入法编辑器（IME）。

WebAssembly 上的 WebView2" 也得到了改进，本地打包的 Web 资源加载更加可靠。基于 Skia 渲染器的 WebAssembly 拖放功能已得到扩展，支持从外部应用拖放文件。

该版本还对所有支持的目标平台（包括 WebAssembly、iOS、Android、macOS、Windows 和 Linux）进行了更全面的稳定性优化，修复范围涵盖 TextBox、ListView、ProgressRing、PasswordBox 和 MenuFlyout 等控件。

本次发布的其他更新包括：Skia 渲染优化、更完善的错误诊断、应用启动与导航稳定性修复，以及跨平台 WebView 的稳定性进一步提升。

感兴趣的开发者可以在 Uno Platform 官方博文"中查看完整详细的发布说明。

【声明：本文由InfoQ翻译，未经许可禁止转载。】

查看英文原文：https://www.infoq.com/news/2026/03/uno-platform-6-5-release/"

Datadog如何将其Agent的Go二进制文件缩减77%

Sergio De Simone — Mon, 16 Mar 2026 02:00:00 GMT

在5年时间里，Datadog Agent从428 MiB增长到了1.22 GiB。Datadog工程师们开始着手缩减其二进制文件的大小。他们发现"，对于大多数Go二进制文件，膨胀的主要原因是隐藏的依赖项、禁用的链接器优化以及Go编译器和链接器中的微妙行为。

不管是对于我们自己，还是对于我们的用户，这种增长都产生了不利的影响：网络成本和资源使用增加，Agent感知变差，并且在资源受限的平台上使用Agent变得更加困难。

Datadog软件工程师Pierre Gimalac写道，为了解决这个问题，他们采取了一些措施，以便尽可能地缩小二进制文件的大小，其中包括：审计导入项、隔离可选代码以及消除反射/插件陷阱。

实际上，在分析了Agent的增长情况后，Datadog工程师发现，这主要是由新功能、额外的集成和大型第三方依赖项（如Kubernetes SDK）引起的。特别是，Go的依赖模型包括传递性导入，使得即使是一个小的变化也可能引入数百个包。

Datadog工程师设计了两种实用的方法来移除不必要的依赖项：使用构建标签（//go:build feature_x）来排除可选代码，并将代码移到单独的包中，从而使非可选包尽可能保持小巧。这两种技术都需要系统地审计导入项，以便确定哪些文件或包可以从给定的构建中排除。例如，仅仅将一个函数移动到它自己的包中，就从一个不使用它的二进制文件中移除了约570个包和约36 MB的生成代码。

审计依赖项并不是一项简单的任务，但Go生态系统提供了三个有用的工具：go list，可以列出构建中使用的所有包；goda，可以可视化依赖图和导入链，帮助开发人员理解为什么需要某个特定的依赖项；go-size-analyzer，可以显示每个依赖项使二进制文件的空间占用增加了多少。

除了优化依赖项外，通过最小化反射机制的使用，Datadog工程师额外获得了20%的大小缩减。反射会悄悄地禁用一些链接器优化，包括死代码消除：

如果你使用非恒定方法名，那么链接器在构建时就无法知道哪些方法将在运行时被使用。因此，它需要保留每个可达类型的每个导出方法，以及它们所依赖的所有符号，这可能会大幅增加最终二进制文件的大小。

为了解决这个问题，他们尽可能地消除了动态反射，无论是在他们的代码库中还是在依赖项中。后一步骤需要向kubernetes/kubernetes、uber-go/dig、google/go-cmp等项目提交多个PR。

另一个禁用死代码消除的功能是Go插件（一种允许Go程序在运行时动态加载Go代码的机制）。实际上，仅仅导入plugin包就导致链接器将二进制文件视为动态链接的，“这会禁用方法死代码消除，甚至迫使链接器保留所有未导出的方法”。在部分构建中，这一变化额外带来了约20%的缩减。

最后，Gimalac强调，这些改进是在六个月的时间里实现的。最重要的是，没有移除任何功能。他的文章里提供了更多的细节，如果想了解整个事情的来龙去脉，请阅读原博文"。

声明：本文为InfoQ翻译，未经许可禁止转载。

原文链接：https://www.infoq.com/news/2026/03/datadog-go-binary-optimization/"

Grab 工程实践：将 LRU 升级为 TLRU，Android 图片缓存节省 50MB+

Sergio De Simone — Sun, 15 Mar 2026 14:40:31 GMT

为了改进 Android 应用中的图片缓存管理，Grab 的工程师将原有的最近最少使用"（Least Recently Used，LRU）缓存机制升级为时间感知最近最少使用（Time-Aware Least Recently Used，TLRU）缓存。这一改进使他们能够更高效地回收存储空间，同时不会降低用户体验，也不会增加服务器成本。

Grab 的 Android 应用使用 Glide" 作为主要的图片加载框架。该框架内置了一个 LRU 缓存，用于在本地存储图片，从而减少网络请求、提升加载速度并降低服务器开销。然而，数据分析显示，使用 100 MB 的 LRU 缓存存在明显问题：对于许多用户来说，缓存空间很快就被填满，导致性能下降；而在另一些情况下，如果缓存始终没有达到大小上限，图片可能会在缓存中保留数月之久，从而造成存储空间浪费。

为了绕过这些限制，Grab 工程师决定在 LRU 的基础上引入基于时间的过期机制。TLRU 通过三个参数进行控制：首先是 Time To Live（TTL），用于确定缓存条目在何时被视为过期；其次是最小缓存容量阈值，确保即使缓存条目已过期，只要缓存容量不足，关键图片仍然可以继续保留；最后是最大缓存容量，用于限制缓存的存储上限。

在实现方案上，Grab 工程师并没有从零开始编写 TLRU，而是选择 fork Glide 项目并扩展其 DiskLruCache" 实现，以利用其“成熟且经过大量实践验证的基础架构”。

这一实现方式在 Android 生态中被广泛采用，并且已经处理了许多复杂的边界情况，例如崩溃恢复、线程安全以及性能优化等。如果从零实现这些能力，需要投入大量额外的工程工作。

为了支持 TLRU，DiskLruCache 需要在三个方面进行扩展：一是增加对最近访问时间（last-access time）的追踪；二是实现基于时间的缓存淘汰逻辑；三是提供现有用户缓存的迁移机制。

其中，记录最近访问时间是为了能够按照“最近访问顺序”对缓存条目进行排序，并且这些时间信息必须在应用重启后仍然能够保留。时间驱动的淘汰逻辑会在每次缓存访问时运行，用于检查最近最少访问的条目是否已经过期，如果过期则将其移除。

对于已有缓存的迁移，主要挑战在于如何为原本的 LRU 缓存条目分配最近访问时间戳。由于文件系统 API 无法提供可靠的时间来源，Grab 工程师最终决定为所有缓存条目统一赋予迁移时间戳。

这种方式可以保留所有现有缓存内容，并建立一个一致的时间基线。不过，它也意味着必须等待一个完整的 TTL 周期之后，缓存淘汰机制的全部效果才会体现出来。同时，他们还确保了双向兼容性：原始的 LRU 实现可以通过忽略时间戳后缀来读取 TLRU 的日志文件，从而在需要时能够安全回滚。

另一个挑战是确定最佳配置参数，这需要通过受控实验来完成。

Grab 为此设定了明确的成功标准：在从 LRU 迁移到 TLRU 的过程中，缓存命中率下降不得超过 3 个百分点（pp）。例如，如果命中率从 59% 降至 56%，就意味着服务器请求量将增加约 7%。这一阈值在存储优化与性能影响之间取得了平衡。

通过这种方案，95% 的应用用户缓存大小减少了约 50 MB，而缓存规模最大的 5% 用户则获得了更为显著的节省。基于这些结果，Grab 工程师估算，在保持缓存命中率处于可接受范围、且不增加服务器成本的前提下，他们可以在用户设备上回收数 TB 级别的存储空间。

原始文章对 LRU 的行为机制以及 TLRU 的实现细节提供了大量更为深入的技术说明，远超本文所能覆盖的范围。如果希望了解完整实现细节，建议阅读原文。

原文链接：

https://www.infoq.com/news/2026/03/grab-tlru-image-cache/

10分钟装好一只“龙虾”，周鸿祎亲自动手！360推出国内首个“安全龙虾”，内置百款大模型

李冬梅 — Sun, 15 Mar 2026 04:47:57 GMT

面对近段时间开源智能体OpenClaw（网络俗称“龙虾”）引发的新一轮人工智能效率变革，360集团昨天在京举办发布会，正式推出“360安全龙虾”智能体应用客户端及“360安全龙虾Box”硬件终端，同时发布专门应对OpenClaw安全问题的“360龙虾卫士”。据了解，360安全龙虾是国内首个以“安全模式”为核心设计的OpenClaw智能体产品。

据360方面介绍，针对当前阻碍OpenClaw普及的“安装难、不好养、容易死、不安全”四大核心难题，360安全龙虾系列产品提供了一套“出厂满血、全能守护”的综合解决方案，旨在让普通受众切实享受到技术红利，实现“龙虾自由”。

为了让普通人零距离感受人工智能带来的效率革命，360在总部园区特设了免费装“龙虾”活动，吸引数百名群众热情参与。360集团创始人周鸿祎更亲自下场化身“AI工程师”，为现场用户安装部署“360安全龙虾”，以实际行动推动前沿AI技术向大众普及。

周鸿祎表示，当前很多普通用户虽然对“龙虾”充满兴趣，但在实际使用时却常常被复杂的安装过程劝退。据了解，部署一套完整的OpenClaw环境并不简单。用户通常需要安装虚拟机、配置Ubuntu系统，并搭建Python、Node等开发环境，同时还要接入大模型API和各种技能组件。即便是熟练工程师，也往往需要约6小时才能完成基本配置。

而360安全龙虾将这一复杂流程整合为一键安装，将原本需要数小时甚至数天的配置过程压缩到10分钟内完成，实现开箱即用。

360 创始人周鸿祎在最新产品发布会上谈到近期爆火的“龙虾”概念时表示，这一产品实际上让他看到了推动“智能体（Agent）普及”的重要契机。

周鸿祎称，过去一年中国 AI 产业虽然经历了大模型热潮，但真正落地并不容易。“去年 DeepSeek 很火，它给中国用户做了一次大模型的科普，让很多企业和普通人第一次知道什么是大模型。但真正推广的时候我们发现，大模型更像一个聊天机器人、聊天助手。”

在他看来，大模型最大的问题是“没有手和脚”。虽然能够推理、规划和对话，但很难直接完成实际任务。因此行业开始引入“智能体”的概念，希望让 AI 能够调用工具、执行任务。不过这一概念过于抽象，普通用户很难理解。

“龙虾其实本质就是智能体，只不过换了一个名字。”周鸿祎表示，这种更直观的表达让技术迅速“破圈”。他认为，如果说 DeepSeek 完成了大模型的科普，那么“龙虾”则完成了智能体的第二次科普，让企业家、政府机构和创业者开始真正理解 AI 如何参与实际工作。

在技术层面，周鸿祎将大模型比作 AI 的“大脑”，而智能体则为它“加上了手和脚”。通过一套新的软件架构，智能体可以操控电脑、浏览器和手机，调用各种工具，甚至自动下载或编写新工具，从而完成复杂任务。

周鸿祎还对“龙虾爆火”的原因进行了分析。他认为，这标志着AI智能体技术正在发生三个重要变化：

首先，智能体拥有了大众可以理解的形态，不再只是抽象的大模型接口；其次，智能体正在从简单的对话工具转变为可以独立执行任务的“数字员工”；第三，借助技能（Skill）体系，智能体的能力可以通过工具组合持续扩展。

周鸿祎认为，随着“龙虾”能力不断提升，人工智能应用正从“问答式对话”阶段迈向真正的执行任务阶段。在他看来，当越来越多“龙虾”开始参与工作，一种新的生产方式也正在形成。

对于外界关注的成本问题，周鸿祎也回应称，智能体在执行复杂任务时需要大量推理和尝试，因此会消耗更多算力和 Token。“如果未来 AI 真正开始替人干活，算力需求可能会增长 100 倍甚至 1000 倍。但随着需求扩大，算力成本反而会进一步下降。”

在他看来，中国在 AI 应用层面拥有巨大优势：产业链完整、应用场景丰富，再加上 DeepSeek 和智能体带来的两轮技术普及，中国有机会在 AI 应用落地上走在全球前列。

据介绍，360安全龙虾在系统架构上整合了多种模型能力与技能生态。系统目前已接入16家国内主流大模型，覆盖文本生成、编程开发、多模态创作等多种能力，并通过智能模型路由机制，在不同任务场景中自动选择最合适的模型。同时，系统内置100余个高频技能，可直接用于文档生成、数据分析、PPT制作、会议转写等常见办公场景。

在开放生态方面，系统还兼容全球开源软件生态，可调用超过2.1万个开源技能与工具。当现有技能无法满足需求时，360安全龙虾还可以通过系统内置的编程能力自动生成新的技能，实现持续扩展，此外还支持自动数据备份和配置恢复机制，即便在系统异常或崩溃情况下，也可以快速恢复运行。

随着OpenClaw开始进入办公、开发和内容创作等实际场景，安全问题也逐渐成为行业关注重点。对此，360推出了专门针对OpenClaw安全风险的防护系统——“360龙虾卫士”。“360龙虾卫士”作为360安全龙虾的原生安全组件，通过虚拟化沙箱（WSL）隔离运行环境，将智能体执行空间与用户数据进行分离，并借助AI安全引擎识别恶意技能、异常指令以及潜在漏洞，从而主动拦截技能投毒、提示词注入等攻击行为。

据介绍，“360龙虾卫士”采用“最小权限原则”和“人在回路”的核心防护策略，在不影响OpenClaw正常学习和执行能力的前提下，通过实时监控与AI安全模型识别潜在风险，构建“以模治模”的智能安全防护机制，从而在保障效率的同时为智能体运行建立安全边界。

此外，“360安全龙虾”还提供新手与高级用户的分级权限管理机制，并支持客户端一键彻底卸载，即使是360安全龙虾自身也能够完全删除，确保用户始终对系统拥有充分的控制权。

面向对数据安全和隐私要求更高的机构用户，360在发布会上还推出了“360安全龙虾Box”硬件设备。该产品通过物理级隔离的方式部署OpenClaw系统，可实现本地算力运行和数据不出内网，为政企机构提供更加安全可控的人工智能应用环境。

与此同时，360宣布将对“龙虾”应用实施普惠战略。“360安全龙虾”软件客户端、基础部署服务以及出厂技能组件均向公众免费开放，用户只需根据实际调用的大模型算力（Token）支付基础费用，入门套餐定价为169元。

业内人士认为，这一举措有望进一步降低人工智能应用门槛，推动智能体技术在办公协作、内容生产和数据分析等场景中的普及应用，加速数字生产力在各行业落地，为实体经济发展注入新的动力。

目前，“360安全龙虾”Windows客户端已向公众开放下载，用户可通过官方网站获取安装程序，MacOS版本即将推出。

官方下载地址：https://claw.360.cn。

360龙虾卫士安全中心：htts://safe.claw60.cn。

Cloudflare发布AI辅助开发的实验性Next.js替代方案

Steef-Jan Wiggers — Sun, 15 Mar 2026 03:00:00 GMT

最近，Cloudflare发布了vinext"，这是Next.js的一个实验性重新实现，基于Vite"而非Turbopack"。该项目由一名工程师在大约一周内使用AI开发完成，API token的成本为1100美元。此外，该公司将其定位为一个即插即用的Next.js替代品，并且针对Cloudflare Workers做了优化。不过目前，该项目被标记为实验性和未经大规模测试。

从早期的基准测试看，该项目前景光明，不过也有一些需要注意的地方。在一个包含33个路由的测试应用中，使用Vite 8打包器Rolldown的生产构建耗时不到1.67秒，而使用Turbopack的Next.js 16则需要7.38秒。速度提升了4.4倍。客户端软件包的大小也从168.9KB减少到了72.9KB，小了57%。但Cloudflare提醒说，这些数字是“方向性的，不是确定性的”，因为它们基于单一测试环境，而不是现实世界中的生产应用。

图片来源：Cloudflare博文"

领导开发这个项目的Cloudflare工程师Steve Faulkner在博文"中描述了其工作流程：最初几个小时在OpenCode中使用Claude定义架构，然后迭代执行任务，由AI编写实现和测试。当测试通过时，合并代码。当测试失败时，AI接收错误输出并迭代代码。800多次AI会话便生成了大部分的代码，但每一行都通过了质量检查：1700多个Vitest测试，从Next.js测试套件移植过来的380个Playwright E2E测试，TypeScript检查和代码分析。

vinext实现了Next.js的API接口、路由、服务器渲染、React服务器组件、服务器操作、缓存、中间件（作为Vite的插件，而不是封装Next.js的输出）。这使得它可以在任何支持Vite Environment API"的平台上运行，尽管Cloudflare Workers是其主要的部署目标。该公司声称，代码库中大约95%的代码是平台无关的Vite代码。

部署到Workers只需要一个命令：vinext deploy。App Router和Pages Router都完全支持客户端水合。缓存方面，vinext包括一个用于ISR（增量静态再生）的KV缓存处理器。在线示例包括一个App Router游乐场"、一个Hacker News克隆"和CIO.gov"（这是美国政府的一个beta站点，由National Design Studio运营）。

一个重要的限制是：vinext尚未支持构建时静态预渲染。Next.js在next build期间使用generateStaticParams()预渲染页面。vinext只支持ISR，缓存并在第一次请求后重新验证页面。不过，静态预渲染已在路线图上"。

Cloudflare提出了一个名为Traffic-aware Pre-Rendering（TPR）的替代方案，目前还是实验性的。TPR在部署时查询Cloudflare的区域分析，并且仅预渲染接收实际流量的页面。对于一个有10万个产品页面的网站，其中90%的流量是访问其中的50-200个页面，这些页面将被预渲染，其余的则回退到按需SSR。这只适用于已接入Cloudflare网络且具备现有分析数据的网站。

社区的反馈已经超出了实现质量的范畴。在Reddit的r/vibecoding论坛"上，开发者们质疑其可维护性影响，有参与者评论道：“最后一句话很随意地承认了该代码难以由人类进行维护这一事实。”此言是针对Cloudflare宣称AI无需中间抽象层，因其“能将整个系统置于上下文之中”的说法。另有人指出：

一周开发完成意味着没有人真正地浏览过代码。

Hacker News上的反馈"也反映出了类似的怀疑。一位评论者指出了文档悖论：

你越完善地记录工作成果，越清晰地定义契约，他人就越容易复制你的工作。若没有Next自主研发的测试工具，Cloudflare根本不可能实现这一目标。

还有一位评论者指出，Vite承担了最繁重的工作：

vinext大约95%的代码是纯Vite。真正的成果是人为构建的Vite。

需要注意的是，该项目目前还是一个实验性的项目。正如Cloudflare的博文所描述的那样：

vinext是实验性的。它甚至还不到一周大，还没有经过任何有意义的大规模流量的实战测试。如果你正在评估将其用于生产应用程序，请务必谨慎行事。

README"列出了明确不支持的特性和已知的限制。Cloudflare正在与其他托管服务商合作推广该工具链；他们不到30分钟就为Vercel完成了概念验证部署，但该项目的长期可行性仍然存疑。

对于有兴趣参与测试的开发者，vinext提供了一个用于迁移的Agent Skill，可与Claude Code、OpenCode、Cursor及类似的工具搭配使用：npx skills add cloudflare/vinext。或者，也可以使用npx vinext init手动处理迁移。

声明：本文为InfoQ翻译，未经许可禁止转载。

原文链接：https://www.infoq.com/news/2026/03/cloudflare-vinext-experimental/"

GitLab：AI 能发现漏洞，但风险治理才是关键

作者：Craig Risi — Sun, 15 Mar 2026 02:00:00 GMT

根据GitLab最新发布的一篇博文"，AI正快速改变软件漏洞的检测方式，但“谁来负责治理AI所暴露的风险”以及“如何应对这些风险”等问题已变得日益紧迫。GitLab认为，尽管静态扫描器、生成式模型等AI工具在识别潜在安全问题并给出修复建议方面效率远高于传统工具，但仅靠检测无法解决风险管理的全部问题。这也促使开发者与安全团队重新思考在现代开发生命周期中应如何构建治理、问责与执行机制。

文章强调，随着AI驱动工具可发现漏洞并提出整改方案等相关成果公布，行业思路正在发生转变。尽管这些创新体现了AI在加速检测方面的价值，但GitLab的文章指出，发现漏洞本身并不等同于降低风险。企业安全负责人愈发关注漏洞是否真正依据业务风险完成分类、定级与修复，相关决策是否有明确的责任主体。如果团队缺少策略约束、场景化风险评分与治理机制来明确哪些问题必须在发布前修复、哪些可以接受或延后处理，那么单纯发现更多漏洞只会产生无效信息，形成干扰噪音。

为解决这一问题，GitLab主张将AI驱动的检测嵌入到更广泛的、基于策略的DevSecOps框架中，推荐的最佳实践包括：在组织层面定义风险容忍阈值；设置与漏洞严重性、可利用性及合规要求相关的合并与部署门禁；在风险接受时保留可审计的审批流程；随着代码、依赖项与威胁情报的变化持续重新评估风险。文章强调，在从代码、流水线到生产环境的整个软件生命周期中保持统一可视性至关重要，从而将AI发现的问题与资产重要性、运行时暴露情况相结合。在此模式下，AI成为安全开发的效能倍增器，而通过平台级管控、可审计性与可量化策略执行实现的治理仍是将检测结果转化为可问责、基于风险的决策的核心机制。

开发者与安全工程师不应将AI当作风险治理的替代品，而应将其视为加速器，并与严格的监督流程和清晰的问责机制相结合。行业趋势显示，这种平衡理念正得到越来越多的认同：近期围绕容器安全与威胁事件的讨论凸显了大规模场景下软件风险的复杂性——AI驱动的扫描与自动化手段正与日趋复杂的供应链攻击、运行时漏洞并存。

整个行业内，众多组织已就AI风险治理原则形成共识，强调检测能力必须与结构化的监督和问责机制相结合。美国国家标准与技术研究院"（NIST）凭借被广泛采用的AI风险管理框架"（AI RMF），提出以治理、风险映射、度量与持续管理为核心的全生命周期管理思路。关键实践包括：明确问责角色、留存审计轨迹、针对公平性与安全标准验证模型，以及将AI风险纳入更全面的企业风险管理体系，而非将其视作孤立的技术问题。这些建议与GitLab的观点高度契合：只有将AI检测结果融入可落地的治理流程与部署管控中，其价值才能真正体现。

科技公司与行业框架也呼应了这种“治理优先”的思路。例如，微软"已建立规范的负责任AI治理体系，包括内部审查委员会、高风险系统的定义与审批流程，以及对模型偏见或不安全输出的持续监控。同时，IBM强调"透明度、可解释性与问责制是构建信任的基础。此外，ISO/IEC 42001"等国际标准及欧盟AI法案相关的新兴监管规范都倡导持续审计、AI使用过程可视化，以及与生产环境中的模型同步迭代的策略化管控。从这些实践中可以形成明确共识：有效的AI治理并非更依赖检测工具的复杂度，而是依托监控、人工审核、可量化的风险阈值，以及贯穿AI全生命周期的持续合规校验等运营实践。

【声明：本文由InfoQ翻译，未经许可禁止转载。】

查看英文原文：https://www.infoq.com/news/2026/03/gitlab-ai-governance/"

Cloudflare 宣布支持 ASPA：为 BGP 路由路径验证引入新安全机制

作者：Renato Losio — Sat, 14 Mar 2026 15:19:37 GMT

Cloudflare 近日宣布支持" ASPA（Autonomous System Provider Authorization）。这一新的加密标准通过验证数据在网络之间传输的路径，使互联网路由更加安全，从而防止流量经过不可靠或不受信任的网络。

ASPA" 是一种基于 RPKI 的安全机制。它通过验证 AS_PATH（即路由通告经过的网络路径），来提升互联网路由协议 BGP 的安全性，从而减少路由泄露（route leaks）以及某些类型的路由劫持。这一新兴标准的目标，是提升互联网的整体可靠性，并减少由于意外或恶意行为导致的流量绕行。Cloudflare 首席系统工程师 Mingwei Zhang" 和首席网络工程师 Bryton Herdes" 解释道：

当数据在互联网上传输时，它会记录自己经过的每一个网络节点。ASPA 为网络运营者提供了一种机制，可以在 RPKI 系统中正式发布其授权的上游提供商列表。这样一来，接收网络就可以查看 AS_PATH，检查相关的 ASPA 记录，并验证数据流是否只经过被授权的网络链路。

边界网关协议（BGP）是互联网流量路由的核心协议，但它本身缺乏原生的路径验证机制，因此容易受到路由泄露和路由劫持的影响。虽然 RPKI 和 Route Origin Authorization（ROA）" 可以加强路由来源的验证，但它们并不会验证端到端路径。ASPA 通过一种加密方式，使网络运营者能够声明其被授权的提供商，从而让接收网络可以验证某个 AS 路径是否符合预期的结构。

ASPA 通过验证互联网路由的预期层级结构来检测路由绕行。在正常的 “valley-free”（无谷）拓扑中，流量会从客户网络向上游提供商传递，可能在顶层经过一次对等（peer）连接，然后再通过提供商向下传递到目标客户网络。这种客户 → 提供商的上行路径、可选的对等连接，以及提供商 → 客户的下行路径，共同构成了符合策略的标准路径。

去年，美国国家标准与技术研究院（NIST）发布了开源测试工具"和数据集，以促进对新兴 BGP 安全和韧性机制的测试与实验，其中包括评估路由器实现 ASPA 规范的能力。

Cloudflare 还在 Cloudflare Radar" 中添加了相关工具，用于跟踪 ASPA 的采用情况，使网络运营者能够查看哪些网络正在使用该技术，以及路径验证的情况。Zhang 和 Herdes 提醒：

随着 ASPA 终于成为现实，我们在互联网路径验证方面迎来了加密层面的升级。不过，对于那些从 RPKI 路由来源验证一开始就参与其中的人来说，他们知道，要让这一技术在互联网上真正产生显著价值仍然需要很长时间。要真正利用 ASPA 对象并进行路径验证，还需要对多个组件进行改造，包括 RPKI 依赖方（RP）软件包、签名实现、RTR（RPKI-to-Router）软件以及 BGP 实现。

Cloudflare 表示，在最近的委内瑞拉 BGP 路由泄露事件" 中，如果部署了 ASPA，网络就可以通过验证观察到的 AS 路径是否符合预期的提供商授权关系，从而检测并拒绝异常的路径通告，而仅依赖来源验证是无法做到这一点的。

Cloudflare 并不是唯一致力于推动这一加密标准的提供商。在去年发布的文章 “AWS secures internet routing with RPKI plus security checks"” 中，亚马逊云科技团队写道：

虽然 ASPA 仍处于标准化过程中，但我们致力于使用它以及所有可用工具，让互联网继续成为一个安全可靠的环境。

尽管相关 IETF 标准仍处于草案阶段，Cloudflare 指出 ARIN 和 RIPE NCC 已经支持创建 ASPA 对象，而路由软件 OpenBGPD 和 BIRD 也已经包含 ASPA 验证功能。

原文链接：

https://www.infoq.com/news/2026/03/cloudflare-aspa-standard/

规范化后量子IPsec: Cloudflare采用混合ML-KEM以取代密码套件膨胀

Steef-Jan Wiggers — Sat, 14 Mar 2026 03:00:00 GMT

Cloudflare最近实施了一种新的标准化方法来处理后量子IPsec，摒弃了之前的“密码套件膨胀”，转而采用混合ML-KEM交换。这一举措标志着广域网（WAN）在不要求专用硬件的情况下，将如何满足NIST 2030年抗量子加密的最后期限。

该公司将混合模块化格基密钥封装机制"（ML-KEM）引入Cloudflare IPsec和Cloudflare One设备，完成了Cloudflare所称的“后量子SASE方程”，使组织能够最终锁定私有网络流量的端到端安全，抵御“现在收集，以后解密”的攻击，即恶意行为者今天抓取加密数据并保存起来，直到量子计算机足够强大再破解它。

Cloudflare的首席执行官兼联合创始人Matthew Prince直言不讳地表示"：

保护互联网免受未来威胁不应该是一个复杂的负担。自2017年以来，我们一直在努力将后量子标准直接融入我们的网络结构。通过将这种保护扩展到我们的整个SASE平台，我们正在使后量子安全成为默认设置——不需要硬件升级，不需要复杂的配置，也不需要增加成本。

早些时候，NIST设定了一个严格的2030年最后期限"，要求放弃RSA和椭圆曲线加密，转而采用抗量子算法。2024年底，明确信号表明经典公钥加密的日子已经屈指可数。德国的BSI"和英国的NCSC"一直在说同样的话。

Cloudflare的方法遵循了draft-ietf-ipsecme-ikev2-mlkem"草案，该草案以与TLS相同的方式标准化了IPsec的后量子密钥交换。混合设置与经典Diffie-Hellman并行运行ML-KEM。可以将其视为一种双重安全：ML-KEM处理量子威胁，Diffie-Hellman覆盖经典攻击。

IPsec走向后量子的道路与TLS的旅程截然不同。早期尝试RFC 8784"依赖于预共享密钥或量子密钥分发，这两种方法在实践中都不太有效。预共享密钥不提供针对量子对手的前向保密。QKD需要专用硬件，这对于大多数部署来说是不可行的。然后RFC 9370"出现了，允许同时运行多达七种不同的算法。Cloudflare称这为“密码套件膨胀”。Palo Alto Networks全力以赴，采用了七种以上的PQC"密码套件，其中大多数与其他供应商不兼容。

draft-ietf-ipsecme-ikev2-mlkem规范最终使IPsec与TLS的运作方式保持一致。Cloudflare在其IPsec IKEv2响应器中构建了混合ML-KEM的生产支持，并针对strongSwan参考实现进行了测试，以确保其正常工作。

Cloudflare One Appliance在2月11日自动升级至2026.2.0版本。由于该设备使用TLS而不是IKEv2，更新相当直接——只需从TLS 1.2升级到TLS 1.3，并内置混合ML-KEM。

Cloudflare IPsec仍在封闭测试中，同时公司正在与第三方分支连接器供应商合作以实现互操作性。Security Brief Australia"指出，Cloudflare的全球网络中加入了高可用性路由，如果数据中心宕机，可以自动重新路由流量。

现在，完整的画面包括了TLS、MASQUE和IPsec的后量子加密入站和出站。根据Cloudflare Radar"的数据，超过60%的人为生成的TLS流量已经使用混合ML-KEM。

所有这些都不额外收费。CISA在其2026"年1月的出版物中承认了密钥协议和数字签名迁移之间的分歧。Cloudflare目前的推动重点是通过混合ML-KEM建立密钥。数字签名的紧迫性较小，因为它们旨在阻止拥有量子计算机的活跃对手，而这样的对手目前还不存在。

原文链接：

https://www.infoq.com/news/2026/03/cloudflare-post-quantum-ipsec/"

亚马逊云科技在其EC2实例中推出了对嵌套虚拟化的支持

Renato Losio — Sat, 14 Mar 2026 02:00:00 GMT

AWS最近宣布支持在运行KVM或Hyper-V的虚拟化EC2实例中嵌套虚拟机"。这是社区期待已久的功能，新选项使得可以在支持的C8i、M8i和R8i实例上进行应用仿真和硬件仿真等用例。

开发者可以使用这个功能来运行移动应用模拟器、模拟汽车硬件，并在Windows工作站上使用Windows Subsystem for Linux（WSL）。根据文档"，Nitro系统将处理器特性（如Intel VT-x）暴露给实例，允许它在内部运行虚拟机。

嵌套虚拟化的架构有三层：物理AWS基础设施和Nitro虚拟机监视器（L0）、运行自己虚拟机监视器的EC2实例（L1）以及在该实例内部运行的虚拟机（L2）。新功能支持在C8i、M8i和R8i实例上使用KVM和Hyper-V。AWS的工程总监Ioannis Aslanidis写道"：

这种能力使开发者和企业能够构建灵活的、嵌套的环境，使用广泛的标准虚拟EC2实例类型。

该功能一直是社区的长期需求，2018"年有开发者在Reddit上写道：

在Azure中，我可以在我的虚拟机中运行KVM，这是一种称为嵌套虚拟化的技术。亚马逊在允许在EC2中使用HyperV/VMware/KVM方面有任何进展吗？

大多数关于新功能的评论都表达了同样的观点：Meta的生产工程师Rolf Neugebauer写道，“你们怎么花了这么长时间？”而Igor Sfiligoi补充道：“直到现在，这真的是不可能的？”在一个热门的Hacker News"帖子中，谷歌的软件工程师Michael Boulos写道：

我感觉得到了证实：几年前，我们为让嵌套虚拟化在GCE上运行良好投入了大量的精力，我很高兴听到AWS也在跟进。你可以告诉人们去做别的事情，可能有一个单独的自然解决方案，等等，但有时你愿意牺牲一些峰值性能，只是为了拥有操作和控制的一致性。

Render的创始人兼首席执行官Anurag Goel"补充道：

这是一个大事件，因为现在你可以在AWS VM中运行Firecracker/其他微虚拟机，而不是昂贵的AWS裸机实例。

AWS的高级解决方案架构师Guillermo Ruiz测试了在实例内运行Firecracker"微虚拟机，并对未来的基准测试做出了承诺。Ruiz写道：

对于任何寻求隔离、Lambda风格的运行时，或者只是从性能和密度的角度比较微虚拟机与容器的人来说，这是一个有趣的角度。

过去，运行EC2上的嵌套虚拟化的唯一选择是使用裸机实例，即没有虚拟机监视器的物理服务器。许多开发者转而使用EC2 Mac实例，这是最小且最便宜的裸机选项，作为一种变通方法。现在启用嵌套虚拟化是一个在启动时设置的API选项，例如：

aws ec2 run-instances \ --image-id ami-0abcdef1234567890 \ --instance-type r8i.4xlarge \ --cpu-options "NestedVirtualization=enabled" \ --key-name my-key-pair \ --placement "Tenancy=host"

AWS仍然建议，运行需要硬件虚拟化的工作负载、对性能敏感或需要低延迟的客户应该继续使用裸机实例，而不是嵌套虚拟化。

嵌套虚拟化在所有区域的C8i、M8i和R8i实例类型上都可用；Graviton实例目前尚不支持。KVM和Hyper-V是唯一受支持的L1虚拟机监视器。

原文链接：

https://www.infoq.com/news/2026/03/aws-ec2-nested-virtualization/"

又一中国玩家入场“龙虾”生态：阶跃星辰推出 StepClaw，开放 5 万个免费部署名额

李冬梅 — Fri, 13 Mar 2026 10:21:01 GMT

3月12日，阶跃星辰推出基于OpenClaw打造的云端AI助手StepClaw，并开放5万个可一键部署并使用“小龙虾”的体验名额，限时免费1个月。

值得关注的是，体验名额不仅支持通过阶跃AI APP一键部署“小龙虾”，更提供了包含5000万模型Tokens、服务器、存储在内的全家桶免费权益，在大幅降低普通用户安装门槛的同时，能够让人们真正把AI工具使用起来。据悉，今天该功能还将在阶跃AI网页端上线，支持部署和使用。

地址：https://www.stepfun.com/chats/new

StepClaw的核心亮点之一在于其搭载的Step 3.5 Flash模型——这款由阶跃星辰开源的基座模型，官方定位是“为Agent而生”，自3月初全面开源后，迅速登顶OpenClaw模型调用量月榜，并连续多日位列全球第一，是开源社区“最受开发者欢迎的龙虾大脑”。

据OpenRouter公布的数据显示，过去30天内Step 3.5 Flash的Tokens调用总量已超越了包括Gemini 3 Flash Preview、Claude Sonnet 4.6在内的国际一线模型，且中国模型在前五名中占据过半席位，也显示出中国开源力量正在全球Agent生态中强势崛起。

根据阶跃星辰官方介绍，StepClaw云端部署配置了双核CPU、4GB内存与40GB存储，支持复杂任务执行、长期记忆且7×24小时在线运行，即使用户设备关机也能保持云端运行。另外，产品内置了阶跃自研搜索工具及丰富的技能库，极大地拓展了用户的使用场景。

目前，迅速走红的OpenClaw生态已从开发者圈层蔓延到普通人的生活场景中，随着腾讯、阶跃星辰等公司纷纷加入“龙虾战局”，推出相应的部署方案，AI Agent加速从前沿技术转变为真正能为服务于普通用户、在实际生活场景中创造价值的AI工具。

如何用 Streamlit 和 Snowflake Cortex 搭建语音助手应用｜技术实践

Chanin Nantasenamat — Fri, 13 Mar 2026 10:15:47 GMT

2026 年，智能体将在企业级应用中取得哪些实质性突破？点击下载"《2026 年 AI 与数据发展预测》白皮书，获悉专家一手前瞻，抢先拥抱新的工作方式！

在本快速入门指南中，您将利用 Snowflake Cortex 的 AI_TRANSCRIBE 函数，构建一个支持语音交互的 AI 助手。用户可通过录制音频消息，经由系统自动转录并由大语言模型处理，实现智能化、自然的对话体验。

学习目标

使用 Snowflake Cortex 的 AI_TRANSCRIBE 函数实现语音转文本功能；创建具备适当加密机制的存储阶段，以安全处理音频数据；将 Streamlit 的音频输入功能与 Snowflake 进行集成；构建一个支持语音交互的对话式智能助手。

构建内容

您将完成一个具备语音交互能力的聊天机器人应用。用户可录制音频消息，系统将自动完成语音转文本处理，并通过大语言模型生成智能回复，最终实现流畅的语音对话式交互体验。

准备要求

具备可用的 Snowflake 账户访问权限"；掌握 Python 及 Streamlit 的基础知识；拥有使用 Cortex AI_TRANSCRIBE 函数的相应权限。

开始使用

请从 30daysofai GitHub 代码仓库克隆或下载代码：

git clone https://github.com/streamlit/30DaysOfAI.git cd 30DaysOfAI/app

本快速启动对应的应用程序代码：

• 第25天：语音助手"

音频配置阶段

音频转录功能需要配置具有服务端加密的存储阶段。AI_TRANSCRIBE 函数只能访问存储在采用Snowflake 托管加密（SNOWFLAKE_SSE）的存储阶段中的文件，这种加密方式可确保音频数据在 Snowflake 处理环境中的安全处理。

创建存储阶段

CREATE DATABASE IF NOT EXISTS RAG_DB; CREATE SCHEMA IF NOT EXISTS RAG_DB.RAG_SCHEMA; DROP STAGE IF EXISTS RAG_DB.RAG_SCHEMA.VOICE_AUDIO; CREATE STAGE RAG_DB.RAG_SCHEMA.VOICE_AUDIO DIRECTORY = ( ENABLE = true ) ENCRYPTION = ( TYPE = 'SNOWFLAKE_SSE' );

创建采用 SNOWFLAKE_SSE 加密的存储阶段，这是 AI_TRANSCRIBE 访问音频文件的必要条件。

重要提示：存储阶段必须使用SNOWFLAKE_SSE 加密，AI_TRANSCRIBE 才能访问音频文件。

构建语音界面

连接与状态设置

首先，导入所需库并建立与 Snowflake 的连接。通过 try/except 结构，使应用程序能够在Snowflake 环境中的 Streamlit 和本地环境中正常运行：

会话状态用于跟踪对话消息、数据库配置以及最近处理音频的哈希值。该哈希值可防止在Streamlit 重新运行时对同一录音进行重复处理。

侧边栏设置

侧边栏包含应用标题、配置选项以及阶段管理控件：

database = st.session_state.voice_database schema = st.session_state.voice_schema full_stage_name = f"{database}.{schema}.VOICE_AUDIO" stage_name = f"@{full_stage_name}" with st.sidebar: st.title(":material/record_voice_over: Voice-Enabled Assistant") st.write("Talk to your AI assistant using voice input!") st.header(":material/settings: Settings") with st.expander("Stage Status", expanded=False): try: stage_info = session.sql(f"SHOW STAGES LIKE 'VOICE_AUDIO' IN SCHEMA {database}.{schema}").collect() if stage_info: session.sql(f"DROP STAGE IF EXISTS {full_stage_name}").collect() session.sql(f""" CREATE STAGE {full_stage_name} DIRECTORY = ( ENABLE = true ) ENCRYPTION = ( TYPE = 'SNOWFLAKE_SSE' ) """).collect() st.success(":material/check_box: Audio stage ready (server-side encrypted)") except Exception as e: st.error(f":material/cancel: Could not create stage") if st.button(":material/delete: Clear Chat"): st.session_state.voice_messages = [ {"role": "assistant", "content": "Hello! :material/waving_hand: I'm your voice-enabled AI assistant. Click the microphone button to record a message, and I'll respond to you!"} ] st.rerun()

侧边栏提供设置界面及相关控件。阶段状态展开面板用于确保音频阶段已正确创建并加密。阶段重建功能可处理阶段配置错误等边界情况。

使用 AI_TRANSCRIBE 转录音频

处理录制的音频

主区域显示对话内容和音频输入组件。录制音频后，系统会将其上传至舞台并进行转录：

st.subheader(":material/voice_chat: Conversation") audio = st.audio_input(":material/mic: Click to record") for msg in st.session_state.voice_messages: with st.chat_message(msg["role"]): st.markdown(msg["content"]) status_container = st.container() if audio is not None: audio_bytes = audio.read() audio_hash = hashlib.md5(audio_bytes).hexdigest() if audio_hash != st.session_state.processed_audio_id: st.session_state.processed_audio_id = audio_hash with status_container: transcript = None with st.spinner(":material/mic: Transcribing audio..."): try: timestamp = int(time.time()) filename = f"audio_{timestamp}.wav" audio_stream = io.BytesIO(audio_bytes) full_stage_path = f"{stage_name}/{filename}" session.file.put_stream( audio_stream, full_stage_path, overwrite=True, auto_compress=False ) safe_file_name = filename.replace("'", "''") sql_query = f""" SELECT SNOWFLAKE.CORTEX.AI_TRANSCRIBE( TO_FILE('{stage_name}', '{safe_file_name}') ) as transcript """ result_rows = session.sql(sql_query).collect() if result_rows: json_string = result_rows[0]['TRANSCRIPT'] transcript_data = json.loads(json_string) transcript = transcript_data.get("text", "") if transcript: st.session_state.voice_messages.append({ "role": "user", "content": transcript }) except Exception as e: st.error(f"Error during transcription: {str(e)}")

st.audio_input() 在主区域提供麦克风按钮供录制使用。音频字节通过 MD5 哈希算法生成唯一标识符。put_stream() 将音频上传至舞台。AI_TRANSCRIBE 结合 TO_FILE() 将语音转换为文本。系统解析 JSON 格式的转录文本，并将其添加到对话记录中。

生成语音响应

构建对话上下文

经过转写后，对话历史将被格式化为大语言模型的上下文，以生成相关响应：

if transcript: with st.spinner(":material/smart_toy: Generating response..."): conversation_context = "You are a friendly voice assistant. Keep responses short and conversational.\n\nConversation history:\n" history_messages = [msg for msg in st.session_state.voice_messages[:-1] if not (msg["role"] == "assistant" and "Click the microphone" in msg["content"])] for msg in history_messages: role = "User" if msg["role"] == "user" else "Assistant" conversation_context += f"{role}: {msg['content']}\n" conversation_context += f"\nUser: {transcript}\n\nAssistant:" response = call_llm(conversation_context) st.session_state.voice_messages.append({ "role": "assistant", "content": response }) try: session.sql(f"REMOVE {stage_name}/{safe_file_name}").collect() except: pass st.rerun() else: st.session_state.processed_audio_id = None

对话历史以对话形式呈现，为上下文提供语境支撑。大语言模型（LLM）负责生成符合对话场景的回复内容。REMOVE命令用于清理临时音频文件。st.rerun()方法可刷新界面，确保新消息能够及时显示。最后，在 else 分支中，当检测不到音频输入时，系统会将processed_audio_id重置为None，从而确保后续录音文件能够被正常处理。

完整应用

将这些代码整合在一起，我们就得到了一个完整的语音助手应用：

import streamlit as st import json from snowflake.snowpark.functions import ai_complete import io import time import hashlib try: from snowflake.snowpark.context import get_active_session session = get_active_session() except: from snowflake.snowpark import Session session = Session.builder.configs(st.secrets["connections"]["snowflake"]).create() def call_llm(prompt_text: str) -> str: """Call Snowflake Cortex LLM.""" df = session.range(1).select( ai_complete(model="claude-3-5-sonnet", prompt=prompt_text).alias("response") ) response_raw = df.collect()[0][0] response_json = json.loads(response_raw) if isinstance(response_json, dict): return response_json.get("choices", [{}])[0].get("messages", "") return str(response_json) if "voice_messages" not in st.session_state: st.session_state.voice_messages = [] if len(st.session_state.voice_messages) == 0: st.session_state.voice_messages = [ { "role": "assistant", "content": "Hello! :material/waving_hand: I'm your voice-enabled AI assistant. Click the microphone button to record a message, and I'll respond to you!" } ] if "voice_database" not in st.session_state: st.session_state.voice_database = "RAG_DB" st.session_state.voice_schema = "RAG_SCHEMA" if "processed_audio_id" not in st.session_state: st.session_state.processed_audio_id = None database = st.session_state.voice_database schema = st.session_state.voice_schema full_stage_name = f"{database}.{schema}.VOICE_AUDIO" stage_name = f"@{full_stage_name}" with st.sidebar: st.title(":material/record_voice_over: Voice-Enabled Assistant") st.write("Talk to your AI assistant using voice input!") st.header(":material/settings: Settings") with st.expander("Database Configuration", expanded=False): database = st.text_input("Database", value=st.session_state.voice_database, key="db_input") schema = st.text_input("Schema", value=st.session_state.voice_schema, key="schema_input") st.session_state.voice_database = database st.session_state.voice_schema = schema st.caption(f"Stage: `{database}.{schema}.VOICE_AUDIO`") st.caption(":material/edit_note: Stage uses server-side encryption (required for AI_TRANSCRIBE)") if st.button(":material/autorenew: Recreate Stage", help="Drop and recreate the stage with correct encryption"): try: full_stage = f"{database}.{schema}.VOICE_AUDIO" session.sql(f"DROP STAGE IF EXISTS {full_stage}").collect() session.sql(f""" CREATE STAGE {full_stage} DIRECTORY = ( ENABLE = true ) ENCRYPTION = ( TYPE = 'SNOWFLAKE_SSE' ) """).collect() st.success(f":material/check_circle: Stage recreated successfully!") st.rerun() except Exception as e: st.error(f"Failed to recreate stage: {str(e)}") with st.expander("Stage Status", expanded=False): database = st.session_state.voice_database schema = st.session_state.voice_schema full_stage_name = f"{database}.{schema}.VOICE_AUDIO" try: stage_info = session.sql(f"SHOW STAGES LIKE 'VOICE_AUDIO' IN SCHEMA {database}.{schema}").collect() if stage_info: st.info(f":material/autorenew: Recreating stage with server-side encryption...") session.sql(f"DROP STAGE IF EXISTS {full_stage_name}").collect() session.sql(f""" CREATE STAGE {full_stage_name} DIRECTORY = ( ENABLE = true ) ENCRYPTION = ( TYPE = 'SNOWFLAKE_SSE' ) """).collect() st.success(f":material/check_box: Audio stage ready (server-side encrypted)") except Exception as e: st.error(f":material/cancel: Could not create stage") if st.button(":material/delete: Clear Chat"): st.session_state.voice_messages = [ { "role": "assistant", "content": "Hello! :material/waving_hand: I'm your voice-enabled AI assistant. Click the microphone button to record a message, and I'll respond to you!" } ] st.rerun() st.subheader(":material/voice_chat: Conversation") audio = st.audio_input(":material/mic: Click to record") for msg in st.session_state.voice_messages: with st.chat_message(msg["role"]): st.markdown(msg["content"]) status_container = st.container() if audio is not None: audio_bytes = audio.read() audio_hash = hashlib.md5(audio_bytes).hexdigest() if audio_hash != st.session_state.processed_audio_id: st.session_state.processed_audio_id = audio_hash with status_container: transcript = None with st.spinner(":material/mic: Transcribing audio..."): try: timestamp = int(time.time()) filename = f"audio_{timestamp}.wav" audio_stream = io.BytesIO(audio_bytes) full_stage_path = f"{stage_name}/{filename}" session.file.put_stream( audio_stream, full_stage_path, overwrite=True, auto_compress=False ) safe_file_name = filename.replace("'", "''") sql_query = f""" SELECT SNOWFLAKE.CORTEX.AI_TRANSCRIBE( TO_FILE('{stage_name}', '{safe_file_name}') ) as transcript """ result_rows = session.sql(sql_query).collect() if result_rows: json_string = result_rows[0]['TRANSCRIPT'] transcript_data = json.loads(json_string) transcript = transcript_data.get("text", "") if transcript: st.session_state.voice_messages.append({ "role": "user", "content": transcript }) else: st.error("Transcription returned no text.") st.json(transcript_data) else: st.error("Transcription query returned no results.") except Exception as e: st.error(f"Error during transcription: {str(e)}") if transcript: with st.spinner(":material/smart_toy: Generating response..."): conversation_context = "You are a friendly voice assistant. Keep responses short and conversational.\n\nConversation history:\n" history_messages = st.session_state.voice_messages[:-1] if len(st.session_state.voice_messages) > 1 else [] history_messages = [msg for msg in history_messages if not (msg["role"] == "assistant" and "Click the microphone button" in msg["content"])] for msg in history_messages: role = "User" if msg["role"] == "user" else "Assistant" conversation_context += f"{role}: {msg['content']}\n" conversation_context += f"\nUser: {transcript}\n\nAssistant:" response = call_llm(conversation_context) st.session_state.voice_messages.append({ "role": "assistant", "content": response }) try: session.sql(f"REMOVE {stage_name}/{safe_file_name}").collect() except: pass st.rerun() else: st.session_state.processed_audio_id = None st.divider() st.caption("Day 25: Voice Interface | 30 Days of AI")

现在，让我们来看看我们构建的语音助手应用程序：

部署应用

将上述代码保存为 streamlit_app.py，并使用以下任一方式进行部署：

本地部署：在终端中运行streamlit run streamlit_app.py；Streamlit Community Cloud：通过 GitHub 仓库部署应用"；Streamlit in Snowflake（SiS）：直接在 Snowsight 中创建 Streamlit 应用"。

总结与资源

恭喜您！您已成功利用 Snowflake Cortex 的AI_TRANSCRIBE 函数构建了一个支持语音交互的 AI 助手。现在，用户可以通过语音提问，并获得智能化的对话式回复。

本课要点

• 使用 Snowflake Cortex AI 服务中的 AI_TRANSCRIBE 函数实现语音转文本；

• 创建具备适当加密机制的内部阶段以处理音频文件；

• 将 Streamlit 的音频输入组件与 Snowflake 平台进行集成；

• 构建一个具备对话能力的语音助手。

狂裁1600人，换掉CTO、晋升“下一代AI人才”！SaaS巨头的转型焦虑

华卫 — Fri, 13 Mar 2026 10:14:05 GMT

整理 | 华卫

近日，软件巨头 Atlassian 宣布将裁撤约 10% 的员工，涉及约 1600 个岗位，并更换首席技术官，以此进行重组，进一步投资AI。该公司一位发言人表示，受影响岗位中超过 900 个来自软件研发部门。之后，该公司股价在纳斯达克盘后交易中上涨逾 4%。

而这家公司在过去 12 个月里，其股价暴跌近74%。Atlassian 是一家总部位于悉尼、在纳斯达克上市的澳美合资科技企业，主营软件开发、项目管理与团队协作工具，旗下拥有项目管理平台 Jira、协同办公产品 Confluence 等全球数十万机构都在使用的核心产品，年收入规模达数十亿美元。

召百名员工来“自裁”：踢走资深员工、新人却没事

美国时间周三晚间，Atlassian联合创始人Mike Cannon-Brookes在一份内部通知中对员工表示，此 “对 Atlassian 而言是正确的决定”。同时他说道，“但这并不意味着做出这个决定很容易，远非如此。我知道这对你们每个人都将产生巨大影响，今天我和整个 Atlassian 都深感沉重。”

“软件公司在增长、盈利、速度、价值创造方面的‘优秀标准’已经提高” ，Cannon-Brookes在致员工信中写道。他表示，裁员是经过 “深思熟虑、极其全面” 的流程后做出的决定。

Mike Cannon-Brookes

针对AI是否取代了这 1600 名被裁员工的问题，他写道：“我们的理念并非‘AI取代人力’。但如果假装AI没有改变我们所需的技能结构，以及某些领域的岗位数量，那就是不诚实的。”该公司发言人透露，受影响员工中约 640 人位于北美，480 人在澳大利亚，250 人在印度，其余分布在日本、菲律宾、欧洲、中东和非洲。据了解，Atlassian 绝大多数员工从事软件工程与设计工作，截至 2025 年 6 月，这部分人员占其 13813 名全职员工总数的 50% 以上。

“这主要是为了适应变化。我们正在调整技能组合，改变工作方式，为未来而建设。”Cannon-Brookes称，超过 100 名 Atlassian 员工参与了裁员岗位评估，优先保留拥有AI相关技能和可迁移技能的员工。同时，Cannon-Brookes告诉员工，Atlassian 正在将自身重新定位为一家“AI 优先公司”。尽管AI不会直接取代这些岗位，但它是此次变革的核心导火索。“我们坚信，人与 AI 协同才能创造最佳成果。”

内部层面，Atlassian裁员岗位的筛选方式引发了困惑与不满。一位不愿具名的员工表示，“除了逐个查名字，根本不知道具体谁被裁了”，流程显得很不统一，“我团队里一位上轮绩效超预期、已任职五年的资深员工被裁了，而入职不到三个月的新人却没受影响” 。

该员工表示，“我个人认为是公司之前招人太多了，而Cannon-Brookes希望借此推高股价。”他们猜测，公司可能因招聘投入或声誉顾虑，不愿裁掉新员工。

还有消息称，Atlassian 上月宣布暂停招聘工程师及其他相关岗位，叫停全球招聘计划。许多急切的求职者称自己被 “彻底失联”或是在最后一刻被收回录用通知。这些求职者纷纷在社交媒体和 Blind 等员工论坛上发泄不满，他们被卷入这场突如其来的招聘冻结。有人在 Blind 上发帖说道，“拿到了工程岗 offer…… 沉默三周后，我终于在领英联系招聘经理，对方告诉我公司冻结招聘了。” 另一则上周的帖子写道，“我也是，六小时后的面试刚被取消，只告诉我职位不再开放。我已经准备了好几周，真的很崩溃。”

CTO都被开了，晋升“下一代AI人才”

值得一提的是，Atlassian 这次的人事调整连技术最高层职位都未放过。Atlassian 向监管机构提交的文件显示，重组后在Atlassian任职近四年的首席技术官Rajeev Rajan将于 3 月底卸任。他曾任职于 Meta，上任后为开发者推行了更严格的绩效指标。

CTO的位置将由Taroon Mandhana 与 Vikram Rao两位内部晋升者联合接任，两人被该公司称作 “下一代AI人才”。Mandhana担任协作首席技术官，Rao担任企业级首席技术官兼首席信任官。

Atlassian表示，这次裁员与战略变化有关，公司计划专注于AI开发和企业销售，将重点转向AI工具和协作产品。在此之前，Atlassian 就已在大力推进AI战略，包括自研AI工具 Rovo、收购开发 Arc 和 Dia 浏览器的 The Browser Company以及开发者智能平台 DX，该公司还计划将这些技术整合到 Jira 和 Bitbucket 等产品中。

同时，Cannon-Brookes称，公司将内部办公聊天工具 Slack 的开放时间比往常延长了至少 6 小时，以便员工与同事道别。他写道，“对于即将离开的 Atlassian 同仁，我为这一决定给你们带来的影响深表歉意，感谢你们为我们这段非凡历程所付出的一切。”Cannon-Brookes还告诉员工，下周将举行全公司线上问答会，解答更多问题。“请善待自己，善待彼此，关心你的同事和朋友，给大家一点时间消化这件事。”

据悉，被裁员工预计将获得至少 16 周薪资的遣散费、每工作一年额外增加一周，以及延长的医保计划、按比例提前发放的奖金、归还公司笔记本电脑后可领取的 1000 美元 “技术补贴”。Atlassian 在监管文件中表示，此次裁员将产生2.25 亿至 2.36 亿美元的相关费用，其中裁员及相关成本预计总计最高可达 1.74 亿美元，而缩减办公场地产生的退租相关费用至少为 6200 万美元。大部分成本将在 3 月底前产生，并于 6 月底前支付完毕。

该公司透露，他们希望重新平衡资源，为AI时代团队合作未来做准备，该计划包括办公空间和内部运营的调整，将支出和团队重新引导至与AI相关的技术和服务。

因 AI 陷危机：市值腰斩、两位联创身家缩水过半

Atlassian由Cannon-Brookes和Scott Farquhar于2002年创立，两人均入选《福布斯》澳大利亚50位最富有人士名单。如今，由于投资者担忧AI会让这家软件公司的服务被淘汰，Atlassian 市值已蒸发过半，股价暴跌也让该公司两位联合创始人的净资产缩水逾半。

在声明中，Cannon-Brookes强调，AI的应用改变了公司所需的技能与岗位结构，此次重组将改善 Atlassian 财务状况，并 “自筹资金进一步加大对AI和企业销售业务的投入”。Cannon-Brookes还写道，该公司于 2015 年上市，但自 2017 年以来的每个财年均处于亏损状态。

据了解，Atlassian 通过 Jira、Confluence、Trello 等流程协作应用的订阅服务获得收入增长，2025 年第四季度营收达 16 亿美元（合 23 亿澳元），同比增加 3 亿美元。但公司的确尚未实现盈利，自 2017 年以来每年均录得数百万美元亏损，其中 2025 年第四季度净亏损 4200 万美元，高于上年同期的 3800 万美元。Cannon-Brookes表示，此次重组将加快公司实现盈亏平衡的进程。

“像Atlassian这样的软件公司有机会通过采用AI工具提升业务效率，尤其是在产品开发中。通过这种方式重组，他们可以减少实现现有业务并实现更高盈利增长所需的资源。“D.A. Davidson分析师Gil Luria表示。

前不久，Cannon-Brookes在接受a16z的采访时表示，在 AI 时代，所有企业都不得不重新进行自我审视。过去你可能认为内部有五十个流程都是你的独门秘籍，但实际上真正具备壁垒的可能只有二十个。“不是每一家 SaaS 公司都能在未来十年活下来。就像当年很多公司没能转型上云，没能从 Windows 时代走向互联网时代一样。”

而在几天前做客20VC播客节目时，Cannon-Brookes又称 “SaaS 已死” 的说法“荒谬至极”。“照他们说的，我们就像一群原始人，只会敲敲打打写汇编代码，完全不懂大语言模型，我们不是简单地把 AI 功能外挂上去，而是在从头构建。”他说道。

然而，有网友这样形容 Atlassian 这家曾经的软件巨头所面临的 AI 时代危机：“现在，一个提示词就能建立Jira。一年内，Atlassian的整个产品组合将可以通过一个提示词克隆完成。Atlassian的股票将归零。”

就在 Atlassian 宣布裁员数周前，科技巨头 Block与澳大利亚科技公司 WiseTech 也因AI相关原因进行了类似裁员。Block 裁掉了全球 40% 的员工，员工规模从 1 万人缩减至 6000 人以下，联合创始人Jack Dorsey称，AI带来的生产力提升 “从根本上” 改变了公司。WiseTech 则宣布将在两年内裁员 2000 人，约占员工总数的 30%。由于上述两家公司在过去半年内股价均大幅下跌，分析师认为，除AI因素外，它们各自还有其他裁员理由。

不少网友评价道，“许多公司都这样做，相信了AI的梦想和炒作，解雇了数千名员工，结果惨败。几乎所有人都不得不紧急招人。”

参考链接：

https://www.theguardian.com/technology/2026/mar/12/atlassian-layoffs-software-technology-ai-push-mike-cannon-brookes-asx"

https://www.news.com.au/finance/business/technology/atlassian-to-cut-1600-jobs-in-ai-push/news-story/8b4b40046ab464788866cb1df4d3a00a"

https://www.smh.com.au/technology/australian-software-giant-atlassian-to-cut-1600-workers-blaming-ai-20260311-p5o9n3.html"

https://www.youtube.com/watch?v=0lzo2tFBFy8"

从概念到产线：具身智能真正卡在哪？

极客邦科技 — Fri, 13 Mar 2026 08:38:31 GMT

具身智能炒得热，落地为啥这么难？是模型不行、数据太少，还是经济账算不过来？四位专家在线拆解具身智能落地四大真问题。
在 4 月 16-18 日将于北京举办的 QCon 全球软件开发大会·2026 北京站上，我们特别设置了【具身智能与物理世界交互】专题。该专题聚焦 VLA/VA 模型与数据体系两大核心，深度拆解具身智能技术链路。拟探讨模型现状、核心挑战与机会，分享高质量数据解决方案，解析仿真与 World Model 的赋能价值，破解核心技术瓶颈。旨在搭建顶尖交流平台，助力从业者与研究者明晰方向，加速具身智能技术研发转化与产业规模化落地。

模型不再是关键？LangChain 创始人：真正决定Agent 上限的是运行框架

允毅 — Fri, 13 Mar 2026 08:12:24 GMT

伴随模型能力持续跃迁，简单调用 LLM API、套一层提示词就能做产品的时代，已经走到尽头。

AI 应用正在从“单次生成”，迈向“持续执行”。下一代软件系统，不再只是把大模型接进工作流，而是围绕一层全新的 agent orchestration 架构展开：它负责让智能体自主规划、调用工具、编写代码、管理文件、压缩上下文、调度子智能体，并在长时程任务中保持连贯行动。

这也意味着：简单封装 AI 的时代正式结束，整个软件基础设施层，正在被重新书写。

刚刚完成 1.25 亿美元新融资的 LangChain，正是这场浪潮的定义者之一。其创始人 Harrison Chase 在最新一期播客中围绕 “到底是模型吞噬框架，还是框架吞噬模型” 的行业争论，直接指出“框架才是未来，模型终将走向商品化”。

在这场对话里，他首次清晰定义出现代智能体的四大核心组件：系统提示词、规划工具、子智能体、文件系统，这是目前业界最统一的 “标准架构”。

面对未来趋势是超强单智能体还是专业多智能体协作，他认为最有价值的永远是指令和工具本身。

他自曝当初创建 LangChain，正是看准了 LLM 循环调用工具的巨大潜力。从早期开源框架，到 LangGraph、Deep Agents、LangSmith 再到 Agent Builder，LangChain 自身也完成了从 “实验玩具” 到 “生产级智能体运行时” 的蜕变。

Harrison Chase 透露，LangChain 接下来的核心方向很明确：一边押注商业化表现最强的可观测性，一边补齐部署与无代码能力，朝完整的智能体工程平台继续推进。

这期访谈，几乎把智能体的底层逻辑讲透：

子智能体的关键不在“分工”，而在“如何好好沟通”。系统提示词，就是智能体的 SOP。文件系统，本质是让 LLM 自己管理上下文窗口。技能（Skill）的核心，是渐进式披露。沙盒的真正价值是从架构上防止提示注入泄露密钥。对智能体而言，可观测性就是生命线。别死磕模型，别死磕框架。把行业知识变成指令 + 工具 + 技能，才是企业真正的壁垒。

以下是访谈全文，经 InfoQ 翻译整理。

长时程智能体，最后都是编码智能体

主持人：我感觉在去年 12 月到 1 月假期前后，出现了一个关键转折点 —— 所有人几乎同时意识到，短短几个月内，智能体的能力已经突飞猛进。你能帮我们对比一下，第一代智能体和现在的智能体有什么区别？

Harrison Chase：如今智能体背后的很多理念，其实在早期就已经出现了。区别在于，当时的模型根本跑不起来。LangChain 大概比 ChatGPT 早一两个月推出，我们一开始加入的核心功能之一，就是让 LLM 在循环中运行并调用工具。当时有一篇非常重要的论文叫 ReAct，核心思路就是这个。它在维基百科问答这类数据集上有效，但在真实场景里完全不行。到了 3 月，AutoGPT 问世，本质也是一样：循环运行、调用工具，在很多方面可以说是 OpenDevin 的前身。

我对智能体发展轨迹的总结是：最开始只有一个非常简单的核心理念 —— 让 LLM 循环运行、调用工具，给它提示词、指令和一堆工具，但效果并不好。于是人们开始围绕模型搭建脚手架，让它们的行为更可预测、更可靠。这也是我们在 LangChain 推出 LangGraph 的原因：它是另一个框架，专门面向图结构工作流，提供更强的结构化能力，适合需要超高可靠性的场景。

但大概在 11、12 月，随着最新一批云模型发布，模型能力变得极强，大家发现它们真的可以直接在循环里跑起来。这不仅仅是模型本身的进步，还有围绕模型的框架。如果你回看一年前的产品，比如 Claude Code、Manis、Deep Research，它们都采用了同样的模式：让模型循环运行、调用工具、编写代码、读写文件。

所以我认为两件事同时发生：

模型本身变得更强；我们开始发现一套基础的框架原语，能真正让模型发挥最佳效果。大家在假期前后基本都意识到了这一点，于是我们看到，开发者开始爆发式地用这些核心原语构建各种智能体。

主持人：我们说的是编码智能体吗？我记得你好像说过，每个智能体都应该是编码智能体。

Harrison Chase：我们看到市场上出现了两类不同的智能体：一类是对话式智能体，比如客服、聊天机器人。它们需要极低延迟，通常以语音为交互媒介，很少调用工具，可能只会一两次，太多就会太慢。另一类是红杉资本提出的长时程智能体，我很喜欢这个定义。它们可以长时间运行、做规划、保持连贯性。而这类智能体，最终大多表现得像编码智能体。

原因有几点：第一，代码通用性极强。你可以用代码解析文本、批量处理文件，与其调用 100 次不同工具，不如写一个脚本循环完成。第二，模型本身就是在代码上训练的。所有大模型厂商都在让模型学习代码、Bash 命令、文件编辑，这些是模型最擅长的事情。

所以我们看到智能体分成两大方向：长时程智能体 vs 对话智能体。而长时程期智能体里，编码智能体或类编码智能体效果最好。

主持人：你认为随着对话智能体往技术栈深处走，它们也会变成编码智能体吗？

Harrison Chase：这是个好问题。我们内部也经常讨论，是否要为对话智能体做一套专门的框架。我认为未来会出现融合：当智能体能可靠地启动并管理其他长时程智能体时，两类形态就会合并。我们在编码场景里看到一个趋势：用户希望一边和主智能体聊天，一边让它在后台启动一批子智能体干活。这在某种意义上和对话智能体非常像。未来语音智能体显然也需要做更多长时程任务，实现方式大概率是：一个对话智能体在前台，后台启动异步运行的子智能体。最终所有形态会收敛到同一个框架里，支持后台异步长时智能体作为工具。

是模型吞噬框架？还是框架吞噬模型？

主持人：你刚才提到，智能体加速的部分原因是模型变强。这让我好奇：最终谁会赢？你认为是模型最终吞噬框架层，还是框架和基础设施层吞噬模型，让底层模型彻底商品化？

Harrison Chase：我认为框架才是最重要的。我不知道未来会怎样，但 Manis 就是一个绝佳例子：它是一个终端产品，但它的框架是真正的核心秘诀，而且能兼容底层任何模型。再看 Claude Code，云模型固然很强，但真正让它跑起来的是框架。Claude Code 也不只是框架，还包含 UI。我现在认为，框架和上层 UI 之间耦合非常紧密，差别很小。

再看 CodeLlama、Claude Code、Manis、各类深度研究产品，都是框架 + UI 的有趣组合。所以我坚信，框架极其重要。

另外一个有意思的点：很多做框架的人，同时也在做模型。从逻辑上讲，既然做了框架又做了模型，就应该用 RL 让模型专门适配这个框架。但你看 Claude Code 使用的工具，其实并不是模型里通过 RL 学到的那套工具。Anthropic 模型内置了文件编辑工具，但实际框架里用的是另一套完全不同的工具。我问过他们好几次，都没有得到明确答复。但我能确定的是：框架真的非常关键。

主持人：用通俗的话讲，到底什么是框架？

Harrison Chase：简单说，框架就是模型与环境交互的整套方式。它是一套通用工具集。有些专用工具我不认为属于框架，但能和通用环境交互的能力，就是框架的一部分。

比如编码智能体：

文件编辑工具属于框架运行代码的能力属于框架

如果你在通用框架上再加一个专门对接 Slack 的工具，那是在框架之上做定制。我们认为，绝大多数智能体都应该这么构建：拿一个通用框架，给它指令、工具，就能用。

如今大部分框架还内置了子智能体（sub-agents）和技能（skills），你可以配置这些能力，这种技能抽象、子智能体抽象，本身就是框架的一部分。框架还会做提示缓存、上下文压缩 —— 当上下文太长时自动压缩。这些都是通用能力，适用于各类应用。

作为应用开发者，你不需要关心底层这些细节，只需要用不同提示词、工具、技能、子智能体去配置，就能打造出面向终端用户的专属智能体。

智能体架构核心组件：提示词、规划工具、子智能体、文件系统

主持人：这些都非常有意思。现在我想深入拆解你刚才提到的各个部分。我们先从系统提示词开始，我认为它是核心架构的一部分。一个详细的系统提示词，到底起什么作用？

Harrison Chase：它驱动智能体，告诉它该做什么。我有时会这么理解：系统提示词就像是给人用的标准作业流程。智能体一启动就会加载它，直接指导行为。

主持人：它存在于哪里？

Harrison Chase：取决于你怎么创建智能体。比如 Claude Code 这类编码智能体，有一部分系统提示词是内置在框架里的，告诉它如何使用通用工具；另一部分则由用户补充 —— 比如你提供的 claude.md 文件、技能、子智能体，都会被插入到整体系统提示词中。所以实际使用中，系统提示词是多部分内容的合并：一部分内置在框架，一部分由定制者添加。

主持人：你提到了工具。我知道还有规划工具的概念，它是做什么的？

Harrison Chase：工具有很多种。有些是框架内置的基础工具，比如我们和其他很多框架都提供的规划工具。它可以生成计划，写入文件，支持后续编辑，也可以只是让智能体调用这个工具。价值在于：计划会被放进智能体的上下文窗口，相当于给它一个思维草稿本。

大多数规划工具输出的是任务列表，每个任务包含描述、状态（待办、执行中、已完成）。但大多数框架并不会强制智能体严格按计划执行，只是把计划放进去，让它用来指导行动。早期模型能力不强时，我们会设计显式的规划步骤：先规划，再执行第一步，再第二步。但现在模型更强了，这种硬编码流程太繁琐，遇到中途调整计划就会出问题。现在的主流方式是：把计划存在文本文件里，主智能体参考它行动，但不做严格步骤拆分。

主持人：那子智能体（sub-agents）呢？

Harrison Chase：子智能体的好处是可以隔离上下文。主智能体在循环中不断积累上下文，信息多是优势，但也会撑爆上下文窗口。子智能体的工作方式是：主智能体给它一个任务、一段字符串，子智能体启动一个全新的上下文窗口，从零开始执行一堆工作，然后只把结果返回给主智能体。这样不同任务之间就有了很好的隔离。

缺点也正是隔离本身：因为隔离，智能体之间必须通信。通信一旦出问题，整个流程就会失效。我们经常看到这种情况：主智能体启动子智能体，子智能体做了大量工作，关键信息都在中间过程，但最后只返回一句 “完成”。主智能体完全不知道它干了什么。这就是子智能体没有收到清晰指令，没有在最终消息里返回结果。

顺便说一句，沟通是人生中最难的事：创业最难、人际关系最难，和智能体协作最难的也是让它们好好沟通。子智能体很强大，但确实增加了一层通信复杂度。

主持人：系统怎么知道什么时候要创建子智能体？

Harrison Chase：完全靠提示词。这就是这类智能体框架的美妙之处。早些年我们用 LangGraph 时，大家会问：我怎么加一个步骤确保智能体在 X 之前做 Y？怎么强制执行顺序？不管好坏，现在的方式就是：你直接告诉它做什么。好处是极度灵活，坏处是无法做到 100% 可靠。

这也是为什么 LangGraph 在强监管行业依然有很高使用率 —— 那里需要极强的可控性、精度和可靠性。即便编码智能体再强，行为依然不可预测，没有任何保证。这也是它迷人的地方：你说什么它做什么；但同时，这也是缺点。

主持人：另一个部分是你提到的文件系统。为什么智能体需要文件系统？

Harrison Chase：我的理解是，一切都回到上下文工程，LLM 能看到什么。文件系统本质上是让 LLM自己管理上下文窗口：

它可以决定从文件里读什么，而不是把所有内容塞进上下文窗口直接撑爆；它可以写入文件，相当于持久化保存，即便上下文被压缩，也能重新读取。

我们在 Deep Agents 里用文件系统来卸载超大工具调用结果。比如一个工具返回 6 万个 token，我们不会全部塞给 LLM，而是存进文件，只给它看前 1000 个 token，剩下的告诉它去读文件。我们也用它做摘要：当上下文快溢出时，执行摘要，把原始消息存进文件系统，方便后续回溯。

总的主题就是：让 LLM 自己管理上下文。越来越自主的智能体，趋势就是让 LLM 做越来越多的事，管理自己上下文就是比单纯调用工具更进一步的体现。

主持人：文件系统就是字面意义的文件系统吗？不是数据库？

Harrison Chase：它可以是任何东西。关键是：以文件系统的接口暴露给 LLM，因为 LLM 最擅长和文件系统打交道。在 Deep Agents 里，文件系统可以是磁盘上真实文件系统、Daytona 沙盒，也可以是上层套了文件系统接口的数据库。不是所有东西都得是文件系统，比如 SQL 表就让它写 SQL。但处理大量文本时，即便存在 SQL 里，给它文件接口通常更友好。

主持人：所以，详细系统提示词、规划工具、子智能体、文件系统 —— 这四个就是现代智能体架构的核心组件？

Harrison Chase：对，就是这四个。我们推出 Deep Agents 时，观察到 Manis、Claude Code、Deep Research 全都具备这四点，于是我们把它们封装进一个 Python 包，让开发者能轻松构建同类产品。这四个至今依然是核心。

其他常用组件还有：

Bash 与代码执行：非常重要，但因为沙盒还比较新，大家还在摸索使用方式，所以还没普及，但需求越来越强；技能（Skills）：新的原语，Deep Agents 刚推出时还没有，现在已经非常重要。

主持人：你能解释一下什么是技能吗？

Harrison Chase：技能本质上就是一堆文件，通常有一个 skill.md，里面是如何完成某件事的指令，也可以包含可执行脚本。它不会直接加载进系统提示词，而是在系统提示词里被引用。你告诉智能体：你拥有代码编写技能、文档编写技能，当它需要时，就会按需读取这些文件。

这叫做渐进式披露：只在 LLM 需要知道时，才告诉它需要知道的内容。这也是让它自己管理上下文窗口的关键方式。这是 Deep Agents 和大多数框架都支持的核心能力。

我们还在重点研究异步子智能体，目前大多数框架做得还不够好，Claude Code 虽然支持，但触发逻辑不透明，也难以观测和管理。但我们认为这会越来越重要。

压缩上下文与语义记忆、情景记忆、程序记忆

主持人：你能聊聊上下文压缩吗？我们在子智能体那部分稍微提到过。它是什么？为什么需要？怎么实现？

Harrison Chase：当你积累了大量上下文，想把它精简缩小时，就会用到压缩。原因很简单：大多数模型无法处理无限上下文，即便能支持百万级 token，你也不想传给它那么多。

在 Deep Agents 里，我们的做法是：

保留最近 N 条消息（比如最近 10 条），保证智能体不中断当前流程；把更早的所有消息进行精简，提取核心目标、关键信息、重要文件，生成摘要放进上下文窗口；同时把原始完整消息存进文件系统。

摘要不可能完美，大概能覆盖 80%–95% 的场景，但万一有只能从原始历史里拿到的关键信息，智能体还能去文件里读。

我们还有一个即将发布的新功能：让智能体自己触发压缩。现在几乎所有框架都是硬阈值触发（比如上下文用到 80% 就压缩）。但本着让模型更自主的理念，我们会给它一个工具，让它自己决定什么时候压缩。比如你让它先做任务 A，用到 60% 上下文，接着让它做完全无关的任务 B，它就应该主动压缩，避免无关历史干扰、浪费成本。

主持人：我们再聊聊记忆。你之前提到过语义记忆、情景记忆、程序记忆。能展开讲讲吗？

Harrison Chase：我把记忆分成三类：

语义记忆：关于世界的事实，比如 “巴黎是法国首都”。我们很擅长做这个，就是 RAG；情景记忆：过去的交互、对话记录，也很成熟，让智能体查历史对话就行；程序记忆：最有意思，是 “如何做某事” 的指令。我认为这本质就是智能体的配置：系统提示词、技能、工具，都是程序记忆。

在 Deep Agents 里，我们把这些都表示为文件，智能体可以在运行中更新它们。所以当我们说 “Deep Agents 可以学习”，真正意思是：它可以修改以文件形式存在的程序记忆。

超强单智能体 Vs 专业多智能体

主持人：随着每个智能体积累更多记忆、更多上下文，你认为最终会出现一个全能超级智能体，还是成千上万的智能体和子智能体协同工作？

Harrison Chase：好问题。我确实认为记忆定义了一个智能体。有趣的是，你可以把定义一个智能体的记忆，作为一项技能暴露给一个超级智能体。

企业里经常遇到这种需求：20 个不同部门，每个部门都要做自己的智能体，但希望用统一界面管控。答案还不固定：

是一个大智能体 + 20 个部门技能？还是 20 个子智能体？还是 20 套完全自定义的工作流？

但我坚信一点：最有价值的永远是指令和工具本身。不管它们被打包成技能、子智能体，还是独立智能体，指令和工具的价值不会变。

我认为未来会走向这种模式：前台是一个同步对话智能体，后台启动一批长时间运行的异步智能体。看起来是一个智能体，实际上是不同记忆模块驱动不同子智能体。组合方式会快速变化，脚手架也会快速迭代，但循环运行、调用工具、文件系统、写代码这套框架核心是稳定的。框架功能每周都在加，但指令和工具永远有价值。我给企业的首要建议就是：专注打磨指令和工具。

主持人：生态里还有哪些足够稳定、值得投入的部分？比如 MCP，大家已经把它当成标准了吗？

Harrison Chase：MCP 很好，它是一种以标准格式暴露 API 的方式，还有引导等功能，只是客户端支持还不多。核心的 “标准化暴露 API” 非常有用。

我认为更稳定的是偏底层的东西：

可观测性：不管智能体长什么样，你都想知道内部发生了什么；评估：不管智能体长什么样，你都需要某种方式度量它；沙盒：非常好的例子，底层基础设施。如果智能体不写代码，沙盒没用；但趋势是，所有智能体最终都会写代码；部署：智能体一定是长时间运行、有状态的，支持长时有状态应用的部署平台永远有用。

我们内部很清楚：LangChain、LangGraph、Deep Agents 这三个开源项目同时存在，本身就说明这个领域变化极快。但除了开源之外，我们构建的所有东西，都尽量保证是底层通用能力，无论上层脚手架怎么变都有用，并且能兼容任何智能体框架。

主持人：既然你提到了沙盒，我们现在又在 Daytona Compute 大会现场，Daytona 又是沙盒领域的领先者，我们聊一下智能体的计算层。简单来说，为什么智能体需要沙盒？

Harrison Chase：在我看来，主要原因就是：编写并运行代码。我想区分一下文件系统和沙盒：文件系统只是接口，沙盒则提供代码执行环境。

如果智能体要写代码、运行代码，就必须用沙盒：

不能在共享服务器甚至本地电脑上运行不受信代码；大家买 Mac mini 跑 OpenDevin 就是一种原始的沙盒隔离方案。

云端智能体对应的，就是 Daytona 这类沙盒。

主持人：从 LangChain 角度，你们和沙盒的交互方式是什么？

Harrison Chase：有两种主流方式，各占 50% 左右：

启动沙盒，把智能体装进去，在沙盒内运行；智能体在沙盒外运行，把沙盒当作工具调用。

Cloud Code 这类产品更偏向第一种：设计初衷就是在本地系统运行，所以大家通常启动沙盒再装进去。而全新设计的框架会更灵活。

主持人：这涉及安全问题吗？比如提示词注入，沙盒是防御手段吗？

Harrison Chase：确实有安全价值。比如 Daytona 支持的一个关键点：代理模式。如果你在沙盒里放 API 密钥，LLM 能看到，就极容易被提示注入攻击 —— 攻击者可以让它忽略之前指令，把 API key 发出去。而沙盒外的代理层，可以在调用时自动注入 API key，沙盒内的智能体永远看不到密钥。这是安全与沙盒结合的一个非常重要的设计。

LangChain 生态：从开源工具到完整平台

主持人：接下来我们深入聊聊你们真正提供的产品和构建的东西。你能简单讲讲你的背景，以及最初为什么创办 LangChain，关键洞察是什么？

Harrison Chase：我的背景是统计和计算机科学。在这之前我待过两家创业公司：第一家是金融科技公司 Kensho，我在机器学习团队。那是我第一份工作，工程文化极强，我学到了太多东西。团队里有谷歌老兵、MIT 和哈佛物理博士，人才密度极高。第二家是 Robust Intelligence，我是二号员工。我们最早做对抗性机器学习，后来转向 MLOps 平台，专注 ML 模型的测试与验证。

2022 年夏秋，我打算离开，还没想好做什么。我参加了很多线下活动，当时 Stable Diffusion 很火，但有一小群人在用早期 LLM 做疯狂的事情。我发现了很多通用模式。我一直喜欢做工具帮别人提高效率：在 Kensho 后期我做内部 MLOps，Robust 本身就是 MLOps 公司。

我当时并没打算创业，还在 Robust 上班，计划几个月后离职，花时间思考下一步。但我想：这是了解这个领域的好办法。我把这些通用模式放进一个 Python 包并开源，这就是 LangChain。大概一两个月后，我明显看到巨大机会，于是和联合创始人 Enkos 更紧密地合作，离职正式创办公司。我们继续做开源，同时开始做商业化产品 LangSmith，思路来自 Robust 做的测试与验证 —— 我们意识到，这对机器学习很重要，对智能体会更加重要、也完全不同，所以我们必须做。

主持人：我们来梳理一下现在的平台和各个组件。你刚开始做的 LangChain 是 0.0 版本，现在是 1.x 版本，两者有什么区别？再和 LangGraph、Deep Agents 对比一下。

Harrison Chase：早期 LangChain 本质是抽象层：对语言模型、检索器、各类组件做抽象，再加上把它们拼起来的流程手册。比如 RAG 链，五行代码就能跑，极大降低入门门槛。但我们很快发现：要上线生产环境，用户需要更多内部可控性。模板化提示词、固定假设，在快速变化的领域里不够灵活。

于是我们做了 LangGraph：

专注编排，极度底层；没有隐藏提示词、没有隐藏认知架构；不强制任何特定方式；内置生产级能力：持久执行、流式输出、人机交互、长短时记忆持久化。

我们把 LangGraph 看作智能体运行时。当用户从探索走向生产，我们越来越推荐基于 LangGraph 构建。

LangChain 最早的理念就是 “让 LLM 循环运行 + 调用工具”，但早期不好用。2025 年我们发现这个模式越来越可靠，于是 LangChain 1.0 彻底聚焦于此，在 LangGraph 之上重构，只保留 create_agent 核心函数：循环运行 LLM、调用工具，极度中立、可高度配置。

Deep Agents 则是开箱即用的完整框架：内置规划工具、文件系统、全套能力。如果你想自己造框架，用 LangChain 和 create_agent；如果你想直接用成熟框架，用 Deep Agents。

主持人：那 LangSmith 呢？主要专注可观测性吗？

Harrison Chase：LangSmith 的核心是可观测性增强版。构建智能体和传统软件最大的不同是：运行之前，你根本不知道它会做什么。原因有两个：

智能体输入极广，理论上无限；传统软件只有按钮等限定输入；LLM 是非确定性的，对提示词微小变化极度敏感。

这使得可观测性比传统软件重要得多，也不同得多：它和生命周期其他环节深度绑定。运行轨迹可以变成测试用例，支撑在线评估、分析等。

LangSmith 里最大的部分就是 observability++，围绕：

run：单次 LLM 调用trace：一组 run 的集合thread：多轮会话整体

除此之外，我们还有应用部署平台，以及最近推出的无代码平台，可以无代码创建智能体，但核心依然是 observability++。

主持人：评估这个话题很有意思。现在有一个趋势，比如 Co-Work 里，终端用户可以评估系统并提供反馈。你怎么看待为企业构建合适框架，让智能体能按用户维度持续进化？

Harrison Chase：评估、记忆、提示词优化之间有非常有趣的关联。它们的逻辑都很像：智能体做某事 → 有奖励 / 评估函数 → 更新某种配置 / 参数。

离线评估：上线前用数据集跑，打分，确保不退化；记忆：用户告诉智能体哪里做错，它更新指令避免再犯；提示词优化：用在线评估数据，让智能体自动优化提示词。

目前这三件事还相对独立，但未来会深度融合。我们在无代码智能体里内置了记忆，并且很兴奋把记忆和评估绑定：当记忆修改内容时，自动添加评估用例，防止未来退化。

主持人：无代码平台让任何人都能构建智能体，同时也要支持极专业用户做高精度定制。你怎么把握合适的抽象层次？

Harrison Chase：Deep Agents 框架的妙处在于：配置框架本质就是写提示词、加工具、加技能 —— 这些都可以无代码完成。工具确实需要写成代码并通过 MCP 暴露，但一旦有了 MCP 服务器，剩下都能无代码操作。所以从框架到无代码的跃迁并不大。你还可以加中间件做深度定制，但影响最大的部分 —— 提示词、工具、技能 —— 都能在 UI 里完成。

主持人：你们刚刚完成 1.25 亿美元新融资。接下来要做什么？愿景和产品路线图是什么？

Harrison Chase：说实话，在这个领域我们甚至没有一年期路线图，能看清一个月就不错了。重点方向很明确：

全力投入可观测性增强版：商业化 traction 非常强；打造智能体工程平台：包含部署、无代码等能力。

可观测性增强版是核心支柱，我们要做到业界顶尖，同时打造完整平台。

主持人：如果框架不断收敛，每个智能体都具备代码执行、文件系统、子智能体、MCP，模型也越来越强，那么对于 AI 开发者来说，差异化到底在哪里？

Harrison Chase：我认为绝大多数差异化，在于指令、工具和技能。也就是你把行业流程知识编码成自然语言，交给智能体，再配上它可以调用的工具与技能。

作为 AI 构建者，你当然应该学习框架、技能这些东西，但不必过度绑定 —— 因为构建方式会变。但领域知识、专属工具、业务流程指令，这些是不会变的，这才是真正的壁垒。

参考链接：

https://www.youtube.com/watch?v=rSKh6bVuVZI

InfoQ 推荐

Elastic 9.3 升级！向量搜索快 12 倍

曝Meta狂砍20%岗位！超1.6万人将失业，传闻“要用AI智能体取代整个工程团队”？

从 ChatBI 到多 Agent 分析中台：Snowflake 与亚马逊云科技的实战架构

为什么我们不再喊「ChatBI」

ChatBI 模式的现实挑战

从 ChatBI 到多 Agent 分析中台

交互层：Amazon Quick Suite

编排层：Amazon Bedrock AgentCore

执行层：Snowflake Cortex AI

核心技术实现：多 Agent 协同的关键机制

双路径智能路由：Dashboard + Text-to-SQL

路径一：Dashboard 预构建查询

路径二：实时 Text-to-SQL

异步处理架构：兼顾复杂查询与前台体验

语义模型驱动的 Text-to-SQL

适用场景与实践建议

写在最后：从「能聊天」到「敢决策」

关于作者

AI x 大前端性能稳定性：快手亿级 DAU 下的智能诊断实践

快⼿性能稳定性背景

AI x 性能稳定性介绍

实践：AI 辅助根因排障

实践：AI 加速应急处置

总结展望

AI 2.0 时代的大模型推理：从模型到硬件的协同优化

以智能革命，引领大模型推理范式变革

以弹性算力集群，驱动云侧智能升级

面向华为昇腾的推理优化部署实践

以有限算力架构，释放终端应用潜能

以大模型推理技术创新，融合人工智能产业创新

AI 领导力：像管理团队一样管理 AI

Vibe Coding ——"心流"在编码中重现

Vibe Working —"心流”延伸至所有工作

AI 领导力——新范式下的核心四要素

行业影响————软件世界的"板块漂移"

Snowflake China 与国内云对象存储的多云集成实战指南：一套架构打通多云对象存储

背景：Snowflake 与多云环境

总体架构：基于 S3 兼容协议的“桥接模式”

实施流程

步骤 1：准备对象存储环境

创建 Bucket

创建访问凭证

步骤 2：在 Snowflake China 侧完成 Endpoint 白名单

步骤 3：在 Snowflake 中创建 External Stage / External Volume + Iceberg

集成实战

配置总览

各厂商常用 Region Endpoint 速查

华为云 OBS

腾讯云 COS

火山引擎 TOS（必须使用 S3 兼容端点）

External Stage 创建

双向 COPY 示例

External Volume + Iceberg Lakehouse

各厂商特殊注意事项

实测验证汇总

典型工作负载模式与架构选择

最佳实践总结：为什么选择以 Snowflake 为中心？

相关资源与参考文档

关于作者

“为了让工程师用 AI，公司会裁掉一半人！”硅谷顶级大佬直言，AI 一天 3 小时搞定工作，还搞 996 的公司必垮

AI之前，你的知识就在不断过时

软件创新长期停滞，直到 AI 出现才重新激活

“裁掉一半人，来供另一半人全力使用AI”

Agent 应用等级

IDE 会“回归”

Gas Town，一个验证边界的想法工厂

百倍提效后，就让员工一天工作3小时

Anthropic 内部的“蜂巢心智”

谷歌：先抢工作，但不做

大厂创新已死

产品游戏化，如何处理“vibe coding 债”

fork 开源项目是常态

要么完全透明，要么藏住不说

“把 Gas Town 部署到手机上”

未来的语言设计

2027年预测

OpenClaw 之父惊叹中国速度！大厂集体杀入新战场：用AI 批量制造“一人公司”

一人公司的开发模式

选工具，挑最容易上手的

把99.9% 代码交给 AI ：腾讯云⼀次“吃狗粮”的⼯程实验

如何用 Streamlit 和 Snowflake Cortex 搭建语音助手应用｜技术实践