基于近两年的实践经验，企业中最常见的AI需求可以归纳为以下四个主要类别：

一、工作流类AI应用

这类应用能有效解决具体问题，但AI技术含量相对较低，通常不足20%（大多在10%左右）：

二、简单AI知识库：AI客服场景

这是最为常见且真正能为企业体系实现降本增效的应用类型，多数情况下实现难度并不高：

三、简单AI知识库：AI内容生成应用

这也是一种相对普遍的项目类型，例如协助撰写公文，即依据现有模板生成符合规范的内容：

四、AIGC：文生图与文生视频

自今年下半年以来，文生图、文生视频相关需求日益增长，甚至已超越AI客服类需求，该领域蕴含巨大的商业机遇，例如AI漫画创作便具有较高的收益潜力：

每种项目类型都具备其固有的方法论、成本结构和技术瓶颈。其中，简单AI知识库构成了一套完整体系（其核心逻辑大同小异），即我们通常所说的RAG系统。然而，目前许多从业者对RAG概念仍感困惑，这包括我的一些学员。

他们在学习时似乎明白，但脱离学习环境后便感到茫然，然而一旦回归实际工作场景，又必然会遇到RAG系统。因此，我们有必要再次将RAG系统拉出来进行深入剖析！

RAG的效果问题

首先，这是必须反复强调的部分：许多同学使用RAG的方式过于粗暴。例如，他们直接将知识库文档丢进Coze或Dify等平台进行自动切片，随后花一下午简单调整提示词，便快速构建出一个聊天机器人。这种做法的效果若能出色，反倒令人意外。

我们这里讨论的是简单AI知识库，甚至可称之为AI搜索。此类产品的特性属于一锤子买卖，其核心衡量标准在于是否输出了期望的内容：

用户提问 -> 检索操作 -> 返回结果。如果检索返回的都是不相关的无效信息，整个流程即宣告失败；即便返回了部分所需内容，但其中混杂大量垃圾信息，同样不能视为成功。

决定这次搜索成败的关键因素有两点：

1. 第一是用户输入，这具有不可控性，因此用户的问题或者说用于检索的关键词必须经过转写和优化；
2. 第二是在确保输入（即用于搜索的关键词）无误的前提下，必须能获得正确的结果，这部分高度依赖最初的数据处理流程；

这里我们先探讨为何要改写用户查询，过程中将逐步涉及最令人头疼的数据入库处理环节：

查询改写

无论是Agent的工具调用，还是构建RAG系统，都会面临相同挑战：这也是稳定工作流难以彻底解决的环节——用户语言过于模糊，常包含多重意图，且泛化能力要求极高，只有模型能够妥善处理。

重申一个核心观点：用户无限的意图需要被有限的工具所收敛，用户无限的问题也需要被知识库设定边界。

例如，用户的一句话可能包含多个问题，但我们只能处理知识库中已有答案的问题，若问题超出范围则无需处理。

综上所述，重写查询相当于在检索前进行一轮语义收束，这将大幅提升检索精度。当前常见的策略包括查询分解，偶尔也会用到HyDE：

查询分解的核心思想是分而治之，将复杂或多意图查询拆分为独立的原子子问题；

HyDE（假设文档嵌入）属于先脑补，后检索策略，即让大语言模型基于问题生成一份“假设答案”，利用其丰富的语义信息进行检索；

大家可能尚未完全理解，此处我们通过一个案例详细展开说明：

案例详解查询改写

用户提问：我入职 8 个月了，想请 3 天病假，需要走什么流程？病假工资怎么算？

该问题同时包含了请假流程和病假工资计算两个意图。每个子问题对应一个明确的意图：

子问题1：“需要走什么流程？”——询问病假请假流程的意图。

子问题2：“病假工资怎么算？”——询问病假工资计算方法的意图。

这里涉及输入查询整理前的第一个关键知识点：问题分类表。

问题分类表（Intent）

模型不可能当场理解业务细节，因此稳定的检索不能仅依赖模型能力。在构建RAG之前，必须明确一件事：你的系统究竟需要解决哪些问题。例如，我在构建个人课程销售AI客服时，就设计了一套问题分类体系：

这种问题分类即我们之前所说的收敛过程：将无限的问题收敛为有限的类型。只要问题与我们预设的解决范围相关，无论用户如何表述都无需过度关注。

