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

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

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

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

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

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

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

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

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

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

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

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

唯一识别

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

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

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

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

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

去重策略

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

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

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

集团客户的层级识别能力

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

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

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

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

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

客户归属 = 系统自动分配

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

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

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

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

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

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

近期，我与律师行业就人工智能的应用进行了一次深入的交流。

这次交流让我发现一个有趣的现象。以医师、教师、律师、工程师和分析师为代表的传统中产专业人士，对于AI技术的接纳度和学习能力普遍较高。他们不仅学习意愿强烈，而且已经能够将AI工具有效地应用于实际工作流程中。具体表现包括利用Coze等平台构建工作流自动化工具，更有甚者已经开始实践AI辅助编程，并取得了一定成果。

值得特别关注的是AI编程的应用。与我交流的这批律师本身并不具备代码基础，这恰恰从侧面印证了一个趋势：编程的技术门槛正在急剧降低。近期随着Gemini 3.0等模型的发布，业界关于“前端已死”的讨论也反映了这一变化。

因此，我们可以得出一个初步结论：AI编程至关重要，它正在对程序员行业产生深远影响。然而，断言AI将完全取代程序员则为时过早。更准确地说，AI编码（AI Coding）的发展预示着我们将进入一个自然语言编程的新时代。

基于我近两年的实践经验，在参与多个公司复杂AI项目时观察到一个普遍模式：核心功能代码可能仅有一万行左右，但用于驱动AI的提示词（Prompt）却可能多达数十万行。

这提示我们，编写提示词本身就是一种自然语言编程。因此，AI不会消灭程序员这个职业，但它会深刻改变职业内涵。被替代的将是那些仅仅停留在“工具使用”层面、机械编写代码的工作，或许可以称之为“代码搬运工”。

对于每一位程序员而言，关键在于清晰地认识到：软件开发范式正在发生根本性转移。未来，程序员可能需要与产品经理、医生、律师等“非专业”开发人员共同竞争提示词编写的工作量。你准备好了吗？

鉴于AI编程如此重要，本文将简要梳理其核心脉络，帮助读者快速建立认知。

实践是最好的老师

AI行业发展日新月异，如果仅仅以学习具体工具或技巧为目标，很容易陷入“学完即过时”的困境。因此，若想有效学习AI编程，需要注意两个要点：

1. 以解决实际问题为导向。最好的学习方式是“以战练兵”，带着明确的目标和项目去学习，效率最高。
2. 夯实基础知识。“以战养战”虽然高效，但也可能因缺乏系统认知而导致基础不牢。因此，在具备初步实践后，仍需进行系统性学习，构建扎实的AI技术理论基础，其重要性远超对单一工具的精通。

对于零基础的初学者，掌握AI编程通常需要跨越以下三个基础阶段：

1. 提示词工程：学会如何与AI有效沟通。
2. 理解工作流：把握AI融入开发流程的整体框架。
3. 案例实践：通过具体项目将知识融会贯通。

首先，需要掌握提示词工程的基本原理与方法。其次，要理解如何将AI工具整合到完整的开发工作流中。最后，便是今天重点探讨的案例实践环节。我们将先阐述方法论，再进行实操演示。

AI编程方法论详解

本次案例实践将假设你是一名毫无技术背景的产品经理，因此部分描述会尽可能详尽，已有技术背景的读者可选择性略过。

一个完整的AI辅助开发流程通常包括：需求拆解、架构设计、提示工程、代码生成、多轮迭代、前后端集成以及部署测试等步骤。

AI编程的核心思路在于：让AI参与到开发的每一个阶段，充当你的智能助手或“结对编程”伙伴。本质上，你扮演产品经理的角色，负责定义和设计；AI则扮演程序员的角色，负责实现具体的“代码搬运”工作。

在实际操作中，不同阶段需要注意的要点各有不同。

一、需求拆解

对于任何开发工作，明确的需求都是前提，与AI协作也不例外。无论AI多么智能，它都需要清晰、具体的指令才能发挥作用。

因此，第一步是将模糊的业务需求梳理成清晰的功能模块和技术组件。假设我们需要开发一个简单的用户反馈收集工具，允许用户提交反馈，管理员可以查看和导出。这个需求可以拆解为：

