别再把 AI 产品都叫“AI 应用”：一套理解未来 AI 产品的分类方法

从产品名称走向产品画像：看清它服务谁、承担什么工作，以及如何交付价值。

为什么越分类，越混乱？

假设你准备做一款企业客服产品，打开竞品清单：ChatGPT、Dify、某款客服 Copilot、某个客服 Agent，都被放在“AI 应用”下面。你很快会卡住：究竟该比较回答质量、流程编排，还是工单解决率？

问题出在清单把不同角色的东西放在了一起。有的交付模型能力，有的帮助开发者搭建产品，有的直接处理用户任务。再把“RAG”“Copilot”“行业 AI”塞进同一列，技术机制、协作方式和应用场景就彻底混在了一起。

按写作、编程、生图分类，适合寻找工具；但要判断竞争关系、规划产品，信息还不够。“都能写代码”，并不能说明两款产品承接了同样的工作。

一套有用的分类方法，应当让我们看清产品之间的差异，也能解释同一个产品内部的不同能力。

下面这套四维框架，是本文提出的实用分析方法。它不追求给每个品牌分配唯一身份，而是为具体产品、具体场景建立一张可以更新的画像。

图 1：四个维度分别回答不同的问题，组合使用才能形成产品画像。文中配图可点击查看原图。

一、产业角色：它提供什么，服务谁？

先看产品交付的是什么，再看它用了什么技术。可以粗分为四类：

• 基础设施：提供算力、存储和运行环境，支持训练、推理与系统运行。
• 模型服务：提供可调用的智能能力，使用者将其接入自己的产品。
• 开发平台与框架：帮助构建、编排和维护 AI 系统；平台与代码框架的交付形态仍有区别。
• 终端应用：直接服务使用者，交付答案、内容或任务结果。

例如，Dify 提供应用构建能力，支持组合模型、知识库和工作流；用它搭建的客服助手则属于终端应用。前者的客户关心能否接入系统、维护流程，后者的用户关心能否解决客服问题。产业角色不同，产品的卖点和验收标准也会变化。

“医疗 AI”“金融 AI”描述的是应用场景，不必再放到应用之上，作为更高级的一层。一个医疗产品也可能是模型服务、开发平台或终端应用。

这里还要区分公司与产品：同一家公司可以同时经营多个层次的业务。分类时应落到具体服务，不能让公司的一个标签覆盖全部产品。

二、人机分工：人把哪些工作交给 AI？

同样是客服场景，AI 可以只是解释退货政策，也可以帮坐席修改回复，或在授权范围内查询订单、处理任务。界面都可能是对话框，工作边界却不同。

可以用三种常见方式描述：生成答复、交互协作、授权执行。生成答复时，用户拿走文字、图像或代码等产物继续工作；交互协作时，人持续选择、修改和确认；授权执行时，人交付目标与边界，系统承担一段执行过程。

Copilot 常用于描述以人为主导的协作方式，但产品名称中的“Copilot”并不能代替能力分析。Cursor 的 Agent 已能编辑代码、运行命令，所以将整个 Cursor 固定归为“只提建议的工具”会失真。Cursor 官方说明

也不要把三种方式理解成产品价值排行榜。关键是写清：谁决定下一步，哪些动作需要确认，失败后谁接手。 一个保留人工确认的执行系统，仍然可以使用 Agent 机制；持续运行很久，也不等于获得了无限权限。

三、实现机制：信息从哪来，任务如何执行？

这一维要拆成两个问题，才能避免把所有技术名词排成一条升级路线。

先看信息和能力来源。模型生成负责理解输入、组织输出；**RAG（检索增强生成）**先找出相关资料，再把资料交给模型作为回答依据；工具调用让系统能查询订单、运行程序或执行其他外部操作。检索可以提供依据，但答案是否可靠，仍取决于资料、检索结果和生成过程。

再看任务由谁组织。按照 Anthropic 的区分，Workflow（工作流） 主要通过预先设计的路径组织模型与工具；Agent（智能体） 则由模型根据目标和执行反馈，动态决定步骤与工具使用。Anthropic 官方说明

这意味着，RAG 可以出现在 Workflow 里，也可以被 Agent 调用。工作流可以包含 Agent 节点，Agent 也可以调用封装好的工作流。一次工具调用并不足以证明系统拥有动态规划能力。

RAG 回答“依据从哪里来”，Workflow 与 Agent 回答“过程如何组织”，Copilot 则更多描述人与系统怎样合作。 它们可以组合，但不适合直接当作互斥的产品类别。

