文章

#1 OpenClaw 开发者: 未来 80% 的 App 将会消失 我们每天在几十个 App 之间切换：在微信回消息，在日历看日程，在打车软件叫车。这种割裂的体验是移动互联网时代的遗毒。 OpenClaw（前称 Clawdbot）开发者 Peter 做出了一个大胆的预测：未来 80% 的 App 将会消失，或者退化为纯粹的 API 接口。 —— OpenClaw 开发者：为什么 80% 的应用会消失？丨 Y Combinator 这真是个掷地有声的观点。 起初我以为，这又是某个吹捧 “AI 将会重塑一切” 的陈词滥调，但当看到后半句 “(APP)将退化为纯粹的 API 接口”时，判断便发生了转折——这实在是只有真正具备丰富的 AI 落地经验的人才会有的洞察。 当 AI 不再只是一个能写文档、能聊天的文字助手，而是切实具备自我思考与执行能力的智能体，并可以通过协议与各类 APP 联系在一起，那么它将产生的效能，将远不止于 OpenClaw 目前所展示出的个人助手效果。 CLI vs MCP：回归最原始、最强大的交互方式 在交互设计上，Peter 提出一个观点：图形界面（GUI）是给人类用的，但对于 AI Agent 来说，命令行界面（CLI）才是最高效的。现在的很多 AI 工具试图模仿人类去点击屏幕，这其实是一种低效的拟人化。 OpenClaw 的设计哲学是复古的，它大量使用类似终端的指令交互。这虽然提高了上手门槛，但极大地提升了操作上限。你可以用一行命令完成复杂的任务链，比如“查找过去一周所有关于‘发票’的邮件，提取附件，分类保存，并生成汇总表”。 “不要试图让机器人像人一样去点鼠标。那是对算力的浪费。给它们最原始的接口，它们能跑得飞快。” 这不仅仅是复古，更是对人机交互效率的极致追求。 计算机本身并不需要 GUI。 图形化用户界面（GUI）的诞生，毫无疑问是计算机发展史上的重要里程碑。它源于贝尔实验室，1973 年推出的 Alto 电脑首次将图形界面系统完整地整合到计算机中。史蒂夫·乔布斯在参观了 Alto 后深受启发，随后苹果公司推出的“Apple II”上也有 Alto 的身影，并且在后续的所有个人计算机产品中，也都能看到这一理念的延续。 ...

马上就要过年放假了，趁着年前的工作将要收尾，想对最近几个月一直在做的“问题数据集”准备工作做一次复盘，把实践之后的一些认知思考沉淀下来。 这几个月，我一直在为一款面向车主用户，解答用车、修车、养车问题的 Chatbot，收集并清洗生成车主问题数据集。 在工作刚开始的时候，我还是抱着对做一款 AI Chatbot 的热情，主动学习并积累了一些 AI 相关的认知，但随着工作的不断推进，每天日复一日地清洗数据，有些东西逐渐开始变得“当局者迷”，越深入越看不清晰。因此想趁这个时间节点，从具体工作中抽离出来，认真做一次复盘。 先简单说说近期的工作成果：在超过 450 万条原始采集数据的基础之上，清洗并汇总出了超 16 万条有效车主问题数据集。 但紧接着，一个更让我值得深思的问题出现了：在 AI Chat 落地的过程中，“问题数据集”的作用到底是什么？ 通用型 Chatbot vs 专用型 Chatbot 在这项工作刚开始的时候，我难免会去向一些做 AI 模型的公司取取经，学习并参考他们在 AI Chat 相关领域的工程实践与专业认知。这其中包括 智谱 AI 首席科学家唐杰的分享 、 MiniMax 创始人闫俊杰的播客 ，以及 GPT 5.2 的大力支持。 正是从这项工作开始，我开通了每月 20 美元的 ChatGPT Plus。它确实帮到了我很多，不仅能帮我写 Python 脚本，也能从它的视角为我提供很多关于 AI 的专业认知。 但就是在这里，一个典型的“分水岭”出现了：像 ChatGPT 这样的通用型 Chatbot 的工程路径，其实和我正在参与构建的这种垂直场景的专用型 Chatbot，在底层逻辑上截然不同。前者强调的是可泛化的智能能力，而后者更需要的则是可控且可靠的业务约束。 我们先来看看，像 ChatGPT 这样能力极强的通用型 Chatbot，它的工程实践路径大致是什么： 超大规模预训练（万亿级 token 语料） 大规模人类反馈对齐（RLHF） 大规模 Eval 体系（多维度 benchmark） 极高模型参数规模（超万亿参数） 简而言之，就是通过堆叠算力与数据规模，弱化甚至替代显式规则，让模型自身学习并内化复杂模式，从而强化其智能表现。 而专用型 Chatbot 的路径则不同。它更多依赖场景分析与系统工程，对模型能力的某一小部分进行针对性强化。 ...