1. 一个包含反馈表单的前端页面。
2. 一个接收提交的后端API接口，用于将反馈数据保存至数据库。
3. 一个管理后台页面（或至少具备导出功能）用于查看反馈列表。
4. ……

一种低效的做法是直接告诉AI：“帮我做个收集反馈的工具。” 当然，如果你对互联网项目的技术构成确实不了解，这也没有关系，可以直接启用AI进行协助。常见的提问方式包括：

1. “要实现XX功能，需要哪些技术组件？”
2. “我要开发一个用户反馈收集网页，应该选用什么前后端技术栈？”

模型通常会给出包含技术选型在内的详细建议。在这一阶段向AI提问时，应尽可能提供充足的上下文和限制条件，例如用户规模、数据类型等。例如，可以使用如下提示词：

我需要一个Web应用来收集用户反馈。  
每天约有100条反馈，需存储文本和用户联系方式。  
我希望有一个简单后台查看所有反馈。  
请问我应该选择怎样的前端、后端框架和数据库？需要哪些主要模块？ 

明确需求细节和非功能需求（如规模）后，AI将能够给出更具定制化的技术方案建议。

二、架构设计

明确需求后，下一步是进行架构设计。这包括确定应用需要哪些页面、后端服务、数据存储方案，以及它们之间的交互方式。在AI的辅助下，这部分工作的复杂度已大大降低。

一、拆解前后端任务

你可以这样描述：

我们需要一个前端页面让用户填写反馈；  
一个后端接口接收提交；  
可能还有一个前端页面供管理员查看反馈或一个接口导出数据。  
将每个模块的职责简要描述出来，然后可以请AI检查是否全面。

在这个过程中，AI可能会提醒你增加诸如表单验证、错误提示等细节模块。这种与AI讨论架构的过程，类似于和经验丰富的工程师进行方案评审。

二、生成项目结构

任务拆解完成后，可以要求AI（例如使用Cursor等工具）生成一个简单的代码组织结构，例如：

前端：index.html, feedback.js...；  
后端：app.py 或 server.js...；  
数据库：schema.sql 或使用SQLite文件...

这些输出可以作为后续实施的具体指引。需要注意的是，AI建议的项目结构通常是通用型的，你应当结合实际需求进行调整（例如，是否需要将前后端完全分离）。但总体而言，在规划阶段AI就能提供一个相当可行的项目骨架。

对于有一定技术背景的产品经理，还可以让AI给出更详细的设计，例如数据库实体关系图、API接口设计规范等：

请设计反馈接口的API，包括请求方法、URL、请求参数和返回格式  

这样的提示会让AI产出类似Swagger风格的描述。例如：

POST /api/feedback - Body: {user, contact, message}  
Response: 201 Created or error code

这些细节设计输出能够显著加快后续的实现速度，并减少反复修改的次数。

这场争论在群里迅速升温，众多参与者加入讨论，但最终未能达成共识。然而，从许多产品与研发领域资深人士的反馈来看，恰恰验证了我之前的一个观察：Agent模式更容易获得资本市场青睐并拿到融资，而Workflow则在解决实际工作问题中发挥着稳定作用。

若要真正厘清两者关系，我们需要深入本质。一个最基础的问题是：Agent与Workflow的根本区别究竟何在？

Agent vs Workflow

Anthropic的观点相当清晰：Workflow是预设的、固定不变的执行流程；而Agent则具备自主决策能力，其行为路径是动态调整的。市面上已有不少对比分析，如下表所示：

可以注意到，此类对比往往极力强调Agent的诸多优势，同时凸显Workflow的种种局限，但对于企业级应用至关重要的稳定性、成本控制以及系统可观测性却避而不谈。

要透彻理解两者的适用场景，最好从任务类型的角度来审视技术路径的选择，如下图所示：

Workflow 特别适用于任务目标严肃、需求明确的场景。例如，基于患者描述生成诊断建议的医疗问答系统，或是自动生成结构化报告。即使在复杂情境下，它也能支持多轮交互与反复优化，其核心逻辑在于依据一套清晰的输入规则，产出一套确定的输出结果。

判断是否应采用Workflow的关键依据在于：你的任务是否需要通过多轮对话逐步收敛，以得到一个确定的答案（或清晰的数据关系），并基于此答案衍生出更多分支结论。

