近期，一些寻找AI领域工作的学员反馈，在面试中常被问及模型微调相关的问题。由于之前学习时未深入掌握，他们希望能对此进行补充学习。

坦白说，我个人对模型微调这个话题怀有复杂的感情，因为它承载了一段并不愉快的记忆。

时间回到大约两年前，当时国内技术圈仍在热衷于模型预训练与微调，这一过程常被戏称为“炼丹”。不知是幸运还是不幸，在那个阶段，我们的团队也投入了大量精力进行模型训练。

彼时，可供企业选择的基座模型寥寥无几，主流选项包括 Bloom、LLaMA、GLM 甚至 GPT-2。

计算资源的成本更是高昂，相较现在可能贵出十倍不止。当时，获取GPT-4-32K API账号异常困难（黑市价格一度高达八万元），有些团队在夜间进行数据训练时，若未做好成本控制，一不小心就可能让十几万元的投入付诸东流。

数据成本同样惊人。获取高质量训练数据的渠道非常单一，也远未有现今“数据蒸馏”这类高效方法。部分原因是技术限制，另一部分则是根本难以获取足量的API调用权限，即便获得，其Token费用也令人望而却步。这种情况直到2024年，随着微软Azure云服务账号的开放购买才逐渐好转。

然而，问题也随之凸显。许多受限于技术和资金实力的公司，耗费巨资和决心训练出的中小规模模型（以7B、13B参数为主），往往刚取得一点进展，就遭遇了GPT系列版本更新或LLaMA 2等更强基座模型发布的降维打击，导致前期努力几乎前功尽弃。

耗费心血训练出的小模型，其效果很快被财大气粗的巨头发布的大模型所持平甚至超越，而团队已无力承担新一轮的训练成本。

另一方面，绝大多数公司在模型研发方面的能力几乎为零。即便训练出的模型在特定任务上表现尚可，其应用场景也极为有限，通常只能处理类似关键词提取的简单任务。核心原因在于，当时超过90%的国内团队都难以有效扩展模型的上下文处理长度，具备此项能力的人才凤毛麟角。

最终的结局是，许多技术积累不足、资金不雄厚的公司，在初步尝试后便迅速放弃了自研模型的技术路线，甚至产生了一种被AI浪潮裹挟、不得不跟风却又力不从心的挫败感。在这场全民“炼丹”的狂欢中，不同公司承担的试错成本虽各有差异，但数百万元的损失估计是普遍存在的。

我至今清晰记得，在一次项目复盘会上，老板质问我当初为何选择这条技术路径，是否清楚试错成本有多高。当时我羞愧难当，垂着头缩在座位上，硬是无法抬头面对，被持续批评了两个多小时，事后足足一个月都没能从那种压抑中恢复过来。

或许有读者会问：既然风险如此之高，为何当时仍有众多公司前仆后继地投身自研训练呢？

这或许是时代背景下的局限性使然。当时国内的业界风气普遍视“套壳”应用为耻，强调底层技术的自主性。我记得这种风气的转变，大约始于Cursor这类优秀AI编程工具的出现，大家忽然发现，基于强大基座模型进行应用开发（即所谓“套壳”）也能创造出极具价值的产品，观念才逐步开放。

因此，一个核心问题便浮现出来：在当前基座模型能力如此强大的背景下，究竟在什么场景下，我们仍然需要考虑对模型进行微调？

为何需要微调

首先，我们需要明确两个通常不需要进行模型微调的典型场景：

无需微调的场景

第一，风格、语气与品牌的个性化定制。在过去，模型的上下文窗口有限，理解能力较弱，容易遗忘指令，因此我们希望将特定的风格“注入”模型底层，以求一劳永逸，微调便成为首选。如今，随着大模型指令遵循能力的飞跃，仅凭精心设计的系统提示词（Prompt）就足以达成目标，这一场景下的微调需求已大幅减少。

第二，复杂结构化输出与特定格式遵循。例如，将客户的自然语言需求自动转化为公司内部标准的JSON格式工单。以往进行此类微调，也是出于对模型原始能力的不信任。现在，通过Few-shot Prompting（少样本提示）等技术，大模型通常能出色地完成这类任务，微调的必要性随之降低。

接下来，我们探讨几个仍然值得考虑进行模型微调的适用场景：

建议微调的场景

第一，在特定专业领域内提升模型的“直觉”与输出“确定性”。

虽然检索增强生成（RAG）技术可以有效地为模型补充领域知识，但微调能够从更深层次塑造模型在该领域内的思维模式。

例如，一个代码生成模型在使用某公司全部内部代码库进行微调后，不仅能调用这些代码（RAG的功能），更能深刻理解该公司特有的编程规范、私有库函数的使用惯例、甚至常见的缺陷模式。它会倾向于以更符合该公司工程师习惯的方式去思考和建议代码。

在此场景下，RAG扮演了“资料库”的角色，而微调则旨在将行业的“标准操作流程”（SOP）内化到模型中，使其蜕变为真正的领域专家。我们团队之前进行的芯片编程辅助模型项目就采用了微调方案，部分原因正是需要让模型学习的内部门类与规则过于庞杂。

第二，出于成本与响应延迟的优化考虑。

对于需要高频调用模型的大型应用，每一次请求都调用云端大型模型的API，累积的成本将非常可观，且网络延迟可能无法满足实时性要求。此时，对一个轻量级模型进行特定任务的微调便具备了应用价值。

但必须明确一点：我们对小模型进行微调，其目标绝不是让它成为一个缩小版的通用对话模型，去处理开放域、创造性的对话任务。

这类特定任务型小模型微调的真正价值在于，高效处理那些定义明确、边界清晰、且对响应速度和成本极度敏感的任务。

典型的适用场景包括：

1. 输入输出高度标准化：输入通常是短文本（如用户查询语句、关键词），输出则为结构化数据（如分类标签、布尔值、特定的JSON对象）。
2. 高频率、低延迟要求：每秒可能需要处理成千上万次请求，要求毫秒级响应。
3. 强领域依赖性：任务逻辑高度依赖企业内部的特定业务规则和数据。

在此进行小结：如果目标仅仅是补充知识或最新事实，应优先考虑RAG，因为微调并不擅长“记忆”大量具体知识；如果目标是重塑模型的输出范式（包括文本风格、规则逻辑、格式要求与处理速度），则微调是更合适的选择。

下面，我们将对这两个微调场景展开详细分析。

提升领域直觉与输出确定性

此场景的核心逻辑是：RAG负责补充“知识”，微调负责塑造“思维”。目标是让模型的回答从“基于检索资料的复述”升级为“遵循行业SOP的深度思考与稳态输出”。在行动前，必须明确以下几点：

一、何时应考虑微调？

需要注意以下几个判断点：

1. 任务所涉及的规则或SOP能够被清晰、明确地梳理和定义。不要试图用一个开放性的、定义模糊的命题来微调模型，那将导致灾难性的结果。
2. 在当前大模型的基础能力上，无论如何优化提示词，任务准确率都卡在某个瓶颈（例如95%）难以突破。
3. 存在必须严格遵守的业务边界或不可触碰的红线规则。
4. 其他需要考虑的特定因素…

在明确准入条件后，便来到了微调的核心环节：数据准备。

二、数据从何而来？

此场景所需的数据通常是高度结构化的，主要包括两类：

1. 整理好的“金标准”：例如完整的SOP文档、公司内部规范、合规条款等。数量可能在1千至5千条之间，关键是一条数据就应包含一个清晰的“判断锚点”或“决策依据”。
2. 负面案例（反例）：收集常见的错误做法及反例，同样需要1-5千条，并明确标注错误原因及正确做法。

特别需要注意的是：微调数据不应只是简单的问答对（Q, A），而应包含中间的推理过程（Q, Reasoning, A）。

以芯片编程为例，数据不应仅仅是“需求描述 -> 生成代码”，而应该是“需求描述 -> 推理分析（为何此处应使用该私有库函数？需要考虑哪些时序与功耗问题？） -> 最终代码”。

通过这种方式微调出的模型，在面对新问题时，会更倾向于模仿预设的推理路径，而不仅仅是输出一个答案。其输出的确定性恰恰体现在其推理过程严格符合我们设定的业务逻辑与规则。

芯片编程的例子可能过于专业，这里举一个更通俗的案例：

三、数据案例剖析

正面案例样本：

Q：“你好，我刚才下班回家，把车停在小区路边了。吃完晚饭下来发现副驾驶的车窗被砸了，车里放的一个笔记本电脑包不见了。电脑是公司财产，估计值一万多块钱。我现在该怎么办？”  
  
Reasoning（推理过程）：  
事件定性：用户描述的核心是“车窗被砸”和“财产丢失”，这是一个典型的“机动车盗抢”案件，应优先归类到“盗抢险”，而非普通的“车损险”。  
责任初判：车辆处于停放状态，且被盗物品为车内财产。根据常见保险条款，盗抢险通常涵盖车内财产损失，但需确认用户是否投保了“机动车盗抢险”及“车内财产附加险”。初步判断保险公司有赔付责任，但需核实具体保单。  
关键信息提取：需要提取的结构化信息包括：事发地点（小区路边）、受损部位（副驾车窗）、损失物品（笔记本电脑）、损失金额预估（10000元）、案件类型（盗抢）。  
后续行动建议：指导用户立即报警（盗抢案件必须要有警方证明）并保护现场。  
  
