从按钮世界到助理世界,重新理解 AI Native 产品

我最近一直在想一个问题：AI Native 到底是什么意思？

这个词现在被用得太多了。一个产品接了大模型 API，就说自己是 AI Native；一个原来的系统右下角加了聊天框，也说自己是 AI Native；一个按钮从”提交”改成”AI 生成”，也说自己是 AI Native。它们当然都用了 AI，也确实可能有价值，但我越来越觉得，这些都还不是 AI Native 最深的变化。

真正的变化不是软件里多了一个 AI 功能，而是软件的使用方式正在变。

过去的软件，本质上是一个”按钮世界”。人坐在屏幕前，学习软件的规则，找到正确的入口，点击正确的按钮，填写正确的表单，按照正确的顺序一步一步操作。软件很强，但它不会主动理解你真正想干什么。你必须把自己的目标翻译成它听得懂的动作。

而 AI Native 软件正在把我们带进另一个世界：一个”助理世界”。在这个世界里，人不再总是亲自点每一个按钮，而是先说清楚目标，然后由一个 AI 执行者去理解任务、拆解步骤、调用工具、操作系统、检查结果，必要时再回来问你确认。

这听起来像是多了一个聊天框，但其实不是。

聊天框只是表面。真正的变化是：软件的主驾驶，正在从人手里的鼠标，转移到一个能理解目标的 AI 执行者身上。

为了把这件事讲清楚，我想用一个贯穿全文的比方：汽车。

传统软件像一辆完全手动驾驶的车。方向盘、油门、刹车、档位、雨刷、灯光，全都由你亲自操作。车很强，但每一个动作都要人来控制。AI Native 软件更像一辆正在长出自动驾驶能力的车。你不是每秒都微调方向盘，而是说”带我去公司，避开拥堵，路上顺便买杯咖啡”。车要自己看路、规划路线、控制速度、判断红绿灯，还要知道什么时候必须让人接管。

这两种车的差别，不是仪表盘上多了一个按钮，而是驾驶关系变了。

软件也是一样。

过去人是驾驶员，软件是车辆。未来很多时候，人更像乘客加监督者，AI 变成中间那个驾驶系统。人负责说目的地、定边界、做关键判断；AI 负责操作车辆、读取路况、执行动作。

如果把这套类比再拆细一点，后面那些看起来很技术的词就会好理解很多：

这张表可以先放在脑子里。后面我们再讲 Agent、Harness、MCP、Skill，就不要把它们当成四个陌生的英文名词，而是把它们想成自动驾驶汽车里的四类东西：司机、整车系统、统一接口、驾驶手册。

这就是 AI Native 最值得关注的地方。

传统软件为什么是”按钮世界”

我们先看传统软件。

你打开一个报销系统，想完成报销。你要先找到”新建申请”，再选择报销类型，填写金额，上传发票，选择部门，提交审批。如果发票格式不对，系统会报错；如果领导没批，你要去催；如果财务退回，你要根据提示修改。整个过程中，你一直在把自己的目标拆成一个个具体动作。

你的目标其实很简单：把这笔钱报回来。

但软件并不真正理解这个目标。它只理解它自己设计好的流程：这个按钮能点，那个字段必填，这个状态可以流转，那个状态不能流转。它像一条生产线，每个工位只能处理被规定好的动作。你要学会这条生产线怎么运转，才能把你的事情送过去。

这就是过去几十年软件的基本形态。

它不是不好。恰恰相反，按钮世界非常伟大。它把复杂的业务流程变成了普通人能操作的界面。没有 GUI，普通人不可能使用电脑、手机、办公系统、银行 App、打车软件。按钮、菜单、表单、页面，让软件第一次大规模进入普通人的生活。

但按钮世界有一个天然限制：软件能做什么，取决于开发者提前设计了哪些动作。

