市场在今年初见到Manus这类Agent时表现出极大的热情，其背后的驱动力值得我们深入探究。Agent这一概念为何兴起？它旨在解决哪些核心问题？更重要的是，它是否能有效解决这些问题？在解决问题的过程中，会遇到哪些障碍与挑战，又该如何应对？

带着这些思考，我们进入今天的探讨主题：我们为什么需要Agent？

Agent出现的深层原因

尽管当前的大语言模型已经展现出强大的能力，但其存在固有的局限性。模型的知识完全来源于训练阶段所摄入的数据，这导致了第一个矛盾点的产生：

1. 当今社会信息更新速度极快，一周内就可能发生诸多重大事件。首先，模型的训练数据无法实时跟进这种变化节奏；其次，模型也不应盲目追逐所有信息，因为互联网上存在大量低质量数据，若不加选择地学习，反而会影响其输出质量与逻辑性。
2. 除了公开信息，各企业还拥有大量私有数据和知识库。如果模型无法与这些内部数据交互，那么其在企业场景下的应用价值将大打折扣。

因此，Agent出现的首要原因，是建立模型与外部世界进行信息交互的通道。尤其是在垂直领域，如果缺乏足够的领域数据支撑，模型很容易产生事实性错误或“幻觉”。

此时可能会有疑问：如果仅仅是为了信息检索，直接采用预定义的工作流模式不就可以了吗？这正是经典的RAG（检索增强生成）逻辑。

然而，即使是简单的信息检索需求，其复杂性也在不断增加。初始阶段可能只需要查询公共网络数据，后续则可能涉及A公司的内部知识库、B公司的CRM系统等。当数据源变得多样化之后，一个新的问题随之产生：由谁来判断应该去哪个数据源获取信息？ 这对于传统的RAG系统而言会变得异常复杂。

试想处理如下问题：

什么是组织结构？
你们公司的组织结构是怎样的？A公司和B公司的组织结构又是怎样的？
他们为何要如此设计？

使用纯粹的RAG也能处理，其流程通常为：先由模型解析用户意图，对问题进行重写或拆分，再分发到各个信息渠道进行查询。一套设计精巧的、包含复杂判断逻辑的工作流类RAG确实能够实现。

这就引出了关于Agent最核心的争议：如果Workflow（工作流）能够完成Agent所能做的一切，那么Agent存在的独特价值是什么？

毕竟，Workflow可以实现循环、重试和复杂策略，只不过这些逻辑需要由开发者显式地编码实现。当业务环境的复杂度提升时，Workflow的开发和维护成本曲线会急剧上升。

在企业真实的应用场景中，复杂度增长通常源于以下三类“难以穷举”的情况：

1. 工具/系统不可穷举： 今天查询公共网络，明天接入A公司的知识库，后天连接B公司的CRM系统，大后天可能又要集成C、D、E等系统。
2. 意图组合不可穷举： 用户的一个问题可能同时包含“解释概念 + 对比多家公司情况 + 分析原因 + 生成结构化表格”等多种复合意图。
3. 异常与边界情况不可穷举： 包括权限不足、字段缺失、数据冲突、查询无结果、网页结构变化、接口限流等各种预料之外的状况。

理论上，可以将所有这些逻辑都编写进Workflow中，但这将导致典型的 “分支爆炸”和“维护爆炸”：

1. 每增加一个系统，不仅仅是多配置一个工具接口，还涉及字段映射、降级策略、测试用例更新等一系列工作。
2. 更关键的是，开发者需要为 “工具之间如何组合、何时进行重试、何时切换执行路径、何时向用户追问补全信息、何时应拒绝回答” 编写越来越复杂的显式编排逻辑。

此时，Agent架构的优势便显现出来。如果新增了C、D、E系统，可能只需要增加几个工具配置，甚至在某些情况下，原有的搜索工具可能已具备兼容性，无需改动。最重要的是，Agent架构将判断用户意图、选择调用哪些工具、验证工具返回结果是否正确等繁琐的决策工作，移交给了大模型本身。

当然，这必然会带来更多的循环调用、相对较低的响应效率以及更高的Token消耗。本质上，Agent是一种用运行时成本（时间/Token）来换取架构设计与维护简洁度的工程范式。

需要强调的是：Agent解决的核心并非“如何回答问题”，而是提供了一套将用户问题“编译”为可执行计划的框架。 你甚至可以将Agent架构本身理解为一套高度灵活、由模型驱动的特殊Workflow，这是当前阶段被验证为行之有效的一种设计范式。

总结来说，相较于传统的Workflow，Agent架构是一种工程架构层面的优化。其核心价值不在于让系统“更聪明”，而在于将一部分原本需要工程师在开发阶段显式编写、固化的控制流逻辑（如条件判断、流程编排、异常处理），转移到系统运行时，交由大模型动态决策（如路由选择、工具调用、多轮尝试、失败重试、信息补全、结果校验）。

Agent的核心交易是：以更高的运行时成本（多轮推理、多次工具调用、更高的延迟与Token消耗），来换取更低的开发与维护成本（更少的分支逻辑、更快的功能扩展、对长尾需求更好的适应性）。

在此基础之上，回顾Agent的发展历程，有助于我们更清晰地把握其技术演进的脉络。

Agent技术演进简史

目前最经典的Agent架构是ReAct，大约在2022年被提出（论文《ReAct: Synergizing Reasoning and Acting in Language Models》）。彼时，大模型并不原生支持“函数调用”这类基础的工具调用能力，因此需要开发者自行实现，既可以通过精心设计的提示词来引导模型识别并输出调用指令，也可以进行模型微调（后者成本较高）。

当时的函数调用流程大致如下： 第一，预先定义Agent可以调用的所有工具，通常以JSON对象描述，其中description字段至关重要。 第二，模型根据用户问题和预设的工具集进行匹配，判断本次需要调用哪些工具，主要依据便是工具的描述。 第三，如果判定需要调用工具，模型会返回工具名称及参数，然后暂停生成。 第四，开发者的程序根据模型返回的信息执行实际工具调用，获取数据，并将结果连同原始用户问题再次提交给模型，以生成最终回答。

显然，上述流程较为繁琐。因此在2023年6月，OpenAI正式推出了Function Calling功能，作为ChatGPT产品的核心能力之一。该功能随后逐渐成为行业事实标准，各大主流模型均提供了相应实现。有了这一基础，Agent的开发与应用变得更为顺畅。