A（最终回答/结构化输出）：  
{  
"案件类型": "盗抢险",  
"保险责任初步判断": "可能赔付，需核实保单",  
"关键信息": {  
    "事发时间": "晚间",  
    "事发地点": "小区路边",  
    "车辆损伤": "副驾车窗被砸",  
    "财产损失": "笔记本电脑包",  
    "损失金额预估": "10000元"  
  },  
"下一步建议": [  
    "请立即拨打110报警，并获取案件回执或证明。",  
    "请对现场和车辆受损部位进行拍照留存。",  
    "请通过App上传保单信息，核实具体险种。"  
  ]  
}

数据准备就绪后，便可选择合适的工具进行微调。由于此场景在一般公司中应用相对较少，我们在此不展开工具使用的具体案例，读者可自行体会其流程。接下来，我们探讨第二个典型的微调场景。

昨日，我在年终总结中提及了“管理无用”的观点，随后便与一些关注者展开了热烈的探讨。

或许之前的表述存在些许偏差，严格来说，并不能断言管理毫无用处。我更想强调的是，业务的增长与管理之间并无直接的因果关系，管理更像是保障团队或企业运营下限的基石。

随后，有朋友希望我能举些实例。回顾过去一年中“AI+管理”的实践，确实积累了不少案例，它们正是下图所示框架中的一个具体分支：

在销售管理的日常中，许多企业都会反复遭遇如下困境：

1. 同一个客户，被两名销售代表同时联系。
2. 客户感到困惑：“你们不是同一家公司的吗？”
3. 销售之间相互争执：这个客户的业绩究竟应该算谁的？
4. 管理层更为头疼：业绩、提成、责任归属根本无法厘清。

这种情况，在销售管理领域有一个非常典型的术语：撞单。

表面上看，这似乎是销售人员之间沟通不畅所致。然而，从大量企业实践来看，撞单问题几乎从来不是由“人”的个体因素直接引发的，其根源往往在于管理体系本身。这也印证了我们前述的观点——管理是用于保障下限的。通常情况下，问题的症结可以归结为：

系统未能有效兜底 + 业务流程不够清晰 + 规则缺乏自动化执行

若想从根本上降低乃至消除撞单现象，答案唯有一个：引入CRM系统，将依赖个人自觉的“人治”模式，转变为由系统规则驱动的“系统治理”模式。

具体的实施路径相当明确：首先梳理标准作业程序，随后通过系统将其固化实现。这类工作的核心工作量在于前期的流程梳理与规则设计，而这本身便是最基本且关键的管理动作，是机制构建不可或缺的一环。

我曾深入研究市场各类解决方案，并融合主流CRM的最佳实践，最终将其拆解为四大防撞机制，方便企业直接参照搭建并落地执行。

当然，为了提升方案的附加值，其中融入了不少AI元素。以下是具体的操作过程与分析：

一、 客户身份的唯一识别：构建精准记忆

许多企业在初期不愿投入过多资源，试图仅通过规章制度来管理撞单，但却忽视了一个根本前提：系统必须首先能够准确识别“谁是谁”。

唯一识别标识

在CRM系统中，每一位客户都必须拥有能够被系统准确识别的身份标识。常见的客户识别字段包括：

• 手机号码（针对个人客户或ToC场景最为可靠）
• 公司全称（针对企业客户的基础字段）
• 统一社会信用代码（ToB场景下的强校验依据）
• 电子邮箱、微信号（作为辅助识别手段）
• 线上线索的IP地址与表单信息（用于线索合并判断）

当这些字段被正确配置后，CRM系统便能在客户录入、批量导入、分配流转等各个环节实现：

• 自动识别并提示重复客户
• 预警潜在的撞单风险
• 阻止创建完全重复的客户档案
• 给出是否进行合并的智能化建议

系统基于规则的判断，远比人工记忆与核对更为稳定和精确：

灵活的去重策略

一套成熟的CRM系统，通常支持多种去重策略的组合应用，而非单纯依赖“销售人员的自觉性”：

• 强制去重：一旦系统发现重复记录，将直接禁止创建。
• 提醒去重：系统提示存在重复风险，由销售代表确认后处理。
• 自动合并建议：对于多条高度相似的客户记录，系统会引导用户将其合并为一条完整档案。

企业可以根据自身所处的业务发展阶段，灵活配置策略，而非采取一刀切的方式：

集团客户的层级识别能力

在ToB业务领域，许多撞单并非源于简单的“重复录入”，而是表现为：同一集团旗下不同的子公司或部门，被销售人员当作完全独立的客户进行跟进。专业的CRM系统通常支持：

• 建立“集团客户→子公司→部门”的多层级组织结构。
• 实现集团层面客户的统一识别。
• 在权限管控下，支持跨组织跟进记录的有限共享。
• 提供跨组织撞单的智能预警。

从而从系统层面，规避“看似不同实体，实则归属同一决策体系”的撞单情况：

二、 AI驱动的智能分配：确立清晰归属

客户的归属权不应通过“争抢”来决定，而应由系统基于规则进行分配。如果仅以“谁先联系到客户”作为归属标准，撞单几乎无法避免。

客户归属由AI自动分配

在成熟的CRM管理体系中，客户资源归属于公司，而非任何个人。

销售人员只是被系统“分配”了跟进职责。CRM通过统一的线索入口，自动完成分配并将客户与负责人绑定：

• 确保每一条线索只有一个明确的责任人。
• 杜绝多人同时跟进同一线索的情况。
• 分配过程迅速，规则透明， resulting in clean data.

常见的自动化分配规则包括：

• 轮询分配（均衡团队工作量）
• 按地理区域分配
• 按产品线或业务线分配
• 根据不同来源渠道制定差异化分配策略

近期，一个令人振奋的消息传来：此前拖欠尾款的公司支付了部分款项，并表现出深化合作的意向。整个故事颇为曲折，还需追溯到去年。当时原本约定的项目款项，因为一起突发事故而未能结清，虽然我心存不满，却也无可奈何。

其次，之前为他们部署的那套AI客服系统确实运行高效，他们几乎裁撤了整个客服团队，从而节省了大量人力成本。

随后，老板尝到了甜头，近期萌生了一些新想法，例如增加知识库功能、进行用户画像分析等。

然而，他们内部技术团队的实施效果不佳，甚至导致原有系统频繁出现BUG。于是，对方**“良心发现”**再次联系了我。这只能感慨其精打细算，每一分钱都花在刀刃上！

不过，此事对我个人产生了一定的冲击：

说来有些讽刺，我本人颇为看重的AI项目进展缓慢，而一个我曾不太瞧得上的AI客服系统，竟让一家公司念念不忘？

是否我认为优质的项目与市场实际需求之间存在错位？那些我觉得技术含量不高、众人皆在做的产品，或许正是市场所渴求却难以获得的？

因此，我们今天有必要共同审视这个我曾认为技术层次较低的AI客服项目。

项目概述

首先，从项目定位来看，这个AI客服属于外包项目，采用的技术也较为常见，因此我最初对其重视程度有限。

其次，项目目标主要分为两大板块：一是攫取平台流量，二是通过AI客服实现降本增效。整体全景如下图所示：

其具体形式是帮助企业在短视频、文档等内容领域进行创作，随后在多平台进行投放以获取流量，最终由客服团队完成转化：

例如，若企业销售化妆品，会在小红书平台维护上百个账号，每天撰写一篇原创内容，再借助AI生成上百篇不同维度与标题的文章。目的十分明确：通过规模效应，确保用户搜索关键词时总能找到企业信息。

需要注意的是，当前各大平台对这类AI灰产行为打击严厉，因此该策略的核心除技术外，还需解决账号资源问题，即必须能获取大量真实可用的账号。

目前，只要涉及商品推广的内容，往往出现一台计算机控制多个AI程序在全网刷数据的现象。您所浏览的许多信息可能都经过人为操纵：

所有流量投放的终极目标是获取销售线索，将公域流量转化为私域流量，随后展开一系列销售活动。此环节同样涉及AI提效的应用：

整个方案的设计难点不在于技术，而在于业务逻辑的梳理。这里简要列举两个AI提效的具体例子：

第一，存在一个模块需用户上传身份证件。过去由客服人工誊写信息，现在通过OCR结合AI技术能迅速处理，此举至少节约了两个人力。

第二，电话销售体系的线索分配逻辑较为复杂。企业可能将线索直接分配给销售冠军，或根据销售效果动态分配；也可能将线索发布至群组，采取先到先得模式。

由于线索数量庞大（达数千条），原先需要五人专职进行分配。该环节完全交由AI处理后，成功节省了五个人力。

以上便是获取线索后企业业务流转的真实情况（AI客服仅占其中一环）。可以看出，如果仅讨论工作流中的AI应用，AI在该企业中的占比可能不足百分之二十，而这或许正是AI在企业应用中真实的渗透率。

最后，我们将AI客服单独提取出来，重点探讨其内部技术团队未能妥善处理的部分。

AI客服系统详解

AI客服系统显著提升了客服团队的工作效率，使五十人团队能够完成两百人的工作量：