图 2：执行路径的组织方式，与知识来源、工具能力和人工确认，是不同的设计问题。

四、融入方式：AI 与原有软件是什么关系？

从软件关系看，可以再加三个标签：

• AI 原生：核心体验与价值围绕 AI 能力组织。拿掉 AI，主要用途难以成立，例如以生成图像为核心的产品。
• 功能增强：既有软件的核心业务仍成立，AI 改善其中的操作，例如在客服工作台中增加回复草稿功能。
• 能力开放：软件把数据或操作接口提供给外部 AI，使其能够被访问和使用。

MCP 是连接 AI 应用与外部系统的开放标准，可以连接数据源和工具。因此，“ERP 接入 MCP”首先说明它开放了连接能力，不能单凭这一点判断整个 ERP 已完成怎样的 AI 改造。MCP 官方介绍

这三个标签也可以共存：客服系统既能内置 AI 回复，又能开放接口供外部 Agent 使用。对于“AI 原生”的判断，应说明观察的是哪项核心能力，而不只是看产品上线得早还是晚。

图 3：观察 AI 改变了哪部分软件能力，三种方式可以在同一产品中共存。

把熟悉的产品放回合适的位置

下表只分析列出的具体能力，不代表产品的全部边界，也不推测未公开的内部架构。产品事实按 2026 年 9 月 10 日公开资料核验，分类是本文的分析判断。

| 观察对象 | 产业角色 | 人机分工与机制 | 融入方式 | |---|---|---|---| | GPT API 模型服务 | 模型服务 | 提供模型能力；应用如何分工由调用方设计 | 以模型能力为核心 | | Dify 平台本身 | 开发平台 | 提供构建与编排能力；分工取决于所建应用 | AI 原生构建平台 | | ChatGPT：对话答疑 | 终端应用 | 在此场景生成答复；不能据此概括全部能力 | AI 原生体验 | | Cursor：Agent 编程 | 终端应用 | 授权执行；Agent 调用编辑与命令工具，权限可配置 | AI 原生开发体验 | | Codex：编程任务委托 | 终端应用 | 授权执行；以编程 Agent 承接任务，由人检查交付 | AI 原生体验 | | Midjourney：提示词生图 | 终端应用 | 生成图像，由用户选择并继续迭代 | AI 原生体验 | | ERP＋MCP：接口开放 | 企业应用及连接能力 | ERP 提供数据或操作；外部 AI 如何执行另行分析 | 能力开放，可叠加增强 |

读这张表时，最值得比较的是：两款产品是否面向同一用户、承接同一段工作。一个平台与一个应用可能存在合作关系；两个都叫“助手”的产品，也可能在争夺完全不同的使用场景。

用一次客服任务，把四个维度串起来

来看一个教学示例：顾客说“这笔订单想退货，应该怎么处理？”团队提出要做一个“客服 Agent”，但这个名字还不足以形成产品方案。

如果主要问题是坐席找政策太慢，可以先做知识辅助：检索退货政策，生成带出处的回复草稿，由坐席检查后发送。画像是：客服终端应用＋交互协作＋RAG＋功能增强。验收重点在政策匹配、引用依据和坐席是否愿意采用。

如果需要连同订单一起判断，就要增加查询工具。假设业务处理路径清晰，可以用工作流串起“查政策—查订单—生成处理建议—坐席确认—调用业务接口”。此时验收重点增加了参数正确性、权限校验和执行结果，而不是只看回复是否流畅。

如果问题差异很大，需要根据反馈决定补问什么、查哪些记录，再考虑让 Agent 动态组织过程。政策检索与订单工具仍可复用，退款等操作依然按业务规则设置确认。系统遇到信息不足、工具失败或权限不够时，应明确交还人工处理。

这三种方案对应不同的问题。只有当更复杂的机制能改善任务结果，额外的成本和不确定性才值得承担。

分类之后，应该做出什么决定？

你可以用一句话描述自己的产品：

面向【用户与场景】，我们提供【产业角色】，以【人机分工】完成【任务】，通过【信息来源与执行机制】交付结果，并以【融入方式】进入用户现有的软件环境。

随后检查四件事：竞争对象是否服务同一用户与任务；所需信息来自哪里；执行路径适合预设还是动态组织；哪些节点必须由人确认和接管。

一张有效的产品画像，应能帮助团队回答这些问题。随着能力、权限与场景变化，画像也应更新。未来再遇到一个新产品，不妨先看清它接手了哪段工作、交付了什么结果，再决定给它贴什么标签。