回到用户关于HR规则的询问，我们需要为每个意图指定一个问题类型（Intent），以指导后续流程：

1. Intent 1: 请假流程咨询。用户询问请病假的具体流程和手续。
2. Intent 2: 病假工资计算咨询。用户询问病假期间工资如何计算。

这应映射到HR领域的一张问题分类表（其作用在于收敛问题范围）：

数据处理

在清晰理解用户的查询输入后（用户的问题会被模型尽可能地引导至相应的问题类别），因此在执行知识检索时，更多是在进行简单的语义识别，甚至在此环节可以不用向量数据库，而采用小模型也能胜任：

承接上文，在我们近两年完成的23个AI项目中，先前已探讨了其中18个属于工作流类型。那么，剩余的5个项目是什么呢？

答案是知识库驱动的AI项目，而在这其中，有3个是标准的简单AI客服系统。

这可能与一些人的直觉相悖。按理说，AI客服不正是最典型的应用场景吗？为何其占比如此之小？答案很直接：因为通常需要部署AI客服的业务环节，往往至关重要，企业不愿在此轻易承担风险。

随之而来的问题是：部署AI客服真的算是一种冒险吗？答案是肯定的，而且风险系数相当高。几乎每一个我经手过的AI客服项目都曾出现过或大或小的事故，无一例外。例如，可以回顾此前的案例分享。

这也解释了为何各公司首先涌现的是工作流类AI应用，而非理论上更应被AI解决的业务核心——客服问题。对于内部工作流AI，即使出错，影响也局限在公司内部；但面向客户的业务一旦出错，就意味着直接的经济损失。

正因为AI客服对稳定性与准确性有着极高要求，所以在架构设计上必须追求高度的可观测性。这引出了当前实现AI项目的两种核心技术路径：AI Max 与 AI Min。

AI Min/Max技术路径解析

近期在授课时，我反复强调一个观点：开发AI应用必须深刻理解模型的边界。这里的“模型边界”衍生出AI应用的两种构建哲学：

1. 能用AI就用AI（AI Max）；
2. 能不用AI就不用AI（AI Min）。

这三句简单的概括背后蕴含了大量隐性知识，包括RAG技术先驱之一Douwe Kiela的见解：应聚焦于系统的可观测性，而非单纯追求准确性。

在AI项目中，实现100%的准确率几乎是不可能的任务。即便能达到90%或95%，企业当前更关切的是如何应对那缺失的5%或10%——即不准确的部分。当错误发生时，系统该如何处理？

除了基础准确性，关键在于如何管理“不准确”，这就需要可观测性的支撑。必须能够细致评估系统表现，并确保存在完备的审计追踪机制，这在受监管的行业中尤为重要。

而这里所强调的可观测性，主要在 “能不用AI就不用AI” 的模式下才更易实现。其背后体现的是对模型边界的清醒认知：追求完美的准确率并不现实，核心是要清晰知晓错误发生在何处、成因是什么、如何修正，并且能证明整个技术框架是闭环且可重复验证的！

下面，我们通过一个具体案例来阐释何为“AI Max”、何为“AI Min”，以及AI项目的可观测性究竟指什么。

案例详解：从排班系统看技术路径选择

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

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

实际系统还需包含多次提醒、少数服从多数、协调学员调整时间等功能，但核心需求是一个时间匹配算法。正是这个简单的系统，能清晰阐明模型边界的概念。

首先，来看“能用AI就AI”的Max路径：

一、AI Max路径：全量交给模型处理

采用AI Max方案非常简单，直接将所有聊天记录扔给大语言模型，并提示 “请问今天我该安排什么时间上课？” 即可。

模型会直接输出建议的时间段。在简单场景下，“能用AI就AI” 往往是最高效的解决方案，许多智能体（如某些自动化助手）在简单任务中表现确实出色。

接下来，看AI Min路径：

二、AI Min路径：最小化AI使用

所谓最小化AI应用，即仅在不得不使用AI的环节使用。在本案例中，不得不使用AI的环节是关键词提取，亦即语义识别每位学员的空闲时间陈述：

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

提取出结构化的空闲时间后，再用传统算法进行时间交叉计算。这立刻引出一个新问题：在最小化AI应用的场景中，何时才必须启用AI？

最近，许多正在求职的学员在面试AI应用工程师、Agent应用工程师或AI产品经理等岗位时，频繁遇到一个相同的问题：