如果开发者设计了”提交报销”按钮，你就能提交；设计了”导出 Excel”，你就能导出；设计了”按时间筛选”，你就能按时间筛选。可如果你想说：”帮我把最近三个月所有跟客户拜访相关的费用整理出来，按项目归类，发现异常金额就标红，再给我写一段说明”，传统软件往往就卡住了。因为这不是一个按钮，而是一串跨页面、跨系统、带判断的任务。

过去我们解决这种问题，靠人。

人打开报销系统查数据，打开 CRM 对项目，打开 Excel 整理表格，再打开 Word 或飞书写说明。软件提供了零件，人负责把零件串成任务。

所以传统软件更像工厂里的机器。每台机器都很强，但它只会做自己的那一道工序。真正知道”这批货最终要变成什么”的人，是站在生产线旁边的工长。

AI Native 的变化，就是软件里开始出现一个类似”工长”的角色。

AI Native 的核心，不是聊天，而是多了一个”会干活的中间层”

很多人以为 AI Native 的关键是自然语言交互，觉得以后所有软件都变成聊天框。这个理解只对了一半。

自然语言当然重要，因为它让人可以直接表达目标，而不是先学习软件的按钮。但真正关键的不是”你可以说话”，而是说完之后，系统里有没有一个东西能把这句话变成行动。

如果你说”帮我整理报销”，系统只是回你一段”你可以先打开报销系统，然后导出数据，再手动分类”，那它还是聊天机器人。它会说，但不会做。

如果你说完以后，它能真的去报销系统查数据，去 CRM 匹配项目，去 Excel 生成表格，发现异常金额，再把说明写进飞书文档，那它就不只是聊天了。它开始成为一个会干活的中间层。

这个中间层，就是我们常说的 Agent。

Agent 这个词听起来很技术，翻译成”智能体”也不太像人话。你可以暂时把它理解成：一个会根据目标自己推进任务的 AI 执行者。

放到汽车类比里，Agent 就是那个司机。你告诉它目的地，它要自己看当前在哪里、路况怎么样、下一步该直行还是转弯、要不要变道、什么时候减速。它不是方向盘，也不是发动机，而是做驾驶决策的那个主体。

它和传统程序最大的不同，不在于聪明，而在于它的工作方式不同。传统程序像生产线上的固定机器，你按下按钮，它执行预设动作；也像一辆手动挡车，踩离合、换挡、打方向都得你自己来。Agent 更像生产线上的工长，也更像自动驾驶里的司机。你告诉它今天要完成什么货，或者告诉它要去哪里，它会自己安排先看原料、再找机器、再检查成品，中间出了问题还会调整。

当然，这个工长不是人。它没有真正的人类经验，也不天然可靠。它会误解目标，会看漏信息，会把事情做偏。所以你不能把它想成一个完全自主的员工，更应该把它想成一个需要制度、工具和边界的 AI 执行者

这就引出第二个概念：Harness。

Harness 也很难翻译。我们先别管英文，可以把它理解成”车和整套驾驶系统”。如果 Agent 是司机，Harness 就是司机所在的那辆车，以及让这辆车能被自动驾驶控制起来的一整套系统：摄像头、雷达、地图、刹车控制、方向盘控制、安全规则、接管机制、事故记录，全都算在里面。

一个裸的大模型，就像一个只会坐在副驾驶上出主意的人。你问它怎么开到公司，它可以告诉你路线，但它不能自己控制方向盘，也不知道你车现在在哪，更不知道前面有没有红灯。

Harness 的作用，就是把这个”会出主意的大脑”装进一辆真正能开、也能被约束的车里。它决定 AI 能看到什么信息，能调用什么工具，能不能写文件，能不能发消息，出了错怎么重试，什么时候必须停下来问人。

这就是为什么同一个模型，在不同产品里体验会完全不同。