此处先稍作吐槽：AI客服系统本身具备巨大价值，但后续发展众所周知，AI技术常被导向裁员方向，这虽显无奈却难以完全避免…

回归正题，每当提及客服机器人，人们的第一反应往往是：提示词工程、RAG技术、向量数据库…

甲方团队的确也沿用了这套模式：粗暴地将文档全部导入，编写一段简略的提示词，最终效果一团糟。当无法向上级交代时，便开始抱怨模型能力不足…

此处借鉴训练营中某产品负责人的吐槽颇为贴切：

我终于明白为何难以理解公司程序员们的工作了。他们在技术架构上采用了一种“AI最大化”思路：

某个开源技术无效就更换另一个，单智能体不行就尝试多智能体，全部试验过后便宣称AI已达上限，再无优化空间，只能等待新的开源技术出现再循环一遍。

我有时确实好奇，忍不住询问他们如何量化这种上限、是否存在过程方法论？而这批程序员往往回答无法量化、难以沉淀，声称只是运行他人成果而已。

我总感觉哪里不对劲，但因不懂技术而难以辩驳，只能听之任之。如今结果确实不尽如人意，看来需要我来为他们规划技术路径了！

RAG技术并非万能良药，其应用需分场景考量。首先要理解业务，其次梳理标准操作流程，然后设计数据框架，最后才能上线测试并收集反馈。

不同场景对应不同的标准操作流程及匹配的数据结构。若期望仅凭粗暴的技术手段解决所有业务问题，这并非傲慢，而是缺乏思考。

然而，当我们着手解决时，程序员们又开始抱怨：公司在该领域历史上几乎没有任何数据积累啊？ 这里可能需要稍作展开说明。

实践案例：从典型到实现

实际上，企业通常存在数据积累，只是较为分散。常见的处理方法是抓取典型样本，例如找出公司的销售冠军，并以此为基础构建其数字分身。这主要包括两个方面：

1. 将销售冠军的工作习惯转化为标准操作流程，即其与客户沟通的具体策略。
2. 整理相关数据，如销售冠军的话术素材，这些数据最终需与标准操作流程映射。

建立了这套标准操作流程后，整体框架便得以形成。随后可依据此框架组织更多的流程模板与话术资源。

为保护客户技术隐私，我们以昨日讨论过的PageIndex技术重现案例：PageIndex案例，向量库已死、RAG永存：模型进步再次干死过时技术

首先是整理出的销售冠军内容：

文档：销售SOP手册.pdf  
第2章 核心价值要点（p12）  
  - 降本：同类替代品平均减少人工 25%（测算方法见附录）  
  - 提效：典型流程时长从 3 小时缩短到 45 分钟  
  - 风险：提供操作留痕与可回溯审计  
  - 上手：1 小时完成基础配置  
  
第3章 异议处理（p18）  
  3.1 价格太贵（p19）  
    目标：把“价格抗性”转为“价值/风险下降/上手简单”  
    触发：贵/太高/预算/折扣/再看看  
    禁忌：承诺具体收益天数；贬损竞品  
    模板 T-3.1-A（标准版）：  
      1) 共情（理解谨慎）  
      2) 价值要点对齐（引用第2章 p12 的要点）  
      3) 风险降低与上手门槛（同样引用 p12）  
      4) A/B 收尾（A：先体验；B：我发一页价值清单）  
  
  3.2 我再考虑一下（p21）  
    模板 T-3.2-B：  
      1) 错失焦虑（非价格型：时间/精力成本）  
      2) 二选一（A：15 分钟演示；B：明早前发体验指引）  
      3) 软担保（支持试用/可回退到基础方案）  
  
第4章 成交与跟进（p28）  
  4.2 逼单子树（p29）  
    路径：异议→松动→试用/演示→收尾（付款方式/排期）  
  
第7章 售后与保障（p30）  
  - 7.1 支持试用与配置回滚  
  - 7.2 技术支持 SLA：工单 4 小时内响应  
  - 7.3 交付可回退（基础版不丢数据）

其次是经过PageIndex解析后的结构化内容：

承接上一篇文章的讨论，我简要回顾了去年在AI+管理领域的创业尝试，并得出了一个个人结论：面向企业（2B）的服务可能并不适合我这种偏重产品研发、与销售端距离较远的人。之后，许多朋友表现出浓厚兴趣，希望我能深入分享更多细节。

具体来说，一旦展开细节，整件事就显得有些微妙甚至令人费解。我首先提出一个反直觉的观点：一套声称能提升1000%效率的AI解决方案，在目标企业里很可能根本无法实施落地…

以下通过实际案例来具体阐述这一现象。

案例解析：身家亿万的‘传统’企业家为何拒绝AI提效？

去年十一月，经过多次引荐，一位老板邀我前去**“洽谈合作”。以往这类会议通常在办公室对着PPT进行，但这次地点选在了一家茶楼**，仅从场所选择就能看出此次会面的非同寻常。

果不其然，一位气场强大、精神矍铄的老板，声如洪钟，招呼服务员上茶后便递烟。由于我们不吸烟，他便自顾自地一支接一支抽了起来…

初步交流得知，他早年似乎从事中小型水电站业务，近年转向自来水厂运营。他深切感受到公司效率低下，希望借助AI技术实现降本增效。

随后，我进行了详尽的自我介绍，提到曾投入数千万研发国内首款AI医生，并列举了其他项目。期间，我敏锐地察觉到随老板前来的某位总监，嘴角泛起了一丝难以察觉的笑意…

细细想来，这场景确实有些突兀：颇有几分在街头小店夸夸其谈，声称刚与特朗普达成数亿生意的荒诞感…

经过后续几轮深入接触，我发现即便不引入任何AI工具，只需优化现有的人效管理，该公司就能实现500%的效率提升；若再结合AI，理论上完全可能达到1000%的提效空间…

根本原因在于，员工的工作量严重不饱和，大多数人每日有效工作时间不足两小时。午后在厂区里，最常见的“集体活动”竟是打麻将和斗地主…

在调研中，我提出了多项数字化改进策略，却几乎都被那位总监逐一驳回。例如：他们坚持采用手动签到、手写报告，再驱车前往各个厂区实地收取；又如，他们一定要亲自前往某厂进行安全巡查，随后要么回宿舍休息，要么继续麻将娱乐…

坦白说，我有些羡慕他们。他们真心感激时代进步，如今有了抖音和各种小说，除了打麻将，又多了许多消磨漫长工时的娱乐方式。从他们身上，我看到了人类面临的两大根本挑战：

第一是解决温饱，第二是填饱之后所有无所事事的时光！

最终，与这家传统企业的合作自然无疾而终。他们需要的并非简单的AI赋能，而是一场翻天覆地的系统性变革，我自认尚无此能力。

类似情况并非孤例。我的一位好友曾从事货运行业，他们开发了一项能便捷检测货车是否超载的技术，却遭到了货车司机群体的坚决抵制。具体原因虽不明确，但那个本可极大提升效率的技术项目，最终也只能搁浅。

由此可见，优秀技术产品的落地应用，始终需要妥善应对复杂的人性因素。

两个世界：AI拥趸的狂热与90%人群的冷漠抵制

过去一年，我仿佛目睹了两个平行世界。不到10%的群体不断惊叹于AI的迅猛发展，并热衷分享各种效率提升案例，例如：

1. 某电话销售团队，客服人员裁减50%后业务运转如常；
2. 利用工具十分钟内生成上百篇图文并茂的热门文章；
3. …

当这一小部分人陷入AI带来的效率焦虑时，其余超过90%的大众却似乎无动于衷。以我身边的妻子为例，她依然每日沉浸于各类网络小说和轻松综艺节目…

然而，当AI真正触及他们的实际工作时，潜意识的反应往往是**“排斥”**。

去年担任某公司AI顾问期间，我发现其人力资源部门的工作方式极为原始：需要将PDF简历逐一录入内部Excel表格，同时还需把入职员工的身份证等信息手动输入另一份Excel员工花名册。

这项工作在繁忙时段甚至需要投入整整两名员工的全天时间！于是，我们花费一天搭建了一套自动化工作流，核心不过是简单的OCR识别结合AI信息提取。这立即使他们的效率大幅提升，HR人员欣喜致谢，感慨这解决了大难题。

然而两个月后，我发现他们依然在手动执行上述操作。询问原因，答复是AI工作流不好用、存在BUG，但进一步追问具体BUG时，却又语焉不详。最终私下了解到的真实答案是：近期工作量不饱和，他们认为手动处理这些工作更好，至少能让自己显得“忙碌”一些…

类似案例屡见不鲜。另一家电话销售公司，每日需处理超过4000条销售线索，为此专门设立了一个由3人组成的线索分配策略组。该小组每日加班至深夜，仍常出现线索分配不及或错误分配，导致下游客服团队空转的情况。

于是，这次我们花费约一周时间，深入理解其工作模式，并为其开发了一套AI线索自动分配工具。这无疑再次解决了他们的核心痛点，甚至使得以往需要3人完成的工作，现在连1个人力都显富余！

但一段时间后，当我回访询问优化建议时，发现他们根本没有使用该系统，仍是原班人马加班加点手动处理。理由很简单：你的AI工具BUG太多！而且他们彻底不愿再尝试任何新工具了…

总结反思：AI创业的教训与未来方向

