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

事实上，在电话销售（电销）模块中，存在着众多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含量”可能并不如想象中那么高。

最近，许多正在求职的学员在面试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项目团队应如何搭建的问题（参阅文章：《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训练营第一批学员正式毕业。最终课程平均评分达到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+管理”的实践，确实积累了不少案例，它们正是下图所示框架中的一个具体分支：

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

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标杆DeepSeek正式推出了其全新的模型迭代，完整版本号为DeepSeek-V3.2-Speciale (02-2026)。官方披露的核心升级点涵盖多个维度：

1. 推理能力实现质的飞跃 - 在数学运算、代码编程、逻辑推演等复杂任务上的表现取得了显著进步。
2. 知识库完成重要刷新 - 模型的知识截止日期已延伸至2025年5月，确保了信息的时效性。
3. 长上下文理解能力精进 - 对多轮、冗长对话的整体脉络与细节把握变得更加精准。
4. 回复质量全面优化 - 生成的答案在准确性与条理性上均达到了新的高度。

然而，上述提升仅是基础。真正让该版本在全球范围内引发强烈关注的，是其在关键性能指标上实现的突破性优势：

1. 推理成本堪称全球最低，每百万tokens仅需0.14元人民币，在全球主流模型中处于绝对领先地位，其成本仅为GPT-5.1的八十分之一。
2. 上下文长度问鼎全球巅峰，支持高达1M tokens的上下文窗口，这意味着模型可以一次性处理相当于《三体》三部曲总和的文本体量。
3. 首字延迟速度行业领先，平均首字输出时间小于0.2秒，其流式响应速度极快，用户体验无限接近人类对话的自然停顿节奏。

综合来看，DeepSeek-V3.2的核心标签可概括为：具备顶级推理能力且价格最亲民的模型、拥有最长上下文处理窗口的模型，以及在国内权威评测中位列第一的模型。

这些特性无疑令人振奋，但更深的期待在于另一个维度。正如行业共识所预示，2026年将成为智能体（Agent）技术大规模应用的元年。作为备受瞩目的核心模型，DeepSeek在此次更新中为Agent能力进行了哪些专项优化呢？

回顾历史，模型针对Agent场景的优化通常聚焦于特定能力：

Agent执行任务最核心的两大能力在于“任务分解”与“工具调用”。

根据DeepSeek公布的部分评测数据：

1. 在天罡评测体系的“任务分解”单项中，得分高达93.5，稳居国内榜首。
2. 在天罡评测体系的“信息抽取”单项中，得分达到93.49，同样位列国内第一。

整体性能可参考下图。不过，目前披露的信息仍显不足，或许需要等待更详细的数据集跑分结果，才能全面揭示DeepSeek在Agent侧所做的深层优化与具体提升：

上个月，Manus1.5的发布，其核心演示点集中在网站开发领域，尽管未明确提及，但几乎直指前端开发。

紧接着，近日Gemini3的推出，网络上各种喧嚣的观点再次指向**前端已死！**前端开发为何屡屡成为焦点，不断面临各种挑战？

从早期互联网萎缩宣称前端已死，到各类SaaS工具平台涌现前端再死，随后低代码、零代码兴起依然前端死，再到Coze、Dify出现还是前端死，以及Cursor、Claude Code问世自然也是前端死……

前端似乎成了众矢之的，如今各公司领导者也似乎采纳了这些观点，不久前某公司前端团队裁员比例高达50%，这已非危言耸听，前端领域确实面临严峻压力。

因此，我们不得不深入探讨：AI是否真的意图取代前端开发？

AI对前端的冲击：范式和数据

首先，AI对程序员，尤其是前端开发者的冲击如此直接和剧烈，核心原因在于范式和数据。

AI模型对开发者的编码习惯有深入理解，同时各种开发框架已相当成熟。

自ChatGPT问世以来，能够稳定消耗算力的文本类AI应用，主要集中于即时聊天、AI客服以及AI编程三大领域。

