AI

结合自己最近一段时间在 AI 工作中的实际体会，在知乎上看到一个很合自己感觉的回答，里面对中国市场下 AI 机会的分析，和我这段时间自己的观察不谋而合，顺手记录一下，并分享出来： 为什么这波 AI 浪潮没有带来大量的就业岗位? - Simon Zhang的回答 - 知乎 我自己比较认同的几个点，大概是这些： 在这两年的经济环境下，AI 在资方的眼里就是用来降本增效的。也许长期看会重塑整个社会对于劳动力的定义和商业模式，但短期看并不会带来大量的就业岗位； 国内这波 AI 浪潮，一是大厂和明星独角兽做 ToC，二是海量的小微初创企业在寻找 ToB 的机会； 小微企业在这轮 AI 浪潮中，实际上成为了有 AI 需求的大中型企业的外包合同工。这既来源于经济环境降本增效的需求，也可以归因于业务本身难以泛化复用的困境； 目前几乎所有 AI 产品和服务的死穴：生成式 AI 解决不了最后 10% 的不确定性问题，正如同快递和外卖行业最难的是最后的一公里。 在这波 AI 浪潮的乙方市场当中，头部的聚集效应极其明显，前 1% 的人和团队拿到 80%-90% 的融资，后 99% 的人和团队以灵活就业的外包模式去争夺市场上剩下的 10%-20% 的融资和业务。 （这个判断和我的另一篇随记 《当创新不再诞生在居民楼里》 不谋而合）

一个还不太成熟的想法：AI 应用的第一性原理，或许是输出有业务价值的 Token。 比如 Claude Code，输出的 Token 是高质量代码，能够直接替代程序员的人力成本，这是业务价值； OpenClaw 输出的 Token 是能够直接操作计算机，执行工作的 CLI 命令，从而减少人工工作成本，这同样具备业务价值。 而如果放在 AI 游戏里，这个 Token 可能是高精度的 3D 建模（类似 Hunyuan 3D ），也可能是有趣好玩的文本内容（AI 文字冒险游戏）。 Sora 输出的 Token 是视频（🪦R.I.P） 但它们的共同点，都在于：Token 本身具备可兑现的价值。 图源：腾讯研究院-Token经济学七问 从这个角度看，NVIDIA 提出的「AI 工厂」概念，其实也是在抽象 AI 应用的本质—— 输入电力与数据，输出 Token； 而阿里最近新增的事业群「Alibaba Token Hub」，某种程度上也像是在推动行业对 AI 应用价值的共识。 NVIDIA 不只是单纯的 GPU 芯片公司，更像在建造一种新型基础设施：AI 工厂。 原料是电力和数据，产出是 Token。 —— Jensen Huang: NVIDIA - The $4 Trillion Company & the AI Revolution | Lex Fridman Podcast ...

OpenClaw 的价值，不在于 Agent 本身，而在于它通过 IM 这种低心智入口，把 agent 从“极客工具”变成了“大众可感知的体验”。 它撬开的不是技术能力，而是 AI 在下沉用户中的使用门槛。 OpenClaw 不是让 AI 更强，而是第一次让“不会用 AI 的人，也能用上 AI”。

不到一顿火锅的钱，养一只 7×24 小时在线打工的 🦞 把我的配置经验整理了一下，希望能帮到想入坑的你 🚀 1. 云服务器 一开始，我在自己的 MacBook Air 上体验了 OpenClaw。但考虑到 7×24 小时运行的需求，最终还是决定租一台云服务器。 反复对比之后，我选择了 火山引擎·香港： 配置：2核4G 价格：约 ¥87/月 2G 内存虽然更便宜，但实测跑 agent-browser skill 时会爆内存，因此调大了一点内存。 香港服务器的优势： 默认自带翻墙，能直连 Github、Google、Clawhub 但由于是机房 IP，OpenAI、Anthropic、Gemini API 会被墙 这个问题不大，可以通过 WildCard 解决 我之前尝试过用国内服务器 + Clash 订阅代理，但在安装 OpenClaw 下载 git、node 时就遇到了 502 Bad Gateway，估计和云服务器的网络配置有些冲突。于是思来想去，为了省心就直接选香港服务器了——事实上效果确实让我省心很多。 相关链接： 火山引擎香港实例购买 2. Minimax Coding Plan 推荐先用最低版 ¥29/月 的套餐体验一下，后续按需提升。 相关链接： 订阅套餐 Coding Plan API Key 3. 原生安装 OpenClaw 这里不太推荐使用云服务器厂商的应用模板，配置起来不爽。 ...

OpenClaw 登顶 GitHub，超越 Linux 和 React。 如果说 ChatGPT 让人第一次意识到，AI 可以像人一样对话； 那么 OpenClaw 这类项目，正在让更多的人进一步意识到，AI 不只会说话，它还可以直接完成工作。 它让人们开始认真相信，Agent 不只是玩具，而可能成为下一个时代的主角。

马上就要过年放假了，趁着年前的工作将要收尾，想对最近几个月一直在做的“问题数据集”准备工作做一次复盘，把实践之后的一些认知思考沉淀下来。 这几个月，我一直在为一款面向车主用户，解答用车、修车、养车问题的 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 交互原型，以及小规模场景下的效果验证数据。 ...