技术的演进遵循直线逻辑，追求绝对的最优解；而组织的运作则遵循曲线逻辑，强调平衡与稳定。

这意味着：理论上的最优策略，在现实世界中未必行得通。这一点在我过往的管理策略实践中已有深刻体现。

作为一名技术背景出身的AI创业者，我曾坚信“效率即正义”，手握自以为能改变世界的“AI利器”。但现实却告诉我，这记重拳往往打在了一团名为“人性惯性”与“组织惰性”的棉花上，无处着力。

这段经历曾让我陷入长时间的消极情绪，因为它实实在在地冲击了我原本“坚固”的认知：AI技术落地的主要障碍，往往并非技术瓶颈，而是深层的管理问题与人性博弈。

我所设想的“1000%提效”，在现实中常常遭遇组织对“平衡与稳定”的内在需求。

孤立的管理体系本身价值有限，也难以简单复制移植。你无法将一套自认为高效的系统，强行植入一个安于现状的生态。员工抵制AI工具，并非因为BUG太多，而是因为这套系统威胁到了他们既有的、舒适的生存状态与工作节奏。

因此，AI创业的重要教训在于：必须先深刻理解即将踏入的“人性战场”，而非仅仅高举技术利剑盲目冲锋。

综上所述，一个核心结论是：面向企业的AI服务（AI 2B）确实艰难，需谨慎进入。关键在于建立筛选逻辑，选择那些自身具备强烈变革意愿的公司，尤其是一把手的决心必须坚定。切勿试图强行介入，否则很难取得良好结果。

上周，AI训练营第一批学员正式毕业。最终课程平均评分达到80分，从最低70分到最高95分不等，甚至有几位学员主动推荐课程。这让我如释重负——总算没有被误解为“割韭菜”。

尤其想分享其中一位产品负责人的深刻感慨：

我终于明白，为什么过去总搞不懂公司里程序员们在做什么了。他们采用的技术架构思路是“AI Max”模式：一个开源方案不行就换另一个，单智能体效果不佳就转向多智能体。当所有方法都尝试过后，结论往往是‘AI的能力上限就到这里了，没有优化空间，等下一代新技术开源再说’。

我有时忍不住追问：你们如何量化这个所谓的上限？有没有系统化的过程和方法论？而他们的回答通常是：无法量化，也无法沉淀，都是拿现成的东西跑一遍而已。

我总觉得哪里不对劲，但苦于不懂技术，无法提出有力质疑，只能听之任之。现在好了，既然这条路确实走不通，那就由我来为他们设计技术路径！

实际上，上述场景正是许多公司面临的共性问题：由于AI项目的入门门槛极低，导致整个团队可能没有一个人真正理解AI项目的内核，也能拼凑出一个70分的产品。然而，当需要从70分优化到80分时，整个团队便束手无策。

根据过往经验，这类试错的成本，少则50万，多则上千万。通常，技术负责人在经历两三次失败后，才不得不真正深入探索可行的技术路径，而这一探索过程本身的成本，往往以百万元计。

于是，困境出现了：公司投入百万级别的AI项目，其产出却如同玩具般简陋。当你询问技术负责人如何改进时，他/她很可能一脸茫然，最终给出标准答案：“当前模型的能力就是这样了，我也没办法。”

最终的结果是，管理者们对AI的期望值大幅降低，认为行业泡沫过大，不愿持续投入。这也导致从2025年至今，超过80%的公司停留在搭建各种AI工作流的浅层应用，并未真正涉足AI项目的深水区。

这片深水区至少包含以下三个核心层面：

1. 认知知识化与数据组织：如何将模糊的认知系统地整理为可用知识；或者，在已有知识的情况下，如何高效地组织相关数据。
2. 数据交互与反馈循环：数据应如何与AI系统交互，以确保AI每次都能获取到最相关的信息。如何识别因数据不足导致的AI问题，并利用生产数据构建反馈系统来持续优化知识库——这正是我们常说的“数据飞轮”，它是数据工程的一个重要分支。
3. 意图识别：理解用户或系统的真实意图，这是实现精准响应的最后一道关卡。

如果要将这个“深水区”进一步提炼，浓缩成面试中的一句话，那便是：定义AI项目的模型边界，或者说，构建AI项目的可观测性。 这里的可观测性，正是无数技术负责人苦苦追寻的、清晰可落地的技术路径。

然而，这句话背后隐含着一系列复杂的背景知识。那么，是否存在一种更简单的理解方式呢？答案是肯定的。

可观测性

近期授课时，我反复强调一个观点：开发AI应用，必须理解模型的能力边界！ 这里的“模型边界”引出了AI应用的两大基本流派：

1. AI Max：凡是能用AI解决的，就尽可能使用AI。
2. AI Min：凡是能不用AI解决的，就尽量避免使用AI。

这三句简单的概括，直接指向了RAG技术先驱之一Douwe Kiela的核心思想：关注AI项目的可观测性，而不仅仅是准确性。

在AI项目中，可观测性比单纯追求准确率更为重要。 在确保基础准确率达标之后，重点应转向对错误的归因追溯、全流程的审计追踪以及系统性错误分析。进而，需要建立反馈闭环与监控系统，确保项目合规并实现持续改进。

在AI项目中，追求100%的准确率几乎是不可能完成的任务。即便能达到90%或95%的准确率，企业当下更关心的是如何处理那缺失的5%或10%——即出错的部分。当错误发生时，我们该如何应对？

除了基础准确性外，关键在于如何管理和应对“不准确”，这就需要引入可观测性。我们必须能够系统性地评估模型表现，并确保存在恰当的审计追踪机制，尤其是在金融、医疗等受严格监管的行业。

而这里所强调的可观测性，只有在**“能不用AI就不用AI”** 的模式下才更容易实现。其背后体现的是对模型边界的深刻认知：追求完美的准确率不现实，核心是要知道错误发生在哪里、为什么会发生、以及如何改进！并且能够证明整个技术框架是闭环、可重复、可溯源的！

这里的 “哪里错、为什么错、怎么改”，恰恰是前文所述众多技术负责人难以回答的终极问题。今天，我们就通过一个简单的案例，来解释什么是‘能用AI就用AI’，什么是‘能不用AI就不用AI’，以及什么才是‘AI项目的可观测性’。

模型边界

此前AI课程学员较多，需要一个排班系统。基本需求如下： 学员在微信群中发出自己每日的空闲时间段，由AI自动统计出所有人都有空的时间，若满足条件则自动预约会议。 学员在群中的发言示例如下：

A：20.00-22.00有空  
B：18-20点没空，其他都可以  
C：二十点后可以；  
D：下午4点前没空；  
E：我随便了，都行；

当然，实际系统会包含更多功能，如提醒、少数服从多数的协调规则等，但其核心就是一个时间匹配算法。

一个看似简单的需求，却足以清晰地阐释模型边界的概念。首先，我们来看“能用AI就AI”的技术路径。

一、能用AI就AI

采用全AI方案非常简单，只需将所有聊天记录一股脑地输入给大模型，并附加指令：“请问今天我该安排什么时间上课？”

GPT的回答示例：

DeepSeek的回答示例：

在简单场景下，“能用AI就AI” 往往是最优解。包括许多智能体（如Manus）在处理简单任务时，表现确实出色。

接下来，我们看“能不用AI就不用AI”的方案。

二、最小化AI应用

所谓最小化AI应用，是指只在绝对必要的地方使用AI。在这个案例中，唯一必须使用AI的环节是关键词提取，即语义识别每位学员的空闲时间陈述：

1. A：空闲时间段为 20:00 - 22:00。
2. B：18:00 - 20:00 没空，其他时间空闲。
3. C：二十点后可以，即 20:00 后空闲。
4. D：下午4点前没空，即 16:00 后空闲。
5. E：所有时间都空闲。

提取出明确的时间段后，剩余的排班匹配逻辑则用传统算法实现。这立刻引出一个新问题：在最小化AI应用的策略中，如何判断何时必须使用AI？

三、泛化能力

答案很明确：当场景充满泛化需求时，就必须使用AI。例如上述ABCDE的多样化表述，很难用固定的正则表达式完美匹配。类似这种对关键知识（信息）的提取，只能依赖AI的理解能力。

先前我曾探讨过AI项目团队应如何搭建的问题（参阅文章：《AI团队组织结构该如何设计？》）。文中提及一个观点：在项目初期，产品经理这个岗位其实缺乏实质意义。部分读者可能感到诧异，因为在过去的职业转型路径中，产品经理往往是许多技术或测试人员向往的角色，例如从测试或开发转向产品。如今却被告知这个角色可能不再必要，这难道不是颠覆性的吗？要透彻理解这一观点，我们或许需要追本溯源。

产品经理的“权柄”何在？

若要用一句话概括产品经理的核心权力，我认为是：产品经理通常是产品或项目成果的验收者。换言之，产品经理往往拥有对产品（从测试完成到正式上线前）的首次评价权。更进一步说，产品经理有时也被视为产品的定义者，但这一点在实际中往往较为模糊。在多数中小型企业中，产品的最终设计决策者通常是老板，老板本身就是“最大的产品经理”。倘若你真正拥有定义产品并拍板的权力，那么你的角色可能已超越纯粹的产品经理，更接近于公司高管。