#1 圆桌对话：关于中国 AI 的未来 本月 10 日，在北京中关村举办的「AGI-Next 前沿峰会」上，中国多位顶尖的大模型领导者齐聚一堂。 其中一段围绕「中国 AI 的未来」展开的圆桌讨论，整体质量非常高，让我印象深刻。 姚顺雨：OpenAI 前核心研究者、腾讯 AI 新部门负责人 林俊旸：阿里 Qwen 技术负责人 唐杰：清华大学教授，智谱创始人 我特别赞同姚顺雨关于中国需要一个更成熟的 ToB 市场的判断。市场，终究是技术与产品孵化最重要的“底池”。 他还进一步提到一个主观因素——中国具备创新与冒险精神的人不够多。在我看来，某种程度上，也正是因为缺乏成熟的市场支持，导致创新的回报风险大、投入不确定性高，而社会兜底机制与对失败的包容性尚不完善，这些因素叠加在一起，才使得国内真正敢于放手一搏的人并不多。 中美之间在财富规模与算力储备上的差距本身并不令人意外，但林俊旸提到，中国在算力层面可能落后美国 1–2 个数量级，这一点仍然让我感到震惊。在 scaling law 的作用下，这样的差距并非线性，而是会对模型能力产生显著影响。 此外，他对 「未来最领先的 AI 公司是一家中国公司的概率大约 20% 」 的判断，也让我感觉非常务实，尤其是他提到，这里面“真的有很多历史积淀的原因”，让我不得不苟同。 相比之下，唐杰的回答则更加稳健。 他在正视现实差距的同时，也明确提到，中国的国家战略与营商环境正在逐步改善，对创新的鼓励力度也在持续增强； 与此同时，中国的年轻一代正在变得更愿意承担风险，去尝试不确定性更高的事情。 顺着这条逻辑推演，未来的走向，终究仍然取决于我们每一个人自己。这是一个非常朴素，却充满智慧的判断。 以下内容摘录自： 科技爱好者周刊（第 381 期）：中国 AI 大模型领导者在想什么 发言实录： https://www.53ai.com/news/LargeLanguageModel/2026011069524.html 主持人提问 李广密（主持人）：我想问大家一个问题，在三年和五年以后，全球最领先的 AI 公司是中国团队的概率有多大？我们从今天的跟随者变成未来的引领者，这个过程到底还有哪些需要去做好？ 姚顺雨的回答 我觉得概率还挺高的，我挺乐观的。目前看起来，任何一个事情一旦被发现，在中国就能够很快的复现，在很多局部做得更好，包括之前制造业、电动车这样的例子已经不断地发生。 我觉得可能有几个比较关键的点。 （1）中国的光刻机到底能不能突破，如果最终算力变成了瓶颈，我们能不能解决算力问题。 （2）能不能有更成熟的 To B 市场。今天我们看到很多做生产力或者做 To B 的模型和应用，还是会诞生在美国，因为支付意愿更强，文化更好。今天在国内做这个事情很难，所以大家都会选择出海或者国际化。这和算力是比较大的客观因素。 （3）更重要的是主观因素，我觉得中国想要突破新的范式或者做非常冒险事情的人可能还不够多。也就是说，有没有更多有创业精神或者冒险精神的人，真的想要去做前沿探索或者范式突破的事情。我们到底能不能引领新的范式，这可能是今天中国唯一要解决的问题，因为其他所有做的事情，无论是商业，还是产业设计，还是做工程，我们某种程度上已经比美国做得更好。 林俊旸的回答 这个问题是个危险的问题，理论上这个场合是不可以泼冷水的，但如果从概率上来说，我可能想说一下我感受到的中国和美国的差异。比如说，美国的 Compute（算力）可能整体比我们大1-2个数量级，但我看到不管是 OpenAI 还是什么，他们大量的算力投入到的是下一代研究当中去，我们今天相对来说捉襟见肘，光交付可能就已经占据了我们绝大部分的算力，这会是一个比较大的差异。 ...

