AI Native 不是消灭流程，而是让人不再操作流程

最近在设计一个企业 AI Workflow 项目时，我们讨论了一个问题：

如果未来员工只需要在飞书机器人里说一句话，就能完成需求整理、策略生成、候选对象评估、对客材料制作和反馈沉淀，那么现在还有必要开发业务前端吗？

这个问题表面上是在讨论前端和聊天机器人的选择，背后其实是一个更重要的问题：

什么是 AI Native？

很多人会把 AI Native 理解成给原来的软件增加一个聊天框，再让大模型调用几个接口。

过去需要点击“创建项目”，现在对机器人说“创建一个项目”；过去点击“生成报告”，现在输入“帮我生成一份报告”。界面从按钮变成了自然语言，看起来已经很 AI 了。

但仔细想想，用户仍然需要知道系统有哪些功能，应该先做什么、再做什么，以及每一步应该给 AI 什么指令。软件内部的结构没有发生变化，只是把鼠标操作换成了聊天命令。

这可能是 conversational UI，也可能是 AI-enabled software，但还不一定是真正的 AI Native。

真正的 AI Native，也许不是让人用对话操作软件，而是让软件开始理解人的工作。

每一代 Native，都在重新定义事情应该怎么完成

理解 AI Native，可以先回头看互联网和移动互联网时代发生过什么。

打车软件并不是把出租车公司的电话号码搬进 App。

如果只是这样，用户仍然需要找到附近的出租车公司、说明自己在哪里、反复确认司机什么时候到，再通过现金完成支付。它只是把电话簿从纸上搬到了手机里。

真正的打车软件重新设计了整件事：定位、供需匹配、司机调度、价格计算、路线追踪、支付和评价被组织成一个新的系统。用户只需要表达“我要从这里去那里”，大量原本需要人参与的协调过程就被隐藏到了软件背后。

淘宝也不是把商场的商品目录搬到网页上。

它重新设计了商品发现、搜索推荐、信用体系、支付担保、商家经营和物流协作。招聘软件也不只是把纸质简历电子化，而是改变了职位发布、人才搜索、双向匹配、沟通和筛选的方法。

因此，Native 从来不只是适配一种新的界面或终端。

每一代 Native 应用，都不是把旧系统换一个入口，而是利用新技术重新定义“这件事应该怎么完成”。

互联网让信息可以被连接，移动互联网让服务可以随时发生，AI 则开始让软件具备理解意图、处理非结构化信息、组织任务和使用工具的能力。

这才是讨论 AI Native 的起点。

从“人找功能”到“软件理解目标”

传统软件的基本假设是：用户知道自己要做什么，也知道应该如何操作系统。

因此，软件把能力组织成菜单、页面、按钮和表单。用户需要先理解软件的结构，再把自己的工作翻译成软件可以接受的操作。

理解任务
→ 找到对应功能
→ 进入正确页面
→ 按要求填写字段
→ 点击按钮
→ 查看结果
→ 判断下一步去哪里

在这个过程中，业务目标属于用户，软件只负责执行明确指令。

AI Native 改变的，首先是这个分工。

用户不再需要从一开始就把任务拆成一连串软件操作，而是可以先表达目标、提供已有材料和必要约束。系统负责理解上下文、发现信息缺口、组织可用能力，并推动任务向前发展。

用户表达目标
→ AI 理解上下文
→ 判断缺失信息
→ 调用业务能力
→ 在关键节点请求确认
→ 根据反馈继续推进
→ 完成任务并沉淀经验

过去是人理解软件，然后操作软件。

未来是软件理解人的工作，然后组织自己。

这不是一次简单的界面变化，而是软件基本交互模型的变化。

AI-enabled、聊天式软件和 AI Native

为了把这个区别说得更清楚，可以把企业软件使用 AI 的方式分成三个层次。

第一层是 AI-enabled。

传统系统增加几个 AI 功能：AI 整理需求、AI 生成文案、AI 总结会议、AI 推荐候选对象。它们可以提高某个节点的效率，但系统的主体仍然是原来的页面和流程。

第二层是 conversational UI。

系统增加一个聊天入口，用户可以通过自然语言调用已有功能。例如“创建项目”“生成报告”“查询进度”。这降低了寻找菜单和按钮的成本，但用户仍然负责拆任务、选择功能和推动流程。

