我之前曾指出，对于AI智能体（Agent）而言，记忆系统或上下文工程往往会成为其发展中的难点与瓶颈，而技能（Skills）生态才是其真正核心所在。这一点从OpenClaw的调教过程中便能得到印证：

大家在训练和优化这类智能体时，几乎不会过度关注上下文管理，但一定会持续不断地打磨Skills。原因非常简单：记忆系统通常是一个黑盒，难以直接干预；而Skills则是具体工作流程（Workflow）的迁移与封装。

因此，我们有必要再次深入探讨Skills，重新认识其价值。不过，这一次我们将引入更**“权威”**的视角：参考由Claude Code团队工程师Thariq撰写的一篇长文：

Lessons from Building Claude Code:  
How We Use Skills 

Skills系统概述

首先，现代语境下的Skills含义非常丰富。它不再是一个简单的提示词文件，而是一个完整的能力包。这个能力包具备可维护、可复用、可度量的特性。

作者强调，一个Skill本质上是一个文件夹，它可以包含脚本、资产文件、参考文档、配置文件、数据以及各种钩子（Hook）。

它通过渐进式披露的策略，在不导致上下文信息爆炸的前提下，将流程沉淀为可被触发的工作流。需要注意的是，这里所说的流程既可以是个人工作习惯，也可以是组织或团队的协作流程。

Thariq这篇文章的核心价值并非其中提供的几段指令模板，而是他提出的一个系统性建议。这个建议的实践结果，催生了一套可规模化的Skills管理系统：

1. ***技能分类法（共9类）：***帮助你像管理产品功能矩阵一样管理技能组合；
2. ***设计原则：***避免写入常识性内容、将易失败点明确标注为“Gotchas”、利用文件系统实现渐进式披露、防止过度“牵引”模型行为、确保初始设置（setup）可恢复、从“提示工程”转向“上下文工程”；
3. ***分发与治理机制：***从项目仓库内的 .claude/skills 目录，到插件化与市场（Marketplace）；从“自发试用”过渡到“被动发现+准入门槛”，以解决规模化后带来的技能冗余、冲突与上下文成本上升问题；
4. ***度量闭环：***利用 PreToolUse 钩子记录Skill调用情况，识别热门技能、低触发技能及过度触发技能，从而将主观的“感觉很好用”转化为可量化、可迭代的增长系统。

原文链接如下：

https://x.com/trq212/article/2033949937936085378

我明白这些概括性的要点可能不易理解，它们相当于整篇文章的摘要。我们后续会逐一详细解释，因此不必担心。

这里需要补充两点：尽管Skills概念最初由Claude团队明确提出，但现在几乎所有主流的基础模型都对其提供了支持。这清晰地预示着一个趋势：

Skills正在成为AI Agent的通用中间层，它介于模型的基础能力与**具体工具（Tools）**之间，专门用于承载和封装各类流程与工作流。

简而言之，Skill就是为Agent准备的标准化作业程序（SOP）包。其内容核心，很多时候也确实就是SOP本身。

接下来，我们将进一步拆解，详细说明Skill包的组成部分及其运行机制。

Skills技术架构拆解

Skills包（或文件夹）是一种可执行的配置与资产封装格式，其典型结构如下所示：

<skill-name>/  
├── SKILL.md  
├── references/  
├── assets/  
├── scripts/  
└── 其他配置/数据文件

这意味着，一个Skill是一个目录级的能力单元：

• SKILL.md：作为整个能力包的入口文件与主要说明文档。
• references/：用于存放长文档、参考资料、规则解释等背景知识。
• assets/：用于存放模板文件、样例、静态资源等。
• scripts/：用于存放可执行的脚本文件。
• 必要时还可以包含 hooks、config、data 等目录或文件，用于承载约束条件、配置项与持久化状态。

这里需要再次强调：Skill的本质不是提示词的简单增强，而是工作流的系统性封装。

首先，我们来解析最外层的SKILL.md文件。

一、SKILL.md：总入口与调度中心

许多人会本能地认为SKILL.md就是写给模型阅读的正文内容，因此试图将所有说明、注意事项和流程步骤一次性全部塞入其中。

这是一种常见的误解。

SKILL.md真正扮演的角色，是这个能力包的索引页、路由页与使用说明页的综合体。它至少承担着以下四个核心职责：

1. 向模型说明这个Skill是做什么的。
2. 向模型阐明在什么情况下应该触发这个Skill。
3. 引导模型在触发后，应该先读取什么内容，后读取什么内容。
4. 规定模型输出的结果大致应该是什么样的格式或结构。