你在普通聊天框里让 AI 修一个复杂代码仓库，它可能只能给建议；你在 Claude Code 或 Cursor 里让它修，它就能读文件、改代码、跑测试、看报错、继续修。模型可能差不多，但车不一样。一个只是副驾驶嘴上指挥，一个已经接进了方向盘、仪表盘和刹车系统。

所以 AI Native 产品的竞争，绝不只是模型竞争。模型像发动机和驾驶大脑，Harness 像整车平台。发动机再强，底盘、刹车、传感器、安全系统不行，这辆车也开不稳。

MCP：不是插件，而是车和外部世界的”统一接口”

有了 Agent 和 Harness，还不够。

一个 AI 执行者要真正干活，必须能接触外部世界。它要读文件、查数据库、看飞书、操作 GitHub、访问网页、调用部署系统。否则它再聪明，也只能在聊天框里说话。

这时候就需要 MCP。

MCP 这个词也很技术。你可以先把它理解成：让 AI 调用外部工具的一种统一接口。

为什么要有统一接口？因为没有标准的时候，每个工具都要单独接线。放到汽车里，如果地图、雷达、摄像头、红绿灯、充电桩、停车场闸机，每一个都用完全不同的方式和车通信，自动驾驶系统就很难稳定使用它们。统一接口的意义，是让外部能力用一套标准方式告诉车：”我是谁，我能提供什么信息，你该怎么调用我。”

软件世界里也一样。过去一个程序要接外部服务，靠 API。比如接支付、接地图、接短信、接数据库，开发者读文档，然后写代码调用。API 的默认使用者是开发者，人来读文档，人来决定什么时候调。

但 Agent 不一样。Agent 在执行任务过程中，需要临场判断：”我现在是不是该查 GitHub？是不是该读这个文件？是不是该把结果发到飞书？”如果每个工具都只有一份给人看的文档，Agent 很难自己使用。

MCP 做的事情，就是让工具用一种模型能理解的方式介绍自己。它不像普通插件那样只是给软件多加一个功能，更像给自动驾驶汽车定义了一套和外部设施沟通的标准。

它会告诉 Agent：我是谁，我能做什么，我需要什么参数，我会返回什么结果。比如一个文件系统工具会说：”我能读取文件、列出目录、写入文件。”一个 GitHub 工具会说：”我能查看 issue、读取 PR、查询 CI 状态。”一个飞书工具会说：”我能读取文档、发送消息、创建表格。”

这样 Agent 在执行任务时，就像一辆自动驾驶车进入一座城市。地图、路牌、信号灯、停车场、充电桩都能用标准方式和它沟通，它就可以根据当前目的地和路况，判断接下来该读哪份地图、看哪个信号、调用哪个外部服务。

所以你给 Claude Code 装 MCP，不是在装几个普通插件，而是在给 AI 接外部器官，也是在给这辆车接入城市基础设施。

没有文件系统 MCP，它只能听你描述文件；有了文件系统 MCP，它能自己读文件。没有 GitHub MCP，它只能告诉你怎么提 PR；有了 GitHub MCP，它能自己看 issue 和 CI。没有飞书 MCP，它只能帮你写一段通知；有了飞书 MCP，它才可能真的把消息发出去。

这也是聊天机器人和 AI Native 软件的分界线。

聊天机器人主要在语言世界里工作。AI Native 软件必须能穿过语言，进入真实系统，读数据、改状态、触发流程。

当然，能行动就意味着有风险。一个 AI 说错话，后果通常还在屏幕里；一个 AI 删错文件、发错消息、改错数据库，后果就进入真实世界了。所以 MCP 不能单独看，它必须和 Harness 一起看。MCP 负责接上工具和外部设施，Harness 负责规定哪些工具能用、什么动作要确认、出了问题怎么停。

就像汽车可以接入地图和充电桩，但什么时候变道、什么时候刹车、什么时候让人接管，仍然要由整车驾驶系统来治理。

Skill：不是提示词，而是给 AI 准备的”驾驶手册”

再看 Skill