这一点理解起来略有复杂度，建议读者结合自身遇到的复杂生产级应用场景反复体会这段话，相信会有所启发。

而 Agent 则更适合处理目标发散、答案不唯一的开放性任务，尤其擅长协同完成某些创造性工作，例如多人协同编程。

判断是否应采用Agent架构的依据是：用户的意图是否已被充分收敛，即任务本身是否具备明确的边界和终点。如果任务追求的是稳定、可控的输出，那么它本质上是收敛的；反之，若任务本身开放、探索性强，则更适合采用Agent架构。

不过，若以发展的眼光看，理论上任何类型的任务都可以尝试用Agent架构实现。但现实情况往往更为复杂。衡量一个Agent产品是否优秀，至少需要考察以下三个核心指标：

1. 任务完成成功率；
2. 执行成本是否可控；
3. 响应与处理速度是否够快；

从这三大指标来评估，现阶段是否存在成功的Agent应用案例呢？答案是肯定的，其典型代表就是AI编程工具（如Cursor、Claude Code）。

那么，AI编程是否就应该被归为Agent的范畴呢？

AI编程是Agent吗？

答案可能有些反直觉：以Cursor/Claude Code为代表的AI编程工具，严格来说并非纯粹的Agent！

它们是当前最成功、但也最**具有“迷惑性”**的所谓Agent应用。或者说，如果严格遵循ReAct框架的定义，AI编程可算作Agent；但若依据Anthropic对Agent的界定，则不尽然。

AI编程之所以成功，恰恰因为它处理的是一类边界相对清晰、可被 “半收敛” 的特殊任务。这种特性并不能简单推广到所有通用场景。什么是 “半收敛” 特性呢？主要体现在以下三个方面：

一、目标相对可收敛：

用户的需求，无论是“实现一个登录功能”还是“修复这个Bug”，虽然最初以自然语言描述，但最终总能收敛为一段语法正确、功能完备的代码。代码能否通过编译并正确运行，提供了一个极其明确、非黑即白的验证标准。

二、环境高度结构化：

代码所运行的上下文环境，包括集成开发环境（IDE）、代码仓库、编译器及测试框架，构成了一个高度结构化、完全数字化的“微观世界”。Agent在这个世界中的可行操作（如读取文件、编写代码、运行测试）是可枚举的，且行动结果能获得清晰、即时的反馈，这大幅降低了其决策的复杂度。

三、反馈循环明确：

代码是否存在语法错误（导致编译失败）、逻辑缺陷（导致测试失败）或功能偏差（由用户指出），这些反馈都是即时、精准的。这使得Agent能够基于反馈进行高效的试错与学习。

因此，AI编程实际上是运行在一个目标可收敛、环境结构化、反馈即时的“沙盒”之中。其本质是在探索如何组合已知的代码模块与应用程序接口（API），以满足一个最终可以被明确验证的特定目标。

综上所述，AI编程更接近于一种增强型、智能化的Workflow。

从用户体验角度，它更像是一个融入了Agent交互风格的智能IDE，与追求完全自治的通用Agent仍有区别。

为了更清晰地阐明这一点，我们可以从控制权分配的角度进一步描述：

Cursor/Claude Code 的整体控制流、可用工具链、上下文构建方式都是由产品方预先设计好的。例如，“重构这段代码”、“根据需求生成新文件”、“在全项目范围内搜索相关代码”等操作，背后都遵循着一个固定的产品流程：

收集上下文信息 → 构建提示词（Prompt） → 调用大语言模型 → 校验结果或生成代码差异（Diff） → 展示结果供用户确认

因此，大模型只是在既定流程框架内进行局部决策，并未获得 “随心所欲定义和执行流程” 的最高权限。从这个视角看，它更接近一种智能化的预制工作流。

总结来说，传统软件开发流程是：设计 -> 编码 -> 调试 -> 测试 -> 重构；

而AI增强后的开发流程演变为：人类构思任务 -> AI辅助编码/生成代码 -> 人类评审与调试 -> AI辅助重构/解释代码 -> 人类集成与最终测试；

在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训练营的第一批学员（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？

在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需求可以归纳为以下四个主要类别：

一、工作流类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上传保单信息，核实具体险种。"  
  ]  
}

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