因此，SKILL.md实际上是一个调度入口：

一个Skill包就像一个项目文件夹，而SKILL.md则是这个文件夹的README文件、运行手册（runbook）和路由契约（routing contract）的结合体。

由于SKILL.md的核心作用是说明**“具体如何操作”**，其撰写原则也就清晰了：

1. 主流程必须清晰明了。
2. 触发条件和边界必须明确。
3. 关键易错点需要突出强调。
4. 引导模型按需读取references、assets等其他目录的内容。

二、description字段：触发协议

许多Skill失效，问题不在于内容本身，而在于description字段的编写。大多数人在撰写description时，产出的内容更像产品功能简介：

本文的思考源于我个人近半年在Agent领域的生产实践，以及与众多团队在过去一年间关于Agent的深入交流。这些讨论也源于我对诸如Manus这类项目所抱持的一些疑问。

当前，业界对于Agent的看法呈现出两种截然对立的观点：一方坚信Agent就是未来，将取代其他过时技术；另一方则断言Agent（如Manus）毫无用处，无法解决实际问题。

以下是两派观点的真实摘录：

Agent支持派 AI技术的发展日新月异，上半年的经验到了下半年可能就已经失效。 去年Dify、n8n等工具备受推崇，但随着今年Agent模型的流行，新启动的项目普遍采用具备自主规划能力的Agent方案，已经很少有人再去考虑Dify、n8n这类被认为是过时的思路了。 事实就是，新型Agent相较于旧式工作流，在效果上有着巨大提升。 它缺乏专业数据、没有专属的工具链、没有行业认证、未能与业务深度集成，也没有绑定高价值的业务场景。换言之，任何人都可以模仿构建。因此，它更像是工程能力的延伸，而非在构建具有壁垒的场景护城河。 用户会发现，当他们面临真正复杂的挑战时，这种通用Agent仍然无能为力，最终不得不转向专业的垂直解决方案或人工服务，这导致了用户留存率的持续低迷。 ……

总结来说，现状可以概括为一句话：有人认为Agent已近乎无所不能，代表着当前最先进的生产力；也有人认为Agent毫无价值，缺乏技术壁垒，耗费资源且无法解决实际问题。

如何理解这两种极端观点呢？过于悲观和过于乐观的认知都存在偏差，其直接后果是导致企业决策混乱——要么盲目投入，要么完全放弃投入。

在过去三年中，我全身心投入AI相关工作，先后接触了超过40家公司，主导或参与了25个AI项目（投入规模从过亿元到不足十万元不等）。基于在Agent领域的实践与思考，我希望能系统性地探讨以下核心问题：

Agent技术究竟先进在何处？它是否真的具备解决实际问题的能力？

Agent为何在2025年迎来元年

首先，必须明确Agent的核心在于调用外部工具。严格来说，Function Calling是Agent架构得以成立的基石，正是因为有了这项能力，模型才得以正式、规范地使用各类Tools。

虽然在OpenAI官方提出Function Calling概念之前，开发者也能通过训练特定模型或引导模型输出特定格式来模拟工具调用，但这终究不是通用、标准化的方法，因为更换模型后其效果往往难以保证。

当前最经典的Agent框架是ReAct（Reasoning and Acting），其思想大约在2022年提出，相关论文《ReAct: Synergizing Reasoning and Acting in Language Models》中就已包含了伪Function Calling的实现。直到2023年6月，OpenAI的一次更新正式推出了Function Calling，将其作为ChatGPT产品的核心能力之一。此后，这项能力逐渐成为行业事实标准，各大基座模型纷纷跟进实现。有了这个稳固的基础，Agent的构建与普及才真正变得顺理成章。

国内“Agent”概念的火爆始于年初的Manus。但如果追溯更早且具有广泛影响力的开源Agent项目，2023年3月发布的Auto-GPT是一个标志。然而，即便是今年初的Manus，也因早期基座模型能力不足而表现欠佳，更不用说更早期的Auto-GPT了。

自Manus发布后，行业焦点逐渐从“2025 AI应用元年”转向“2025 AI Agent元年”。与此同时，模型本身也取得了长足进步，包括整体推理能力和上下文长度都得到了极大增强。我个人相信，各主流基座模型一定在工具调用相关数据上进行了大量微调训练，其直接体现便是2025年下半年，模型的工具调用能力出现了显著提升。