Skill 很容易被误解成提示词。因为很多 Skill 的核心确实是一段写给模型看的说明，比如”写公众号时要注意什么”、”做 PPT 时按什么流程”、”修 CI 时先检查哪些地方”。但如果只把 Skill 理解成提示词，就会漏掉它真正重要的地方。

我更愿意把 Skill 理解成：给 AI 准备的驾驶手册。

还是用汽车的例子。一个司机不可能把所有场景的处理细则都一直摊在方向盘前。高速驾驶有高速驾驶的规则，雨天驾驶有雨天驾驶的规则，侧方停车有侧方停车的技巧，复杂路口有复杂路口的判断方法。平时这些手册放在资料柜里，只有进入对应场景，才拿出来看。

Skill 就是这个资料柜，也是一册册针对具体场景的驾驶手册。

为什么不能把所有手册都塞给 AI？因为模型的上下文是有限的。哪怕现在上下文越来越大，也不代表你应该把所有材料都塞进去。一个司机正在高速上开车，你不应该同时把沙漠越野、雪地救援、赛车场漂移、地下车库停车的手册全铺在它面前。东西太多，它反而抓不住当前场景的重点。你让 AI 写公众号，也不应该同时给它塞修服务器、做表格、写法律合同、剪视频的所有规则。

所以 Skill 的设计思路是：平时只让 AI 知道”这里有一份什么能力”，等任务真的需要时，再把完整手册打开。

比如你有一个”啸天公众号写作” Skill。它里面可以放你的文风、标题偏好、文章结构、常见反例、审稿清单、历史样稿。你不需要每次写文章都复制一大堆规则。只要你说”帮我把这两个节点整理成公众号”，系统就知道这已经进入”公众号写作路段”，于是把这本驾驶手册加载给 AI。

这和传统软件里的模块、组件有点像，但触发方式不一样。

传统软件里，开发者要主动 import 一个库。你知道自己要用图表库，就在代码里引入图表库；知道要用邮件库，就引入邮件库。它是开发者主动调用。

Skill 更像是根据任务意图自动激活。你说出任务，系统判断需要哪份手册，然后再加载。过去是”人去找能力”，现在变成”能力根据意图被叫出来”。

这也是 AI Native 很重要的一个变化。软件里的能力，不再只是代码库和组件库，也开始变成一份份可触发的工作方法、流程规范、风格规则和领域经验。MCP 解决的是”车能接上哪些外部设施”，Skill 解决的是”司机在具体场景下应该怎么开”。

对很多非程序员来说，这点特别重要。

因为你过去的经验也可以被 Skill 化。一个运营知道怎么写复盘，一个销售知道怎么判断客户优先级，一个产品经理知道怎么拆需求，一个内容创作者知道怎么写出自己的文风。这些东西以前很难变成软件功能，现在可以被整理成 AI 能调用的驾驶手册。

这可能是很多人参与 AI Native 构建的入口。

GUI 不会消失，但它的位置会变

现在我们可以回到最关键的话题：AI 和 GUI 的关系。

很多人听到自然语言界面，会自然想到一个问题：以后是不是所有软件都变成聊天框？按钮和界面是不是都没用了？

我觉得不是。

GUI 不会消失，因为人类仍然需要看见状态、比较信息、确认风险。一个复杂项目的进度，用一段文字描述很费劲，但用看板一眼就能看懂；一组销售数据，用聊天解释很啰嗦，但用图表立刻清楚；一次代码修改，用一句”我改好了”不够，最好能看到 diff、测试结果和风险提示。

所以 GUI 的价值仍然很强。它适合展示复杂状态，适合让人做确认，适合提供稳定边界。

但 GUI 的位置会变化。

过去 GUI 是人直接操作软件的主入口。你亲自点按钮、切页面、填表单、导出文件。未来很多场景会变成：自然语言是主控层，Agent 是执行层，GUI 是展示和确认层。

