AI

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