尽管模型在工具调用的稳定性上已有不小改进，但当可用工具数量增多时，仍会出现“找不到合适工具”或“胡乱调用”的问题。为此，Claude团队总结了大量工具调优经验，于2025年10月正式提出了“Skills”技术。可以将其视为对Function Calling机制的重要补充（当然，Skills的目标远不止于提升工具识别能力）。

现阶段，通过结合使用Skills、Function Calling以及精心的上下文工程，已经能够将工具调用的准确率提升到相当不错的水平（例如，我们实践中的某些场景可以达到90%以上，这在之前是难以想象的）。

以上是我从技术演进视角观察到的近三年Agent发展脉络。简而言之：在2025年之前，想要构建一个真正好用的Agent几乎是不可能的任务；而从2025年下半年开始，这一难度已大幅降低。

因此，最终的结论是：此前对于Agent的诸多质疑以及糟糕的产品体验，预计在2026年将得到极大程度的缓解。从这个角度看，Agent的发展直接依赖于模型底层能力的跃迁，任何工程优化可能都比不上模型自身一次关键的能力升级。

接下来，我们将剖析其核心的编排层，这有助于解释Agent为何会变得越来越强大。

核心框架剖析：思考-行动-观察的循环机制

许多开发者知道Agent的工作模式在模仿人类，但未必熟悉“ReAct”这一术语，也未必能深刻理解**“思考-行动-观察”** 这一循环究竟有何价值。

毕竟，多一轮交互就意味着更慢的响应速度和更高的资源消耗（Token成本）。那么，为什么需要设计这样的多轮循环呢？我认为这主要是为了弥补模型自身规划能力的不足。通过多轮的自我调优与验证，模型才能最终生成一个相对合理的行动计划。

这就像一个需要引导的学生。一个生动的案例可以说明这种循环“调教”对于模型做出合理规划的重要意义：

“六顶思考帽”是一种经典的“平行思维”框架，旨在将混乱的思考过程结构化。其核心是为思考者赋予六种不同的角色（“帽子”）：

1. 白帽：客观中立，只关注事实与数据。
2. 红帽：感性直觉，表达情绪与直觉预感。
3. 黑帽：谨慎批判，专注于风险与潜在缺陷。
4. 黄帽：积极乐观，着眼于价值与机遇。
5. 绿帽：创新创造，探索新想法与可能性。
6. 蓝帽：统筹控制，管理整个思考流程并负责总结。

这一框架的威力在于强制切换视角，避免人们陷入单一的思维立场（例如一味批判或盲目乐观），从而实现对问题的全方位审视。以 “是否在公司启动一个Agent项目” 为例，运行一轮六顶思考帽，就相当于引导模型完成了一套ReAct循环：

1. 白帽：我掌握哪些客观事实？公司现有基础如何？预算多少？有哪些现成的数据和系统可用？
2. 黑帽：最坏的情况是什么？可能遇到哪些“坑”？哪些部门可能会强烈反对？
3. 黄帽：如果项目成功，最大的收益是什么？对业务和团队能力会产生何种放大效应？
4. 绿帽：在现有资源约束下，是否存在性价比更高的替代路线？例如，是否可以从改造一个小型流程开始，而非一上来就搭建全栈Agent平台？
5. 蓝帽：将前述所有视角收束整合，形成一个可执行的行动计划：先做什么、如何分阶段、如何验证效果、失败后如何止损——最终由蓝帽角色收尾并输出结论。

这一整套流程跑下来，模型在持续地对自身的初步想法进行追问、纠偏和补充，实现了典型的“自我对话”。这带来了三个关键好处： 第一，强制补全思考的视角盲区；第二，将“想清楚”这件事，从一次性的直觉判断，转变为逐步逼近最优解的迭代过程；最终，让决策规划从不可捉摸的“黑盒”，变为可复盘、可分析的清晰过程。

“六顶思考帽”这种模式，实质上为模型设计了一套自我对话与训练的框架。从Agent的视角看，这是对 “思考-行动-观察” 这一ReAct循环进行了更精细的角色化实现。其结果印证了一个观点：模型的规划能力并非凭空产生，而是在一次次结构化的自问自答中逐渐“生长”出来的。

随着模型底层能力的持续增强，其生成的解决方案自然会更加完善。因此，从框架设计层面看，Agent架构确实具备越来越强的潜力，尽管目前较高的Token消耗成本暂时无法完全避免。

市场在今年初见到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技术的接纳度和学习能力普遍较高。他们不仅学习意愿强烈，而且已经能够将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发送节点的流程结构。