后续的发展大家比较熟悉。国内AI Agent概念的热潮始于2025年初的Manus，但如果追溯更早且具有广泛影响力的开源项目，则是2023年3月出现的Auto-GPT。不过，即便是今年初的Manus，也因基座模型能力限制而早期表现不佳，更不用说更早期的Auto-GPT了。

自Manus发布后，行业焦点逐渐从“2025 AI应用元年”转向“2025 AI Agent元年”。与此同时，基座模型能力取得了显著进步，包括整体推理能力、上下文长度都得到了极大增强。可以确信，各大模型均在工具调用相关数据上进行了大量微调训练，其直接成果便是2025年下半年，模型在工具调用方面的准确性和稳定性有了明显提升。

在此阶段，由于基座模型能力的提升，开发者发现Agent对工具的需求急剧增加，且必然会出现大量功能相似的工具。因此，MCP（Model Context Protocol）概念开始兴起。它一方面旨在解决Function Calling带来的工程维护难题，另一方面也致力于推动工具生态的共享与复用。MCP也几乎成为了新的业界标准，Agent生态随之进入了一个快速发展的阶段。

2022年底，ChatGPT 3.5的发布标志着我们正式步入了以大模型为核心的人工智能时代。

经过三年的飞速发展，模型的基础能力经历了全面跃升：推理能力、上下文长度、响应速度、API成本以及多模态支持等关键维度均被持续突破。

在国内，一个标志性的事件是2025年DeepSeek的爆发，它意味着AI应用的土壤开始变得肥沃。自那时起，整个AI领域便呈现出**“乱花渐欲迷人眼”** 的态势：

1. 今日发布一个Manus，明日便出现一个Lovart；
2. Cursor的热度尚未消退，Claude Code似乎已悄然成为AI编程领域的新标杆；
3. 人们前脚还在探讨如何撰写提示词，后脚便有专家宣称RAG技术已经过时，并抛出了“上下文工程”的概念；
4. 当我们正感叹Coze平台宣布开源时，Google的Nano Banana项目又瞬间刷爆了朋友圈；
5. 飞书发布会刚刚浓墨重彩地介绍了其多维表格，钉钉便迅速跟进，强势推出AI表格功能；
6. 医疗AI明星公司OpenEvidence估值高达120亿美元，法律AI公司Harvey的估值据称也已接近110亿美元；
7. …

然而，时间刚刚踏入2026年，我们面临的已不再是新工具层出不穷的问题，而是AI技术正切实地逼近我们当下的工作岗位。它在研发、执行与内容生产三个方面展现出了巨大的变革潜力：

AI编码：重构研发链路

第一条主线是AI编码。它早已超越了补全几行代码或撰写单个函数的初级阶段，开始向分解需求、编写代码、运行测试的全流程渗透。

这背后是整个软件研发链路正在被高度压缩。过去需要一个团队协作完成的任务，如今可能由单人在AI辅助下即可实现。程序员的角色也开始从“代码撰写者”逐渐转向“AI成果评审者”。以下图案例为例，这在AI时代之前几乎是难以想象的：

OpenClaw：从数字员工到技能框架

与其将OpenClaw简单称为数字员工框架，不如将其理解为技能框架或标准化作业程序（SOP）/工作流框架。它的核心在于允许个人用户上传和定制自己的SOP。这意味着你可以将个人或团队的工作流程、业务规则与操作方式系统化地整合进去，AI便能依据这些预设步骤自动执行任务。

OpenClaw的颠覆性并不在于“智能体”这个概念本身，也不在于它是否能处理收发邮件、安排日程、登录系统、填写表单或执行审批等操作——因为这些任务在没有OpenClaw的两年前，通过其他方式也已能够实现。

它真正引发关注的地方在于，越来越多的企业管理者开始相信并采纳OpenClaw这类框架。他们正切实地要求员工梳理和固化SOP/工作流。这将导致一个直接后果：大量流程化、重复性的岗位确实面临着被自动化替代的风险。

AIGC：从“能生成”到“能交付”

以Seedance 2.0为代表的视频生成技术，已经超越了制作炫酷演示的层面，正越来越接近真正可以投放、商用或直接交付成片的水平。例如：

国产AI短剧《霍去病》火爆全球：仅以3000元成本、3人团队耗时5天便产出了80集内容，总播放量惊人地突破了5亿！

研发、执行、内容创作——这三条过去最依赖人类智慧与经验的生产链路，几乎在同一时间被AI技术所“撞开”。

2026：被AI加剧的普遍焦虑

人们突然意识到，2025年大家还在讨论**“我是否需要学习AI”**，而到了2026年，问题已经演变为：

如果AI已经开始撰写代码、运行流程、输出成熟的作品，那么我原本赖以生存的工作技能体系，究竟还能维持多久？

于是，核心问题随之浮现：作为普通人，我们究竟应该如何学习AI，又该如何缓解这种“技术迭代过快、内容过多”所带来的焦虑感？

事实上，大家真正需要的是一套清晰的 AI学习路线图。因为在笔者看来，这里存在一个略显激进的观点：过去几年间，除了底层基座模型的能力在提升之外，整个AI工程和应用层的基础范式并未发生根本性的剧变…

深层观察：AI世界的变与不变

如果我们仅从层出不穷的AI产品视角观察，发展速度确实令人眼花缭乱，甚至感到陌生。但如果切换至工程实现的视角，便会发现，除了基座模型能力的大幅增强外，许多所谓的“新事物”不过是工程侧为解决特定问题而进行的必要优化与演进…

模型能力跃升与相关概念演进

首先，对比近两年GPT系列基座模型的各项关键指标，它们几乎可以被视作不同的物种。例如，单是上下文长度就扩大了惊人的128倍：

除了模型自身能力的飞跃，近两年围绕模型衍生出的高频概念无非是：Function Calling、MCP、Agent/ReAct、CoT、Skills 等。

以我们最为关注的智能体（Agent）为例，其核心框架最早可追溯至2022年，由论文《ReAct: Synergizing Reasoning and Acting in Language Models》正式提出。当时由于需要调用外部工具，而官方并未提供标准接口，只能通过复杂的提示词工程来实现，流程远比现在繁琐。