其中，AI编程的快速发展，离不开全球开源社区构建的庞大代码语料库。GitHub上超过2亿个开源仓库，为代码模型的训练提供了海量、结构化且高质量的“教材”。

将视角聚焦于前端，我们会发现一个关键事实：业务逻辑的可穷举性。

前端的业务逻辑，尤其是UI组件与交互模式，相对规整且高度模式化。经过数十年的演进，这些模式在GitHub上已被近乎完全穷举。这意味着：训练一个精通前端开发的AI，所需的数据是完全充足的。

相比之下，后端领域虽有大量代码，但企业的核心业务逻辑代码通常不会开源，导致语料在深度上存在缺口。至于芯片设计等更底层领域，由于缺乏开源语料，AI辅助编程几乎难以开展。

因此，我们必须承认：正是由于前端业务逻辑的相对简单性与开源语料的极度丰富，使得AI在前端领域能够快速达到“优秀”水平，从而对前端开发中“代码生成”这一环节构成了最直接的冲击。

这一冲击在当前工具生态中已显现端倪。从GitHub Copilot到Cursor，从Claude Code到通义灵码，AI编程助手正快速渗透前端开发的日常工作流程。

业界估计与我的实践经验一致：前端开发中约60%以上的标准化任务已可实现高度自动化，包括组件生成、样式编写、基础业务逻辑实现等。

那么，前端是否即将被淘汰？常说的AI对前端的10倍效率提升究竟体现在何处？

AI在前端开发中的效率提升：理想与现实

根据个人实践：AI确实能在某些场景下实现10倍甚至100倍的效率提升，但在真实业务开发环境中，实际的效率提升通常低于60%。

为何存在如此大的差距？接下来，我们详细拆解这一问题。在许多AI的宣传案例中，经常出现以下示例：

输入提示词：  
“帮我实现一个数独游戏，使用JavaScript实现。”

大约30秒后，Cursor即可完成从需求分析、问题拆解、编码实现到效果预览的完整流程。示例效果：

这个数独游戏不仅功能完整，还支持响应式布局。

如果让开发者手动编码实现，大约需要4-8小时，而Cursor仅需30秒，提升的效率何止10倍？甚至达到100倍。

这类场景的确容易让人认为AI具备颠覆性的效率提升。但我们需要剖析这些案例的特点：

1. 需求清晰、任务简单：数独游戏的规则固定，AI只需基于已有训练数据生成代码，而不需要额外的上下文理解；
2. 代码质量不重要：在展示“AI速度”的场景中，代码的健壮性、可维护性往往被忽略。即使生成的代码不符合团队规范、不易扩展，也不会影响展示效果；
3. 极端场景的放大：一些演示视频可能会挑选AI表现最优的时刻，而忽略它犯错的情况。例如，在AI生成UI代码时，可能会遗漏复杂交互的细节，导致实际使用时需要大量修改；

这种能力对于非专业开发者快速验证MVP的门槛大幅降低。

然而，这仅仅是理想化场景，现实中的业务开发却远比这复杂得多。

实际业务开发中的AI应用分析

为了分析AI在业务开发中的实际提效，我们先拆解前端开发的典型流程，以及各环节的大致时间占比：

从表格可以看出，占据开发者较多时间的环节主要是：

1. 需求分析
2. UI还原与组件开发
3. 业务逻辑实现
4. API集成与调试

接下来，我们分析AI在这些环节中的实际表现：

需求分析：AI介入难度极大

原因很简单：

1. 需求分析涉及业务背景、上下文理解、利益取舍，需要大量主观判断。
2. 需求变更频繁，AI很难高效处理动态变化。
3. 许多需求难以用自然语言准确描述，导致AI生成的内容不够精准。

结论：AI在需求分析环节几乎无法发挥作用。

UI还原：能力有限，仍需大量人工调整

当前AI可以基于Figma设计稿或截图生成UI代码，但仍然存在较多问题：