综上所述，对产品好坏的评价能力，是产品经理赖以生存的基石，也是其能够对开发人员提出要求与指导的资本，毕竟他们处于工作流的上游。然而在当下，这块基石正变得松动，或者说其评价权已被很大程度上分割出去。我们可以通过一张全景图来审视：

这张图几乎涵盖了一个生产级复杂AI项目的全部关键任务。理解此图，便能明白为何产品经理的价值在AI项目中可能显著降低：

• 行业专家是整个AI项目的核心评价者。AI的回答是否优质、是否专业、存在哪些缺漏，都需要由他们进行评估，并将意见反馈给技术负责人。
• 技术负责人则是项目组的核心驱动力，承担承上启下的关键作用。他们需要评价与决策技术路径的优劣。此外，行业专家团队虽然能发现问题，但通常无法独立解决问题；任何问题的最终解决，都必须回归技术团队。

而产品团队在AI时代面临着比较尴尬的处境，主要原因有二：

1. 过去互联网产品的交互与审美范式已高度固化。如今想要设计一款产品，市面上通常已有大量可参考甚至直接借鉴的案例。
2. 关键在于，AI产品的核心交互往往只是一个极其简单的对话框。这极大地压缩了产品经理在交互设计与审美层面的发挥空间。更重要的是，产品经理通常缺乏评价AI回答专业性好坏的能力，这意味着他们部分丧失了对其产出的核心评价权。作为曾经产品验收环节的重要参与者（至少是执行者），产品经理的角色权重被大幅削弱。

相应的，以往对程序员的评价主要集中于代码质量，而现在逐渐需要加入对“提示词是否优雅高效”的考量。AI项目带来的变革，本质上是整个价值评价体系的重塑。

理解了这一底层逻辑后，我们可以进一步探讨，在中小型公司里，产品经理所承担的其他重要角色。

具备高度兼容性的项目协调者（PMO）

以产品“首次评价者”及修改建议（常为决策）提供者的传统角色来看，产品经理在实际工作中会有意或无意地承担起一个角色：团队的项目协调者（PMO）。

大家可能会发现，产品经理似乎天然适合这个角色。一方面，他们需要梳理大量信息，确保团队运作顺畅；另一方面，也需要确保产品在执行过程中不偏离既定方向。

然而，我认为产品经理在此岗位上最为重要的作用或许是：进行有效的向上管理，因为繁琐的汇报工作总需要有人承担……

程序员群体通常比较“务实”。他们在日常工作中，往往会优先选择对自身职业生涯最有助益的任务，或者说将时间精力投入到投资回报率更高的技能提升上。

因此，在互联网行业增长放缓之前，程序员普遍更倾向于默默编写代码。这几乎是一种“难以两全”的选择，只有真正写过代码的人才能体会其中的深度。以十年前的前端技术栈演进为例：

1. 最初可能只需精通JavaScript或CSS其中一项，便足以立足。早年许多专攻JavaScript的开发者甚至不擅长编写CSS，这听起来或许令人惊讶。
2. 随着行业竞争加剧，前端开发者开始需要同时掌握JS和CSS，这相当于涉及两套技术栈，各自熟练起来花费半年时间实属合理。
3. 竞争持续升级，仅精通前端还不够，还需涉足原生应用开发。于是Hybrid、React Native等技术应运而生。此时前端业务代码的复杂度已显著提升。
4. 但从业者众多，为了拉开差距，Node.js出现了，前端开发者开始向后端领域拓展。这其中存在不小的技术栈跨越，要达到熟练程度，半年时间绝不夸张。
5. 然而，无论是Node.js还是PHP，更多是语言层面的问题。数据库知识总需要了解吧？各种潜在的技术难点与性能瓶颈总需要应对吧？这绝非一年半载能够轻松掌握。我曾认识一位后端出身的朋友，在B站就因一个锁机制理解不透彻，直接导致了一次严重的线上事故。
6. 技术演进之路还在继续……

以上就是所谓“全栈工程师”的成长路径。可以看出，要达到公认的全栈标准，需要投入巨大的精力，绝非一朝一夕之功。这也引出一个现实问题：

真正靠谱的程序员，往往既没有时间也没有心思去处理产品相关的杂务，因为他们可能认为这些工作属于“通用性较低的低阶技能”。毫不夸张地说：

项目管理的核心，某种程度上就是任务清单加时间提醒，需要持续进行沟通、确认、汇报，并全程推动各方进度……

而承担这个协调者角色，实际上具备良好沟通能力的技术人员，往往比纯粹的产品经理更合适，因为他们更清楚团队中谁在认真工作，谁在敷衍了事。只不过过去他们大多不愿意接手这类工作罢了。但如今情况已发生翻天覆地的变化：

1. 市场遇冷极大加剧了行业内部竞争。
2. AI的出现显著提升了工作效率，并降低了成为全栈工程师的门槛。

于是，“你不愿意做，自然有其他人愿意做”的局面开始出现。当技术负责人（或经理）愿意主动承担项目协调者（PMO）的职责时，普通产品经理的地位就显得有些微妙了……

因此，产品经理当前的生存空间实际上正在被同步压缩。现阶段，嗅觉敏锐的产品经理已经开始积极学习Vibe Coding，至少掌握一些Coze或Dify的使用技巧——他们也试图在技术领域开辟新的战场。不难看出：当下正是行业重新定义各岗位职责边界的关键时期。

产品经理：企业的“翻译官”

综上所述，在AI项目从0到1的初创阶段，产品经理的传统价值确实有限。然而，当项目发展到一定规模，进入规模化扩张或商业化运营阶段时，往往需要协调市场、运营、销售等多方资源。此时，纯粹的技术背景人员可能会感到吃力。

例如，仅是与商务团队沟通需求这一项，技术人员就可能很不适应。销售为了达成交易倾向于过度承诺，而技术人员为了确保可行性则倾向于保守承诺。销售可能认为技术人员思维僵化，影响成交；技术人员则可能认为销售言过其实，给自己带来麻烦。久而久之，容易产生摩擦。

除非能从根本上解决这种因上下游立场不同而产生的结构性矛盾，否则更需要精通业务、具备跨部门沟通能力的“多面手”角色。我认为一个恰当的比喻是：产品经理是公司内部的“翻译官”。他们首先需要帮助老板“翻译”并传达战略意图，其次需要为各个部门“翻译”不同的业务语言和需求。

这不是技术专家或业务专家能否胜任的问题，而是比较优势的问题。谁更擅长此类沟通与协调，谁就应该承担相应职责。只不过，当项目进入规模化阶段、产品已然上线时，团队已非初创状态，角色分工也会随之演化。

核心结论与未来展望

最后总结核心观点：AI技术的兴起，对当前项目研发链条中的各个角色都带来了显著冲击，其根本原因在于价值评价体系被重塑。

一方面，AI产出内容的专业性需要行业专家来评判，这剥离了产品经理过往对内容价值的评价权。另一方面，我们每个人的工作过程与成果，也前所未有地暴露在AI的辅助分析与审视之下，这使得岗位价值必须回归到更本质的贡献层面来衡量。

一旦评价权重塑，团队的组织形态便被迫重组。尤其是在从0到1的AI项目中，一种更“原生AI化”的团队组合方式正在显现：让技术背景人员承担更广泛、更核心的角色。

但必须澄清，这并非主张“彻底取消产品职能”，而是指传统产品经理依赖PRD（产品需求文档）、传话、对齐等工作的“中间层”价值被系统性压缩了。更高效的新型团队结构可能呈现如下特征：

一、创始人成为实质上的首席产品经理

在AI项目初期，关键往往不在于挖掘海量需求，而在于清晰地定义AI产品的能力边界。对于“做什么”与“不做什么”，必须做出果断取舍。

根据近年在多家公司的观察，越来越多的CEO倾向于亲自深入业务一线：他们第一时间体验产品输出质量、亲自判断能力边界、亲自决定后续迭代的优先级。这或许是时代发展的必然要求，否则信息在“转述-再转述”的过程中会产生严重损耗，导致决策与执行速度大幅下降。

更进一步，增长思维也被更早地融入产品构建过程中：如何向用户清晰传达产品价值、如何在社区中验证需求、如何建立有效的反馈闭环，这些本质上都是产品工作的一部分，而非产品上线后才开始的“运营动作”。

总之，成功的AI项目，必然是“一把手”深度参与的工程。

二、产品经理转型为“Coze搭建能手”

当产品交互被简化为一个对话框时，产品设计的关键便不再是绘制复杂的原型图。新的挑战在于：如何将企业的品牌调性、用户体验、安全约束等抽象要求，巧妙地融入这个简洁的聊天界面，同时避免使其变得臃肿。

观察发现，如今优秀的产品负责人正变得非常“卷”，他们往往主动学习并掌握Coze等低代码/无代码AI应用搭建工具。这带来的变化是，他们在“原型验证”阶段开始部分绕过研发团队。

过去写在PRD里的功能描述，正越来越多地被“可运行的原型”、“可交互的演示Demo”或“可直接对齐的业务工作台状态”所取代。这种通过Coze等工具快速搭建并验证通过的方案，其本身几乎就是一份立体的需求文档。

三、技术负责人需兼具全栈能力与项目管理智慧