什么是ReAct？它主要用来解决什么问题？

客观地说，这个问题的涵盖面相当广泛，并不太适合作为大多数常规岗位的面试提问。

但这绝不意味着ReAct不重要。恰恰相反，ReAct本身是一个非常重要的概念。只不过，要想完全理解它，几乎需要梳理清楚整个智能体（Agent）的架构设计，因此大多数人很难给出令人满意的回答。

另一方面，对于多数从业者而言，这个词显得比较**“低频”**。因为许多（尤其是中小型公司）的决策者可能更多地将Agent视为融资或讲故事的标签，而非真正用于解决实际生产问题的工具，导致很多同学缺乏相关的实践机会。最终的结果便是：

大多数人仅仅在一些文章里读到过这个术语，对其理解整体上非常模糊。 那么，ReAct究竟是什么？

ReAct = Reasoning（推理） + Acting（行动），是Google与普林斯顿大学的研究人员在2022年提出的一种范式。其核心包含三个部分：

1. 推理： 驱使大型语言模型去思考“为什么”以及“如何”执行某项行动。
2. 行动： 驱使大型语言模型执行具体的行动，并与外部环境（如工具、API）进行交互。
3. 循环反馈： 通过观察行动产生的结果，来驱动下一步的推理过程。

简单翻译一下，就是“先思考，再行动”。然而，这个概括性的说法并不能充分回答“为什么需要它”、“它具体是什么”以及“如何实现它”等一系列深层问题，因此我们需要追本溯源。

为何需要ReAct？理解模型演进的关键一步

从大语言模型的能力演进来看，我们试图解决的核心问题是模型**“只能思考和表达，但不能实际操作”**的局限性。

在此背景下，我们引入了函数调用（Function Calling）或模型上下文协议（MCP）等概念。其基本模式是预先定义一系列工具并将其“挂载”到模型上，每次模型在处理用户请求时，会根据问题内容与工具的描述、名称等参数来判断是否需要调用某个工具。

例如，一个经典的问题是：“成都这两天的天气怎么样？” 若想由模型自动调用工具处理，通常需要如下配置：

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "查询未来几天某个城市的天气预报",
    "parameters": {
      "type": "object",
      "properties": {
        "city": {
          "type": "string",
          "description": "城市名，例如：成都"
        },
        "days": {
          "type": "integer",
          "description": "查询多少天的预报（1-7）"
        }
      },
      "required": ["city", "days"]
    }
  }
}

当这种基础的交互模式确立后，问题随之而来：真实应用场景中工具数量可能非常庞大、用户提问的方式往往模糊不清、用户的真实意图可能错综复杂……

总而言之，将所有挑战叠加在一起，可以归结为一句话：模型在工具调用方面的表现不尽如人意。

于是，思维链（Chain-of-Thought, CoT）技术应运而生。它的核心理念是：模型需要对用户问题进行逐步分析，将复杂问题拆解为一系列可执行的小步骤（对应小工具调用），然后观察这些工具依次执行，成功完成一步后再进行下一步。 希望通过这种方式提升整体AI产品的体验。

总结而言，ReAct旨在解决的核心问题是：将模型的“思考能力”与“操作外部世界的能力”紧密结合，形成一个可观察、可迭代的闭环任务执行流程。

接下来，我们通过一个简单的例子来详细探讨ReAct架构的具体实现。

ReAct架构核心：思考、行动与观察的循环

本质上，ReAct架构是一套循环执行的工作流：

... → 推理 -> 行动 -> 观察 -> ...

这一范式的精髓在于，智能体在**“思考-行动-观察”的循环中逐步推进任务。** 换言之，Agent一边思考如何解决问题，一边调用工具获取新信息，然后根据观察到的结果调整后续计划，直至得出最终答案。

近期有学员在寻找AI相关职位时，反馈面试中常涉及模型微调的相关问题。由于此前学习过程中未能深入掌握，他们希望补上这一课。事实上，对于模型微调这一技术，我内心颇为抵触，因为它曾给我带来不少痛苦的回忆。