此前，我们探讨了关于AI浏览器作为未来流量入口的竞争格局。既然流量的核心入口呈现出从传统浏览器向AI浏览器迁移的趋势，那么其背后的信息检索底层技术也必然发生根本性的转变：从搜索引擎优化（SEO）转向生成式引擎优化（GEO）。这标志着围绕关键词布局、外链建设等传统逻辑正在逐渐失效。

GEO：Generative Engine Optimization，即生成式引擎优化。

关于AI将取代搜索引擎的讨论由来已久。例如，三年多前笔者从事医疗AI领域工作时，在产品演示直播中就有许多观众表示：AI能否替代医生尚不可知，但替代百度这类搜索引擎则是必然的。

现实情况也印证了这一点。目前，我仅在三种特定场景下才会使用百度或谷歌：

1. 首先，检查网络是否断开；
2. 其次，确认VPN代理是否正常工作；
3. 最后，当对AI生成的答案存有疑虑，需要追溯和核查原始信息源时。

我们深知流量即商业价值。当用户日益频繁地向AI咨询产品、寻求解答时，一个核心问题便浮现出来：我们应当如何**“优化内容以适配AI”**，从而让自家的产品或信息被优先推荐？如下图所示：

一个明显的趋势是：近期咨询GEO相关策略的企业主显著增多，他们普遍关心两个实际问题：具体该如何操作？以及需要投入多少成本？

要深入解答这些问题，或许需要从大语言模型的底层运行逻辑谈起。

GEO的底层逻辑

如图所示，大语言模型（LLM）本质上是遵循特定模式的输入输出系统。GEO的核心目标，是通过影响模型训练阶段所使用的语料库，或者干预其回答问题时调用的外部知识库，最终达到塑造和影响其输出内容的目的。

这与传统SEO存在显著差异。搜索引擎的排序算法相对透明，首先高度重视网站的整体权重，其次考量页面的多项关键指标（如关键词密度、停留时间等）。这种清晰的排序逻辑使得关键词竞价等商业行为具有可预测性和可计算性。

然而，LLM将海量语料“消化吸收”后，其内部形成了一个复杂的“黑盒”。不仅内容发布者难以预知自己的信息何时会被调用，甚至模型开发者也可能无法保证输出结果的绝对稳定性。因此，在当前阶段，若有企业主急于在GEO领域进行大规模投入，很可能需要承担较高的试错成本与风险。

我们有必要尝试解析这个“黑盒”。首要问题是：模型生成答案时所依据的内容究竟从何而来？

厘清内容来源是理解GEO的基础。答案主要集中于以下三个方面：

一、固化数据：模型的内嵌知识库

第一部分是模型参数内封装的固有知识，即通过预训练和微调阶段注入的数据。这些数据构成了模型认知世界的基础框架与知识体系，犹如一座经过高度压缩的巨型图书馆。

在此层面，试图通过直接“投喂”数据来影响基座模型，对于绝大多数公司而言是一个不切实际的目标。若有服务商承诺能将网站数据直接编入诸如ChatGPT之类的核心模型，这几乎可以判定为夸大其词。

当然，这并非意味着完全无法介入。用于训练的数据要求具备极高的质量，必须是权威、精炼的精品内容，其准入门槛本身就极高，例如：在顶级学术期刊上发表SCI论文。

二、RAG：当前GEO的主战场

第二部分是检索增强生成（RAG），这是目前GEO最核心、最具有现实操作空间的优化方向。当用户提出问题时，AI系统会实时从互联网检索最新相关信息，将这些信息作为“上下文”与用户问题一并提交给LLM，进而生成基于实时信息的答案。

其具体工作流程通常包括：AI对用户问题进行意图识别与关键词解析，随后从预设的索引库中查找相关网页。

需要特别注意的是，这一过程仍然在很大程度上依赖于传统搜索引擎的索引与排序逻辑。因此，扎实的SEO基础能力在此环节依然至关重要！

背后的核心逻辑在于：AI系统会优先选取并信赖那些来自权威、可信、专业信息源的内容（这意味着E-E-A-T原则的重要性丝毫未减）。