Function Calling：工程复杂度的简化

随着Agent生态的发展，OpenAI可能认为原始的实现方式过于复杂，便于 2023年6月 正式推出了Function Calling接口，并对模型进行了大量的针对性微调训练，以确保工具调用的稳定性和准确性。这一举措本质上是为了降低Agent实现的工程复杂度：

MCP：工具集成的解耦方案

然而演进并未停止。当一家公司内部部署了多个AI Agent时，工具的维护便会产生耦合问题。一旦工具数量增多，整个系统的维护成本将急剧上升！

试想一个场景：一家企业中有10个不同的AI Agent需要接入20个数据源或工具。如果每个应用都为其所需的每个工具编写专用适配代码，那么将产生高达200个集成点。任何工具的API发生变更，都将引发连锁反应，维护工作异常繁琐。

正是基于此类工程难题，模型上下文协议这类结构化规范被提出，其核心目标正是解决工具集成的工程化维护问题。

Skills：提升复杂任务下的工具调用可靠性

演进仍在继续。随着模型能力提升，Agent所需完成的任务日趋复杂，需要调用的工具数量也相应增加，新的问题随之浮现：

即便不考虑上下文长度的限制，虽然模型的理解能力显著增强，但它依然无法保证工具调用的绝对准确性。

在之前的讨论中，我们曾提及“管理无用”的观点，这引发了一些读者的深入探讨。

实际上，我更想表达的是：业务增长与管理并无直接的因果关系，管理更多地是保障运营下限的基石。为了更清晰地阐述这一观点，我们可以回顾去年一些 “AI + 管理” 的具体实践案例，它们正是此理念下的一个具体分支。

许多企业在销售管理过程中，都会反复遭遇一个经典难题：

1. 同一客户，被两名销售同时跟进联系。
2. 客户感到困惑：“你们不是同一家公司吗？”
3. 销售之间相互争执：这个客户的业绩究竟应该归谁？
4. 管理层更为头疼：业绩核算、提成分配、责任界定变得模糊不清。

这类情况，在销售管理领域有一个非常典型的名称：撞单。

表面上看，这似乎是销售团队内部沟通不畅所致；然而，从大量企业实践反馈来看，撞单问题几乎从来不是简单的“人”的问题，其根源往往在于管理体系本身。这也印证了我们前述的观点——管理旨在确立下限。通常，问题的核心涉及系统层面，根本原因可归结为：

系统设计未能兜底 + 业务流程不够清晰 + 分配规则缺乏自动化

若期望从根本上减少乃至消除撞单现象，答案指向明确：引入CRM系统，将依赖个人自觉的“人治”模式，升级为依靠规则与数据的“系统治理”模式。

具体的实施路径颇为常见：首先梳理标准作业程序（SOP），继而通过系统实现自动化。所有此类工作的核心工作量集中于流程梳理，而这本身就是最基础的管理动作，是机制设计的重要组成部分。

回顾当时的解决方案设计，我们参考了市面上的多种策略，并结合主流CRM的最佳实践，最终拆解出四大防撞机制，便于企业直接参照搭建并落地执行。当然，为了提升解决方案的价值，其中融入了不少AI元素。以下是具体的操作过程：

一、记忆客户：建立唯一身份标识

许多企业初期希望仅通过制度约束来避免撞单，不愿投入系统资源，但忽略了一个关键前提：系统必须首先能够准确识别“谁是谁”。

唯一识别

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

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

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

• 自动识别重复客户记录
• 提示可能存在的撞单风险
• 阻止完全重复的客户档案被创建
• 给出是否合并相似记录的智能建议

系统基于规则的判断能力，在稳定性和准确性上远超人工核对。

去重策略

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

• 强制去重：系统检测到重复客户时，直接禁止创建新记录。
• 提醒去重：系统提示潜在重复风险，由销售人员进行确认操作。
• 自动合并：对多条高度相似的客户记录，系统引导用户将其合并为一条完整档案。

企业可以根据自身所处的业务阶段灵活配置策略，避免一刀切。

集团客户的层级识别能力

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

• 构建“集团客户 → 子公司 → 部门”的多层组织结构。
• 实现集团级客户的统一识别。
• 设置跟进记录的跨组织共享或权限隔离。
• 提供跨组织撞单的预警功能。

从而从系统层面避免“看起来是不同客户，实则归属同一决策体系”的情况发生。

二、AI分配：确立清晰的归属规则

客户归属权不能依靠争抢决定，而应由系统自动分配。如果仅以“谁先联系到客户”作为归属标准，撞单几乎无法避免。

客户归属 = 系统自动分配

在成熟的CRM管理体系中，一个核心原则是：客户资源归属于公司，而非个人。

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

• 确保每条线索只有一个明确归属。
• 杜绝多人同时跟进同一线索。
• 分配过程快速、规则清晰、 resulting in 干净的数据记录。

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

• 轮询分配（均衡销售资源）
• 按地理区域分配
• 按产品线或业务单元分配
• 针对不同来源渠道设置不同分配策略

这一切涉及根本的销售利益，仅靠人力协调完全无法实现公平与高效，因此需要借助AI算法进行智能化的线索分配。

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

其次，之前为他们部署的那套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创业的浪潮中摸爬滚打了近两年时间，我主要投身于面向企业的AI服务领域。去年尝试搭建了一个SaaS平台，原本计划销售标准化产品，但在实际推进过程中，却不得不为各家客户进行定制化部署实施。更令人无奈的是，项目尾款的回收过程异常艰难，最终核算下来，这一年非但没有盈利，反而亏损了数十万元。这段经历让我深刻体会到了国内市场在企业服务付费意愿和习惯上的现状。

尽管遭遇了财务上的挫折，但抛开纯粹的“生意”视角，我在这一过程中也观察到了一些值得深思的现象，其中不乏与主流认知相悖的发现：对于相当数量的公司而言，AI技术的实际效用有限，或者说，他们并未真切感受到AI带来的价值。

举例来说，去年我曾接触过几家传统制造业企业（例如水务公司和工厂）。这些企业本身已实施了一定程度的自动化改造，其中一家啤酒生产商的自动化率已经相当高。其保留的岗位员工并非技术不可替代，而是出于某些管理或人情上的“需要”。对于这类传统企业而言，他们并不认为AI能带来显著的额外价值（同样地，他们对数字化转型也持保留态度）。