时间回溯到两年前，当时国内技术圈仍聚焦于模型的预训练与微调，这一过程被戏称为“炼丹”。不知是幸运还是不幸，我们团队在那个阶段也进行了大量训练实践。彼时，可供企业选择的基座模型相当有限，例如Bloom、LLaMA、GLM乃至GPT2。计算成本方面，更是比当前高出十倍不止——GPT-4-32K的账号一票难求（最高曾被炒至八万元），有些团队因未做好控制，一夜之间便可能让十多万元付诸东流。

数据成本同样高昂。获取优质数据的途径较为单一，且根本不存在所谓“数据蒸馏”的概念，因为实际操作中难以获得相应账号，即便获得，Token费用也令人望而却步。直至2024年，随着微软云Azure账号的开放购买，这一状况才逐渐缓解。但问题也随之浮现：许多受限于技术积累与资金实力的公司，耗费大量资源训练的小型模型（以7B、13B规模为主），刚刚取得些许进展，便因GPT版本更新或LLaMA2的发布而前功尽弃。

更具体地说，这些团队训练的小模型效果很快被资源雄厚的大型模型持平甚至超越，而团队已无力承担再次训练的成本。另一方面，多数公司在模型研发侧的能力几乎为零，即便训练效果尚可，其应用场景也极为有限，往往仅能处理诸如关键词提取等简单任务。原因很简单：约九成的公司无法扩展模型上下文长度，国内具备此能力者寥寥无几。

最终结果是，许多实力不足、积累浅薄的公司，在初步尝试后便迅速放弃了这条技术路线，甚至产生一种被AI浪潮裹挟的无力感。在这场“炼丹狂欢”中，不同公司承受的试错成本虽有差异，但数百万级别的投入损失并不罕见。我清晰记得，在一次项目复盘会上，老板质问为何当初选择这条技术路径，并强调试错成本之高。那一刻，我低头缩肩，整整两小时无法抬头，被当面严厉批评，事后一个月都未能完全恢复。

此时可能有读者会问：既然风险如此明显，为何当时仍有众多公司选择自主训练？这或许是时代的局限性使然。当时国内技术圈普遍以“套壳”为耻，直到Cursor等工具出现，大家发现套壳方案也能如此强大，风气才逐渐转变。于是，核心问题浮现：在当前基座模型能力已如此强大的背景下，何时才真正需要用到微调？

为什么需要微调

首先，我们明确两个不应使用微调的典型场景：

不应微调的场景

第一，风格、语气与品牌的个性化定制。以往因上下文窗口有限、模型理解能力较弱且易遗忘，我们需要通过微调从底层注入风格，以求一劳永逸。但如今，这一场景已基本消失。

第二，复杂结构化输出与特定格式遵循。例如将客户需求自动转化为公司内部JSON格式的工单。此类微调同样源于模型能力不足，担心不微调会导致错误，但现在已无此必要。

接下来，我们探讨几个适合使用微调的场景：

适合微调的场景

第一，在特定领域提升“直觉”与“确定性”。尽管RAG（检索增强生成）能够提供知识，但微调可以增强模型在特定领域内的思维模式。例如，一个代码模型在使用某公司全部内部代码库微调后，会对该公司特有的编程规范、私有库函数乃至常见Bug模式产生更深理解。它不仅能够引用知识（通过RAG），更能以符合公司习惯的方式思考并建议代码。在此场景下，RAG类似于资料查询，而微调则倾向于内置标准操作程序（SOP），将模型转化为领域专家。我们近期在芯片编程领域的实践便采用了微调方式，部分原因在于需要学习的内容体量过大。

第二，成本与延迟优化。对于高频调用的大型应用，每次调用云API都成本高昂且延迟显著。此时，对小型模型进行微调便显得尤为必要。但需特别注意，我们微调小型模型的目标绝非让其扮演“缩小版GPT”来处理开放领域或创造性对话。这类微调的真正价值在于处理特定任务——那些定义明确、边界清晰、且对速度与成本极度敏感的任务。例如：

1. 输入输出标准化：输入为短文本（如用户查询、一句话、搜索词），输出为结构化数据（如分类标签、布尔值、JSON对象）。
2. 高频率、低延迟要求：每秒需处理成千上万次请求，且对响应速度要求极高的场景。
3. 领域特定：任务高度依赖企业自身的业务逻辑与数据。

总结而言：如果仅为补充知识或最新事实，应优先选择RAG，因为微调不擅长注入知识；如果旨在影响模型的输出能力（包括文本规则、格式与速度），则可以考虑微调。

提升模型的直觉与确定性