技术骨干在新型团队体系中，很可能依旧是**“最忙碌”**的核心成员。项目早期的工程师不仅是需求的实现者，更需要负责将模型能力、上下文管理、工具链、评估测试链整合贯通。

AI项目的演示原型可能很快就能做出，但将其打磨至真正可用、好用的程度，则极其考验耐心与综合能力。因此，这本质上也是一项巨大的项目管理工作，要求负责人具备高超的管理智慧。

这个角色需要将各项工作串联起来：如何构建测试集、如何设定质量红线、如何进行回归验证、如何监控线上模型的性能漂移与潜在风险。工程师越是善于利用AI工具提升个人与团队效率，团队就越能用更精简的人数完成业务闭环，也越不需要依赖传统的“中间协调岗位”来维持运转。

最终，在AI驱动的项目中，谁掌握了核心的评价方法与实现能力，谁就掌握了事实上的话语权与决策权。这或许就是新时代团队构建的本质逻辑。

近期，在我参与的创业项目“空气小猪”的下一轮迭代中，产品设计耗费了大量心神，以至于没有充裕时间撰写长篇内容。

翻看旧日素材，决定将去年一个电话销售项目中的某个功能片段——“销售线索自动分配”拿出来探讨。该功能上线后曾一度体现出显著的业务价值。

事实上，在电销业务模块中，人工智能有着多样化的应用场景，例如之前提及的AI客服系统（相关案例可参考过往文章）。而本次介绍的销售线索自动分配功能，虽然只是庞大线索管理体系中的一个子模块，但在上线之前，其所关联的问题却相当棘手。

线索分配的核心矛盾

去年，我曾实际为三家规模不等的电销业务团队提供支持，其客服人员数量在50至300人之间。他们的业务模式非常典型，遵循着标准的广告投放引流逻辑。

作为一名拥有多年经验的产品研发管理者，若被问及所有团队中最难管理的是哪一类，我会毫不犹豫地回答：销售团队。这个群体往往想法复杂，个人主义色彩浓厚。

他们有时会过于自信，甚至认为公司的全部业绩都归功于其个人能力，从而可能表现出傲慢与自大。然而，电销业务的核心本质在于流量运营。整个广告投放流程及各种流量获取技巧至关重要，它们直接决定了销售线索的数量与质量。

获取线索之后，紧接着便会面临另一个关键问题：分配。这不仅仅是任务的派发，在更深层次上，这近乎是利益的分配。因此，销售团队内部及团队之间常常因此产生冲突。

一个销售小组，多则20人，少则5人。争斗首先会在小组之间爆发，其次蔓延至组内成员之间。其核心矛盾点始终围绕着一个命题：线索分配是否公平。

这些销售深谙“会哭的孩子有奶吃”的原则。那么，真实的线索分配在小组层面是否公平呢？

答案是：当然不公平！ 同样分配给两个小组各25条线索，其中一个小组获得的线索质量可能远高于另一组。这其中的操作空间和潜在因素非常复杂。

于是便出现了经典的局面：忙的忙死，闲的闲死；旱的旱死，涝的涝死。

管理层并非没有意识到这种内耗，但“有人的地方就有江湖”，情感因素和人为操作始终存在，使得这个问题一直悬而未决，偶尔还会变得异常尖锐。正因如此，AI线索自动分配系统的构想应运而生。

要实现这个功能，其难点与人工智能技术本身关系不大。撇开复杂的管理学问题，其核心在于分配策略的设计。

系统在设计之初就必须规避人为分配线索的环节，实现 “线索主动寻找团队、寻找销售” 的机制。从根源上杜绝销售人员争抢线索的可能性。即便出现问题，也属于系统策略层面的调整，而非个人矛盾。

所有这类项目的实施大致可分为三步：建立数据模型、构建分配流程、设置提醒机制。看起来步骤清晰，实际执行起来却也绝不简单。

线索建模：自动分配的基石

在销售自动化系统中，线索建模是实现自动分配的逻辑基础。

线索评分旨在对各个潜在客户线索进行相对客观的价值排序，帮助企业识别高质量线索。换言之，优质的线索往往拥有更高的成单概率。这不仅对销售端有益，对广告投放端也具有重要指导意义。因此，对线索进行建模分析是必不可少的环节。

曾有在Oracle工作的同行提及，他们的销售体系会强调基于潜在客户的匹配度和意向等级对线索进行打分，以此实现更高的成本效益。

要进行有效的线索建模，首要任务是对线索来源进行分类并评估其优先级。

常见的线索来源包括：官网主动注册留资、电话主动咨询、抖音广告点击、小红书内容触达、线下地推扫码等。不同来源的线索在意向度特征、数据完整度、最终转化概率等方面存在显著差异。我们可以依据这些维度，为每一类线索赋予不同的初始评分或权重。

注：由于涉及公司具体实践项目，真实的完整建模数据在此不便展示。以下示例旨在提供一种类似的评估思路供大家感受。

一、官网主动留资 用户主动通过官网表单提交个人信息，通常显示出较强的购买意向。所填写的信息（如姓名、电话、具体需求等）也较为完整，转化概率相对较高，因此评分应位于前列。

二、电话主动咨询 用户直接拨打电话进行咨询，其意向度通常极高（近乎于准客户状态），转化潜力最大，可考虑赋予满分或接近满分的评分。

三、地推扫码 用户在推广活动现场主动扫码报名留资，意向度一般较高（毕竟是主动参与），但所留数据可能不如线上表单填写得完整，因此评分可略低于上述两种来源。

四、小红书内容触达 用户通过浏览小红书平台的内容或广告点击了解到产品，意向度属于中上水平。该平台用户质量相对较好，互动深度也较高（用户需要主动浏览内容后决定是否咨询），故评分可设定在中位偏上。

据统计，小红书广告带来的线索很多源于用户的主动搜索，意图明确，其转化率显著高于一般的信息流广告。

实践表明，对于面向消费者（2C）的产品，小红书是目前非常优质的渠道之一。

……

从线索模型到销售分配逻辑

建立线索评分模型后，便可以依据分数高低来制定具体的分配规则。

近来在负责创业项目“空气小猪”的下一轮迭代，产品设计耗费了较多心神，因此没有太多精力撰写长篇内容。翻看往期素材库，我决定将去年在电销项目中实践过的某个片段功能——“销售线索自动分配”拿出来分享。这套系统在上线初期，确实为团队带来了显著价值。

事实上，在电话销售（电销）模块中，存在着众多AI技术的应用场景。例如我们之前探讨过的AI客服系统便是一个典型案例。而本次将要介绍的销售线索自动分配功能，虽然只是庞大销售线索管理体系中的一个子模块，但这个看似微小的环节，在上线前却引发了诸多复杂的管理问题。

线索分配引发的内部矛盾

去年，我实际服务了三支电销业务团队，其客服人员规模在50至300人之间不等。他们的业务模式非常典型，主要依赖于广告投放获取流量。

作为多年的产品与研发管理者，如果被问及所有业务团队中哪一类最难管理，我的答案无疑是销售团队。这个群体往往拥有诸多“个人考量”。他们时常自信地认为公司的业绩全然由自己创造，因而可能表现出一定程度的自负。然而事实上，电销业务的核心竞争力在于“流量运营”。广告投放的策略与各种获取流量的技巧至关重要，它们直接决定了销售线索的数量与质量。

当销售线索获取后，紧接着便面临“分配”这一环节。与其说这是在分配工作任务，不如视作是在“分配利益”。因此，销售团队内部因线索分配而起的冲突屡见不鲜。一个销售小组，多则二十人，少则五人，争斗首先发生在不同小组之间，继而蔓延至组内成员之间。其核心矛盾点往往聚焦于“线索分配不公”。

销售们深谙“会哭的孩子有奶吃”的道理。那么，真实的线索分配是否存在不公呢？答案是肯定的。即便两组分配到的线索数量相同，比如各25条，但其中一组的线索质量可能远胜于另一组。这其中的门道相当复杂。

于是便出现了“忙的忙死，闲的闲死；旱的旱死，涝的涝死”的局面。管理层并非不知晓这种内耗，但有人的地方就有江湖，涉及情感与利益就难免存在操作空间。因此，这个问题一直存在，时而还会变得相当尖锐。正是基于此背景，“AI线索自动分配”系统应运而生。

要实现这一功能，真正的难点与AI技术本身关联不大。抛开复杂的管理学问题，其核心在于“分配策略”的设计。系统从设计之初，就要规避任何形式的人为干预，实现“线索自动匹配团队与人”的机制，从而在根源上杜绝销售人员争抢线索的可能性。如果出现问题，也将是系统性的策略调整，而非个人操作。

这类项目的实施大致可分为三步：建立线索模型、构建分配流程、设置跟进提醒。看似步骤清晰，实则每一步都需精心设计。

构建线索质量评估模型

在销售自动化系统中，线索建模是实现自动分配的逻辑基础。线索评分旨在对各个潜在客户进行相对客观的价值排序，帮助企业识别出高质量的销售机会。简而言之，优质线索的成交概率远高于普通线索，这不仅对销售端有益，对前端的广告投放也具有关键的指导意义。因此，对线索进行建模评估是必不可少的一环。

我曾与在Oracle工作的粉丝交流，他们的销售体系也强调根据潜在客户的匹配度和意向等级进行线索打分，以此提升营销的整体成本效益。