本文尝试从业务视角出发，讨论当 Chatbot 作为一个 C 端产品，进入真实组织与资源约束环境时，阶段性更可行的产品设计判断。 业务前提 在真实企业环境中的 C 端产品业务里，Chatbot 的核心目标始终是服务业务。 在这一前提下，产品设计与能力取舍都应优先围绕业务价值展开，而非单纯追求技术能力的完整性或先进性。 具体到 C 端车主场景，一款 Chatbot 的价值并不取决于“是否足够智能”，而在于是否能够持续提升用户留存与互动频次，并进一步支撑清晰、可落地的业务转化路径。 基于这一判断，本文将聚焦业务视角下 Chatbot 应优先完成的关键事项，尝试厘清阶段性目标、产品定位以及更现实的落地路径。 结合我对“AI 产品经理”的理解，这里的讨论基本落在我所定义的 AI 应用层 。 一、核心判断 在真实的 C 端业务落地过程中，一个更合理、也更稳健的产品判断是： 将 Chatbot 视为一个可控、可量化的产品组件，而非一个“智能系统”。 在这一判断下，阶段性的工作重点并不在于： 解释 AI 技术或模型能力本身 一次性打造“足够专业”的专家型系统 构建覆盖所有问题场景的完整知识体系 而应优先聚焦以下三项更具现实业务价值的目标： 确保 Chatbot 在 App 中被真实用户持续使用 将使用效果映射为清晰、可解释的业务指标 在有限资源条件下，形成可持续迭代的产品结构 二、Chatbot 的阶段性产品定位 ⛔ 业务阶段不宜优先采用的定位方式 在 C 端场景中，以下车主 Chatbot 的产品定位虽然在技术层面具备合理性，但在实际业务落地阶段中风险较高： 专业 AI 助手 汽车专家系统 智能决策引擎 以复杂 RAG 或深度推理链为核心的产品形态 这些定位通常强调模型能力的完整度或技术深度，但并不直接等价于使用频次、用户留存或阶段性业务提升。 ✅ 业务阶段更合适的产品定位 从业务视角出发，一个更贴近现实的定位是： 车主高频问题的即时响应入口（Retention-first） 换一种更直观的表述，即： 通过 Chatbot 延长用户在 App 内的停留时间，促使用户产生更多交互，而非在首次交互后立即流失。 ...

本文更多是一种工程路径的推演，而非已经被完整实践验证的结论。 它更像是一张“地图”，用来帮助在构建 Chatbot 的过程中尽量避免迷路。 背景 在很多产品团队的讨论里，“做一款车主 Chatbot”往往会被简化成： 接入一个大模型 设计一些提示词 准备文档材料，接入知识库（RAG） 然后在 APP 里设计一个对话框 UI，开启对话功能 但当你真正把它视作一款需要长期落地、持续迭代，并承担真实业务责任的产品时，就会发现：它并不只是“把模型接进来”，而是要让模型在真实业务场景中形成稳定、可依赖的专业判断能力。 在阅读智谱 AI 首席科学家唐杰的分享 「谈 2025 年对大模型的看法」 后， 我尝试从第一性原理出发，推演如果从零构建做一款车主 Chatbot，在业务落地层面，可能需要经过哪些关键路径。 从第一性原理出发，对车主 Chatbot 实现路径的推演 一、第一性原理 目标：用 AGI 替代 汽车技师 的部分工作，解答车主的日常问题咨询。 如果这个目标成立，那么后续所有产品设计，都应该围绕 “专业判断能力是否形成” 展开，而不是围绕用户画像、问题类型或业务流程本身。 二、让模型对齐真实业务场景，增强实际体感 Mid 和 Post Training 使得模型更快对齐业务场景，并具备更强的推理能力成为可能。 换句话说，就是让模型更快学会在真实业务场景下应该如何思考，如何回答。 1. 继续预训练 Continued Pre-Training（CPT） 目标：补齐领域知识与因果结构。 汽车领域的知识并非“百科式知识”，而是由大量工程结构与因果关系构成，例如： 系统原理：发动机 / 变速箱 / 底盘 / 电气架构 等 故障机理：症状 ↔ 原因 ↔ 处理路径 维修动作：检测步骤、拆装流程、风险提示 品牌差异：不同车型的共性与特例 CPT 的意义，并不在于让模型“记住更多资料”，而是让模型内部表示方式更接近这一领域的知识结构本身。如果缺少这一阶段，后续的 SFT 很容易沦为“教话术”，而非真正补足能力。 ...