此处的逻辑在于：RAG补充知识，微调补充思维，目标是将“资料检索型回答”转变为“按行业SOP思考并稳定输出”。在行动前，需首先思考以下几点：

一、何时需要微调？

需注意以下几个关键点：

1. 能将规则或SOP明确梳理出来，且行业中存在清晰标准。避免使用开放命题进行微调，否则难以取得预期效果。
2. 在当前大模型能力基础上，无论如何调整提示词，准确率始终无法突破95%。
3. 存在必须严格遵守的边界或不可触碰的红线。
4. 其他相关考量。

明确准入条件后，核心便转向数据准备。

二、数据来源

此场景下的数据通常具有高结构化特征，例如：

1. 整理出的金标准：如SOP、公司规范、合规条款等，数量约1k至5k条，每条都应作为“判断或建议的锚点”。
2. 负面案例：常见错误及反例，同样需要1k至5k条，明确阐述错误原因及修正方法。

需特别强调的是：微调数据不仅应包含问答对（Q, A），还需涵盖推理过程（Q, Reasoning, A）。以芯片编程为例，数据不应仅是“需求 -> 代码”，而应是“需求 -> 分析（为何此处需使用此私有库函数？需考虑哪些时序与功耗问题？）-> 代码”。如此微调出的模型，在面对新问题时，会更倾向于模仿这种推理路径，而非仅仅输出答案。其“确定性”便体现在推理过程符合预设规则。

由于芯片场景较为晦涩，下面提供一个更简单的示例：

三、数据案例

首先是正面案例：

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

数据准备完毕后，便可选择相应工具进行微调。此场景因一般公司使用较少，此处不展开案例，读者可自行体会。接下来是第二个微调场景：

近期，一些寻找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.

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

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

在过去一年的商业观察与实践中，我以“猎头”角色深度介入前公司的2B业务运营。由于我最初的创业项目聚焦于CEO数字分身——一个典型的2B业务，这让我对企业服务领域保持着持续的关注与思考。

然而，经过深入的调研，我发现在众多我所接触的公司中，其2B业务的开展模式仍然延续着经典的三部曲：

投入资金进行广告投放，以扩大潜在客户线索来源 → 与客户进行初步接触，努力达成合作意向 → 最终谈判敲定，确定产品价格与服务条款。

这套方法论本身经过了市场的长期检验，运行逻辑清晰。但我始终感到其中存在某种隐忧，其核心问题在于一个关键指标的不合理：投资回报率（ROI）。

这一模式的驱动核心，表面上依赖于产品与研发，实质上却是由销售团队主导。而一个可以确定的现实是，销售往往对产品的技术细节与能力边界并不熟悉，他们在推广过程中所承诺的，大概率存在夸大成分。

于是，整个2B行业催生了一种奇特的现象链：

1. 甲方客户期望以低廉的价格获取高价值的解决方案；
2. 乙方销售敢于做出超越产品实际能力的承诺，甚至将其描绘得更加完美；
3. 乙方产品与研发团队成为下游的最大受害者，常常在不明所以的情况下承担销售过度承诺的后果，并受到管理层的指责；
4. 在一个项目周期内，销售因达成业绩获得了丰厚回报（奖金或晋升），而研发团队却付出了额外的、未被计价的努力；
5. 甲方可能验收“通过”，但整体项目ROI为负；或者甲方验收不通过，拒绝支付尾款，双方陷入漫长的纠纷与“扯皮”；
6. 尽管单个项目或团队ROI为负，但公司凭借总体营收规模，可能达成某些业绩目标，甚至获得政策性补贴，从公司整体层面看依然“盈利”；
7. 另一种情况是，在甲方第一阶段验收通过后，若要启动第二阶段，乙方极有可能大幅提价，从而从整体上实现盈利。

因此，这套模式隐藏的核心法则是通过动态调整，让最终定价趋于合理——白菜价终究只能买到白菜。即便初始定价不合理，也总会有一种“神秘力量”将结果拉回平衡：

1. “先免费试用，后收费”或“先低价切入，后提价”是一种常见策略；
2. 申请并获取政府各类补贴与扶持资金是一种策略；
3. 维持一定的收入规模，以满足资本市场的要求并获取融资是一种策略；
4. 即使项目赔钱，也要维持项目数量与收入规模，以期用成功案例获取更优质的订单，这也是一种策略；
5. ……