进行线索建模，首先需要对线索的来源渠道进行分类，并评估其优先级。常见的线索来源包括：官网主动注册、电话主动咨询、抖音广告点击、小红书内容触达、线下地推扫码等。不同来源的线索在意向强度、数据完整度、历史转化概率等方面存在显著差异。我们可以依据这些维度，为每一类线索赋予不同的初始评分或权重。

注：因涉及公司具体商业实践，真实的建模参数不便公开，以下示例仅供感受其思路。

一、官网主动留资 用户主动通过官网表单留下个人信息，通常表现出较强的购买意向，且填写的信息（如姓名、电话、具体需求）较为完整，转化概率较高，因此评分应位居前列。

二、电话主动咨询 用户直接拨打电话进行咨询，其意向度极高（几乎可视为准客户），转化潜力最大，可赋予满分或接近满分的评分。

三、地推扫码 用户在线下推广活动中主动扫码留下信息，意向度一般较高，但其填写的数据可能不如线上表单完整，因此评分略低于上述两类。

四、小红书内容触达 用户通过小红书平台的内容或广告了解到产品后产生咨询，意向度属于中上水平。该平台用户质量普遍较好，互动也更为深入（用户需主动浏览并决定是否咨询），故评分居中偏上。据统计，小红书广告带来的线索很多源于用户的主动搜索，意图明确，转化率显著高于普通信息流广告。

从评分模型到分配规则

建立起线索评分模型后，便可以依据分数高低来制定具体的分配规则。评分高的线索意味着用户意向强烈、资料完善、成交可能性大，这类线索通常交由销售精英或冠军团队跟进。这符合销售领域的“二八定律”，即80%的业绩往往由20%的顶级销售创造。

我们曾咨询过从事CRM系统开发的同学，他们也建议将高价值线索优先分配给经验丰富的销售专家，以最大化转化机会。而对于评分较低的线索，则可以自动流转至线索培育池，或由系统设定自动化跟进任务。

在明确了高优先级线索的定义后，下一个关键决策是：哪些线索应直接分配给销售团队，哪些需要进入培育流程。通常，只有经过模型评估后的高分线索，才会被直接移交至销售端进行跟进。

注：在我们的实际项目中，所谓的“线索培育组”后期功能被集成化的AI客服系统所替代。

总之，通过线索评分模型来推导分配逻辑，可以实现 “以质取胜，分级跟进” 的策略。高分线索由资深销售快速响应，提升转化效率；中等评分线索按既定规则分配给常规销售团队；低分线索则交由AI或培育团队进行深度孵化。这样既避免了优质销售资源的浪费，也确保了潜力线索不被忽视。

模型数据反哺广告投放策略

为什么说线索建模是必须做好的一环？因为其产出的数据可以反向指导流量投放策略与广告预算分配。一个核心原则是：产生优质线索越多的渠道，其投放价值就越高。

这一点至关重要：一个百人规模的客服团队，其年度人力成本可能不到500万，但对应的广告投放预算却可能高达上亿。算法侧微小的优化带来的效益，可能就足以覆盖整个客服团队的成本。其中的轻重权衡，需要清醒认识。

如果通过模型分析发现，来自搜索引擎优化（SEO）或搜索引擎营销（SEM）的渠道产生了大量高分线索，那么就应该倾向于增加该渠道的广告预算。反之，如果某些平台带来的多为低分线索，则说明该渠道流量质量一般，应考虑减少投入或彻底优化其投放策略。

有行业分析显示，小红书广告的电商转化率平均在3.0%至7.5%之间，显著高于抖音平台的1.5%至4.0%。小红书用户决策成本更高，但其粉丝的商业价值也更为突出。单就商业变现能力而言，小红书的潜力不容小觑。

此外，渠道分析还可以进一步细化。例如，可以对比视频类广告（如抖音短视频）与图文类广告（如公众号图文、信息流广告）所带来的线索质量差异。普遍认知中视频更具吸引力，但究竟哪种形式的线索转化更好，仍需依据自身业务数据进行判断。

实现分配流程的自动化

请注意，直到这一步，才与人工智能（AI）产生较为直接的联系。这也印证了在许多工作流项目中，所谓“AI含量”可能并不如想象中那么高。

自去年DeepSeek发布以来，国内人工智能应用市场呈现出一片蓬勃发展的景象，随之而来的是相关岗位需求的显著增加。

大约在今年三月，我身边有两位朋友表达了向AI领域转型的意愿。我带领他们进行了一段时间的系统学习，最终他们都成功找到了心仪的工作。这段经历也促使我初步构建了AI训练营的课程框架。

进入五月，我手头一个结合AI与英语的创业项目面临现金流紧张的问题。当时摆在我面前的有两条补充现金流的路径：一是外出打工以供养团队，二是通过开设AI课程来维持团队运营。

经过深入权衡，实际上可行的选择只剩下一个：通过开发课程来支撑团队发展。原因在于，几乎没有企业主会允许员工利用公司资源处理个人事务。于是，我开始正式运作AI训练营项目，至今即将迎来第九期学员的开班。

今年年初，随着OpenClaw的爆火，人工智能的热度得以延续，相应的AI岗位需求也持续保持旺盛。

然而，当前的市场环境与去年已有所不同。一方面，整体经济形势面临挑战；另一方面，部分商业案例可能让一些企业主对AI投入更加谨慎；加之今年AI编程（AI Coding）技术尤为强势，导致的结果是整个科技行业出现了较为严重的裁员潮。

总体而言，当前形势并不轻松。但正如前文所述，AI领域仍然蕴藏着大量的职业机会。因此，许多朋友希望能踏入这个行业。我此前曾整理过一份系统的学习路径图：

核心知识地图与迭代升级

这份学习路径的整体框架和思路是经得起推敲的。不过，其中部分工具和技术已经出现了迭代更新。例如，过去我们可能会使用Coze、Dify这类低代码Agent平台来构建工作流应用。

但现在，为了更贴合企业的实际需求，我们转向采用AI编程与智能体（Agent）技术来承载核心工作流与技能（Skills）。基于此，我们对整个课程体系进行了全面的4.0版本升级：

课程目标人群精准定位

本课程主要面向互联网从业者，尤其适合那些渴望转型成为AI产品经理或AI工程师的人士。如果您符合以下身份或诉求，欢迎报名参与：

一、AI领域的创业者

如果您正在人工智能领域进行创业，特别关注AI项目的试错成本与控制，希望深入了解不同类型AI项目的成本构成，或者想要汲取更多来自AI创业失败案例的经验与教训，那么这门课程将非常适合您。

我将为您剖析To B（面向企业）类AI项目的核心难点在于订单获取与尾款回收，而To C（面向消费者）类项目的挑战则聚焦于流量获取与防止创意被快速复制。

同时，我将带您深入钉钉、飞书等AI办公生态系统的核心，帮助您更清晰地定位自己在未来AI赛道中的生态位。

二、AI项目的核心负责人

如果您即将或正在某个AI项目中扮演关键角色，并且希望了解或正在遭遇一些棘手的人工智能难题，那么这门课程将能为您提供有力的支持。

我将为您阐释AI项目中存在的非对称性优势是什么，以及模型可观测性（Observability） 的重要性。

此外，我会深入讲解几种主流的AI项目类型，剖析不同类型项目在生产环境中的实践方案、核心难点及其解决方案。

三、寻求AI转型的从业者

如果您是产品经理、程序员或其他互联网角色，并且希望找到一份与AI相关的工作，那么这门课程将尤其适合您，您所能收获的价值可能比前两类人群更为直接。

我将为您展示完整的AI项目全局视角，这甚至是许多已经入职的AI产品经理或工程师都未能全面触及的领域。

揭秘生产级AI项目的内部架构

许多正在转型的同学存在一个普遍的认知误区，他们认为只要拿到AI相关的录用通知，就等于坐拥了巨大的AI红利。这种想法可能过于乐观了！

一个预算达到亿级别的AI项目，其全貌通常只允许3到5名核心成员知晓，有时甚至更少。原因很简单：公司投入巨额资源形成的核心知识资产，怎能轻易被他人掌握？

具体到工作内容，也存在明确的分级：

1. 整体架构设计：涵盖AI工程、数据工程以及两者间的协同，这是公司知识产权最集中的部分。
2. 模型调优与精炼：涉及后训练（Post-training）、检索增强生成（RAG）等技术的深度应用，通常是项目的核心策略层，位于架构之下，也是面试中高频出现的技术难点。
3. 提示词工程与上下文工程：具体到各个业务模块的标准操作流程（SOP）编写，是将公司业务具象化的关键环节。
4. 数据工程的具体实施：某个特定板块的详细数据验收工作。这通常在基础架构验证完成后进行，需要与各领域专家协作，收集AI工程所需的高质量数据，是构建数据壁垒的过程。
5. 模型效果测评：涉及执行行业内的AI应用评测标准（方案由架构层决定，此处为执行层），包括测试数据集准备、竞品调研、异常案例分析等。
6. 技术论文与公关文稿：即对外宣传和影响力构建相关的内容，一般初级人员很少涉及。
7. 技术工具选型：涉及常用工具的调研与选择，例如向量数据库选型、Agent平台（如Coze， Dify， n8n）评估、AI编程工具选型等。
8. 内部降本增效工具开发：例如数据知识库后台、提示词管理系统等。这类工作技术含金量可能不高，但权限控制至关重要，否则极易导致公司机密泄露。
9. 项目实施与交付团队：如果是专注于To B AI工具的团队，可能还存在实施团队，负责工具售前支持或实际行业落地，属于项目执行层面的关键力量。
10. 其他辅助性与支持性工作。