第三层才是 AI Native。

用户表达的是目标，不是功能名称。系统需要理解目标属于哪个业务场景、当前处于什么状态、缺少什么信息、可以调用哪些能力、哪些动作需要确认，以及结果应该写回哪里。

例如，用户只说：

这是一个新项目的客户邮件和群聊记录，先帮我处理一下。

一个 AI Native 系统不应该只回复一段总结。它应该进一步判断：

• 这是新项目还是已有项目；
• 客户、产品、预算、市场和时间要求是否明确；
• 哪些内容来自客户原文，哪些只是推断；
• 是否需要向用户追问缺失信息；
• 能否调用相似项目和历史客户经验；
• 应该生成哪种结构的需求文档；
• 需要由谁确认；
• 确认以后应该触发什么工作；
• 人工修改和客户反馈如何被保存。

用户没有逐个调用功能，但系统仍然完成了任务拆解、信息组织和流程推进。

这才开始接近 AI Native。

流程没有消失，只是从界面进入了系统内部

AI Native 容易带来一个误解：既然用户只需要表达目标，是不是以后就不需要 Workflow 了？

恰恰相反。

用户不再操作流程，不等于系统不再需要流程。

客户需求仍然需要被确认，预算仍然不能凭空生成，对客材料仍然需要审核，重要决策仍然要有负责人，客户反馈仍然要留下记录。权限、责任、状态和风险不会因为出现一个聊天框而消失。

消失的是用户亲自推动每个细节的必要性。

过去，流程主要表现为页面和按钮：完成 A 页面，点击下一步，再进入 B 页面。

在 AI Native 系统里，流程更像隐藏在背后的状态、规则、工具和确认节点。AI 可以根据上下文选择如何收集信息和组织任务，但不能忽略企业必须遵守的业务约束。

可以把它理解为两个层次：

对用户：目标、对话、结果、必要的确认

对系统：状态、权限、工具、规则、日志、异常处理

AI Native 隐藏的是操作复杂度，不是业务责任。

但长期来看，AI 也会反过来改变流程

“流程没有改变”适合描述 AI Native 的第一阶段，但它不一定是最终状态。

很多传统流程步骤之所以存在，并不是因为业务本身需要，而是因为过去的人和软件能力有限。

例如：

• 人工把聊天记录整理成表格；
• 在不同系统之间复制同一份信息；
• 逐个检查字段是否缺失；
• 手动通知下一个负责人；
• 把客户反馈重新归类；
• 项目结束以后再凭记忆做复盘。

这些看起来像业务流程，实际上只是信息处理和组织协调的成本。

AI 可以理解非结构化材料、保持上下文、调用工具并主动发现异常以后，其中一些步骤就不再需要作为独立的人工作业存在。

因此，AI Native 的演进通常会经历两个阶段：

1. 先让 AI 在现有流程中承担部分信息处理工作；
2. 再根据新的能力和成本，重新设计整条工作方式。

这和打车软件、淘宝真正带来的变化一样：开始可能只是把原来的事情搬到线上，最终却形成了过去不存在的新协作方式。

AI Native 不等于只有一个聊天框

如果 AI Native 以自然语言为入口，未来的软件是否只需要一个对话框？

我认为不是。

聊天非常适合表达模糊目标、补充上下文、追问缺失信息、查看进度和完成简单确认。但它并不适合所有操作。

一次比较几十个候选对象、批量修改价格、查看版本差异、调整复杂内容和分析项目整体状态，通过连续对话完成，未必比表格或专用页面更高效。

真正 AI Native 的界面不应该只有聊天，而应该根据任务动态选择最合适的交互方式。

对话：表达目标、补充信息、推进任务
卡片：查看摘要、完成简单确认
表格：批量录入、比较和修改
专用页面：复杂编辑、版本对比和异常处理

用户可以从飞书机器人开始工作。机器人理解任务后，如果只是确认一份 Brief，可以直接展示卡片；如果需要比较大量候选对象，则提供一个临时工作台；完成以后，再回到对话继续推进。

所以，AI Native 不是取消界面，而是让界面不再成为系统的固定入口。界面应该在需要时出现，完成任务后退到背景中。

没有真实 Workflow，就没有 AI Native

这也解释了一个看似矛盾的问题：既然未来希望用户不再操作流程，为什么现在还要花时间还原流程、设计字段和建设前端？