这段时间在参与 AI 落地相关工作的过程中，我逐渐形成了一个相对清晰的判断： 不同组织对「AI 产品经理」的理解，往往并不在同一个层级上。 需要说明的是，这并不是对个人能力高低的划分，而是当 AI 项目承担的责任不同 时，产品角色自然发生的变化。 如果从“AI 在组织中承担的责任”这一维度出发，大致可以划分为三个层级。 第一层：AI 叙事层 AI 叙事层是大多数组织在引入 AI 时，最先进入、也最容易停留的一层。 这一层的工作，主要围绕“AI 能做什么”展开，包括： 描述 AI 可以解决哪些问题 Demo 能否跑通、是否具备展示效果 PPT 中的 AI 相关 KPI 是否足够好看 在这个阶段，AI 更多是一种叙事工具，用于解释方向、争取资源、传递信心。 这种推进方式在成熟企业中较为常见，尤其在上市公司环境下更为典型： 一方面，风险较低，无需立即承担业务结果的不确定性； 另一方面，也更容易为提出者在组织内带来正向增益，例如项目立项、资源倾斜等。 因此，这一层的核心责任在于：方向感与表达能力。 相应的产出，主要体现在方案设计、演示 Demo、以及用于对齐与汇报的 PPT 材料等。 但也正因如此： 这一层并不需要真正的 AI 工程判断介入。 因为一旦引入数据质量、成本、稳定性等现实问题，叙事本身往往就会被打断。 第二层：AI 应用层 当组织不再满足于“讲清楚 AI 能做什么”，而是希望真正把 AI 用起来，就会进入这一层。 这一阶段的典型工作包括： 接入模型 API 调整提示词、优化单次回复效果 设计基础的 Chatbot 交互 在小规模场景中验证可行性 相比 AI 叙事层 ，这一层已经开始真正“做事”，也确实能够产出一些可被业务感知的结果。 因此，这一层的核心目标是：可用性与体验成立。 在这一阶段，常见的产出包括 Prompt 提示词、Chatbot 交互原型，以及小规模场景下的效果验证数据。 ...

这篇文章记录的是：我在为一款 垂直应用 Chatbot 准备数据的过程中，经过一系列实践尝试，逐渐沉淀下来的一套数据工作流思路。 它并不新颖，也并不复杂，但在真实的业务环境中，非常管用。 如果从产品视角来看，这里的大多数问题，都已经落在我所定义的 AI 工程化层 。 适合谁阅读（请先看这里） 在继续往下之前，我想先明确一点：这篇文章并不适合所有人。 它可能不太适合： 算法研究员 AI 竞赛玩家 以模型结构与训练技巧为主要关注点的 ML 工程师 它更适合： AI 产品经理 应用型 AI 工程师 在团队里「被迫开始做数据」的人 想把 AI 真正跑起来，而不仅仅停留在 Demo 阶段的人 如果你期待的是更复杂的模型、更新颖的算法，这篇文章大概率会让你失望； 但如果你关心的是，在现实约束下，数据如何一步步从无到有，从充满噪声到变得可用，那它或许能给你提供一些参考。 任务背景：做一款面向车主的 Chatbot 最初的目标，是做一款面向普通车主的问答型 Chatbot，用于解答他们在真实用车场景中会遇到的各类问题。 例如： 「仪表盘上那个像茶壶一样的灯亮了，是怎么回事？」 「开车时方向盘老是抖，速度越快抖得越厉害，怎么回事？」 「这两天仪表盘上老显示一个保养的黄扳手，请问再多跑一两千公里去保养行吗？」 这类问题通常具有一些共性特征： 高度口语化 上下文信息缺失 专业名词与俗称混杂 带有明显的情绪与不确定性 如果希望模型的回复在语气上更贴近真实车主的表达，在判断上让人感到安全、可信，而不只是一个干巴巴的“百科式问答机器人”，那么仅靠现成的通用语料显然是不够的。 因此，我需要准备一批来源于真实车主表达、语气自然、质量可控且规模足够大的车主问答数据，用于后续的车主画像分析与模型微调。 第一个问题：数据从哪里来？ 无论是用于后续的 LoRA 微调，还是支撑更高质量的车主画像分析与多轮对话策略设计，首先要解决的，其实都是同一个问题： 如何规模化地收集来自真实车主表达的问答数据？ 在已有的数据资产中，我们并不具备这一类型的数据，因此只能从外部渠道入手，尽可能补齐这一基础。 在不依赖任何内部或私有数据的前提下，可用于分析的数据来源其实并不多，主要包括： 汽车社区与论坛（如汽车之家、懂车帝车友圈等） 内容型平台（如 B 站、抖音、小红书等） 公开数据集（竞赛数据集、Hugging Face 等） AI 生成的 dummy 数据 综合数据质量、表达真实性与规模潜力等因素评估后，我们最终将最高优先级放在了内容型平台（B 站、抖音、小红书等）。 这类平台上的内容更贴近真实车主的自然表达，往往带有情绪、口语化表述与大量俗称，同时数据规模足够大、问题类型覆盖全面，既有利于后续的数据扩展与迭代，也适合用于分析不同问题类型与使用场景下的车主画像。 但关键问题在于：这些地方的数据，噪声太大了。 大量与问题无关的闲聊与互动（如点赞、调侃） 大量表情、重复性内容 大量上下文缺失的碎片文本 甚至夹杂着广告或完全无关的信息 很快，我便意识到一件事： ...