你说”帮我整理这周项目风险”，Agent 去查飞书、GitHub、会议纪要和项目管理系统，然后把结果呈现在一个看板里。你说”把这几个候选方案做个对比”，Agent 去收集信息、生成表格，然后把关键差异可视化给你。你说”修掉这个 bug”，Agent 改代码、跑测试，最后把 diff 和测试结果展示给你确认。

在这个过程中，人不一定直接操作每个 GUI，但人仍然需要 GUI 来理解 Agent 做了什么，判断能不能通过。

所以更准确的说法不是”自然语言替代 GUI”，而是：自然语言站到 GUI 上面，变成新的指挥层；GUI 下沉一层，变成状态展示、人工确认和 AI 可操作的界面。

再回到汽车的比方。

自动驾驶出现以后，方向盘不会立刻消失，仪表盘也不会消失。你仍然需要看到速度、路线、剩余电量、接管提示。只是你不再每一秒都亲自转方向盘。方向盘从”持续操作工具”，变成”必要时接管的工具”；仪表盘从”辅助驾驶的信息”，变成”监督自动驾驶的信息”。

GUI 也是这样。

未来软件界面不一定是让人每一步都点，而是让人看清楚 AI 正在做什么、准备做什么、做完了什么、哪里需要你拍板。

这会带来一个很大的产品设计变化：未来的软件，可能不只要给人用，也要给 AI 用。

过去我们设计界面，只考虑人怎么看、怎么点。未来还要考虑 Agent 能不能理解这个页面，能不能识别状态，能不能知道哪个按钮危险，能不能在执行前把风险说清楚。一个好的系统，既要 human-readable，也要 agent-readable。

这句话可能会变得越来越重要。

AI 和人的关系：不是替代，而是驾驶层级变化

GUI 的变化背后，其实是人和 AI 的关系变化。

过去人和软件的关系，是人亲自驾驶。软件像车，人坐在驾驶位上，方向盘、油门、刹车都由人控制。你会不会用软件，取决于你熟不熟悉它的按钮、菜单和流程。

AI Native 之后，人和软件的关系更像进入辅助驾驶甚至自动驾驶阶段。人不再总是亲自控制每一个动作，而是更多负责三个事情：定目标、定边界、做判断。

定目标，就是你要说清楚目的地。比如”把客户反馈整理成老板能看的决策材料”，而不是”打开 A 系统，导出 B 表格，复制 C 字段”。AI 越强，人越需要说清楚真正想要的结果。

定边界，就是你要告诉它哪些事情能做，哪些事情不能做。能不能发外部邮件？能不能改线上数据？能不能删除文件？花钱之前要不要确认？涉及客户隐私能不能进模型上下文？这不是细枝末节，而是未来 AI 系统最核心的治理问题。

做判断，就是在关键节点拍板。AI 可以给你三个方案，但哪个方案符合业务现实，哪个表达符合你的风格，哪个风险你愿意承担，仍然需要人判断。

所以 AI Native 并不是简单地让 AI 替代人。它更像把人从具体操作层，抬到目标和判断层。

这对很多岗位都会产生影响。过去一个人价值很大一部分来自”熟练操作系统”：知道入口在哪里，知道怎么导数据，知道怎么跨系统搬运，知道怎么按流程跑完。但如果 Agent 能做这些操作，单纯的按钮熟练度就会贬值。

真正升值的，是你能不能提出好目标，能不能判断好坏，能不能设计边界，能不能把自己的经验沉淀成 AI 能使用的 Skill。

人不会因为不点按钮而失去价值。人会因为只会点按钮而失去价值。

这对 Builder 意味着什么

如果你是一个 Builder，这套变化意味着什么？

我觉得最重要的是，你以后做 AI 产品，不要再从”我要加一个 AI 功能”开始想，而要从”这个产品里的 AI 执行者是谁”开始想。