因为 AI 想隐藏流程，必须先理解流程。

一个可靠的 AI Native 系统至少需要知道：

• 有哪些业务对象和状态；
• 每项任务需要什么输入；
• 哪些信息已经确认，哪些只是 AI 推断；
• 谁拥有查看、修改和确认权限；
• 哪些能力可以被调用；
• 哪些动作可逆，哪些动作风险较高；
• 失败以后如何恢复；
• 结果应该保存在哪里；
• 什么信息能够进入长期记忆。

如果这些问题没有答案，聊天机器人隐藏的不是复杂度，而是混乱。

它可能可以生成一段看起来不错的内容，却不知道内容属于哪个项目、是否经过确认、应该交给谁、能否进入下一步，也不知道生成错误以后如何撤回。

因此，真实 Workflow 不是 AI Native 的对立面，而是它的基础设施。

前端也不一定是最终产品形态。它可以是 AI Native 系统建设初期的“显性训练场”：帮助团队确认真实流程、业务对象、状态、人工确认和异常情况，同时收集 AI 原始输出、人工修改和客户反馈。

这些能力被验证以后，才可以逐步从固定页面中抽离，变成 AI 能够安全调用的业务工具。

从 Workflow 走向 AI Native

企业系统从当前形态走向 AI Native，可以分为四个阶段。

第一阶段：把真实工作显性化

还原业务流程，确认角色、输入、输出、状态、审核和异常。通过前端或低代码工具跑通一个真实项目。

此时最重要的不是“AI 有多聪明”，而是系统是否理解了真实工作。

第二阶段：把业务能力工具化

把创建项目、整理需求、保存草稿、提交审核、评估候选对象、生成对客内容和记录反馈等能力，设计成边界清楚、权限明确、可以独立调用的工具。

当前由前端调用这些工具，未来也可以由 AI 调用同一套工具。

第三阶段：让 AI 组织工具和流程

AI 开始根据用户意图和当前上下文选择工具、补充参数、追问信息，并在关键节点暂停等待人工确认。

用户不再需要知道每个功能在哪里，但系统仍然保留明确状态和责任边界。

第四阶段：重新设计工作方式

当 AI 的真实使用数据足够多以后，企业可以重新判断哪些步骤仍然必要，哪些只是过去的信息处理成本，哪些可以并行完成，哪些可以从被动操作变成主动建议。

这时，AI Native 才真正开始改变组织的工作方式。

AI Native 的核心不是自主，而是新的协作关系

很多关于 AI Native 的讨论会强调 Agent、自主规划和工具调用。但对企业来说，自主程度并不是唯一目标，甚至不应该是第一目标。

真正重要的是重新设计人、AI 和系统之间的分工：

• 人负责表达目标、提供判断和承担责任；
• AI 负责理解信息、组织任务和处理不确定性；
• 业务系统负责状态、规则、权限和数据一致性；
• 界面负责在必要时呈现信息和承接操作；
• 可观测和审核机制负责让整个过程能够被理解和追溯。

如果 AI 只是生成内容，人仍然要完成所有组织和协调，它只是一个更强的输入法。

如果 AI 可以直接操作一切，却没有权限、确认和追溯，它又会变成一个不可控的黑箱。

AI Native 真正需要建立的是一种新的协作关系：让 AI 承担越来越多的理解和组织工作，同时让人的判断出现在真正重要的位置。

写在最后

App 时代，人们学习页面、菜单和按钮，通过操作软件完成工作。

AI Native 时代，人们开始直接表达目标，由软件理解上下文、组织能力，并在必要时请求人的判断。

业务流程不会凭空消失。它会从用户每天需要操作的页面，进入系统内部，变成状态、规则、工具、记忆和确认节点。

开始的时候，我们只是用 AI 改变流程中的某些细节。

再往后，AI 会让我们重新思考：这件事情为什么要这样做？哪些步骤是真正的业务要求，哪些只是过去技术条件下不得不承担的成本？

所以，AI Native 不只是给旧软件增加一个新的入口，也不只是让 Agent 调用几个接口。

AI Native 不是消灭流程，而是让人不再操作流程。

当人只需要说明自己想完成什么，而软件开始理解工作、组织能力并承担过程，软件才真正进入了 AI Native 的时代。