AI在替代低端、重复性劳动方面，目前发挥的作用其实相当有限。 即便是其公认擅长的客服领域，也并非企业主真正关心的核心成本项。对于客服团队庞大的公司而言，其市场营销投入往往更为惊人。当老板面对上亿元的广告费用账单时，客服部门数百万的人力成本相比之下就显得微不足道了。

再看AI渗透较为深入的领域，例如AI辅助医疗，这是我较为熟悉的板块。这项技术确实具备可行性，但当前多模态能力的不足是明显短板。只要在体征检查、触诊等需要物理交互的环节无法取得突破，AI医疗的完整拼图就始终存在缺失。

法律领域的情况可能比医疗更为复杂。当前法律数据的分散性极高，且法律推理本身具有一定的不确定性，存在“正确的输入未必能保证正确的输出”的情况，其中的挑战远比表面看来更多。

教育领域则更为特殊。它看似与AI医疗、AI律师类似，但真正落地时，第一步就会遇到障碍——例如构建“学生知识成长图谱”。如果AI无法精准评估学生的真实能力水平，就无法实现学习内容的“难度N+1”自适应推送，所有的输出都可能沦为低效的重复。

当前受AI冲击最显著的领域或许是程序员行业。最典型的例子是AI大模型对前端开发的影响。由于前端场景相对容易穷举和模式化，今年几乎每一次重磅模型的发布，都被视为对前端行业的一次冲击，到Gemini发布时，类似的“唱衰”已经发生了不下八次。

然而，断言AI将消灭程序员显然是不准确的。更恰当的认知是，AI编程的发展预示着我们将迈入自然语言编程时代。在我经手的几个复杂AI项目中，实际情况是：核心业务代码可能仅有一万行左右，而用于驱动AI的提示词（Prompt）却多达数十万行。可以认为，编写高质量的提示词本身就是一种自然语言编程。因此，AI淘汰的并非程序员，而是那些仅仅停留在工具使用层面、缺乏抽象和解决问题能力的“代码搬运工”。

综上所述，AI技术在“高大上”的创新赋能和“接地气”的基层作业替代这两个层面，其实际意义都还与业界宣传存在差距。近来备受关注的、号称能完成所有任务的“AI智能体”，也收到了诸多质疑的声音。

结合我为超过40家企业提供服务的实际经验来看，AI项目落地带来的价值更多体现在“降本”上，而“增效”的效果并不显著。但若将降本的功劳完全归于AI，似乎也不够公允。它更像是企业数字化转型进程的延续，AI补全了其中20%左右难以通过传统自动化实现的环节（这也是为什么像飞书、钉钉这类协同办公平台极力推广AI表格功能的原因）。

话题展开得有些广泛，现在让我们回归今天的重点：分享一些在AI to C（面向消费者）产品领域的实践心得与技巧。

---

聚焦AI to C产品领域

首先给出一个核心观点：在我看来，打造面向消费者的AI产品，其可行性要高于面向企业的AI服务。 在决定暂停2B业务后，今年我将精力投入到C端产品的打磨上，投入了数十万资金，主要涉及两个方向：

1. “叶小钗”个人IP的塑造；
2. “空气小猪”产品（一款基于熟人社交的英语学习工具）。

今天我们将重点探讨第二个产品——“空气小猪”的实践。

那么，我是在鼓励大家都涌入AI to C赛道创业吗？恰恰相反，我强烈不建议个人或小型团队贸然进入AI to C领域开发小型产品。 原因非常直接：当前市场环境极其恶劣，内卷严重。

创业环境：高门槛与长周期

首先，AI产品的核心交互离不开对话，因此小程序的体验往往不佳，并不适合作为主要载体。用户普遍反感在微信聊天界面和AI产品之间频繁切换。

如果选择开发原生APP，成本将大幅攀升，并面临一系列门槛：

1. 采用uniapp等跨端框架并不合适，至少需使用React Native，因为需要处理虚拟键盘的大量兼容性问题；
2. 算法备案流程，耗时约6个月，费用8000元起；
3. 大概率需要申请电信业务经营许可证（ICP证等）才能上架应用商店；
4. 其他隐形成本。

总而言之，从一个AI APP的构思到最终上架，至少需要20万元启动资金和4个月的时间周期。

请注意，对于许多创业者而言，20万并非小数目，这笔资金足以支撑一家小型实体店的初期运营。

由此得出的结论是：尽管宏观政策层面一直在支持AI产业发展，但具体到创业环境，或许是出于保护普通创业者的考虑，当前环境对一般人的AI创业并不友好。 且不论各种资质审批的复杂性，在许多办公空间闲置的背景下，我个人在成都甚至一直未能成功申请到免费的创业孵化器工位。

由基础环境导致的产品开发周期长还只是小问题，接下来的两个挑战几乎是所有2C产品都难以避免的。

同质化困境：创新难逃抄袭命运

C端AI产品的同质化现象异常严重，几乎不存在绝对的创新壁垒。因为如果你的创新点确实出色，最多一个月，类似的功能就会出现在其他竞品上。

以“空气小猪”为例，我们曾对产品中的某个聊天交互创新点非常自信。在开发前，我们调研了市面上所有知名的英语学习产品，再三确认没有类似功能后才启动开发。

然而，就在开发完成之际，我惊讶地发现海外版的钉钉、飞书已经上线了类似功能，再打开微信一看，它竟然也有了。

产品正式推出后，又有用户反馈说发现另一个创业团队在做和我们几乎一样的事情。

因此，你认为的绝妙创意，很可能只是信息搜集不够全面。许多自以为是的天才想法，或许早已遍地开花。这也是做C端产品必须警醒的一点：很难依靠单一功能点或产品特性建立长期优势。

对于初创团队而言，用户体验并非唯一重要的因素，C端产品必须尽快实现商业闭环。

必须以盈利能力为核心来评估和迭代产品，切忌在一些自认为“贴心”但非必需的功能点上过度投入成本，因为最终往往发现，许多“贴心”功能并非用户真正需要的。

只要是面向消费者的产品，就离不开流量逻辑。只要流量足够大，即便产品体验有所欠缺，依然可能产生营收。这就引出了C端产品最核心的板块：流量获取。

流量困局：稀缺性与获取难度

既然环境不佳、成本不低、同质化又严重，是否意味着C端AI产品完全没机会了呢？