#1 人工智能时代需要反思的经典产品规则 Rupesh Agarwal｜前 Zalando 产品负责人 传统 PM 经验在 AI 场景下可能整体失效。 前 Zalando 产品负责人 Rupesh Agarwal 在本视频中概述了产品负责人在向 AI 时代转型时需要做出的十个关键转变： 这十个关键转变，尤其可作为我所定义的 AI 应用层 产品经理，向 AI 工程化层 过渡时的参考坐标。 转变 1：从确定性到概率性 在经典产品中，功能是确定性的。如果你发布一个登录按钮，它要么能用，要么不能用。相同的输入，结果相同。然而在 AI 产品中，输出变成了概率性的。相同的输入可能产生不同的结果，准确率也会波动。 因此，思维模式要从“控制”转变为“引导”。这意味着 AI 将产品工作从确定性管理转变为概率管理。对你而言，这意味着停止承诺确定性，开始管理概率范围。 转变 2：从发布功能到训练系统 在传统产品管理中，焦点几乎总是像时钟一样精准地发布功能。然而在 AI 产品世界里，真正的产品是从数据中学习的系统。你真正的产品是持续训练和再训练的系统。 这对你意味着：你的路线图必须包含数据质量、再训练周期和模型监控，而不仅仅是 UI 或工作流的发布。 转变 3：从客户反馈到数据反馈 在传统产品中，反馈通常来自访谈或调查。但对于 AI 产品，反馈往往来自错误标记或缺失的数据。 最重要的反馈可能永远不会直接来自用户。用户描述症状，数据揭示原因。这对你意味着：必须建立持续观察模型输入和输出的系统，反馈现在存在于你的数据之中。 转变 4：从静态 KPI 到动态性能 在经典产品中，成功通常通过采用率、留存率、收入等来衡量。然而在 AI 产品中，我们需要额外的指标：模型准确性、延迟、公平性、偏见和可解释性。 这里的业务 KPI 失败通常追溯到模型性能问题，而不仅仅是产品 UI 缺陷。因此，平衡这些指标与传统 KPI 至关重要。如果一方出现漂移，另一方就会崩溃。这里的要点是：AI 产品的失败通常不在 UI 层，而在模型层。这对你意味着：你需要从两个维度衡量绩效——业务影响和模型行为。 ...

