AI

马上就要过年放假了，趁着年前的工作将要收尾，想对最近几个月一直在做的“问题数据集”准备工作做一次复盘，把实践之后的一些认知思考沉淀下来。 这几个月，我一直在为一款面向车主用户，解答用车、修车、养车问题的 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」，看起来用了大模型，设计了提示词，准备了知识库和数据集，但它们的底层逻辑其实让人异常熟悉——熟悉到令人不安。 它们做的事情是： 把知识整理成 结构化业务规则 ， 再要求大模型 严格按规则进行分析、判断并生成回复 。 换句话说，是在用 21 世纪的大模型技术，复刻上世纪的规则驱动型对话机器人。 Chatbot 的本质，从来不是“规则执行器” 如果一个 Chatbot 的目标是： 按业务流程一步步走 在预定义框架里做判断 输出完全可解释、可复盘的结果 那么，其实并不需要大模型。 规则引擎 、 状态机 、 模板系统 ，在确定性问题上反而会更便宜、更稳定，更可控。 Chatbot 的核心价值，从来不在于“照着规则走”，而在于通过概率推理，实现具备泛化能力的智能回答。 正确的方向，其实恰恰相反 一个真正合理的 Chatbot 架构，应当是： 模型是主脑 数据定义能力边界 系统工程负责稳定性与成本控制 评估与反馈驱动系统持续进化 它不是先把世界“压扁”成规则，再让模型当一个高级填空器。 而是： 在足够干净、足够真实的数据分布上， 让模型能力自然生长， 再通过系统工程，把这种能力稳定地转化、放大，并外溢为业务 KPI。 为什么很多团队会“退回规则引擎” 原因其实并不复杂，因为规则引擎： 规则 可解释 流程 可画图 决策 可复盘 PPT 好汇报 而模型能力的进化： 本质上是概率性的 存在波动与不确定性 可解释性有限 需要长期的系统工程与认知支撑 在大量团队中，这种回退不仅仅是技术选择的问题，还往往叠加了一个不那么容易被察觉的因素——互联网产品经理通常不具备完整的 AI 通识认知体系。 从专家系统 → 机器学习 → 深度学习 → 大语言模型，这一演进过程并非单纯的技术升级，而是对“智能如何产生”的理解范式发生了转变。 ...

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

我目前认为，在国内做 AI 创新，更可能落地的方向大致有四类： 1. AI 硬件创新：做 AI 领域的大疆 相较于软件，硬件在商业模式上天然更容易变现（直接售卖产品），再结合以深圳为代表的中国完整工业制造体系，以及大疆、影石等硬件领域的先行者作为参照，这条路经蕴含着巨大的机会空间。 相关资讯： 蚂蚁、美团入局 AI 硬件，Looki 完成超 2000 万美元 A 轮融资 2. 成熟业务模式 + AI：电商 + AI、游戏 + AI 等 这对国内绝大多数的公司而言，是最稳定的 AI 落地范式，也是我目前在实际工作中接触最多的路径：不改变原有商业模式，AI 主要用于降本增效、提升转化和留存。ROI 可计算，组织也更愿意为此买单。 但这种方式往往带来的只是“增量改良”，创新很容易被 KPI 吸收，最终沉淀为工具或能力组件，而非真正意义上的新产品。 3. 成熟互联网生态 + AI：头部互联网平台产生业务增量 在腾讯、字节、阿里等成熟互联网生态中，由于其本身已具备显著的规模化能力——有流量、有场景、有数据、有分发——因此 AI 更容易实现规模化落地。 但关键并不在于“是否引入 AI”，而在于：能否将 AI 转变为用户习惯性的流量入口；否则，它也可能只是短期热度，难以转化为实质性的业务价值。这也是近期字节布局手机端系统级 Agent、以及阿里高度重视并推进 C 端产品「千问」 APP 的原因之一。 4. 具身智能供应链：在产业链中寻找可落地的机会 尽管人形机器人的研发与制造门槛极高，真正具备全面下场能力的玩家有限，但顺着产业现实，切入具身智能的供应链环节，仍然存在可行空间，例如零部件、模组、系统集成、渠道与交付等。 在国家层面的具身智能战略与完整工业制造体系的基础之上，通过供应链与工程能力获取产业红利，而非依赖技术叙事去赌终局，本身也是一条具备现实可行性的路径。 延伸阅读 《创新是一场充满激情的远行，却未必是明智的商业选择》 《任正非：要支持美国科技文明的发展》

#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 层，而在模型层。这对你意味着：你需要从两个维度衡量绩效——业务影响和模型行为。 ...