倒也并非如此，这很大程度上取决于创始人的心理预期。C端市场体量巨大，只要创始人拥有足够强大的心力（这一点至关重要，否则极易中途放弃），总能从这片流量海洋中分得一杯羹。

分享一个我们相对轻量级的案例：一款日活跃用户约500的英语学习产品，每月能产生4万元左右的收益。

4万元这个数字当然不算高，并且这款产品似乎已触及增长天花板，很难再有突破。但对于许多产品而言，或许只需要不到1000的日活就能维持良性运转，这也算是一种“小而美”的存在方式。

只不过，你需要权衡的是，是否愿意投入50万到100万的现金，去博取一个“日活500、月入4万”的可能性。请注意，这仅仅是一种可能性，因为达到这个目标本身就非常困难。

流量是稀缺资源。 不可能仅仅因为你发布了一款产品，在朋友圈转发几次，就能吸引大量用户下载。成为爆款是小概率事件，并且大多数普通团队并不具备技术上的绝对亮点，很难吸引市场注意力。

对于多数普通人而言，要做C端产品，只能一步一个脚印地积累，并且在初期切忌盲目投放广告。最务实的方法是进行“流量化缘”。

---

“流量化缘”实战策略

关于“流量化缘”，具体方法有很多，它属于体系化流量运营的一部分。为了提供更实际的帮助，这里我将分享其中一种效率相对较高的策略，并对其拆解说明。

当前主要的流量平台集中在抖音、小红书、视频号/公众号体系。对于产品推荐而言，抖音和小红书尤为适用。

最常见的“流量化缘”或引流做法，是去相关领域的大主播视频评论区进行互动。例如，我们会在英语教学类博主的短视频下评论：“用过‘空气小猪’学英语，体验真的超爽！” 就是这样简单的一句话，往往能带来可观的流量收益。

那么，流量化缘的答案就是让大家四处去评论吗？

当然不是，那样就显得太没有技术含量了。事实上，所有流量运营体系都应该尽可能实现自动化，否则人力成本将难以覆盖收益。

为了让分享更具价值，我将具体如何实现自动化（以抖音为例）的方法也一并公开。首先，我们需要理解自动化评论并非胡乱操作，首先要获取目标抖音博主的视频文案，判断内容是否相关，只有合适的视频才进行评论，有时甚至可以针对视频下的用户评论进行二次回复。

我们采用的方案是：利用Coze平台进行前端信息采集，再结合飞书多维表格进行数据存储与流程控制，从而构建完整的自动化工作流。

承接上篇文章《万字：AI Coding 到了什么程度了？》的探讨，我们得出的核心结论是：

AI编程已经超越了仅仅编写演示代码、补充函数或创建简单页面的阶段。

在约束条件清晰、业务边界明确且验收标准可执行的前提下，它已经能够胜任相当一部分实际的软件交付工作。

与此同时，深度使用过AI编程工具的同学也必然清楚，在新项目或规则清晰的项目中，AI的表现往往非常出色。随之而来的一个关键问题是：在面对那些历史悠久、结构混乱的“遗留代码”时，AI编程的表现又如何呢？ 例如：

对于一个运行超过十年、文档缺失、逻辑错综复杂、维护成本极高的系统，想要重构却担心引发问题，不重构又严重阻碍业务发展。在这种“地狱难度”的场景下，AI能否真正发挥作用？

今天，我将分享我们团队一次真实的AI编程实战经历：仅用两周时间，成功完成一个运行十年、累积54万行PHP代码的核心电商系统的重构，并将其平稳迁移至Java技术栈。 整个项目全程深度依赖AI辅助，最终实现了按时且平稳的交付。

项目背景：一场高风险的技术战役

十年老系统、54万行PHP代码、两周交付周期、核心电商业务链路、从PHP迁移到Java，当这些要素组合在一起时，即便是完全依靠人工团队来完成，也足以让许多经验丰富的团队感到棘手与沉默。

此类项目的最大难点，从来都不在于“如何编写新代码”，而在于：你很可能根本不清楚自己正在改动的是一个什么样的系统。

遗留系统与新项目截然不同。新项目的业务逻辑相对清晰（至少文档是齐全的），很多时候只要将需求拆解清楚，AI就能持续推动进度。然而，“遗留代码山”并非如此。

它最核心的问题并非代码质量低下，而在于其低质量的复杂性、真实性与经年累月的线上运行历史交织在一起。

大量逻辑没有文档记载；无数业务分支在设计稿中无从查找；许多兼容性代码，甚至连最初的开发人员都可能遗忘其存在的初衷。你今天看到的一段糟糕代码，很可能并非源于当时开发者的能力不足，而是因为三年前某次线上事故，临时采用这种方式进行兜底处理；你觉得某个字段命名怪异，其背后或许关联着三个旧版本客户端和五个外围系统的调用。

因此，面对这类系统，最大的风险并非“写不出代码”，而是“你以为自己理解了，但实际上并未真正理解”。

本次项目最具价值的部分也恰恰体现在这里。它并非意在证明AI已经能够独立完成遗留系统的重构，而是证明了：

当人类工程师牢牢守住系统边界与核心决策权时，AI足以承担重构过程中大量最繁琐、最枯燥、最重复的工作任务。

这才是本次案例真正值得深入探讨的原因。接下来，我们将直面项目中的具体挑战。

直面挑战：老系统重构的三大核心难题

提及老系统重构，多数人的第一反应通常是代码基数庞大、历史包袱沉重、技术债务堆积如山。

这些固然是事实，但如果你真正参与过此类项目，便会发现导致项目最终失败的，往往并非代码质量问题本身，而是以下三方面因素叠加所产生的影响：

挑战一：代码量巨大，难以全面掌握

54万行的总代码量，意味着几乎没有人会真的打算逐行阅读所有代码。

这并非“多花几天时间总能看完”的问题，而是你根本无法在有限时间内建立起对整套系统足够可靠且全面的认知。

尤其是核心电商系统，商品导购、详情页、库存管理、价格计算、促销活动、异常处理以及各类兼容性分支，这些模块通常深度耦合、相互牵连。

一个看似简单的接口，其背后可能隐藏着一长串复杂的调用链路；一个响应对象中不起眼的字段，可能已被前端页面、运营后台以及多个外围服务同时依赖。