注：当然，实际应用中也存在一些不尽如人意的情况。例如，近期观察到某些模型在生成答案时引用了CSDN社区中质量参差不齐的内容，这确实令人有些无奈。

在这一领域，策略的核心仍然是在优质平台上进行大规模的内容发布。至于“大规模”的具体标准，则见仁见智，本质上这依然是一种依托平台流量分发的逻辑。

这里存在一个关键洞察：某些对人类读者体验不佳的文档格式，可能对AI处理异常友好。所谓“对AI友好”通常具备以下特征：

1. 以清晰的问答对形式组织；
2. 内容体量庞大、覆盖信息点全面；
3. 采用短句结构，便于被精准截取和引用；
4. ……

三、外链的辅助作用

第三部分是超链接。如果问题描述或相关文档中包含了链接，模型有时也会尝试访问并读取链接内容。然而，仅凭这一点对于GEO效果的提升帮助较为有限。

综上所述，从模型的内容生成逻辑来看，其核心评判标准似乎依然延续了E-E-A-T原则的框架：

1. 经验（Experience） - 这是一个新增且日益重要的维度。
2. 专业度（Expertise）
3. 权威度（Authoritativeness）
4. 可信度（Trustworthiness）

以上是对GEO基本逻辑的初步梳理。接下来，我们需要思考第二个关键问题：对于AI领域的创业者而言，是否应该搭上GEO这班车？它当前的实际商业价值究竟如何？

GEO的市场价值与前景

关于GEO市场的具体规模，目前可查证的直接数据相对有限：根据Valuates的研究报告估算，2024年GEO相关服务市场规模约为8.86亿美元，预计到2031年将增长至73.18亿美元。

我们可以通过相邻市场的规模作为上下界参考：传统的SEO服务市场预计在2025年达到约749亿美元，2030年有望增至1273亿美元。

同时，市场预算迁移的信号已十分清晰。例如，美国的AI搜索广告收入预计到2029年将达到259亿美元，占据整个搜索广告市场的13.6%。

从需求端渗透率来看，谷歌的“AI Overviews”功能在2025年3月已触发了高达13.14%的搜索查询。

综合而言，GEO虽然仍处于早期发展阶段，但已展现出可观的成长潜力：在AI搜索渗透率持续提升与市场营销预算结构性转移的双重驱动下，它正从一个“增量试验田”逐步演变为独立的细分市场。

从纯粹的数字增长角度判断，GEO的价值毋庸置疑。然而，必须清醒认识到，这块市场蛋糕的大部分利润很可能被基座模型公司所摄取，并且他们已经在积极布局。

流量入口的争夺战

我们之前讨论了AI浏览器作为下一代流量入口的趋势，也提及了像Atlassian以6.1亿美元收购Dia这类标志性事件。这些都明确显示，流量入口的主导权正从传统浏览器向AI浏览器及更广义的智能交互界面转移。

因此，科技巨头们纷纷加大投入，争夺定义下一代用户“入口”的主导权，并且这场竞争已不再局限于浏览器界面本身，而是深入到了工作流整合、智能决策支持与深度生态集成等多个层面。

在此趋势下，所谓的AI浏览器与AI智能体（Agent）之间的界限正变得越来越模糊。

传统巨头的防守与进化

对于已经占据入口优势的巨头，他们正致力于将既有优势发挥到极致：

1. 微软：将Copilot深度植入Windows操作系统内核，实现系统级的智能体调用与协同。
2. 谷歌：通过Gemini模型重构Chrome浏览器，使搜索结果能够直接呈现动态生成的3D模型演示等富媒体内容。
3. 苹果：将Siri升级为具备前瞻能力的主动式智能体（Proactive Agent），可跨设备预测并响应用户的行为轨迹。

新兴势力的冲击与创新

与此同时，众多新兴力量也在不断冲击这一领域：

1. Dia浏览器：通过实时屏幕语义分析技术，能够在用户点击之前就预加载其可能需要的相关信息。
2. Manus智能体：首创“认知沙盒”技术，支持并行运行多个智能体以协作处理复杂任务。
3. Nova Act SDK：提供跨平台的智能体运行时环境，旨在打破浏览器与本地应用程序之间的界限。