我可以负责任地告诉您，上述列表中真正具有高价值的工作，新手可能一个都接触不到。 真实的职业发展路径往往是：先从边缘的辅助性工作做起；接着承担各种繁琐的基础工作，例如协助领域专家整理数据；然后才能独立负责一些小模块，比如竞品调研或模型测评。

如果表现突出、做事严谨，并且在公司服务超过半年，才有可能接触到具体某个业务模块的提示词编写工作。而更上层的架构设计等核心模块，则非常难以理解和参与。

这一方面是由于严格的保密要求，另一方面是因为核心架构已经完成，没有人会轻易将历史上遇到的“坑”、为何最终选择此架构等核心细节和盘托出。

以上便是行业内正在真实发生的事情。而在这门课程中，我将以AI项目的全局视野，带领您学习、感受甚至部分实操这些内容，助您触碰那些看似遥不可及的核心领域。

高频疑问权威解答

以下是一些大家普遍关心的问题：

一、课程采用何种形式进行？

课程为真人讲师在线直播授课（非录播），使用腾讯会议平台。每周上课2至3次，时间通常安排在工作日晚上10点或周末上午10点半。

二、课程是否提供回放录像？

所有课程均会提供录播视频，便于复习。同时，课程会布置作业并进行检查。

三、不具备编程基础是否可以参加？

可以参加，但学习过程中可能会感到有些吃力。我们的最低要求是能够撰写清晰的产品需求文档，即对逻辑思维能力要求较高。编程能力不是强制要求，但具备基础会更有优势。

四、课程能否提供工作推荐机会？

可以。只要学员能够高质量地完成所有作业，成功转型上岸的概率很高。

五、往期学员主要来自哪些背景？

目前学员背景多样，最高职级达到P9级别（有2位），其中包括多位企业高管、创业者、人力资源负责人、CEO助理以及经理级别人员。但超过50%的学员是希望转型AI的普通产品经理和程序员。

六、如果学习效果不理想怎么办？

我们提供课程重修的机会。

系统化课程大纲深度解读

从AI实际应用的视角出发，许多复杂的专业名词对于大多数应用者而言并非必需。例如，我曾见过某《AI工程师XX计划》课程礼包中包含TF-IDF， Bm25， BERT， 贝叶斯， FastText， LSTM， Viterbi， 向量化， Encoder-Decoder， 知识图谱等内容。

上周我们探讨了Workflow的重要性，随后有许多读者私下联系，希望我能深入剖析Workflow、RAG与Agent之间的关联。这个问题起初让我有些为难，一方面觉得这三者之间的关系似乎不言而喻，另一方面又觉得它们之间并没有绝对的、排他性的联系。

然而，经过一番思考，我意识到这恰恰反映了一个普遍的AI认知现状：我们这些频繁接触AI项目的人视作常识的概念，对大多数人而言却相当陌生，这种信息鸿沟远比想象中要大。 就像我每天分享AI文章，我的家人可能选择忽略甚至感到厌烦。因此，我们认为理所当然的知识，对他人来说可能真的需要清晰的解释。

三大支柱概述

广义而言，Workflow（工作流）、RAG（检索增强生成）和Agent（智能体）可以被视为AI项目落地的三大技术支柱。它们分别对应着不同的业务场景需求：

1. Workflow：适用于流程明确、步骤固定的场景，如HR效率提升（自动筛选简历、录入身份信息）。
2. RAG：适用于需要基于特定、最新或私有知识库进行问答的场景，如智能客服。
3. Agent：适用于目标复杂、步骤不确定、需要自主规划和调度的场景，如根据指令自动搜索网络信息并生成PPT或博客文章。

由此可见，它们本质上是三种不同的技术路径或架构模式，并且并非互斥。一个RAG系统中很可能包含多个Workflow；一个复杂的Agent则很可能同时整合了Workflow的流程控制和RAG的知识检索能力。

如果用更抽象的概念来对应，它们依次关联着算法、数据与泛化能力。通俗的解释是：

1. Workflow 解决“如何做”的问题，它将任务分解为可控的、顺序执行的步骤。
2. RAG 解决“用什么数据做”的问题，它为模型提供完成任务所需的外部知识。
3. Agent 解决“如何灵活应对”的问题，它赋予系统一定的自主能力，能够自行组合合适的Workflow并调用所需的数据。

下面我们将对这三大支柱进行详细展开。

Workflow → SOP：流程化的基石

Workflow，或称工作流，核心是解决“如何一步步完成特定任务”的问题。许多人认为“工作流”一词过于简单，难以体现业务的复杂性，因此在实际交流中更倾向于使用“SOP（标准作业程序）”这个概念，后者在管理者听来也更具专业性。

SOP对应着我们常说的行业Know-How（技术诀窍）。它定义了为达成优质结果所应遵循的标准化流程，是一套可被设计和编码的策略，将人的经验与操作转化为机器可执行的语言，即算法实现或业务系统化。

Workflow的核心是“梳理”，其背后涉及大量的沟通、设计和流程优化等管理工作，这本身极具挑战。如果聚焦于“Workflow + 大语言模型”的具体应用，最常见的有两种形式：

一、关键词提取（实体/槽位填充）

一个经典案例是：“请问北京明天的天气情况如何？” 工作流程序会执行两个核心操作：关键信息提取与流程执行。 具体来说，就是先提取出“明天”（时间）和“北京”（地点）这两个关键实体，然后调用相应的天气查询接口。这是早期利用模型能力最普遍的方式，也是提升AI产品稳定性的关键，专业上称为“实体提取”或“槽位填充”，我个人更倾向于“关键词提取”这个说法。

二、意图识别

同样以“请问北京明天的天气情况如何？”为例，为什么程序调用的是天气接口，而不是机票查询接口？这背后依赖的是LLM的自然语言理解能力，即意图识别。 这正是Agent进行工具（Function Calling/Tool Calling）调用的准确性基石。何时调用天气接口、何时调用旅游规划接口，这些都需要提前被清晰地定义和设计。如果模型识别不准，我们可以通过微调或优化提示词等方式进行针对性处理。这也引出了一个关键点：

我们常讨论的模型可观测性，很大程度上就体现在意图识别这个环节。

为什么说“仅有Workflow还不够”？

既然Workflow模式如此稳定，而当前大模型最被诟病的就是其不稳定性，按理说企业应该非常青睐Workflow才对。事实确实如此：目前运行在生产环境中的AI应用，超过80%都基于Workflow构建。 真正对Workflow模式“不满”的主要是两类人：

1. 专注于Agent方向、需要融资或售卖课程的人。
2. 一线的研发与工程人员。

为什么研发人员会不喜欢？答案是：维护成本太高，这是一个极其复杂的工程问题。 下图展示了一个维护三年后的Workflow可能呈现的复杂状态：

Workflow的挑战不在于技术实现难度，而在于维护难度。它需要持续应对：

1. 不断新增的用户意图。
2. 频繁变更的业务策略（需求）。
3. 用户千奇百怪、难以穷尽的表达方式。

本质上是有限的、预设的Workflow需要去覆盖和处理无限的用户意图与表达。 最终结果往往是维护成本呈指数级增长，到达某个临界点后，任何修改都可能引发新的错误。

至此，相信大家对Workflow的概念及其优缺点有了比较清晰的认识。接下来我们探讨RAG。

RAG：知识的桥梁

模型本身的知识受限于训练语料，无法满足信息快速更新、领域高度专业或数据严格保密的需求。为了获取更新、更专业、更私密的知识，RAG技术应运而生。

RAG常用的数据源包括本地结构化知识库和网络信息，同时也支持PDF、Word、Excel、图片等多种格式。

RAG的难点表面上在于“如何精准检索出用户所需的知识”，但真正的挑战在于其背后的一系列工程问题：如何进行数据结构设计、如何有效清洗数据、如何处理和优化用户提问等。

到这里，大家应该能看出：RAG系统必然离不开Workflow。 因为数据清洗、存储、用户问题重写、检索结果排序等每一个环节，都是一个具体的小Workflow。

尽管RAG的整体框架看起来简单，但实现一个可用的系统却非常困难。很多开发者可以快速掌握Workflow，但一旦要求构建一个简单的AI客服（RAG应用），就会感到无从下手。以下简述一个RAG项目的基本策略（不涉及具体代码），一次完整的RAG流程是：

用户提问 → 检索操作 → 返回结果

许多开发者在此遇到的最大问题是：检索返回了大量不相关的“垃圾信息”，导致整个流程失败；即使返回了相关内容，若噪音信息过多，也难以算作成功。

确保检索成功的核心有两点：

1. 用户输入（查询）的优化：用户的原始提问是不可控的，因此，用于检索的关键词必须经过重写和优化。
2. 数据源的质量保证：在输入（优化后的查询词）无误的前提下，必须能检索到正确答案，这就要求在数据处理的源头下功夫。

这两点分别对应着查询改写和高质量的数据入库处理：