更为棘手的是，这类系统通常还伴随着以下几个典型问题：

1. 文档严重缺失，甚至许多关键部分完全没有文档。
2. 存在大量弱类型代码，字段的真实数据类型并不稳定。
3. 诸多隐式业务逻辑和历史兼容代码隐藏在细节之中。
4. 代码“坏味道”明显，但出于风险考量又不敢轻易修改。

因此，最大的难点并非读不懂某一段具体代码，而是代码量近乎无限，你永远无法“看完”，也无法掌握全貌。

挑战二：交付时间异常紧迫

如果时间充裕，无论系统多么复杂，总有可能通过逐步推进的方式完成重构。

但本次项目不具备这个条件。两周的交付窗口，首先意味着，在组织层面，“重构”本身就可能被视为一种资源浪费行为，而非必要的技术投资。团队历史上的技术基础设施建设（或称技术债务偿还），往往都是在高强度加班中完成的…

其次，它意味着你没有足够的时间去彻底读懂旧系统，没有时间先行补充完整文档，没有时间进行从容的抽象设计，更没有机会采用许多人习惯的传统路径：先完全理解，再逐步重构。

真实业务场景下没有“尽力试试”的选项，只有必须按时交付的硬性要求。项目几乎没有试错空间，也无法以“尚在理解过程中”作为延期借口。

每一次对核心系统的重构，都如同在高速行驶的汽车上更换轮胎，充满了极高的风险与压力。

挑战三：业务风险等级极高

如果这只是一个边缘系统、内部后台或报表工具，出现问题尚有修复和回旋的余地。

但本次面对的是核心电商系统。这类系统最可怕之处，并非它是否会直接崩溃，而在于它很可能陷入一种更为麻烦的状态：表面运行正常，但核心业务行为已悄然发生改变。

例如，金额少计算了一点，库存判断出现一次偏差，导购页面漏掉一个分支逻辑。这些看似微小的差异，一旦置于线上真实流量之下，便会造成切实的业务损失。

因此，项目真正的难点在于：

如何在极短的时间内，将一个庞大而未知的系统，转化成一个可分析、可验证、可灰度发布、可快速回滚的工程对象？

如果无法做到这一点，AI的编码能力越强，可能引入的潜在风险反而越大。

破局关键：确立可验证的行为基线

许多团队在进行老系统重构时，初期很容易陷入一个思维定势：必须先将旧系统彻底理解透彻，再开始动手改造。

这听起来合情合理，但在高压交付环境下，这条路径极易导致团队陷入认知泥潭而无法推进。因为对于许多遗留系统而言，“彻底看懂”本身就是一个伪命题。

尤其是运行了十年的老系统，其线上真实表现与最初的设计意图往往早已大相径庭。大量业务逻辑、分支判断和兼容性代码，都是在线上运行过程中逐步演化出来的。如果一味追溯它“原本应该如何设计”，经常会使重构方向越走越偏。

因此，我们本次项目改变战局的第一步，是放弃“先求全面理解”的路线，转而采取了一条更为务实的策略：不追求立即获得完整理解，而是优先还原系统的真实运行时行为。

换言之，我们不再首先追问“它本该如何设计”，而是优先探究：

1. 这个接口当前实际接收哪些参数？
2. 它会经过哪些具体的逻辑处理分支？
3. 它会返回什么样的结果数据？
4. 它会访问哪些数据库表或外部服务？
5. 它会产生哪些副作用（如写日志、发消息等）？
6. 在异常情况下，它的实际表现究竟是怎样的？

我们最终以每个URL接口作为最小单元，进行行为还原。这是一个至关重要的策略转向。因为一旦确立了清晰的行为基线，后续许多工作便有了明确的判断标准：

1. AI生成的新代码是否正确，有了比对基准。
2. 测试用例该如何编写，有了具体依据。
3. 进行差异分析时，有了可靠的锚点。
4. 能够清晰区分哪些是代码优化，哪些是可能改变原有行为的潜在风险。

如果没有这一步，重构工作很容易从“代码迁移”演变为一场“悄无声息的重写”。而老系统重构最忌讳的，并非代码无法产出，而是在无意中改变了原有系统的行为，却误以为自己是在进行优化。

基于近两年的实践经验，企业中最常见的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领域的一张问题分类表（其作用在于收敛问题范围）：

问题类型	示例
请假管理 ： 请假与休假办理、审批规则、证明材料、销假/续假；考勤记录与异常更正（补卡/漏打卡）、迟到早退等出勤异常处理。	1）我想请病假/年假，怎么申请？ 2）请 3 天病假需要什么证明？ 3）我忘记打卡了，怎么补卡？
薪资规则 ： 计薪口径与发放周期；扣款/补发规则；补贴、加班费、绩效奖金发放；与出勤/请假相关的计薪规则（如病假工资）。	1）病假工资怎么算？会扣多少？ 2）这个月工资少了，扣的是什么？ 3）加班费怎么算？周末和节假日一样吗？
社保公积金 ： 参缴条件、基数比例、增减员；断缴/补缴/转移；商业保险与福利报销类事项的办理要求。	1）社保公积金什么时候开始缴？基数怎么算？ 2）社保断缴了怎么办，能补缴吗？ 3）商业保险怎么报销，需要什么材料？
入职、转正 ： 入职手续与资料；试用期与转正流程；工龄口径；员工信息变更；在职/收入等证明开具。	1）我什么时候转正？流程怎么走？ 2）工龄怎么计算？影响年假吗？ 3）在职证明/收入证明怎么开？
离职 ： 离职申请与通知期；交接要求；离职证明；最后工资/补偿结算；社保公积金停缴/转移；未休假期结算。	1）离职流程怎么走？要提前多久提？ 2）离职证明怎么开？什么时候能拿？ 3）最后一个月工资怎么结算？
制度查询 ： 制度入口与版本；条款解释与适用范围；例外情形；违纪处理；保密/竞业等合规边界说明。	1）公司制度在哪里看？最新版是哪份？ 2）某条规定怎么解释，有没有例外？ 3）这个做法合规吗？有红线吗？

数据处理

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

承接上文，在我们近两年完成的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？

在2025年10月6日举行的OpenAI DevDay上，出人意料地推出了一款名为AgentKit的产品。该产品旨在帮助开发者以更少的时间和精力，完成从原型设计到生产部署的全过程。简而言之，OpenAI构建了一套工作流编排工具，其本质是一个低代码平台。