以上诸多领域是传统SEO无法有效触及的，但必然是未来GEO需要重点关注和布局的板块。从这个意义上说，GEO所能覆盖的流量场景和范围实际上已大幅扩展。

回顾过去几年的创业历程，我获得的最重要认知是：一切商业竞争的终点，最终都将演变为对用户注意力的争夺。

面向企业的AI服务（AI to B），让我得以深入市场一线，洞察客户的真实付费意愿，掌握了将产品推向市场的方法论，同时也深切体会到了盈利的艰辛。 面向消费者的AI服务（AI to C），则让我在实践中深刻领悟了流量运营的精髓，特别是如何高效获取免费流量。在当今商业环境中，流量的价值毋庸置疑。

我观察到众多企业，从早期的搜索引擎优化、公众号运营到如今的短视频营销，其流量策略始终紧跟平台变迁的步伐，与不断演进的平台算法进行着一场持续的“博弈”。

若要问每个流量阶段的特性是什么：那么答案往往是缺乏恒定不变的规则，正因如此，企业才会组建专门的流量团队与平台“周旋”。这些团队在流量获取上的年度预算投入可能超过总成本的60%，比例之高令人咋舌，也直接导致了团队普遍存在的流量焦虑。

近期，这种焦虑感进一步加剧了，因为流量分配的基本逻辑正在经历一场深刻变革。以我最近咨询的一家公司为例，其流量团队反馈：

当前各家企业在百度竞价广告（SEM）上的投入已大幅缩减（效果不尽如人意），甚至整个浏览器端的SEO流量份额也在急剧萎缩。企业流量的主战场已经转移至微信、抖音、小红书等内容生态体系。

该团队判断：未来，生成式引擎优化（GEO）将吞噬大量流量，因此他们成立了专项小组对此进行研究。

然而，GEO领域目前同样缺乏明确的规律可循，团队既往的研究成果或实践经验都具有一定的时效性，很可能在几个月后便不再适用。因此，他们迫切希望更深入地理解GEO的本质，以便进行长远的战略布局。

今天，我们就来深入探讨一下什么是GEO。

GEO的本质

探讨GEO，必然要提及SEO，因为两者仅有一词之差：

SEO的核心目标是确保内容能被搜索引擎检索并排名靠前，其优化策略侧重于TDK（标题、描述、关键词）的优化，以及在高权重网站获取反向链接等。

而GEO，其效果直接依赖于大语言模型的输出能力。模型的输出又取决于两大数据源：一是内置的预训练数据，二是实时调用的外部数据（通过爬取各类网站获得）。

所谓GEO，就是使你的（产品或服务）内容成为模型生成答案时的优先选择，更准确地说，是成为模型的首选知识来源。如下图所示：

大语言模型是一套标准化的输入-输出系统。GEO的目标是通过影响模型训练时所用的语料，或者其回答问题时所参考的外部知识库，最终达到影响其输出结果的目的。

更进一步说，GEO的优化动作实质上是去影响大语言模型的这两个数据源，其本质与RAG（检索增强生成）技术异曲同工：

首先，内置数据源（预训练数据）很难被外部力量直接影响。基础模型的训练数据核心目的是提升模型在各领域的通用推理能力，因此很难将大量相对次要的品牌信息纳入其中，这些信息对模型而言可能被视为负担甚至噪声。

因此，各公司的GEO核心策略便放在了如何**“影响”或“优化”模型的外部数据源上**。这里的逻辑与传统SEO的筛选过程类似：

1. 第一步是让模型能够“找到”你，这要求你的内容必须数量充足、更新及时。
2. 第二步是让模型能够“信任”你，这要求你的内容所发布的平台需具备一定的权威性和可靠性。
3. 第三步则进入了模型的“黑箱”，即模型如何具体判断你内容的优质程度，这因各家基础模型厂商的算法差异而各不相同。

