实习生怎么在传统行业推 AI

这篇文章讲什么

2025 年 9-11 月，我在蔚来能源做 AI 产品经理实习，待了两个月。做了两件事：把一个准确率 15% 的销售 AI Agent 拉到 80%，以及把部门三张互不相通的核心表统一成了一个数据源。

这两件事的技术含量都不高。但它们改变了我对”在传统行业推 AI”这件事的理解——瓶颈不在模型，不在算力，而在组织内部的信息混沌。

一个准确率 15% 的 AI Agent

我接手的是一个面向销售渠道的问答 Agent。销售们每天在群里骂它”根本不能用”。我诊断后发现，问题不在模型，在知识库。

用一句话概括：它是一个不怎么聪明的做题家，做了一些不怎么聪明的题。

它的知识库有 200 多条数据，全部来自客服的口语化问答记录——冗余、过时、甚至有些是错的。它完全不懂我们的产品参数，一旦问题超出这 200 条的覆盖范围，就开始胡言乱语。

我的策略是停止喂它垃圾，给它构建一个干净的”大脑”。把知识库拆成两部分：

服务诀窍层：高频的、偏经验性的问答。这部分我没有自己写——我找到了一位直接向我 mentor 汇报的核心销售，借力让她来维护最佳实践答案。她是一线最懂业务的人，让她写比我写靠谱得多。

产品事实层：底层的、关于产品参数和规格的信息。这一层的挑战不是技术性的——是我发现部门内部对产品的定义本身就是混沌的。不同的人手里有不同版本的产品文档，对同一个产品的参数描述可能不一致。我像一个侦探一样辗转了很久，对比了无数份文档，最终找到了一份相对最权威的销售渠道参数表。把它处理成结构化的 JSON 喂给了模型。

效果立竿见影。衡量标准也很务实：从”销售每天在群里骂”，变成统计他们反馈”这个回答没问题”的比例。最终稳定在了 80%。

三张不互通的表

在做 Agent 知识库的过程中，我发现了一个更底层的问题：部门里有三张核心表——产品目录、订单审批、销售报表——分散在三个人手里，数据完全不互通。

每次有产品更新，需要手动在三张表里分别修改。更离谱的是，其中一张表的名称和编码对应关系，是用硬编码逻辑实现的。维护成本极高，而且几乎必然会出错。

我的直觉是：这个系统需要一个唯一的、可信的数据源（Single Source of Truth）。但直接提这个方案太”大”了——涉及三个人的工作流程，作为实习生推不动。

机会在一次日常任务中出现了。mentor 让我手动在两张表里同步一则新产品信息。我抓住这个窗口，在他那张表的旁边新建了一列，用飞书公式从我维护的产品目录里自动同步了产品名称。这个操作不影响原有逻辑，但效果一眼就能看到——人工同步的那列和公式同步的那列，数据一模一样，但后者不需要人。

他看到效果后立刻同意了。我顺势接手了整个部门的数据治理：搭建统一数据源、建自动化看板、清理历史数据里所有的错漏和不匹配。

为什么这两件事本质上是一件事

表面上看，“优化 AI Agent”和”统一三张表”是两个不相关的任务。但做完之后我意识到，它们的瓶颈是同一个东西：组织内部的信息混沌。

AI Agent 不准，不是因为模型差，是因为没人整理过一份靠谱的产品知识库。三张表不互通，不是因为没有工具，是因为没人站出来说”我们需要一个唯一的数据源”。这两个问题在技术上都很简单——难的是在一个分工成熟、流程惯性很强的组织里，作为一个实习生，找到推动改变的支点。

我从这段经历中提炼出的方法论是：最小原型破局。不要一上来就提一个”全面重构”的方案——没有人会信任一个实习生的全面重构。而是找到一个小到不可能被拒绝的切入点（一列公式、一份 JSON），用它证明你的方向是对的，然后借着这个势头扩大范围。

Q&A

Q: 两个月的实习，能做到这种程度吗？是不是有点美化了？

技术上说，这两件事确实不难。AI Agent 那个，核心操作就是清洗知识库和换数据格式，不涉及模型训练或架构改造。数据治理那个，主要是飞书公式和一些数据清洗脚本。两个月做完这些是够的。真正花时间的是前面说的”侦探工作”——在组织里找到权威的数据源、说服相关的人配合、理解每张表的业务逻辑。这些软性的工作占了总时间的一半以上。

Q: “最小原型破局”这个方法论，有没有失败过的时候？

有。后来在字节的实习里，我设计了一套层级化的生图模型评估框架，也试过用最小原型的方式推——先在一个子场景上跑通，展示效果。但那次没有成功，因为那个方案改变的不是一列公式，而是整个评估 pipeline 的逻辑。最小原型的前提是”不影响现有流程”，而那个方案天然就需要替换现有流程。所以方法论不是万能的，它有适用边界：当你要改的东西足够小、足够独立时，最小原型很好使；当你要改的是系统级的东西时，你需要的是决策者的信任，而不是一个 demo。

Q: 传统行业做 AI PM 和互联网做 AI PM，最大的区别是什么？

信息密度。互联网公司里数据也可以很混沌，但阻力的来源不一样。互联网追求快速落地，推 AI 的阻力是”我们来不及”——不想妄增复杂度，怕拖慢迭代节奏。传统行业的阻力是”我们不需要”——流程已经跑了很多年，大家有一种求稳的惯性，改变本身就是风险。前者你需要证明方案足够轻量、不增加负担；后者你需要证明现状确实有问题、改变是值得的。最小原型破局在两种语境下都能用，但对话的姿态完全不同。