它像设计一辆带自动驾驶的车。你不能只问发动机多强，也不能只问中控屏好不好看。你要问：驾驶系统能看见什么路况？能控制哪些部件？遇到危险怎么刹车？什么情况下让人接管？导航目标怎么输入？行驶过程怎么展示给人？

对应到 AI Native 产品，就是五个问题。

第一，这个产品里的 Agent 是谁？也就是这辆车里的”司机”是谁。它要替用户推进什么任务？是代码助理、销售助理、运营助理、财务助理、内容助理，还是项目管理助理？它不是一个泛泛的聊天机器人，而应该有清晰的职责。

第二，它跑在什么 Harness 里？也就是这辆车和驾驶系统是什么水平。它能看到哪些上下文，能用哪些工具，状态怎么保存，错误怎么恢复，危险动作怎么确认？不要只迷信模型。一个没有好 Harness 的强模型，就像一台强发动机装在没有刹车的车上。

第三，它通过什么方式连接外部世界？也就是这辆车有哪些统一接口。哪些系统要通过 MCP 或类似方式接进来？哪些只允许读取，哪些允许写入？哪些动作必须二次确认？这决定它是只会说，还是能真的做。

第四，它有哪些 Skill？也就是司机有哪些驾驶手册。你的领域经验、流程规范、内容风格、判断标准，能不能整理成一份份场景手册，让 AI 在合适场景下自动调用？未来很多人的经验资产，可能就是这样被软件化的。

第五，人和它怎么协作？也就是乘客、司机和仪表盘之间怎么配合。哪些地方用自然语言发起任务，哪些地方用 GUI 展示状态，哪些地方必须让人确认，哪些地方允许自动执行？这决定产品是不是安全、可控、好用。

这五个问题，比”加一个 AI 按钮”重要得多。

因为 AI Native 产品不是传统软件外面套一层聊天框，而是要重新设计：谁来理解目标，谁来操作工具，谁来展示状态，谁来承担判断，谁来负责边界。

未来的软件，可能会从 App 变成”任务系统”

最后稍微往远处看一点。

过去我们使用软件，是在一个个 App 之间切换。写文档去 Word 或飞书，做表格去 Excel，聊工作去微信或飞书，管项目去 Jira，写代码去 IDE。每个 App 像一个房间，人拿着任务在房间之间来回跑。

AI Native 之后，软件可能越来越不像一个个房间，而像一条围绕任务自动组织起来的生产线。

你不再先想”我要打开哪个 App”，而是先说”我要完成什么任务”。系统根据任务，调动不同 Agent、工具、数据和界面。写公众号时，它调用你的 Obsidian 笔记、历史文章 Skill、图片工具和排版系统；做销售复盘时，它调用 CRM、会议纪要、飞书群和数据表；修代码时，它调用仓库、CI、部署平台和监控系统。

人看到的，不再只是一个个孤立软件，而是一条任务流：现在做到哪一步，读取了哪些信息，准备执行什么动作，哪里需要我确认，最终结果是什么。

这时候，软件的基本单位可能会从”应用”变成”任务”。

应用仍然存在，但它们变成任务系统里的工具；GUI 仍然存在，但它更多展示状态和让人确认；API 仍然存在，但它们被 MCP 这类协议包装给 Agent 使用；人的工作仍然存在，但更多集中在目标、判断和边界上。

这就是我理解的 AI Native 软件新形态。

它不是一个聊天框，也不是一个更聪明的按钮，而是一种新的软件组织方式：人说目标，AI 组织执行，工具被协议连接，经验被 Skill 沉淀，界面负责展示和确认。

老软件是按钮世界。

新软件是助理世界。

按钮世界不会消失，就像自动驾驶时代方向盘不会立刻消失。但我们和软件的关系已经开始改变。过去我们学习软件，是为了亲自操作每一步；未来我们学习软件，可能是为了更好地指挥、监督和训练那些替我们操作软件的 AI。

这就是 AI Native 真正开始的地方。