从互联网到AI，科技创新的浪潮此起彼伏。极客们追逐着技术的革新，投机者们寄望于泡沫的繁荣，而那些秉持着长期主义的理性的投资者与创业者们，则以审慎而又乐观的姿态躬身入局，积极投身于“Make the World A Better Place”的事业之中。 创新，无疑是一场充满激情的远行。无论是对前沿科技的探索，还是对泡沫中财富的渴求，抑或是对开创一番新事业的热情，都令人心潮澎湃。然而，创新，却未必是好的商业选择。尽管无数商业著作不断强调“创新的重要性”，但与之相伴的风险与潜在亏损，同样不容我们忽视。 什么才是“好的商业选择”？ 在我看来，一个好的商业选择至少要能实现一个基本目标：盈亏平衡，进而可以在此基础上建立长期可持续的盈利能力。 回顾互联网早期的“烧钱换规模”，以及AI领域在模型预训练与算力基础设施上的巨额投入，这些模式在特定阶段都呈现出“亏损远大于利润”的不健康状态。如果撇开泡沫带来的虚假繁荣，任何商业模式最终都要回归商业的本质——供需平衡与盈利可持续。 值得庆幸的是，互联网行业在经历早期的野蛮生长后，最终找到了一些健康的商业模式。以“电商”为例，电商平台可以通过广告服务与平台佣金，将早期的巨额投入通过规模效应进行回收，进而实现更加长远可持续的发展。而在这个模式下，也诞生出了诸如亚马逊、阿里巴巴、京东这样的新兴商业巨头。 反观当前的AI领域，依然尚未探索出一条明确可以回收早期巨额投入的商业模式，AI应用层面的市场需求尚未完全验证，这其中潜藏的商业风险不容小觑。 诚然，即便没有实现盈亏平衡，企业依然可以通过银行借贷、股权融资或政府补贴等方式维持运营。但这无异于饮鸩止渴——没有人愿意永远供养一个无法自我造血的孩子。长期的亏损会让组织变得“脆弱”：管理层焦虑、员工迷茫、投资者动摇。当融资环境收紧、现金流面临压力、组织压力增大时，这种脆弱最终会引发系统性风险，导致企业的失败。 创新与商业成功并不对立 我们热爱创新，热衷于钻研新兴事物，渴望用新的可能取代旧的秩序。这既是主观的浪漫理想，也符合客观的发展规律，无可指摘。 然而，现实的残酷在于——创新是要消耗资源的。说的更直白些：创新，是要“花钱”的。 “（投资人）他们要的是结果，我在乎的是过程。可过程……有时候会饿死人。” 《一个 RISC-V 理想主义者的幻灭：柯一冉的再次创业》 假若在一个拥有无尽资源的理想国里，我们自然可以无惧失败，让创新成为一场纯粹而自由的激情远征。 可当资源注定有限，投入可能血本无归，资源消耗殆尽就会失败的时候，现实的寒意便扑面而来——创新，是理想高举的火焰；而盈利，则是生存必须穿越的冰山。 因此，那些真正高明的创新者们，既不是纯粹的理想主义者，也不是完全向现实低头的投降派，他们是一群走钢丝的艺术家，永远在“理想的引力”与“现实的张力”之间，寻找一个精妙的动态平衡。 他们用理想定义方向，确保创新不迷失于短视的利润；他们用现实约束脚步，确保每一步都迈得坚实有力。正是这种永恒的、微妙的拉扯，催生出了许多既颠覆想象，又切实可行的伟大产品。创新与盈利，从来不是非此即彼的单选题。 即便是风险投资和长期资本的介入，也并未背离商业本质，而是对创新节奏的优化与改良——将原本“一年定生死”的生存窗口期，延长为“十年磨一剑”的战略探索期；将原本“零容忍”的失败压力，转化为“十个项目中成一个即可”的容错机制。这并不是对商业逻辑的否定，而是对其更深层次的理解与运用。 纵观亚马逊、特斯拉、SpaceX这些卓越的企业，虽然它们早期都曾经历过高风险的投入期，但最终都走向了可持续的盈利之路。这恰恰证明：创新与商业成功，并非背道而驰，而是可以共生共长的同一旅程。 后记：《谷歌14年工作生涯中的21个经验教训》 原文链接： 21 Lessons from 14 Years at Google 我在这篇博客中，找到了一句和我观点不谋而合的一段话： The punchline isn’t “never innovate”. It’s “innovate only where you’re uniquely paid to innovate.” Everything else should default to boring, because boring has known failure modes. 关键不在于“永远不要创新”，而在于“只在那些你因创新而获得独特报酬的领域进行创新”。其他一切都应该回归平庸，因为平庸的失败模式是众所周知的。 延伸阅读 《在中国，哪些 AI 创新路径更可能落地》