总之，最终总会有一个角色或一种方式来补足中间的差价，否则整个商业模式将难以持续。然而，不得不承认，这种模式在当今的市场环境中风险日益增大，且所赚取的利润往往是艰辛而微薄的。

那么，在人工智能技术迅猛发展的今天，2B生意究竟该如何开展？以下是我基于实践的一些思考。

AI时代，2B生意的转型逻辑

在先后经历**CEO数字分身（AI 2B）与空气小猪（AI 2C）**两个创业项目后，我总结出一些个人心得。根据实践反馈，各类商业模式的盈利难度大致排序如下：

打造并销售品牌（大型IP） > 销售知识产权（IP） > 销售标准化产品（相对容易）> 提供咨询服务 > 承接商业广告订单 > 提供人力外包与纯定制化开发 > 销售复杂软件产品（非常困难）

以AI 2B领域的数字分身项目为例，我们从客户那里得到的真实反馈是：

1. 几乎没有企业愿意直接购买这款标准化产品；
2. 企业愿意为我所提供的、基于该产品的研发效率提升服务付费；
3. 企业非常乐意购买我提供的、关于AI应用落地的咨询服务；
4. 在项目合作过程中，不止一位企业老板直接表达希望我入职的意愿；

综合以上，我们可以得出几个结论（从服务提供方视角）：

1. 纯粹的标准化软件产品销售异常艰难；
2. 即使企业采购产品，也更倾向于高度定制化的解决方案，但这会导致服务方ROI急剧下降；
3. 企业希望将部分非核心业务外包，但这部分工作往往价值低、流程杂乱，若无规模营收诉求，利润空间仅为人头成本的20%-50%；
4. 咨询服务利润空间大，且成交相对容易。 其交付标准较为宽泛，只要基本专业度达标，企业或个人客户通常较为满意（某种程度上，赚取的是信息差与认知差的价值）；
5. 参照2C产品“AI训练营”的经验，只要能够获取足够大的精准流量，这便是一门极佳的生意，并且明显具备滚雪球效应，有越做越大的趋势；

因此，我认为，在AI编程工具如此强大的今天，一家2B公司若仍坚持纯粹的软件服务外包路线，其发展道路将越走越窄。一种可能的转型路径是：

打造一款具有吸引力的核心产品原型，围绕该产品构建内容与流量，并以产品为切入点，实质性地开展高价值的咨询服务业务。

因为单纯销售SaaS服务同样面临巨大阻力。相比之下，流量运营、地理定位（GEO）营销、AI赋能出海、AIGC内容生成等方向在当前市场更具可行性。但客户最终为哪项具体服务买单，存在很大的灵活性。

另一方面，当前2B生意难做的原因有多方面：

1. 市场竞争白热化，客户极少愿意为未经验证的新产品直接付费。多数客户缺乏专业判断力，需要持续的市场教育，其最终选择往往带有偶然性；
2. 但客户大概率愿意为你所在行业的AI深度认知付费，例如帮助他们提升团队效率，或“指导”他们如何利用AI拓展业务；
3. 客户非常欢迎“专家”驻场提供陪伴式服务，甚至频繁发生试图“挖角”专家的情况；

所以，若想抢占所在行业在AI领域的流量与心智先机，需把握三个关键要素：清晰的服务清单、专业的团队，以及最重要的、低成本甚至免费的流量来源。

那么，什么是服务清单？

构建差异化产品与服务清单

根据个人实践，我们所要提供的服务清单是业务成败的关键。所选赛道必须精准，核心逻辑应是“市场需求什么，我们就同步补充什么”，而非“我们擅长什么，就强行向市场推销什么”。

例如，以下几类课题具备较高的市场吸引力：

1. XX行业/业务如何获取流量，GEO营销具体如何操作；
2. XX业务如何与AI结合，市面上已有哪些成功案例可借鉴；
3. AI如何帮助机构提升质量与效率，最关键的是如何帮助机构实现收入增长；
4. AIGC（从AI视角）在教学培训、科学普及等领域有何创新价值；
5. XX业务能否借助AI拓展海外市场，如何在海外进行销售，如何解决跨境支付等难题；
6. ……

若希望扩大服务对象的范围，可以将清单内容扩散至相关产业链的主体。

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

其次，之前为他们部署的那套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的理解能力。