综上所述，现阶段各团队在GEO方面能切实操作的只有上述第1、2两点：在全网发布大量内容，并尽可能选择优质平台进行分发。

接下来，我们简要探讨一下具体如何操作。

如何做GEO

首先，大家需要了解一个正派路线框架：E-E-A-T（经验、专业度、权威度、可信度）。该框架源自谷歌的《搜索质量评估指南》，用于评估网页或内容的可信度与质量。

简而言之，其内涵是：我拥有实际经验（E1）+ 我具备专业知识（E2）+ 行业/公众认可我（A）+ 我的内容值得信赖（T）。这套标准恰好可以映射到模型输出的可追溯性要求上：模型应输出来源明确、数据可验证、署名清晰的内容。

遵循E-E-A-T框架是为了让模型更好地理解和信任你的内容，它属于一种面向模型知识源的内容创作范式。只不过，当前模型能力强大，可用的范式多种多样。在实际操作中，我们不需要如此复杂，直接采用**“量大出奇迹”的策略，利用AI工具批量生成内容，并以不同格式在全网广泛发布即可。这种方法往往效果显著，唯一的风险是容易触发各平台的封号机制**。

这里给大家分享一个我们自身产品的实践案例：

此外，与之思路类似的做法是尝试影响基础模型的记忆。例如，通过多个账户持续向某个基础模型提问特定问题，经过一段时间后，模型有概率会“记住”并收录这些信息：

当然，还存在一些其他技巧，但大都比较**“偏门”**，在此就不便详述。如果仅讨论比较正派的策略，我可以随意提出两点思路：

一、猜一猜策略

大模型时代的流量获取将更具技术含量，它要求我们去揣测用户倾向于如何提出问题。

尤其是对于那些长尾的、具体的提示词（用户查询），我们提供的内容如何才能被模型优先选中，这将是关键所在。

因此，这里的工作重心从购买关键词，转移到了穷举用户可能的各种提问方式上。

二、构建权威矩阵

无论国内还是国外，当AI生态发展成熟后，模型势必更倾向于从权威渠道获取信息。因此，如果我们能够成为某个垂直领域的信息入口，或者我们能在各类权威渠道持续发布信息，这些内容将更容易被AI采纳。例如，我们在开发医疗AI产品时，就对信源设定了如下优先级：

1. S级：行业权威诊疗指南 →
2. A级：顶级学术期刊论文 →
3. B级：经典医学教材 →
4. C级：临床专家的经验总结 →
5. D级：医院内部的疑难病例库

关于效果监测平台

其实大家已经看出，上述所有策略均是对E-E-A-T框架的具体实践。但这里存在一个普遍问题：只有内容投放，缺乏效果监测。没有监测就难以评估GEO的投入产出比。例如：即使你的内容被模型引用了，你很可能也全然不知。

因此，现阶段非常需要一个GEO效果监测平台。它至少需要告诉我们内容被引用了多少次，以及是以何种形式被引用的。然而，由于涉及隐私和平台安全，这样的平台很难真正出现。如果未来能够实现，它很可能呈现如下形态：

图源：《7亿人都是如何使用ChatGPT的》

在此进行一下总结：GEO目前仍带有些许“玄学”色彩，但其底层逻辑是清晰的。它本质上是一场针对AI数据源的“供给侧改革”。

在当前阶段，“正派”与“偏门”的做法皆可尝试，能有效获取流量即是成功。并且，不同发展阶段可能需要侧重不同的策略。总而言之，正派策略或许能带来更持久的效益，而偏门方法也可能在一定时期内行之有效。

实操经验分享

接下来，我们通过一个实践案例，来具体看看某公司的流量团队是如何操作GEO，并取得了哪些成效。

需要说明的是，首先GEO的效果本身就不稳定，其次客户公司也不希望我们透露过多细节。因此，这部分内容无法过于具体，仅供大家感受其思路与方法。

该公司进行GEO的目标非常明确：让全球各地的主流AI，当用户询问相关产品时，能优先且准确地将他们的产品推荐为“标准答案”。