随后，LangChain的创始人对这类可视化工作流构建器的价值表达了不同看法，认为其用处有限，并指出诸多原因：拖拽式操作不利于复杂工程构建！ 通俗地说，这类工具门槛过高，程序员群体看不上，普通用户又用不习惯，导致其发展前景不被看好。

然而，凭借OpenAI巨大的行业影响力，其**“直接竞品n8n”** 确实受到了不小的冲击。因为在AgentKit发布后不久，n8n便于10月9日宣布完成了1.8亿美元的融资。可以推测，在n8n融资的关键时期，AgentKit这款“竞品”的横空出世，无疑给其带来了压力。尽管n8n方面可能认为AgentKit并非其真正对手，但OpenAI的入局必定在资本市场上引起了波澜，迫使n8n在融资的关键节点准备了大量应对说辞，最终才如释重负地完成了融资。

紧接着在10月13日，备受压力的n8n发布了可能作为“压箱底”的新功能——AI Workflow Builder，以此继续与OpenAI进行竞争，并传递出一个明确信号：我们不再仅仅卷工作流的拖拽设计了，用户也无需再费力梳理复杂的工作流逻辑，未来直接使用自然语言就能生成n8n工作流！ 这是否意味着，行业竞争的重点已转向自然语言生成工作流这一新赛道？

从自然语言到工作流：技术路径的演进

事实上，AI Workflow Builder并非首个提出用自然语言生成工作流的厂商。Zapier早在10月3日就已上线了AI生成工作流大纲的功能。在Zapier控制台中，用户只需用自然语言描述“当X事件发生→执行Y动作→再进行Z操作”，系统便会自动生成一个包含触发器及若干动作的草稿大纲，用户随后可进入编辑器进行细化。

另一家自动化平台Make也在其公开路线图中强调了AI辅助构建功能，用户可以用目标语句让AI助手搭建一个场景（Scenario）骨架，助手还能解释场景的工作原理并帮助排查错误。

更贴近国内用户的是8月25日钉钉推出的AI表格助理，其核心目标同样是大幅降低工作流搭建的难度。钉钉AI表格助理正式上线后，用户仅需通过自然语言对话描述需求，它就能按要求自动生成AI表格、自动化工作流以及数据仪表盘分析，创造出真正可用的AI应用，显著降低了AI表格的使用门槛，让每个人都有可能成为AI应用的创造者。

上述案例都应归属于同一种思路：在积累了足够数据的前提下，例如已经拥有充足的HR招聘工作流提示词或编排数据后，利用智能体（Agent）技术来降低专业知识（Know-How）的复用成本。不过，从各方面的评测和反馈来看，整体效果目前还处于比较初级的阶段。这自然引出了一个核心问题：为什么会出现AI Workflow Builder这类工具？

AI Workflow 的核心价值：降低应用门槛

先说结论：对于大多数普通用户而言，构建工作流实在是太困难了！ n8n这类工具更多面向程序员群体，对产品经理都不够友好；而Coze虽然对产品经理更友好，但对于医生、律师等非互联网从业者来说，使用门槛依然很高。这里的难点主要在于两方面：

第一，工具本身的学习和使用过程繁琐。即便对于熟悉技术的人来说，掌握Coze、n8n的所有功能也需要投入时间。在完全熟悉工具之前，虽然不会遇到实质性的技术瓶颈，但会非常耗时，例如理解Coze中的循环逻辑就可能花费数小时。

第二，梳理标准作业程序（SOP）极其麻烦，这才是真正的核心难点。任何工作流类的AI应用，其价值瓶颈往往在于工作流的数量和质量。这其中又包含两个挑战：一是需要对相关岗位的业务有基本理解；二是团队在实际沟通和梳理过程中会反复迭代，耗费大量精力。下图展示了梳理HR工作流时的复杂情况：

接下来我们将深入分析，这部分内容逻辑较为紧密。为了便于理解，我们以医生为例进行推演（律师、教师等职业的逻辑是相似的）：

AI数字分身的演进逻辑

假设你是一位拥有10年经验的心内科医生，同时你在大学期间主修计算机专业（并且技术功底扎实，偶尔接一些技术副业）。因此，你同时具备了专业的医疗知识（Know-How）和扎实的工程技术能力。

你医术高明，每天能接诊100名病人。但由于名声在外，实际需要你提供咨询的患者超过1000人，其中900多人的问题非常基础，根本无需你亲自处理。

于是，你利用自己的技术能力，为日常工作搭建了一套工作流AI系统，并为其设计了专用的数据结构（或运用上下文工程），将你的心内科专业知识结构化了进去。

这个心内科数字分身上线后广受好评，它完美解决了你90%患者的常见问题。随后，你的妻子（一位眼科医生）、你的小舅子（一位神经内科医生）以及你的朋友（一位心理科医生）都希望使用这套系统。

于是，你开始进行抽象化设计，将你的工作流逻辑与具体数据剥离，只保留一个基本的智能体框架来承载工作流代码（JSON结构）和数据。最终，你实现了一个类似于Coze的系统，交给家人和朋友使用。

然而，你的妻子、小舅子和朋友并不买账。他们认为这个系统对非技术背景的医生来说太复杂了，那种复杂的工作流拖拽操作，他们根本没有能力完成，而且还需要整理大量结构化数据，这简直难以承受。

在他们的不断敦促下，你不得不对系统进行进一步简化，核心功能聚焦于两点：

第一，让普通人能够通过更自然的语言生成工作流。但由于大模型的能力并非万能，你不得不为每个科室预先设计并生成了多套常见的工作流模板。这样，当你妻子这样的非技术用户用自然语言描述需求时，模型能够根据现有模板，尽可能准确地生成对应的工作流JSON配置。

第二，让普通医生能够上传随手可得的数据（如医患对话记录、病例信息），然后系统自动生成AI所需的结构化专业数据。为了实现这一点，你至少又做了两项工作：首先，尝试利用自己积累的医患对话和病例数据，生成与你历史沉淀数据格式一致的内容；然后，按照这套逻辑为各个科室生成基础的数据集，但允许医生进行最必要的微调。

