乐于分享
好东西不私藏

AI时代各行业生存指南新评估基准与2026递归学习路线图 (Matt Fitzpatrick)

AI时代各行业生存指南新评估基准与2026递归学习路线图 (Matt Fitzpatrick)
Overview背景概览

本文译自 Peter Diamandis 的 YouTube 频道播客节目 Moonshots with Peter Diamandis (Episode #218)。

栏目名称:Moonshots with Peter Diamandis (Episode #218)
主持人:彼得·戴曼迪斯 (Peter Diamandis),以及“登月伙伴”:戴夫·布伦丁 (Dave Blundin)、萨利姆·伊斯梅尔 (Salim Ismail)、亚历克斯·维斯纳-格罗斯 (Dr. Alexander Wissner-Gross / AWG)
访谈嘉宾:马特·菲茨帕特里克 (Matt Fitzpatrick) —— Invisible Technologies CEO,前麦肯锡合伙人兼 QuantumBlack Labs 全球负责人
访谈时间:2025 年 12 月 23 日 (2026 年 6 月跨时空复盘)

▍嘉宾:马特·菲茨帕特里克 (Matt Fitzpatrick) 马特·菲茨帕特里克是 Invisible Technologies 的首席执行官。在加入 Invisible 之前,他曾担任麦肯锡公司 (McKinsey & Company) 的合伙人以及 QuantumBlack Labs (麦肯锡旗下的高级数据分析与 AI 团队) 的全球负责人。他在企业数字化转型、大规模 AI 落地、组织流程再造方面拥有深厚的专业知识和实战经验。

▍关于 Invisible Technologies Invisible Technologies 是一家提供模块化 AI 软件平台与人机协同 (Human-in-the-loop) 流程代理工作流的科技公司,同时也是全球最顶尖 LLM 实验室(如 OpenAI 等)的核心数据训练和强化学习提供商。

核心模式:通过其独创的“数字装配线” (Digital Assembly Line) 架构,将先进的 AI 代理 (Agents) 与全球熟练的人类专家相结合,为企业提供高度定制、高准确率的业务流程自动化 (BPA) 服务,以及为大模型训练提供高质量、带标签、对抗性的指令微调数据。
行业定位:在 AI 时代,Invisible 作为“人机协同”领域的领导者,不仅支撑了大语言模型的底层能力演进,还帮助财富 500 强企业实现业务流程的深度重构。

内容提要:本期访谈中,Peter Diamandis 与登月伙伴们对话 Invisible Technologies CEO Matt Fitzpatrick。Matt 结合其在麦肯锡 QuantumBlack 和 Invisible 的实战经历,深入剖析了哪些行业将在 AI 浪潮中被彻底重塑、为什么未来的企业需要成千上万个垂直基准测试 (Vertical Benchmarks),以及 2026 年“递归学习” (Recursive Learning) 与智能化变革的宏伟路线图。

前言高光预告

马特: 如今,公众的关注点大多集中在针对编程等领域的通用公开基准测试上。然而,我认为问题在于……我是 Matt Fitzpatrick,Invisible Technologies 的 CEO。我们是一家基础设施公司,而这种基础设施使我们能够在大规模尺度上实现我所说的“超个性化软件”。

亚历克斯: 听起来你的立场是,我们需要数以千计全新的、更窄的基准测试,来覆盖每个劳动力类别与每个垂直行业。

马特: 这涉及到这个问题的第二个有趣部分,即……

萨利姆: 到 2026 年,那些未能做出这一改变的企业将面临有史以来最大规模的颠覆。

马特: 在许多行业,其原有的工作结构将会发生改变。如果你想想知识工作、大量文档的制作,这些技术在这些领域是非常颠覆性的。我认为关键问题在于,你的业务中到底有哪些部分可以通过 AI 发生真正的改变。

彼得: 在实施 AI 的过程中,你看到大多数公司犯的最大错误是什么?

马特: 你会面临两种完全不同的挑战。第一是数据,第二是……

彼得: 先生们女士们,那才叫真正的“登月项目”(Moonshot)!

引入与 AI 时代的生存法则

彼得: 嘿伙计们,欢迎来到《登月》(Moonshots)播客。在今天的节目中,我们将讨论为什么所有公司在 2026 年都需要成为 AI 公司。他们该如何做到这一点?如果做不到会发生什么?我们还将讨论大型传统企业是否能够做出如此戏剧性的转变,以及他们如何才能最好地实现这一转变。

我们将探讨一些有趣且有意义的 AI 应用案例,所以请仔细聆听。我认为这些案例会让你对未来的可行性感到兴奋。我们还将深入探讨我们的嘉宾对 2026 年的预测。

今天加入我们“登月伙伴”行列的是节目的老朋友马特·菲茨帕特里克(Matt Fitzpatrick)。在过去十多年里,他一直在麦肯锡(McKinsey & Company)工作,并一路升至 QuantumBlack Labs 的全球负责人,领导该公司的 AI 软件研发和全球 AI 产品。一年前,马特加入并担任 Invisible Technologies 的 CEO。这家公司是由我的一个非常聪明的朋友弗朗西斯·佩德拉萨(Francis Pedraza)创立的。对于那些不了解 Invisible 的人来说,这家公司是一个模块化 AI 软件平台,利用 AI 训练并为市面上大多数大语言模型(LLM)提供商提供数据训练服务,同时为企业构建定制工作流和代理(Agents)。他们的工作立足于创建干净的数据和人机协同(Human-in-the-Loop)交付,以确保可衡量的商业结果。

马特,欢迎你。很高兴你能来。嘿,马特!

马特: 谢谢你们邀请我。

彼得: 我们还有 DB2(戴夫·布伦丁)、AWG(亚历克斯)、萨利姆。祝大家节日快乐!感觉我们在这个播客里就像每隔一天就会聚一次。我想我们应该直接搬进一栋超大的“播客别墅”,这样我们就能完整地记录下奇点(Singularity)的到来了。

戴夫: (笑)噢,不过说真的,我今天非常期待听到马特的分享。因为在周四,我们必须做我们对明年的预测(译者注:指 2026 年的预测)。马特今天会给我们提供大量的真知灼见。我的第一个预测是:与 AI 本身的发展速度相比,企业端落地推进的速度将会慢得像个傻子。而马特是研究 AI 与企业交叉领域的全球顶级专家,所以我简直等不及了。

彼得: 你不能这样作弊啊,戴夫,把马特的预测直接当成你自己的。

戴夫: 我不行吗?

彼得: 不行,每个听这个播客的人都会知道的。好吧,无论如何,做好笔记。

你们准备好开始了吗?马特,我先抛出一个比较宽泛的问题。

在过去的一年里,我们听到几乎每家公司和每个 CEO 都在说:“我们要转型成为一家 AI 公司。”萨利姆,在上一期节目中,你提到:“到 2026 年,那些未能做出这一改变的企业将面临有史以来最大规模的颠覆。”亚历克斯,你使用的词是,如果不做出转变,他们就“完蛋了”(cooked)。

亚历克斯: 我是说“知识工作”(knowledge work)完蛋了,而不是知识工作者或公司。是我们目前所认知的知识工作模式将不复存在。

彼得: 啊,好的。所以你不认为那些不向 AI 转型的公司会完蛋?

亚历克斯: 我认为随着时间的推移,我们会看到越来越多的公司出现,而且会有更多规模更小的公司。

彼得: 明白。我们接下来会深入讨论这点。

萨利姆: 听着,在之前的节目中,我们指出,当你以为自己找到了产品市场契合度(Product Market Fit)并正在扩大一家 SaaS 公司的规模时,其实你已经“完蛋”了,因为在 AI 时代,一切都需要重新思考。而这种规律现在也同样适用于大公司。

彼得: 好的。所以马特,我们要开始提问了:是不是每家公司真的都能成为一家 AI 公司?该如何做?另外,你认为哪些公司和行业现在就需要自我颠覆,否则就会变得无足轻重?我先提一个轻松的暖场问题(笑)。

戴夫: 彼得,把硬骨头留给我来啃,马特。

马特: 没问题。我认为你的第二个问题在某种程度上与第一个问题有关。那就是,我认为(且目前所有关于这方面的数据也都支持这一点)并非所有行业都会受到同等的冲击。有些行业和领域会看到实质性不同的影响。比如媒体、法律服务、业务流程外包(BPO)等。在许多行业,其原有的工作结构将会发生改变。如果你想想知识工作、大量文档的制作,这些技术在这些领域是非常颠覆性的。

但与此同时,在很多行业,AI 的炒作有点过度了,比如石油和天然气,或者房地产。这些行业的底层业务功能将保持相当高的一致性。事实上,过去几年关于工作岗位动态变化的大多数优秀分析报告都指出,这一点。比如,决定购买哪栋公寓楼或哪栋写字楼的决策过程,与 5、6 年前的情况非常相似。所以问题在于,到底业务的哪些部分会发生改变?并非所有部分都会变,有些行业受到的冲击大,有些受到的冲击小。

第二部分是关于“是否所有人真的能成为一家 AI 公司”的有趣问题。

现实是,懂得如何很好地构建或部署这类模型的人其实并不多。因此,一个巨大的挑战在于:你内部是否有这种专业知识?你如何考虑调整公司的运营功能来做这件事?是让你现有的 IT 团队来做吗?特别是,彼得,我们过去讨论过的那群人,比如小企业。如果你是一家只有 50 人的公司,如果没有内部 CTO,想在大规模尺度上部署这些东西是极其困难的。因此,我认为对于那些内部没有资源的公司,他们正在寻找外部租用(rent)或购买(buy)的能力,并与能够帮助他们实现这一目标的人建立合作关系。

Tips麦肯锡 QuantumBlack Labs 及其背景

QuantumBlack 是麦肯锡在 2015 年收购的英国数据分析公司,起初专注于一级方程式赛车的数据分析。收购后,它成为了麦肯锡的高级分析和企业人工智能落地部门。马特·菲茨帕特里克曾担任其全球负责人,这使他深刻理解企业在数字化转型和数据治理中面临的实际阻碍。

Facts企业端落地速度与 AI 发展速度的剪刀差

戴夫在 2025 年底预测企业落地 AI 的速度会慢于模型本身的发展。到了 2026 年中期,这一预测被完全证实。虽然前沿实验室推出了强大的推理模型,但由于数据合规、系统集成和组织内部摩擦,绝大多数世界五百强企业仍然停留在原型测试阶段,未能在生产环境中大规模部署。

彼得: (彼得插播广告:每周,我和我的团队都会研究将改变未来十年行业的十大科技大趋势。我涵盖了从人形机器人、AGI、量子计算到交通、能源、长寿等领域。没有废话,只有影响我们生活、公司和职业的最重要内容。如果你希望我与你分享这些大趋势,我每周会写两次电子报,通过电子邮件发送简短的 2 分钟阅读。如果你想在别人之前十年发现最重要的大趋势,这份报告非常适合你。读者包括全球最具颠覆性公司的创始人和 CEO,以及构建最具颠覆性技术的企业家。如果你不想被告知未来走向、为什么它很重要以及你如何能从中受益,它就不适合你。免费订阅,请访问 diamandis.com/metatrends,提前十年掌握未来趋势。好的,现在回到节目中。)

戴夫: 我认为法律和会计是非常非常棒的案例研究,而且我知道马特对此有更深的见解,特别是结合你在麦肯锡和 QuantumBlack 的经历,你是理解和解析这一切的专家。法律和会计之所以很酷,是因为它们很容易被像 Harvey 这样的初创公司所取代。

马特: 戴夫,关于这点,我想说两件事。我认为在企业端落地生成式 AI 的一个主要挑战是,缺乏一个统计学上可验证的基准线(baseline)来进行对比。

例如,像房贷承销(mortgage underwriting)这样的业务,其实已经取得了巨大的积极进展。现在由银行开发的高效、有安全护栏的算法所处理的房贷承销比例非常高。因为银行可以进行回测并得出结论:“这是一个正确的信贷决策,没有红线偏见等问题。”

而联络中心(contact centers)之所以能成为应用最广泛的场景之一,也是因为有非常明确的基准线:比如单次通话时间、客户满意度(CSAT)、单次通话成本等。你有一套可以量化对比的指标。

但如果是生成一份“投资备忘录”这样的任务,各家公司的格式都完全不同,可能是 10 页也可能是 40 页,内容千差万别,人们很难建立起对比的基准线。

我认为这正是法律服务有意思的地方——在法律领域的某些板块,基准线非常明确,比如生成无息贷款协议(ISA agreement)等文件。但我认为未来在很多不同的细分市场都会看到这一转型。该行业的高端市场仍然会保持极高的差异化竞争力。例如,在处理大型并购(M&A)交易时,你仍然会需要顶尖律师的专业建议。真正被彻底改变的,是类似起草保密协议(NDA)这种最基础、最同质化的工作。高端的人类指导将永远存在,而基础的标准化信息工作——如今许多人为此拿着过高的薪酬——将会被重塑。

戴夫: 确实,保密协议(NDA)是一个极端例子。但我可以告诉你,在我们每年做的大量风险投资交易中,投资条款清单(term sheets)总是写着:被投资公司需要承担法律费用,上限是 5 万美元。然而,每次的交易文件几乎都一模一样,只有大概八个参数可以调整,所有的排列组合甚至能装进一个最小的 U 盘里。我不禁想,这怎么就值 5 万美元了?而且最终费用总是神奇地刚好跑到 49,999.99 美元。这简直是个奇迹!(笑)

所以,在我看来,这虽然处于难度的中等偏上水平,但依然是完全可以实现的。保密协议不用动脑,房贷申请也不用动脑。

马特: 我完全同意。不过有趣的是,像在客服中心(contact centers),实际的普及曲线其实一直相当缓慢。

客服中心原本应该有最迫切的需求——一般来说,客服中心的客户满意度很低,大部分人都不喜欢打客服电话。这种糟糕的客户体验已经持续了十年。所以你本应该期待技术能更快地普及……

彼得: 让我们来聊聊 Klarna 的案例吧。我知道你是这方面的专家。Klarna 的故事非常引人注目。你能和大家讲讲吗?到底发生了什么?

马特: 是的,我个人没有参与 Klarna 的项目,但我可以根据我阅读的资料分享我的观点和推测。简单来说,Klarna 曾宣布他们将把联络中心全面转型为端到端的 AI 智能体(agentic)运营模式。当时,他们是行业内最常被引用的 Agent 成功落地范例。

然而,仅仅 8 到 12 个月后,他们基本上宣布取消这一方案,并重新全面退回到由人类客服代理主导的模式(译者注:马特在此引述了当时行业内的部分传闻和调整)。

原有的发展过程非常有趣。因为如果你去思考如何部署这些系统,一个优秀的多智能体(multi-agent)系统应该具备对来电类型进行分流与编排的能力,并且要有一套验证机制,判断哪些通话处理得当,哪些可能存在问题,并明确在什么情况下需要升级给人类客服,在什么情况下可以直接由 AI 解决。

因此,你永远不应该走向任何一个极端——无论是完全依赖 Agent,还是完全依赖人类。无论在哪个行业、哪个主题,人机协同(Human-in-the-Loop)在很长一段时间内都会是核心模式。大模型是基于历史先例数据进行训练的,当你遇到没有先例、或者需要解决极其复杂的非常规问题时,你必须有人的参与。

所以,Klarna 这种“全人类 -> 全 Agent -> 全人类”的摇摆令人费解。从运营的角度看,最优解应当是人机混合,并根据不同主题动态调整两者的比例。

Facts克拉纳 Klarna AI 客服事件的时空复盘

克拉纳在 2024 至 2025 年间因使用人工智能客服节省巨额成本而成为行业范例。虽然马特在访谈中提到克拉纳因边界案例和客户反馈而大幅回撤,但到了 2026 年中期,实际情况是克拉纳并未重回全人类客服,而是进一步深化了人工智能原生改革,甚至计划裁减更多行政人员。这表明人工智能自动化虽然在边缘情况面临阻力,但其降本增效的长期趋势并未逆转,而是向更精细的人机协同架构演进。

彼得: 萨利姆,你有什么看法?

萨利姆: 我只是想补充一些细节。在 Klarna 这个案例里,他们上线了客服 AI,宣称在首个月内,该 AI 就完成了相当于 700 名全职人类客服的工作量,处理了每月 230 万通电话,并预计每年能节省 4000 万美元。他们非常自豪地表示,这还只是第一个月,未来只会越来越好。

当我看到这个宣传时,我觉得它更像是一个公关手段(PR exercise),而不是实际的业务现状。因为任何成熟的企业都不会在第一个月就大肆宣传,你至少会观察几个月,看看究竟会发生什么。

马特,你能提供更多细节吗?他们最终做出调整(或传出回撤风声)的底层原因是什么?是复杂的边界案例(exceptions handling)太多了?还是面临了文化和舆论的反弹?

马特: 我没有直接和 Klarna 合作,但从我听到的行业反馈来看,联络中心在落地 AI 时挣扎的原因主要有两个:

第一,在许多场景中,人类客户就是单纯想要与另一个真实的人类交谈。因此,宣传“我们正在走向完全去人化的 Agent 时代”在用户心智上是有挑战的。

第二,客服中心最敏感、最难处理的是非一线业务(non-first-line resolution topics)。例如,查询余额很容易,但如果要处理退款,就需要写入后台系统的复杂业务逻辑。Klarna 如此之快地推广这一服务确实令人惊讶,在实际运行中,一旦用户从 Level 1(初级咨询)迅速滑向 Level 2 或 Level 3(复杂纠纷)时,你绝对不会希望只面对一个机械的 AI。

企业 AI 落地的正确姿势:聚焦与 KPI 导向

彼得: 让我们回到核心问题:2026 年马上就要到了(如果你是在 2026 年收听本期节目,那它已经来了)。

如果你是一家中大型公司的 CEO 或 CTO,董事会刚刚质问你:“各位,你们的 AI 计划是什么?你们在做什么?”——这种情况我们见了一次又一次。他们的第一反应通常是什么?他们究竟应该怎么做?我想梳理出一些最底层的基本原则,以帮助我们的听众。

马特: 如果你是那位 CEO,你会面临两种不同的挑战:第一是“我应该关注什么”,第二是“由谁来做”,以及“我们内部是否具备这些技能”。

对于第一个问题,我的建议是:紧跟价值(follow the value)。千万不要采取“让一万朵鲜花盛开”(let a thousand flowers bloom)的无聚焦策略。你应当从列出清单开始,挑选出 2 到 3 个如果做好就能切实为公司业务带来决定性改变的关键环节。也许是客户服务,也许是 FP&A(财务规划与分析)中的预测,也许是库存管理。但几乎世界上任何一家公司,甚至小企业,都能找到两到三个核心的数字化突破点(数字营销通常是另一个常见场景)。

聚焦于这一到两个点,确保把它们推进到试点(pilot)阶段。这里的试点不是指写一份战略 PPT。任何在这一领域深耕过的人都会告诉你:在传统的机器学习(ML)时代,你可能需要花几个月甚至更长的时间来构建一个模型,然后才能统计学上验证其有效性;而生成式 AI 的范式恰恰相反——你可以在一个月内做出一款原型,但你必须进行大量的测试和验证才能确保你可以信任它。

彼得,我经常问的一个问题是:“你愿意拿自己的年终奖去赌这个部署的 AI 用例一定行吗?”这是一个非常微妙的问题。比如处理 10,000 个理赔评估,大多数公司脑子里根本没有概念如何验证这个 AI 系统的质量是否真正过关。

总结一下,你需要明确 2-3 个核心业务点,做出概念验证(POC),并且我强烈建议将第一个用例以 RFP(征求建议书)的形式外包给按效果付费(outcome-based)的第三方供应商。

之所以强调要找外部付费供应商,是因为如果内部团队缺乏经验,你很难以“有结果才付钱”的方式对他们进行问责。将成本与实际产出挂钩可以大幅降低企业的试错风险。

Value企业 AI 落地中的高商业壁垒:数据孤岛与业务流重构

从价值投资和企业护城河的视角来看,通用大模型正在迅速商品化。企业的真正壁垒并不是模型本身,而是对特定业务场景的深度理解、对专有数据的清洗和业务流程的重构能力。如果企业只进行无聚焦的技术尝试,而无法将技术转化为实际的成本削减或收入增长,这实际上是一种资本毁灭。

彼得: 这依然是 Invisible Technologies 的商业模式,对吧?按你们帮客户节省的资金或产出的成果来收费。

马特: 是的,我们根据成果(outcomes)收费。

彼得: 亚历克斯,我想把你拉进讨论中。

亚历克斯: 非常感谢。作为前置声明,我需要做合规披露:我在马特的 Invisible 公司中没有任何财务利益。但我确实有几个问题。

第一个问题,关于测试。我们在这期节目里经常提到基准测试(benchmarking)的重要性。既然 Invisible 正在为如此多的大模型进行训练,你认为目前世界上最需要被建立的基准测试是什么?哪些是缺失的?你最希望看到被创造出来的三大基准测试是什么?

马特: 确实,在过去几个月中,我们看到一些通用的公开基准测试受到了广泛关注,特别是像编程能力等方面的测试。我认为作为评估模型整体认知水平不断进步的指标,这些通用基准测试是非常有用的。你可以看到,在过去三年里,模型在大多数维度上都实现了 50% 到 100% 的提升。

...

亚历克斯: 听起来你的立场是,我们需要数以千计全新的、更窄的基准测试,来覆盖每个劳动力类别和每个垂直行业。这是否也是 Invisible 正在做、或者应该做的事情?

马特: 是的,我们在这方面投入了大量时间。事实上,我们构建的绝大多数内容都是为客户的特定任务定制的基准测试。我们经常思考如何测试一个特定任务的等效性。

很多人还没有完全意识到的一点是:即使你拿到了最先进的大语言模型,要想让它适配你独特的业务场景,必须用你的专有数据进行微调(Fine-tuning)。

之前很多企业抱着“买方思维”(SaaS buyers paradigm),以为自己只要买一个现成的软件就能解决所有问题——比如买一个“销售代理”(Sales Agent),接入后它就能自动帮你把货卖得很好。但现实是这几乎是不可能的。你必须在自己的特定知识语料库和信息流中训练它。我们的思路是:你拿来一个通用的 LLM,或者一个已经经过初步销售训练的 Agent,然后用你们公司的专有产品、销售方式、话风去微调它,接着针对微调后的模型建立一套评估基准(eval),来断言它是否在实际工作中表现合格。

亚历克斯: 我想追问一个问题。大约在一两年前,曾发生过著名的“BloombergGPT 事件”。彭博社当时试图与主流的前沿大模型实验室竞争,他们拥有丰富的内部专有金融数据。他们的计划是推出自己的专有垂直前沿模型,利用内部数据集进行预训练和后训练,以在金融领域实现超群的表现。

但实际发生的是:那些前沿实验室开发的通用模型,仅仅通过抓取互联网上的公开数据,在短短几个月内就彻底超越了 BloombergGPT。

这个故事的启示在我的脑海中是:在通用模型将一切降维打击之前,专有数据集和专有基准测试到底能支撑企业走多远?

马特: 我想澄清一下。我刚才所描述的过程是“将大模型用于你的特定语境”,这本质上是增加上下文信息。绝大多数机构都不应该去建立自己的大语言模型,那需要极其高昂的算力和极高难度的技术工程。企业应当做的是:将这些大型基础通用模型,尾部适配(tailoring)到自己的业务语境中。

亚历克斯: 明白。但我的问题不是机构是否应该去从头预训练模型,而是想问“后训练”(post-training,包括监督微调 SFT、强化学习微调等)是否具有长期价值?或者在 1 到 2 年后,我们是否可以直接使用前沿实验室提供的、开箱即用的通用大模型,根本不需要任何内部数据和基准测试来进行二次后训练?

马特: 我认为,企业内部的后处理层(post-processing layer)将是永远需要的。因为很多专有上下文信息,大模型是绝对不可能接触到的。

例如在律师事务所,公司对于特定类型的并购(M&A)协议有自己独特的设计要求和历史文档,通用模型没有这个数据。因此,你必须在企业端部署一个后处理层。我们现在看到越来越多的企业在这样设计系统——将这一层与底层的大模型解耦,这样一旦底层模型迭代升级,他们可以轻松把新模型“掉包”替换进去。

萨利姆: 事实上,随着时间的推移,这种独特的专有数据边缘(edge in data)将成为任何公司最核心的价值所在,也就是所谓的商业机密(trade secrets)。当然,这些数据也有可能泄露到公共模型中……

戴夫: 比如你使用了 OpenAI 的 API(笑)。

萨利姆: 是的,如果你把所有数据都传到这些前沿模型中,你的专有资产就会直接飞上云端。这是非常危险的。我们必须构建一层强大的保护屏障。我的一个预测就是:未来在企业专有数据与公共 AI 世界之间,必须出现一层坚固的安全防护层(protection layer)。

Inverse数据出域与主权隐私的物理墙

将数据通过接口发送给第三方模型开发商,会使企业面临数据泄漏和丧失竞争优势的风险。逆向思考告诉我们,这种中心化云端模型的发展存在制度和物理上限。这为本地化部署的轻量级大模型以及安全的本地数据处理服务创造了永久性的防御性市场空间。

隐形科技(Invisible Technologies)的企业落地案例

彼得: 马特,我想让讨论更具体一些。我知道你不能透露你们与那些超大规模云服务商(hyperscalers,译者注:指微软、谷歌等 LLM 开发商)的具体合作细节,但你提到了五六个可以公开分享的客户案例。如果你不介意的话,我们能聊聊这些具体案例吗?

顺便说一句,既然亚历克斯做了合规声明,我也声明一下:我是 Invisible 的骄傲顾问和投资人,我以一种非常积极的方式支持马特和弗朗西斯。马特,你想先挑哪一个案例?我个人非常喜欢篮球场的那个例子,能和大家讲讲吗?

马特: 好的。我们与夏洛特黄蜂队(Charlotte Hornets)合作,为他们的选秀选材(draft prep)微调了定制的计算机视觉模型。

在黄蜂队的场景中,他们希望在非常广泛的尺度上,通过大学联赛和国际赛事中的单点位摄像机画面,分析球员在球场上的空间移动模式(spatial movement patterns)。为此,我们微调了一个定制的计算机视觉模型,专门识别他们感兴趣的动作特征,这成为了他们选秀前评估球员的关键部分。

彼得: 翻译成大白话,就是你们利用 AI 模型去评估视频里每个球员的表现?(我不是个体育迷,所以……)

马特: (笑)嗯,这点在你的提问里表现得挺明显的。

戴夫: 没错。(笑)

马特: 简单来说,传统的 NBA 数据只关注统计指标,比如得分、篮板以及所谓的正负值(plus-minus,即球员在场时球队的净得分)。但这些都属于“结果性”数据,无法捕捉球员在场上的动态行为——比如谁擅长创造空间,谁在特定时间点的站位最合理。

这正是最有趣的数据所在。就像当年比利·比恩(Billy Beane)在奥克兰运动家队对棒球数据分析(Moneyball)所做的变革一样,核心在于空间排布和移动模式。以前有一些公司在标准化球场(比如装有固定追踪设备的球场)做类似的事情,而我们能够做到的是:针对不同的拍摄角度、不同的场馆画面,利用计算机视觉快速输出分析结果。

彼得: 黄蜂队是如何利用这个结果的?选人还是选秀决策?

马特: 选秀选材。用于理解哪些球员具备他们所需的空间运动特质。

彼得: 太不可思议了。

戴夫: 这是一个非常复杂的问题。因为球员之间的化学反应(chemistry)也很重要,这不仅是挑出最强的个人。这个案例很有意思。

加文·贝克(Gavin Baker)最近提到,现在全美各地的“幻想橄榄球”(fantasy football)联盟里,很多老玩家都在输给 AI 智能体。因为 AI 能够追踪更庞大、更细微的数据,比如一个球员往返球场时的步频降低了,普通人根本不会注意,但 AI 能在瞬间察觉并将其纳入模型中。

这真的很酷。马特,你刚才问传统企业应该如何考虑落地 AI,我再给你分享一个有些不同的案例——Lifespan MD。彼得,这个案例应该会引起你的共鸣,它是一家高端定制医疗(concierge medicine)机构。

彼得: 我知道, Chris 在管理它。

马特: 是的。Lifespan MD 在全美及海外拥有一套诊所网络,每家诊所都掌握着患者各自不同的医疗数据。

在开展任何 AI 落地工作时,我一直强调:必须先解决数据问题。在引入 AI 之前,你必须确保所需的结构化和非结构化数据已经就绪。

我们为他们做的一件事是:在我们的 Neuron 数据平台上,为他们构建了一个符合 HIPAA 医疗合规的多租户云实例,将所有相关的患者与医疗提供者数据整合在一起,形成对患者和诊所的 360 度全景视图。

有了这个基础,你就可以开始做很多有意思的分析。比如:哪些针对长寿(longevity)的检测在 35 到 50 岁的男性患者中最常用?哪些诊所的运营效率更高?哪些患者可能存在合规性问题(比如没有按医嘱服药)或互动度不够?它有效充当了一个掌控全域的控制塔。

在此基础上,生成式 AI 的价值体现在:构建聊天 Agent 和知识管理系统,允许医生直接对所有诊所的底层核心数据进行提问和交互。

这里最大的难点在于医疗行业的合规性——你必须非常小心,明确哪些患者数据应该保留在诊所本地,哪些可以汇总到中央。因此,这个 HIPAA 合规的多租户云实例非常关键,它确保了患者数据绝不出诊所的本地物理边界,同时又让医生能够获取必要的数据进行统计分析。

戴夫: 我这周听到一个非常酷的事情。一家 QA 软件公司发明了“与你的 Bug 对话”的功能。你可以直接询问 Bug 本身:“你是在哪段代码里产生的?”这太酷了。

我也完全能想象在医疗领域实现“与你的疾病对话”。你可以跟自己的病痛聊天:“你从哪里来的?我该怎么治疗你?如果我吃这个药,你会变好还是变坏?”然后疾病用一种特定的声音回答你,这简直是史上最酷的想法!

马特: 这确实很神奇。和 Bug 对话挺好,但是和体内的细菌对话感觉还是有点奇怪……

戴夫: 比如给它配一个伏地魔的声音:“告诉我,怎么才能杀死你?”(笑)

马特: 戴夫,关于医疗,我想补充一点。经常有人问我,这个行业会如何演化?我认为“AI 是否能直接代替医生做治疗决策”依然是一个很模糊且敏感的问题。但一个更清晰、更容易落地的突破点是行政成本的削减。

美国在医疗上的人均花费大约是每人每年 13,000 到 14,000 美元,而加拿大或德国只有 2,500 到 3,000 美元。美国这笔巨额开支中,有 30% 到 40% 是纯行政管理成本(admin cost)。

这是没有任何人愿意承担的无意义损耗。Lifespan MD 的实践方向并不是要改变诊疗标准,而是为了让医生更加专注,将那些繁琐的行政事务、表格填写和日程调度完全剥离出来,交给 AI 处理。AI 将在这些繁琐的后台行政领域大显身手。

彼得: 那么你认为中大型公司真的有干净的数据吗?他们要花多长时间才能把数据整理成高保真且有用的格式?这是一个艰难的过程还是一个容易的过程?

马特: 这取决于你采取什么范式。如果你的想法是“我要把所有的专有数据放进一个数据湖,并把所有的架构理顺”,那可能会花上 5 年时间。实际上大部分大公司都花了半个十年试图把他们主要的数据模式搞规整,但仍然以失败告终。然而,如果你从具体的用例出发:“做这个具体的信贷决策,我需要什么数据?”你通常只需要围绕这个信贷本身、市场以及公司核心财务状况的 5 到 6 个核心数据变量,而不需要让整个商业银行的每一个表都完美无缺。专注于特定用例的数据整理,成功的概率要大得多。

此外,对于生成式 AI 而言,许多最重要的数据是非结构化的(图像、视频、文本文件),而不是传统系统记录的表格数据。因此第一步是定义好问题,然后理清该问题所需的局部数据。

戴夫: 没错。我今天早上刚开完一个长会。我们投资的一家非常AI超前投资的组合会计公司叫 Vestmark。在账户核对(account reconciliation)中,数据是海量的,但数据并不会记录“操作人员实际做了什么”。现在的成功路径是,首先让 AI 协同工具帮助他们度过一天的工作,并在后台记录下他们的实际操作。这些累积下来的行为数据就是未来 RLHF 和微调(tuning)大模型的专有资产。很多银行或保险公司的高管会说:“我们的数据是优势,直接倒进神经网络训练吧!”这简直是胡扯,纯粹是一堆毫无逻辑的表格和杂乱文件,塞进去只会得出令人崩溃的幻觉。

萨利姆: 此外,你还会遇到各种组织壁垒。我曾与一家全球最大银行的 CIO 交流,他们内部竟然有 300 个不同的客户数据库!房贷部门一个,车贷部门一个……而且房贷部门的数据绝不肯共享给车贷部门,他们像守护领地一样防范彼此。这对于可怜的 CIO 来说简直是场灾难。

递归学习与人机协同的终极辩论

彼得: 极具启发性。亚历克斯?

亚历克斯: 我觉得这些点都非常有趣。如果我可以冒昧的话,我想把讨论提升几个高度,谈谈 Invisible 的商业模式。

根据我的理解,马特,你们的业务中有一个部分(我记得叫 Meridial,译者注:即 Invisible 的大模型数据训练外包平台),它本质上是一个机器学习自由职业者(ML freelancers)的交易市场。

我好奇的是:在当前的 AI 行业中,一个被选择性忽略的“房间里的大象”(elephant in the room)是我们正处于“递归自我提升”(recursive self-improvement)的边缘。几乎所有的前沿模型实验室都会同意,我们正在逼近一个临界点——你只需要把计算资源交给一个“AI 研究员”(AI researcher)智能体,它就能做得和实验室里最优秀的人类 AI 研究员一样好,甚至更好。

如果事实确实如此,那么对于一个依赖机器学习自由译员来训练模型的市场(如 Meridial)来说,当 AI 研究员本身就可以为每个客户构建定制模型、专有数据集和专属基准测试时,这个市场的需求难道不会彻底蒸发吗?

马特: 对我们而言,我们业务有两块:一块是 Meridial(大模型训练),另一块是面向企业构建定制化应用。

过去五年里,行业内一直有一种观点,认为在某个时间点,我们将不再需要人机协同的强化学习(RLHF)来验证和测试模型。

我认为这种逻辑忽略了几个现实: 首先,在语言、多模态以及像计算生物学等前沿专业领域中,推理任务非常复杂。许多研究表明,将合成数据(synthetic data)与人类真实数据结合使用效果最好,你依然需要在每个应用端引入人类的验证反馈。

其次,RLHF 的性质正在发生根本性的变化。我们正在从简单的“标注猫狗”这种同质化劳动,转向所谓的“RL Gym”(强化学习体育馆)、受控模拟环境。现在我们平台上的专家很多都是博士和硕士。如果你要训练一个模型去识别“17 世纪法国建筑在法语语境下的演变”,你仍然需要顶尖的专家来进行 RLHF 验证。随着模型向更专业的深水区迈进,对高质量、专业化人类反馈的需求反而在呈指数级增长。

TipsInvisible Technologies 的“数字装配线”与人机协同

“数字装配线”是隐形科技的核心运营概念。它将复杂的企业任务拆分为微小步骤,通过软件自动流转,并在关键节点引入人类专家进行质量校验和数据微调。这种模式有效解决了纯软件自动化易出错和纯人工成本高昂的痛点,是生成式人工智能时代数据标注与业务落地的关键基础设施。

亚历克斯: 这很有意思。我想分享一下我的直觉,并听听你从实际一线业务中看到的真实情况。

我的直觉是,我们正在看到越来越高的“数据效率”(data efficiency)。RLHF 在过去三年里确实非常流行,甚至可以说经历了“过度炒作的顶峰”。但随后我们看到了强化微调(reinforcement fine-tuning)等机制的崛起,它们在数据和人类时间的使用效率上高得多。如果你只需要构建一个强化学习环境,这从人效比(human hour involved)来看,显然比在发展中国家雇佣大量人员来做猫狗标注(或者 SFT)要高效得多。

因此,即使你的假设成立——即我们迎来了高度垂直的任务细分,每一项都需要手工标注——但算法的进步(如强化微调)带来的效率提升,会极大稀释对人类标注的依赖。你对此怎么看?

马特: 过去五年里人们一直在讨论这个趋势。但根据我们在最前线的实际观察:要想达到企业级的准确率并控制大模型的幻觉(hallucinations),人机协同(Human-in-the-Loop)在很长一段时间内依然是不可或缺的刚需(feature),而不是暂时无法解决的缺陷(bug)。

很多人被带进了一个误区,以为企业级 AI 可以实现 100% 自主运行且无需人类监管。实际上,随着任务越复杂,你在每个关键步骤中需要的“人类阀门”就越多。

后训练(SFT/RLHF)只占整个大模型开发计算成本中极小的一部分,但它带来的安全性与业务对齐价值却是最高的。比如在法律服务中,你要训练一个能够评估并购协议的 AI,你需要真正优秀的人类律师参与,来测试 AI 产生的结果是否真正达到了人类资深合伙人的水平。

也许在 10 到 15 年后,我们会彻底耗尽能用于训练的新内容。但在那之前,还有多语言、多模态、机器人技术(Robotics)、模拟环境等无数前沿需要攻克,对专业人类反馈的需求依然无比庞大。

彼得: 亚历克斯,你是认为这些智能体的智能水平在跨越 AGI 并走向 ASI(超人工智能)时,将能像人类一样解决所有问题,从而彻底消灭人类阀门?你的时间表是怎样的?

亚历克斯: 这正是我的核心观点,彼得。如果让我给出一个粗略的预测时间表(当然,这不是我们的年度预测专题节目,别太较真):

我认为最保守的外包边界是,在未来两到三年内,我们将拥有在构建 ML 模型上与人类研究员同等甚至更强的 AI 研究员。这是两到三年的上限。

但我完全赞同马特的另一个观点:2026 年将是“递归自我提升”(recursive self-improvement)能力疯狂指数级增长的一年,同时也是企业端落地“慢如蜗牛”的一年。由于数据孤岛、合规和组织官僚,大模型的威力会在企业端遭遇严重的堰塞湖(log-jammed),这会让谷歌和 OpenAI 感到无比沮丧。而像 Invisible 这样的公司,本质上充当了企业与先进技术之间的“润滑剂”(lubricant)。

再回到客服电话的例子,在我们的测试中,80% 的用户非常喜欢 AI 客服;但剩下的 20% 极其反感它的用户,其愤怒情绪足以把整个项目折腾死,迫使公司撤回整个系统。

Facts2026 递归自我提升与大模型演进的现实

亚历克斯关于 2026 年是递归自我提升爆发之年的预测得到了印证。以强化学习为驱动的推理技术在推理阶段进行多步骤链式思考,极大提升了模型的复杂问题解决能力。但在商业端,由于数据质量和流程治理的滞后,这种模型能力与实际商业产出之间仍存在明显的落后差。

戴夫: 确实,有些问题是谷歌和 OpenAI 解决不了的,这需要非公开的、不在通用训练集里的专有数据。如果两年前你告诉我,全世界所有的出租车司机都会知道 RLHF 是什么,或者世界上会出现靠提供 RLHF 赚大钱的几十亿美金的巨头,我一定会觉得你在胡说八道。但现在这不仅发生了,而且规模极其庞大。

到 2026 年,一定会出现很多新名词来描述企业在应用 AI 时遇到的各种瓶颈(比如为什么银行不用、为什么医院不用)。这些瓶颈在客观上为 Invisible 这样的公司创造了极其丰厚的商业机会。

马特: 是的,这非常有趣。2026 年将是这两种路线(是依靠通用大模型自我迭代,还是依靠超专业化的人类专家标注)正面交锋的拉锯战。

亚历克斯: 戴夫,你切中了要害。我并不是在质疑监督微调或 RLHF 的价值,我真正关心的是:在不久的将来,大模型通过“自我引导”(bootstrapping)可以解决其中多少工作,又有多少必须依赖人工输入?

我们需要平衡好“通用性”与“超特定性”之间的关系。对于通用模型,我认为 RLHF 确实不那么重要了。但在面对具体的企业任务(例如生成 10 页的保险理赔备忘录)时,你必须进行人类等效性测试。因为大语言模型本身并没有关于你们公司特定理赔业务的任何先验数据,这部分测试必须由人类来定义基准。

亚历克斯: 马特,你是否同意,随着时间的推移,即使是这些高度专业的细分技能,最终也会被越来越强大的通用模型所吞噬?还是你认为这永远不会发生?(在 10 到 15 年的长期尺度上)

马特: 我不认为所有专业的技能都会消失。因为很多领域最核心的经验和诀窍,根本没有任何公开的可供训练的数据。它们只存在于专家的脑海和经验中。

我们坚信人类的温度和触觉会变得越来越重要。以销售为例,现在市面上有 500 家公司在推销基于 AI 的自动化邮件开发工具(SDR)。但在一个每个人每天都会收到 50 封 AI 垃圾邮件的世界里,真正有温度的人类面对面沟通反而变得更加难能可贵。所以,我认为专业技能的价值在许多领域会不降反升。

另外,从实际的推广曲线上来看,我们虽然已经进入 AI 时代四五年了,但在全美数千家联络中心里,真正完全迁移到使用 AI 客服的比例依然微乎其微。

戴夫: 我想问一个关于 Jane Street(简街资本)的问题。很明显,在金融交易和选股(stock picking)领域, AI 正在以光速推进。

因为在交易领域,这里没有任何物理屏障或行政阻力。下单是完全数字化的,而且回测极其容易,能赚更多钱就是硬道理。所以金融量化成了 AI 发展的风向标。

萨利姆: 是的,而且公开股票市场的大部分交易量很久以前就被算法主导了,这在几十年前就发生了。

戴夫: 没错,这起源于高频交易,量化团队早已就位。现在它正在向基本面分析(fundamental analysis)演化。这就是为什么金融领域跑得最快。

但在非金融的领域(比如你是一个修理汽车的技工),你诊断汽车故障时需要音频、传感器数据,这同样是个很好的 AI 用例。

然而,你会愿意把你的诊断数据通过 API 传输给 OpenAI 吗?如果 OpenAI 以后决定自己开一家修车厂,它不就直接继承了你所有的专有技术?因此,企业是会选择把数据送上云端,还是会使用某种物理隔离的“私有化模型”(walled-off model)?

Jane Street 绝对不会把他们的专有交易数据拱手送给 OpenAI。那么介于两者之间的中层企业——银行、保险公司、医院——他们该如何抉择?在 2026 年,利用 API 做这件事在技术上变得极其简单,但由于数据主权和竞争优势,他们根本不想把核心资产送到云端 API 里。

马特: 是的。在很多高度敏感的行业(如银行、医疗),很多企业已经决定将数据保存在本地(on-premise),或者专门使用小语言模型(SLMs)。

我认为这一趋势将继续延续。企业也需要做好资产的分类:并非所有数据都是敏感的机密。例如,Jane Street 的高频交易策略是绝对机密,但他们后台的日常财务预测和报销数据则不然。因此,企业需要理智地区分“核心专有资产”和“通用业务流程”,而不是走向另一个极端——因为害怕泄露而完全拒绝使用云端大模型,将自己完全孤立起来。

从“电视里的收音机”到“AI 原生”业务重构

萨利姆: 我想稍微调整一下讨论的方向。

我同意自动化是未来,但我认为自动化的发生方式与我们刚才讨论的有些不同。让我举个例子:假设我是佳能(Canon),正在销售家用打印机。目前,我有很多人在做市场营销、内容开发、品牌管理,还有销售人员负责卖给百思买(Best Buy),还有线上人员,购买后还要引导客户注册打印机,接着是售后维修技术人员,最后是公司的会计人员。在现有的组织架构中,你在不同的环节雇佣了不同职能的人。

如果我要建立一家“AI 原生”(AI-native)的打印机销售公司,我可能会考虑将所有这些职能完全用 AI 替代。这样,公司就不再是“以人为中心”,而是“以功能为中心”进行连接:打印机在墨水用尽时能自动上报并触发物流配送;当机器出现潜在故障时会自动报警,并提示售后团队“嘿,也许我们现在可以给他推荐升级一款新打印机”。你基本上通过 AI 实现了核心功能链的闭环自动化,从而将人类从 90% 的日常流程中彻底解放出来。

然而,我们现在看到的做法,就像我常说的“在电视里播收音机”(radio over TV)——当电视机刚被发明时,人们直接把电台播音员拉到镜头前,让他们照着广播稿读,完全没有适配新媒介的特点。目前大多数企业做 AI,只是在用 AI 机械地替代现有的员工正在做的具体动作,而不是从底层的“功能流”(functional flow)出发,重新设计一套无需人类参与的 AI 原生流程。

当然,前提是未来还有人需要打印(笑)。

戴夫: 谁还会去打印?不过我们先把这个现实问题搁在一边。

彼得: 我认为你逆向思维完全正确,萨利姆。这就是年轻的 AI 原生初创公司能够重新想象整个行业的原因,因为他们没有任何历史包袱,也没有组织摩擦。

正如马特在开头所说,大公司的优势在于“分销渠道”(distribution)。因此,大型传统企业要想生存,最聪明的办法其实是去投资那些外部创业者。我们经常探讨:如果我是一家大公司,不知道该怎么做,我可以直接举办一场创新大赛,邀请全球的年轻 AI 创业者来提案:“如果让你颠覆我们公司,你会怎么做?”给他们提供资金支持和我们宝贵的内部数据,让他们在边缘(edge)去 disrupt 我们。最终,当我们发现某个方案可行时,直接将其收购或控股,让其成为我们公司未来的核心。这就是“边缘创新与核心替代”的经典战术。

Inverse“电视里的收音机”:企业 AI 转型的路径依赖与伪创新

萨利姆指出的现象揭示了企业转型的路径依赖。仅仅用人工智能去提升现有岗位员工的效率,只是在旧有框架下的修补,并没有真正释放新技术的潜力。真正的技术变革需要彻底打破旧有职能部门的划分,从功能流的角度重构整个业务逻辑,虽然这会在组织内部遭遇巨大的政治阻力。

彼得: (本期节目由 Blitz C 赞助。Blitz C 提供具有无限代码上下文的自主软件开发。Blitz C 使用数千个专业 AI 智能体,它们可以思考数小时,以理解包含数百万行代码的企业级代码库。工程师在每个开发冲刺开始时使用 Blitz C 平台,输入其开发需求。Blitz C 平台提供开发规划,然后为每项任务生成并预编译代码。Blitz C 自主交付 80% 或以上的开发工作,同时为完成冲刺所需的最后 20% 的人类开发工作提供指南。当企业将 Blitz C 作为 IDE 之前的开发工具,并将其与自选的编程协同工具(Coding Co-pilot)结合使用时,工程效率提升了 5 倍,从而将 AI 原生软件开发生命周期(SDLC)引入其组织。准备好将您的工程效率提升 5 倍了吗?访问 blitzee.com 预约演示。)

为什么 95% 的企业 AI 模型无法上线?

萨利姆: 如果你是一家中大型企业,在 2026 年,你必须采取行动。你面临着来自董事会、股东和竞争对手的巨大压力。

从马特刚才的分享中,我总结了以下几个核心步骤:

搞干净你的数据,确保了解公司的实际数据资产现状。
选择 2 到 3 个核心业务场景(建立定制评估/基准测试),进行概念验证和实验。不是提方案,而是马上去跑。
一旦验证成功,迅速向这些确实见效的用例倾斜资源,并将成功经验向公司核心业务板块辐射。

马特,你怎么看?请帮我们梳理更多具体落地的步骤。

马特: 既然我们讨论了模型的巨大进步,也讨论了重组一家 AI 原生公司的无限潜力,那么这里有一个必须回答的灵魂拷问:

为什么最近 MIT 的研究报告显示,企业开发的 AI 模型中,最终只有 5% 能够真正进入生产环境(production)?

面对如此高涨的技术热情,落地为什么还这么艰难? 答案是:瓶颈根本不在于底层技术,而在于数据准备度、业务优先级的聚焦,以及最关键的——推进这些项目的组织架构(organizational structure)。

我给所有企业领袖的核心建议是:千万不要把 AI 落地项目放在技术部门(IT/Technology department)!

你应当挑选你公司最优秀的运营专家(operator),给他们分配明确的业务 KPI(如客户满意度 CSAT、单次通话时长、库存周转天数、缺货率等),并让他们以此为导向全面主导 AI 落地。以业务结果为唯一准绳,你才能真正取得进展。

过去大多数企业的失败模式都是:让一千个想法野蛮生长,没有任何一个项目背负具体的业务运营 KPI,最终所有的 AI 试验都沦为了只烧钱不产出的“科学实验项目”(science projects)。

Value组织架构阻力与 5% 生产环境转化率的底层逻辑

只有 5% 的企业模型能进入生产环境,这一数据的本质在于资本分配和组织权责。传统的网络技术部门通常是成本中心,关注安全与合规,缺乏推动核心业务变革的动力。只有将项目主导权交给背负具体经营指标的业务运营主管,并以实际商业成果作为问责依据,才能突破这一落地瓶颈。

彼得: 没错,这太准了。如果你走进一家公司说:“我免费送你 100 万个天才,随便让他们做点什么。”最终一定会以失败告终。因为你没有想清楚具体的业务痛点,只是想让鲜花盛开,却不提供明确的生长方向。我见过太多这样的悲剧,令人痛心。

萨利姆: 我们的建议甚至更激进:不仅要交给运营人员,而且要将这个团队直接剥离出原有的母公司组织,把他们放到业务的“边缘”,让他们在完全不受内部官僚机制和陈旧规则束缚的净土上,从头构建这套系统。否则,这个项目迟早会被母公司的利益纠葛和遗留体系(legacy constraints)活活拖死。这不应该是传统的“技术部门孵化”,而应当像苹果当年开发麦金塔(Macintosh)团队那样,作为一支特种部队在边缘颠覆核心。

彼得: 苹果确实是这方面的绝顶高手。他们会组建一支非常精悍的秘密特种部队,放在公司的边缘,保持隐蔽和潜行状态,并对他们说:“去颠覆下一个行业(无论是手表还是零售)。”他们会极其耐心地进行迭代。

我认为这正是未来很多公司需要效法的模式。因为大公司虽然在其主营业务上难以自我革命,但他们对上下游和相邻行业的业务洞察是极其深刻的。他们可以利用这种认知在边缘孵化 AI 原生的初创企业,去侵入和颠覆他们邻居的领地。

马特,在聊到 2026 年预测之前,你能再分享几个好玩的应用案例吗?

马特: 好的。我们曾与 SAIC Vantour 以及美国海军(US Navy)合作,为水下无人潜航器(UUV)和无人机集群的协同作战构建决策智能系统。

想象一下,你有一组水下无人机,每台机体上都装有大量的传感器,你需要实时理解并编排这些不同机体的空间移动模式。当它们在水下发现目标时,应当战术撤退,或者与其他机体协同包抄?我们为其微调并训练了决策模型,分析处理庞大的运动轨迹和传感器数据。由于无人机在海战中必须具备极高的自主决策能力,在如此复杂的物理环境中实现协同非常具有挑战性。

另一个更贴近日常消费品领域的案例是瑞士军刀行李箱品牌 Swiss Gear。

和许多传统企业一样,Swiss Gear 内部拥有数量极其庞大的不同数据表(涵盖产品、客户、供应链等),导致他们根本无法做好精准的库存预测。

我们使用 Neuron 数据平台,在几个月内快速打通并整合了 750 张分散的数据表,重新设计了他们的库存预测逻辑,重点优化两个目标:最小化缺货率(stock outs)与最大化资金占用效率。

对于中小型和大型企业来说,如果能把库存预测做好,价值是无可估量的——它意味着直接减少收入流失,同时大幅降低积压资金。特别是当你的供应链采购周期长达 6 到 8 个月时,预测的难度极高。我们最终帮助他们将整体库存预测的可靠性覆盖率提升了 30%,并将能够进行可靠预测的 SKU 数量翻了一番。而这整个项目的交付仅用了几个月。

展望 2026:企业 AI 的三大前沿预测

彼得: 精彩的案例。在本周晚些时候,我的登月伙伴们将和我一起录制我们专属的“2026 年预测专题”。我们会邀请 Emad(Stability AI 创始人)回归,每人提出两个关于 2026 年的重磅预测。我们会发起听众投票,看看谁的预测最准(当然,大家肯定都会投给亚历克斯的,哈哈)。

马特,先跟我们剧透一下你对 2026 年的一些核心预测吧。

马特: 好的,我们团队最近刚刚完成了一份关于 2026 年趋势的深度研究报告。我不剧透全部,但可以和大家分享最核心的三个趋势:

第一是多智能体协作网络(Multi-agent teams)。在企业端落地 AI 时,你不再需要一个无所不能的超级模型去包揽所有业务决策。你会为特定的小任务训练特异性极高的 Agent(比如专门负责合规校验的 Agent、负责数据富化的 Agent),并由一个大语言模型担任“编排者”(orchestrator)。这种架构能够极大提高特定任务的准确率,并利用 LLM 的逻辑能力进行统筹。我们已经看到了很多成功客服中心的绿芽(green shoots)在采用这一方案。

第二是多模态交互的爆发(Multimodal leap)。视频、图像、特别是音频(Audio),将成为人机交互的绝对主流。未来的交互将不再局限于冷冰冰的文本框,人们会以非常自然的语音、视觉等方式与大模型对话。2026 年将是多模态体验真正走向大众的黄金时代。

第三是强化学习竞技场与镜像世界(RL Gyms / Mirror World)。这指的是为软件系统、机器人、甚至生产线构建仿真环境和数字化双胞胎(digital twins)。在将 AI 代理或系统推向物理世界之前,你可以在这个虚拟竞技场里进行数百万次的模拟对抗和调试,大大降低真实环境中的出错风险。

彼得: 亚历克斯,对于马特的预测你有什么看法?

亚历克斯: 我认为这里最核心的拷问在于:人类的专业技能究竟还有没有未来?如果有,它的半衰期(half-life)是多久?还是它真的彻底完蛋了?

我想把这个问题抛给马特:在今天所有的职业类别和人类专长中,你认为哪三个职业会是最后被 AI 攻破、坚持到最后的“幸存者”?

彼得: 最后一个坚守阵地的人类专家,哈哈。

马特: 我还是坚持我刚才的看法。很多悲观的自动化言论忽略了工作在当今社会的实际物理和社会属性。

首先,像石油和天然气行业中的地质和地震分析工程师,以及那些在钻井平台一线操作的物理工人,他们的工作有着无法被纯数字模型替代的物理交互和现场经验。

其次是高档房地产经纪人等依赖人际信任和高端社交关系的职位。你可以列出很长一串名单。

媒体是另一个很有意思的例子。五六年前,大家觉得传统媒体快完蛋了,但现在我们看到 Substack、Medium 等创作者经济平台的崛起,诞生了海量的媒体创业者。虽然资金的流向和媒介的形态改变了,但它并没有导致总体就业人数的减少。

历史经验告诉我们:在过去 100 年的美国社会中,约有 25% 的高中毕业生,最终所从事的职业在他们读高中时根本还不存在。人们会主动利用新工具去创造新的职业需求。

《华尔街日报》前几周报道了一个惊人的数据:目前美国有 20% 的就业岗位属于“数字生态系统相关工作”(digital ecosystem jobs),甚至有高达 9% 的美国系统公民是全职或兼职的“社交媒体影响力创作者”(social media influencers)。这在 20 年前是完全不可想象的。因此,工作的本质在不断进化。

彼得: 我想你说的最后留存的电工和水管工,在不久的将来也会面临人形机器人(humanoid robots)的竞争(笑)。

亚历克斯,迅速说出你认为的“最后三个坚守阵地的人类角色”是什么?

亚历克斯: 我有三个相互竞争的假说:

第一个假说是政治家(Politician)。因为他们是制定规则和法律的人,只要人类社会存在,规则的最终话语权就会被人类牢牢把持。

第二个假说是顶尖智力创作者,比如物理学家和数学家。虽然我们在节目里经常说,科学和数学的边界正在被 AI 快速推平,但这些领域代表了人类心智能力的最高结晶,最伟大的大脑将是自动化浪潮的最后一站。

第三个假说是兜售“人类真实性”和审美话语权的人(Tastemakers / Authenticity)。这与能力无关,而是源于消费者的心理偏好——人们天然渴望知道交互的另一端是一个拥有真实体温和灵魂的同类。因此,那些高度强调人际信任、真实温度和独特品味的职业将永远存在。

Inverse“最后的人类”:真实性溢价与物理墙的终极对决

随着认知类劳动的边际成本趋近于零,经济价值将向两端转移:一端是难以被数字模型替代的物理世界工作(如电工、数据中心维护),另一端是强调人类真实情感和审美偏好的领域(如艺术策展、深度社交关系)。在全自动化时代,能够传递人类真实温度和信任的互动反而会获得更高的溢价。

彼得: 这与迈克尔·塞勒(Michael Saylor,MicroStrategy 创始人)在游艇落日派对上和我们探讨的观点如出一辙。谢谢你,亚历克斯。

萨利姆,你有对马特的结语提问吗?

萨利姆: 你们之前做过不少政府项目。在政府职能(government functionality)中,你认为 AI 能带来的最大自动化、效率提升和改造成果会在哪里?

马特: 答案是:所有地方。

我认为这可能会成为对人类社会最积极的变革之一。我最近看到一份研究报告,利用 AI 辅助进行行政许可审批(permitting),能将能源和数据中心项目的落地周期缩短 50%。

再比如住房问题。目前美国新房建设的最大阻碍就是各种官僚主义的“邻避效应”(NIMBY)监管,不同地区的分区法和建设合同极其复杂。经合组织(OECD)的报告指出,AI 可以将公共部门在许可证发放、社会福利审批和合规监管等方面的处理周期缩短 70%,从而大幅加速基础设施的建设。在公共治理领域,利用 AI 优化项目管理和公共支出流向,将为全社会释放巨大的效率红利。

彼得: 提得好,萨利姆。戴夫,你来提最后一个问题吧。

戴夫: 我有无数个问题,但我只挑最精彩的。第一,马特,一年后的今天,网络上关于你的长视频内容,会比一年前增加多少倍?(笑)因为我们几周前在利雅得刚见过面,我知道你绝对是解决“AI 落地企业瓶颈”这个行业核心命题的思想领袖。以前网上只有你在 CNBC 或彭博社的 5 分钟快节奏访谈,而今天在我们的播客里,我们能听到你最深邃的完整思考。一年后我们能看到多少个小时关于你的深度探讨?

马特: 在 12 个月前,我几乎没有接受过任何媒体采访。过去的一年对我来说是一次非常有趣的经历。我非常喜欢播客这种长音频格式,因为它能让你充分展开那些非常复杂的商业和科技话题。希望明年能带给大家更多有价值的分享。

戴夫: 我希望能看到 10 倍以上的爆发。我的第二个追问是:你认为你的“AI 虚拟分身”(avatar)在 2026 年能上线吗?

马特: 是的,大概率会在 2026 年发生。基于我所有的公开演讲和言论去训练一个我的数字分身在技术上并不难。事实上,我们目前正在体育领域开展虚拟分身(avatar training)的研发工作。我认为未来的交互将不仅仅是文字对话框,人们会非常渴望通过虚拟分身与他们熟悉和信任的行业专家直接交谈,这会成为社会的一种新常态。

彼得: 戴夫,你怎么知道坐在你面前的马特现在不是一个虚拟分身呢?(笑)

戴夫: 问得好。(笑)

萨利姆: 看起来还是挺真实的,我不太确定。

马特: 最优秀的虚拟分身往往就是真假难辨的。

彼得: 马特,大家怎么找到你?怎么找到 Invisible?什么样的企业应该联系你们?

马特: 我们目前在全球有七个办公室:纽约、旧金山、奥斯汀、华盛顿特区、伦敦、波兰和巴黎。我就在联合广场旁边的纽约办公室里。

如果收听节目的中大型企业或跨国公司的领袖,明知 AI 能为你的公司带来巨大的效率飞跃,却在实际落地、数据打通、工程实施和团队变革上感到挣扎,那么 Invisible 就是你的最佳选择。

正如亚历克斯所言,过去几年技术的发展已经完成了决定性的跃升,但最难的瓶颈依然在变革管理、业务实操、指标追踪和质量评估。

我们创始人 Francis 曾比喻道:现在市面上拥有制作蛋糕的所有原材料,但你手里并没有一个成型的蛋糕。而 Invisible 的工作就是 bake the cake。我们为你把蛋糕烤好,做真正有结果的 AI(make AI work)。

彼得: 太棒了。网站是?

马特: invisibletech.ai

彼得: 好的,非常感谢你,马特。萨利姆、戴夫、亚历克斯,几天后的“2026 预测专题”见。记得准备好你们最精彩的观点!

亚历克斯: 我们需要为预测建立一套基准测试(笑)。

彼得: 那是你的工作。祝大家今天愉快!

彼得: (彼得结语:每周,我和我的团队都会研究将改变未来十年行业的十大科技大趋势。我涵盖了从人类智能机器人、AGI 到计算科学、交通和能源等。如果没有废话,只有影响我们生活的最重要内容。免费订阅,请访问 diamandis.com/meta-trends。)

Takeaway2026 企业 AI 落地行动指南

一、聚焦核心价值:停止无目的的广泛尝试,列出两到三个能直接影响利润的关键场景进行试点。 二、业务主管挂帅:千万不要将项目主导权留在技术或研发部门,应由最优秀的运营主管牵头,并背负具体的业务指标。 三、按成果付费:在探索初期,优先采用按实际产出或节省资金收费的外部合作伙伴,以控制项目试错风险。 四、保护核心资产:明晰核心商业机密,建立专有数据的出域安全防护,合理搭配使用公有云接口和私有化模型。

PUBLISHED VIA AIR7.FUN | STYLE: SWISS
基本 文件 流程 错误 SQL 调试
  1. 请求信息 : 2026-06-29 16:43:15 HTTP/1.1 GET : https://www.yeyulingfeng.com/a/815286.html
  2. 运行时间 : 0.122160s [ 吞吐率:8.19req/s ] 内存消耗:5,015.26kb 文件加载:145
  3. 缓存信息 : 0 reads,0 writes
  4. 会话信息 : SESSION_ID=1e4a41f143c372c19e41de030e09ba08
  1. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/public/index.php ( 0.79 KB )
  2. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/autoload.php ( 0.17 KB )
  3. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/composer/autoload_real.php ( 2.49 KB )
  4. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/composer/platform_check.php ( 0.90 KB )
  5. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/composer/ClassLoader.php ( 14.03 KB )
  6. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/composer/autoload_static.php ( 6.05 KB )
  7. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/helper.php ( 8.34 KB )
  8. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-validate/src/helper.php ( 2.19 KB )
  9. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/ralouphie/getallheaders/src/getallheaders.php ( 1.60 KB )
  10. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/helper.php ( 1.47 KB )
  11. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/stubs/load_stubs.php ( 0.16 KB )
  12. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Exception.php ( 1.69 KB )
  13. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-container/src/Facade.php ( 2.71 KB )
  14. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/deprecation-contracts/function.php ( 0.99 KB )
  15. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/polyfill-mbstring/bootstrap.php ( 8.26 KB )
  16. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/polyfill-mbstring/bootstrap80.php ( 9.78 KB )
  17. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/var-dumper/Resources/functions/dump.php ( 1.49 KB )
  18. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-dumper/src/helper.php ( 0.18 KB )
  19. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/var-dumper/VarDumper.php ( 4.30 KB )
  20. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/guzzlehttp/guzzle/src/functions_include.php ( 0.16 KB )
  21. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/guzzlehttp/guzzle/src/functions.php ( 5.54 KB )
  22. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/App.php ( 15.30 KB )
  23. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-container/src/Container.php ( 15.76 KB )
  24. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/psr/container/src/ContainerInterface.php ( 1.02 KB )
  25. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/provider.php ( 0.19 KB )
  26. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Http.php ( 6.04 KB )
  27. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/helper/Str.php ( 7.29 KB )
  28. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Env.php ( 4.68 KB )
  29. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/common.php ( 0.03 KB )
  30. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/helper.php ( 18.78 KB )
  31. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Config.php ( 5.54 KB )
  32. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/alipay.php ( 3.59 KB )
  33. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/facade/Env.php ( 1.67 KB )
  34. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/app.php ( 0.95 KB )
  35. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/cache.php ( 0.78 KB )
  36. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/console.php ( 0.23 KB )
  37. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/cookie.php ( 0.56 KB )
  38. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/database.php ( 2.48 KB )
  39. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/filesystem.php ( 0.61 KB )
  40. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/lang.php ( 0.91 KB )
  41. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/log.php ( 1.35 KB )
  42. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/middleware.php ( 0.19 KB )
  43. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/route.php ( 1.89 KB )
  44. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/session.php ( 0.57 KB )
  45. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/trace.php ( 0.34 KB )
  46. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/view.php ( 0.82 KB )
  47. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/event.php ( 0.25 KB )
  48. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Event.php ( 7.67 KB )
  49. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/service.php ( 0.13 KB )
  50. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/AppService.php ( 0.26 KB )
  51. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Service.php ( 1.64 KB )
  52. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Lang.php ( 7.35 KB )
  53. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/lang/zh-cn.php ( 13.70 KB )
  54. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/initializer/Error.php ( 3.31 KB )
  55. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/initializer/RegisterService.php ( 1.33 KB )
  56. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/services.php ( 0.14 KB )
  57. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/service/PaginatorService.php ( 1.52 KB )
  58. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/service/ValidateService.php ( 0.99 KB )
  59. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/service/ModelService.php ( 2.04 KB )
  60. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-trace/src/Service.php ( 0.77 KB )
  61. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Middleware.php ( 6.72 KB )
  62. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/initializer/BootService.php ( 0.77 KB )
  63. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/Paginator.php ( 11.86 KB )
  64. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-validate/src/Validate.php ( 63.20 KB )
  65. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/Model.php ( 23.55 KB )
  66. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/Attribute.php ( 21.05 KB )
  67. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/AutoWriteData.php ( 4.21 KB )
  68. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/Conversion.php ( 6.44 KB )
  69. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/DbConnect.php ( 5.16 KB )
  70. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/ModelEvent.php ( 2.33 KB )
  71. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/RelationShip.php ( 28.29 KB )
  72. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/contract/Arrayable.php ( 0.09 KB )
  73. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/contract/Jsonable.php ( 0.13 KB )
  74. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/contract/Modelable.php ( 0.09 KB )
  75. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Db.php ( 2.88 KB )
  76. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/DbManager.php ( 8.52 KB )
  77. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Log.php ( 6.28 KB )
  78. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Manager.php ( 3.92 KB )
  79. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/psr/log/src/LoggerTrait.php ( 2.69 KB )
  80. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/psr/log/src/LoggerInterface.php ( 2.71 KB )
  81. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Cache.php ( 4.92 KB )
  82. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/psr/simple-cache/src/CacheInterface.php ( 4.71 KB )
  83. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/helper/Arr.php ( 16.63 KB )
  84. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/cache/driver/File.php ( 7.84 KB )
  85. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/cache/Driver.php ( 9.03 KB )
  86. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/contract/CacheHandlerInterface.php ( 1.99 KB )
  87. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/Request.php ( 0.09 KB )
  88. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Request.php ( 55.78 KB )
  89. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/middleware.php ( 0.25 KB )
  90. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Pipeline.php ( 2.61 KB )
  91. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-trace/src/TraceDebug.php ( 3.40 KB )
  92. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/middleware/SessionInit.php ( 1.94 KB )
  93. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Session.php ( 1.80 KB )
  94. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/session/driver/File.php ( 6.27 KB )
  95. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/contract/SessionHandlerInterface.php ( 0.87 KB )
  96. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/session/Store.php ( 7.12 KB )
  97. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Route.php ( 23.73 KB )
  98. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/RuleName.php ( 5.75 KB )
  99. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/Domain.php ( 2.53 KB )
  100. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/RuleGroup.php ( 22.43 KB )
  101. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/Rule.php ( 26.95 KB )
  102. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/RuleItem.php ( 9.78 KB )
  103. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/route/app.php ( 3.94 KB )
  104. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/facade/Route.php ( 4.70 KB )
  105. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/dispatch/Controller.php ( 4.74 KB )
  106. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/Dispatch.php ( 10.44 KB )
  107. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/controller/Index.php ( 9.87 KB )
  108. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/BaseController.php ( 2.05 KB )
  109. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/facade/Db.php ( 0.93 KB )
  110. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/connector/Mysql.php ( 5.44 KB )
  111. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/PDOConnection.php ( 52.47 KB )
  112. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/Connection.php ( 8.39 KB )
  113. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/ConnectionInterface.php ( 4.57 KB )
  114. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/builder/Mysql.php ( 16.58 KB )
  115. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/Builder.php ( 24.06 KB )
  116. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/BaseBuilder.php ( 27.50 KB )
  117. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/Query.php ( 15.71 KB )
  118. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/BaseQuery.php ( 45.13 KB )
  119. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/TimeFieldQuery.php ( 7.43 KB )
  120. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/AggregateQuery.php ( 3.26 KB )
  121. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/ModelRelationQuery.php ( 20.07 KB )
  122. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/ParamsBind.php ( 3.66 KB )
  123. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/ResultOperation.php ( 7.01 KB )
  124. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/WhereQuery.php ( 19.37 KB )
  125. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/JoinAndViewQuery.php ( 7.11 KB )
  126. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/TableFieldInfo.php ( 2.63 KB )
  127. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/Transaction.php ( 2.77 KB )
  128. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/log/driver/File.php ( 5.96 KB )
  129. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/contract/LogHandlerInterface.php ( 0.86 KB )
  130. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/log/Channel.php ( 3.89 KB )
  131. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/event/LogRecord.php ( 1.02 KB )
  132. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/Collection.php ( 16.47 KB )
  133. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/facade/View.php ( 1.70 KB )
  134. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/View.php ( 4.39 KB )
  135. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/controller/Es.php ( 3.30 KB )
  136. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Response.php ( 8.81 KB )
  137. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/response/View.php ( 3.29 KB )
  138. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Cookie.php ( 6.06 KB )
  139. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-view/src/Think.php ( 8.38 KB )
  140. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/contract/TemplateHandlerInterface.php ( 1.60 KB )
  141. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-template/src/Template.php ( 46.61 KB )
  142. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-template/src/template/driver/File.php ( 2.41 KB )
  143. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-template/src/template/contract/DriverInterface.php ( 0.86 KB )
  144. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/runtime/temp/c935550e3e8a3a4c27dd94e439343fdf.php ( 31.50 KB )
  145. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-trace/src/Html.php ( 4.42 KB )
  1. CONNECT:[ UseTime:0.000630s ] mysql:host=127.0.0.1;port=3306;dbname=wenku;charset=utf8mb4
  2. SHOW FULL COLUMNS FROM `fenlei` [ RunTime:0.000849s ]
  3. SELECT * FROM `fenlei` WHERE `fid` = 0 [ RunTime:0.000345s ]
  4. SELECT * FROM `fenlei` WHERE `fid` = 63 [ RunTime:0.000318s ]
  5. SHOW FULL COLUMNS FROM `set` [ RunTime:0.000884s ]
  6. SELECT * FROM `set` [ RunTime:0.000200s ]
  7. SHOW FULL COLUMNS FROM `article` [ RunTime:0.000749s ]
  8. SELECT * FROM `article` WHERE `id` = 815286 LIMIT 1 [ RunTime:0.004147s ]
  9. UPDATE `article` SET `lasttime` = 1782722595 WHERE `id` = 815286 [ RunTime:0.003145s ]
  10. SELECT * FROM `fenlei` WHERE `id` = 64 LIMIT 1 [ RunTime:0.000311s ]
  11. SELECT * FROM `article` WHERE `id` < 815286 ORDER BY `id` DESC LIMIT 1 [ RunTime:0.000546s ]
  12. SELECT * FROM `article` WHERE `id` > 815286 ORDER BY `id` ASC LIMIT 1 [ RunTime:0.001672s ]
  13. SELECT * FROM `article` WHERE `id` < 815286 ORDER BY `id` DESC LIMIT 10 [ RunTime:0.013256s ]
  14. SELECT * FROM `article` WHERE `id` < 815286 ORDER BY `id` DESC LIMIT 10,10 [ RunTime:0.009928s ]
  15. SELECT * FROM `article` WHERE `id` < 815286 ORDER BY `id` DESC LIMIT 20,10 [ RunTime:0.004460s ]
0.123777s