完成这两项改进耗费了你大量的精力。最终，当你将新系统交付给家人使用时，终于获得了他们的认可。这时你才深刻意识到：对于大多数领域专家来说，他们真的不想在工具使用上多走哪怕一步弯路！

以上就是AI数字分身（或者说专业领域Agent）的演进逻辑，实际上，这也是从n8n传统工作流模式向AI Workflow模式演进的内在逻辑。接下来，让我们看看n8n的实际实现情况。

AI Workflow Builder 功能实测

在n8n Cloud界面中进入AI Workflow Builder，用户可以在对话框中输入指令。系统会提供实时生成进度反馈，并允许用户追加指令对生成的工作流进行迭代优化。

注：当前AI Workflow Builder处于Beta测试阶段，使用自然语言指令会消耗一定的平台积分。

总体体验下来，该功能定位于帮助具有一定技术背景但非专业开发人员的用户，快速将他们的专业知识（Know-How）转化为可运行的n8n工作流。

这里存在一个关键问题：n8n生成的工作流是AI从零开始构建的，还是通过检索内部已有的工作流模板进行组合？

n8n官方维护着一个庞大的工作流模板库，其公开的社区模板数量超过6000个。如此丰富的现成流程，理论上可以作为“范例”供AI学习和复用。这个问题的答案关系到AI生成流程的独创性和最终输出的可靠性。

如果是完全原创生成，可能更加灵活，但也更容易出现错误配置或产生不符合逻辑的“幻觉”节点；如果是基于现有模板进行复用和组合，输出质量可能更稳定，但也可能缺乏针对特定场景的创新性。

技术实现策略推论

n8n的工作流本质上是由JSON格式定义的，包含了节点列表、连接关系以及各节点的参数等。我们分析了一份由AI Workflow Builder生成的示例工作流JSON，以下为关键片段截取：

{
  "name": "AI Generated Workflow",
  "nodes": [
    {
      "id": "1",
      "name": "Gmail Trigger",
      "type": "n8n-nodes-base.gmailTrigger",
      "parameters": { ... }
    },
    {
      "id": "2",
      "name": "AI Agent",
      "type": "@n8n/nodes-base.openai",
      "parameters": { ... }
    },
    {
      "id": "3",
      "name": "Slack",
      "type": "n8n-nodes-base.slack",
      "parameters": { ... }
    }
  ],
  "connections": {
    "Gmail Trigger": {
      "main": [[ { "node": "AI Agent", "type": "main", "index": 0 } ]]
    },
    "AI Agent": {
      "main": [[ { "node": "Slack", "type": "main", "index": 0 } ]]
    }
  }
}

示例说明：假设用户提示要求“监控Gmail新邮件，用AI总结内容后发送Slack通知”，AI生成了上述包含Gmail触发器→AI总结节点→Slack发送节点的流程结构。

上周，我们AI训练营的第一批学员（1班和2班）正式毕业了。课程最终收获了平均80分的评价，最低分70，最高分95，甚至还出现了几位主动推荐新学员的情况。这让我如释重负，总算没有被大家看作是“割韭菜”的行为。

特别想分享的是，其中一位产品负责人学员发出的感慨：

我现在终于明白，为什么以前总搞不懂公司里那帮程序员在忙什么了。他们在设计技术架构时，采用的是一种“AI Max”的思维模式：

某个开源技术不行就立马换另一个，单智能体效果不佳就尝试多智能体。把所有能试的都试过一遍后，得出结论：AI的能力上限就到这里了，没有优化空间了，只能等待更新的技术开源出来，然后再重复一遍这个过程。

我有时实在好奇，会追问他们如何量化这个所谓的“上限”、有没有系统性的方法论？而程序员的回答往往是：这没法量化，也无法沉淀经验，无非是拿别人的东西跑一下试试看。

我总觉得哪里不对劲，但由于自身不懂技术，也说不出个所以然，只能听之任之。现在好了，既然这条路确实走不通，那就换我来给他们设计技术路径！

实际上，上述场景正是当下许多公司共同面临的困境：由于AI项目的入门门槛看似很低，导致整个团队可能没有一个人真正理解AI项目的内核，也能勉强做出一个70分的产品。然而，当需要从70分优化到80分时，整个项目就陷入了僵局…

根据过往的经验，这样的一次试错，成本少则50万，多则甚至上千万。通常到了第三次尝试时，AI技术负责人就不得不亲自下场，深入探索真正合适的技术路径，而这个过程的成本，至少以100万元为起点…

于是问题接踵而至：公司投入百万的AI项目，看起来却像个玩具。当你询问技术负责人如何改进时，对方往往一脸茫然，最终抛出一句：“当前模型的能力就是这样了，我也没办法。”

最终的结果是，众多企业老板对AI的期望值大幅降低，认为泡沫过大，不愿继续投入。因此，从2025年至今，超过80%的公司都停留在搭建各种自动化工作流的层面，根本没有勇气涉足AI项目的“深水区”。

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

1. 第一，认知的知识化。 如何将模糊的业务认知整理成结构化的知识；或者，在已有知识的情况下，如何有效地组织相关数据。
2. 第二，数据与AI的协同交互。 如何确保AI每次都能获取到最相关的数据。当发现因数据不足导致的AI问题时，如何利用生产环境中产生的数据反馈来优化知识库——这正是我们常说的“数据飞轮”系统，它是数据工程的一个重要分支。
3. 第三，意图的精准识别。 理解用户或系统真实意图的终极关卡。

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

只不过，这句话背后涉及一连串复杂的背景知识。那么，有没有更简单的理解方式呢？答案是肯定的！

理解可观测性：从准确率到可追溯性

最近在给学员授课时，我最常强调的一句话是：构建AI应用，必须深刻理解模型的边界！ 这里所说的模型边界，关联着AI应用的两种主流思想：

1. AI Max 流派：凡是能用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 Max）

如果全部交给AI处理，方法非常简单：直接将所有聊天记录扔给大模型，并附加一句指令：“请根据以上对话，推荐今天适合安排上课的时间段。”

这是GPT给出的回答：

这是DeepSeek给出的回答：

在简单场景下，“能用AI就AI” 往往是最优解。包括许多智能体（如一些自动化工具）在处理简单任务时，表现确实可圈可点。

接下来，我们看看“能不用AI就不用AI”的路径：

路径二：最小化使用AI（AI Min）

所谓最小化使用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？