AI 不会让软件消失，但会改变我们使用软件的方式

过去半年，我一直同时承担两个角色：AI 产品经理和 Agent 工程师，深度参与了多个 AI 产品从零到一的建设和持续迭代。

作为产品经理，我需要想清楚用户要解决什么问题，产品应该如何设计，AI 怎样融入实际工作；作为 Agent 工程师，我还要亲手把这些想法落地。从框架选型、编写 Skill、开发 Tool，到分析实际对话和任务执行过程，再到模型与 Skill 的评测、调优，这些环节我都深度参与。

这意味着，一个产品从“应该怎么做”，到“能不能做出来”，再到“为什么没有做好、下一轮怎么改”，我都需要一路跟进。这些实践，我也在《半年时间，上百亿 token，我终于搞懂了怎么做好一个 Agent》里做过一次系统复盘：从定义交付标准、设计工具分工，到建立评测、分析失败和持续迭代，讨论的都是怎样让 Agent 在真实业务里稳定把事情做好。

按我自己的使用记录汇总，过去半年，我累计消耗了约 360 亿 Token，平均每个月约 60 亿。

也正是在反复设计、实现、评测和调整的过程中，我逐渐形成了一些对 AI 产品未来的判断，也陆续写过文章讨论。

此前，在从 Moltbook 谈产品与商业模式变化的文章里，我就提出：当 Agent 开始替人使用产品，产品需要为它提供可以直接调用的能力，商业模式也可能随之变化。后来在《别争了，CLI + Skill 才是 AI 工具的未来》里，我进一步讨论了工程上的做法：工具提供能力，Skill 提供使用方法，让 Agent 按需获取信息、完成任务。

如今，看到这些设计出现在越来越具体的产品里，我对这个方向也更有信心了。同时，一线实践也让我把一些判断想得更细，尤其是界面会承担什么工作、专业软件为什么仍然有价值。这两篇文章，是沿着之前的思考继续往下走。

我想先回答一个问题：如果 AI 能替我操作软件，软件应该变成什么样？

一种很流行的想象是：既然 AI 能写代码，以后有需求就现场生成一个软件，现有应用也就没什么价值了。另一种想象则简单一些：软件还是原来的软件，只不过每个页面旁边多一个聊天框。

我觉得，这两种想象都没有充分描述我关心的变化。

用户会越来越多地把任务交给 Agent，由它调用专业软件完成工作。软件依然有价值，但用户未必需要亲自进入每一个软件，才能获得这些价值。

这篇文章先把这件事讲清楚。至于这样的变化为什么值得大厂争抢，留到下一篇。

同样是做一份 PPT，谁在组织整个过程？

假设现在要做一份季度经营汇报。你需要找数据、核对口径、整理结论、制作图表，再把内容放进公司的模板，调整版式，检查有没有文字溢出。

这个过程中，你可能会用到数据库、表格、搜索、文档和演示软件。每个软件都能解决一部分问题，但把这些能力串起来的是你：你知道先做什么、后做什么，也负责在软件之间搬运信息。

现在换一种使用方式。你把数据和模板交给 Agent，说明汇报对象、内容重点和交付要求。它去读取数据、调用分析工具、生成图表，再调用演示文稿服务，给你一份可检查、可修改的稿件。

这当然是一个理想化的工作场景，具体产品能做到哪一步，还要看任务和能力。但它揭示了一个值得关注的变化：组织任务的工作，开始有一部分从用户转交给 Agent。

搜索、分析、排版这些专业能力仍然存在。变化发生在它们被谁调用、怎样协同。

图 1｜以制作经营汇报为例的工作方式对比

这也是我理解“AI 原生产品”时最关心的地方。给旧软件加一个对话框可以有价值，但更进一步的问题是：用户能不能直接交付目标，而不必继续亲自安排每个操作步骤？

先理解 Agent，后面的变化就不难理解了

这里不争论一个产品有没有资格叫 Agent。为了方便讨论，我采用一个实用的理解：它是一个能围绕目标，借助模型选择下一步行动、使用工具，并根据结果继续调整的系统。

重点在“根据结果继续调整”。让模型回答一次问题，和让一个系统读取文件、发现缺少数据、再去查询、检查结果，最后交付文件，是不同的工作方式。Anthropic 在《Building effective agents》中，也把预先规定路径的工作流，与由模型动态决定过程和工具使用的 Agent 区分开来。来源：Anthropic，2024-12-19

还拿 PPT 来说。模型判断需要数据，系统执行查询，把查询结果交回模型；模型判断需要图表，系统调用绘图工具，再把结果交回来。这个循环可以进行多轮，直到完成任务，或者需要人补充信息、作出决定。

所以，一次用户请求背后可能有多次模型调用。不过，也不是每个任务都需要这么复杂。能用固定程序完成的步骤，就应该允许程序直接完成。

要把这个系统理解清楚，我会看三个方面：

• 模型：负责理解、推理和选择行动。它影响系统能处理多复杂的问题。
• 运行环境与工具：负责让行动真正发生。其中，Harness 管理模型调用、上下文、状态和执行循环；文件系统、浏览器、数据库等工具提供具体操作能力。
• 业务上下文与方法：告诉系统正在为什么人做事、数据是什么口径、结果要符合什么要求。Skill 可以承载操作方法、脚本和参考资料，但并不等于全部业务知识。

这里几个概念很容易混在一起。模型聪明，不代表它天然知道你公司的经营口径；有一份操作说明，也不代表系统已经获得了数据库的访问权限；工具能成功运行，更不代表结果符合业务要求。

Anthropic 对 Agent Skills 的官方介绍，就把它描述为由指令、脚本和资源组成、可按需加载的能力包。这种设计的价值，是让通用 Agent 获得具体场景的方法，而不是每次从头摸索。来源：Anthropic，2025-10-16

图 2｜Agent 的简化工作机制。运行框架承接循环，模型选择行动，工具执行，业务上下文提供依据。

只要理解这一点，后面的判断就有了基础：同一个 Agent，可以通过调用不同工具、加载不同方法，处理不同任务。用户不必为每一种能力都重新学习一套完整的操作流程。

当 Agent 成为使用者，产品该怎样提供能力？

过去，我们设计软件时，首先考虑的是人怎么使用：按钮放在哪里，菜单如何组织，拖拽是否顺手。这些问题当然还有价值。但如果使用者还包括 Agent，就需要多考虑一层：能力能否被可靠地调用？

仍然以 PPT 为例。人习惯拖动图形来调整位置，Agent 则可以通过工具修改位置、调用布局规则，再查看渲染后的页面是否正确。它不需要模仿人，把每个鼠标动作都重演一遍。

这不是说“能改坐标就能做好 PPT”。布局、审美、内容关系、字体兼容、导出质量，仍然需要专业能力。恰恰因为这些工作有难度，把它们积累为稳定的工具才有价值。

一种产品可以开放底层操作，例如查询数据、插入图表、导出文件；也可以提供更完整的服务，例如接收内容和模板，返回一份排好版的演示文稿。更进一步，服务内部还可以运行自己的 Agent，处理多步骤任务。

API、CLI、MCP、Skill 在这里承担的作用并不相同。API 提供程序接口，CLI 让能力能通过命令调用，MCP 提供连接工具与资源的协议，Skill 则补充使用方法与相关资源。它们可以组合，也不必每个产品全部采用。

用户交给入口的是一个任务，入口向专业服务请求的，可以是一个操作，也可以是一份完整交付物。

图 3｜专业能力可以以不同粒度交付。API、CLI、MCP 是接入方式，Skill 提供方法。

这并非只有概念。Firecrawl 的官方文档已经把网页搜索、内容提取等能力作为 API 提供，并提供 Skill、CLI 和 MCP 接入方式。它说明，面向 Agent 提供专业能力，已经是一种具体的产品设计。来源：Firecrawl 官方文档

飞书也在 2026 年 5 月介绍了官方 CLI，把消息、日历、文档等能力通过命令开放出来。来源：飞书 CLI 官方说明 对照旧文里讨论的个人开发者版飞书 CLI，这个变化让我尤其有感触：软件厂商自己也开始为 Agent 铺设调用能力的路径。我此前关于“产品需要为 Agent 使用而重新设计”的判断，正在这些具体选择中逐步得到验证。

但我不会据此推导出“做了接口就一定赚钱”。接口是交付方式，持续被调用的前提仍然是：效果好、成本合理、结果稳定，而且确实解决问题。

既然 AI 能写软件，为什么还需要专业产品？

这个问题值得正面回答。AI 确实会让一部分临时工具更容易生成，也会让定制开发变便宜。比如，针对一份表格写个清洗脚本，或者做一个只用一次的小页面，现场生成完全可能是合理的选择。

但从“能生成”走到“每次都应该重新生成”，中间还差一笔账。

你想做一份 PPT，并不一定想顺便开发和维护一套排版引擎。一个示例文件能成功导出，也不代表几十种复杂内容、不同字体、不同模板都能稳定处理。修复一次边界情况的投入，如果能在大量任务上重复使用，就有机会摊薄成本。

因此，真正应该比较的是：为了获得一份合格结果，总共要付出多少代价？这里既有模型调用和工具费用，也有等待、检查、返工，以及后续维护。

成熟产品不一定总赢，现场生成也不一定总便宜。对于低频、简单、个性化的需求，生成可能更合适；对于高频、复杂、交付标准明确的需求，复用成熟能力通常更值得比较。

图 4｜生成与复用的决策框架

我不赞成用“AI 写的代码只能做 Demo”概括它的能力。AI 参与开发与软件达到生产要求，并不冲突。真正的问题是：测试、适配、稳定性和持续维护这些工作，有没有被完成，而不是代码最初由谁写出来。

所以，我更愿意做这样的判断：当生成能力变强，专业产品需要更清楚地证明自己的价值。这个价值可以来自独特的数据、稳定的执行、专业质量，或者长期维护，而不只是一个更容易上手的界面。

Agent 成为入口以后，界面反而有新的工作要做

在之前那篇谈 Moltbook 的文章里，我曾把工具类场景推演为：任务交给 Agent，人类不再需要碰界面。现在结合更多实际工作，我会给这个判断补上一层：Agent 接过操作，并不意味着人不再需要看见过程、检查结果和动手修改。

如果我交给 AI 一个任务，然后十分钟没有动静，我会想知道：它到底有没有在做？卡在哪里？读了哪些材料？是不是把需求理解错了？

等它交付 PPT，我也很难只通过聊天判断版式好不好。看到页面、对比版本、选中某一页修改，往往比写一大段描述更直接。

这里有两个独立的问题：一是信任，用户需要能够了解和干预任务；二是表达，有些事情本来就更适合通过视觉和直接操作完成。即便模型很强，画布、图表、预览和编辑器也可能继续有价值。

因此，在很长一段时间里，我更看好 Agent 与界面配合的形态：用户通过自然语言提出目标，Agent 执行任务，界面呈现关键进展、依据和结果，用户在必要时审核、调整或接管。

这不意味着把所有内部日志都展示出来。用户真正需要的是：现在在哪一步，已经得到什么，哪里存在不确定性，以及接下来有什么需要自己决定。

这一方向已经有明确的产品与协议支持。2026 年 1 月 26 日，MCP Apps 成为官方扩展，允许工具把仪表盘、表单、可视化等交互界面直接带进对话。来源：MCP 官方发布

我从中看到的，是一种值得继续探索的交互方式：界面可以围绕任务出现。例如处理数据时出现图表，核对内容时出现预览，需要精修时出现编辑器。

图 5｜一种可能的交互演进。第三种形态是开放推演，各种形态可能长期共存

至于更远的未来，模型能力和用户信任会发展到什么程度，我现在不想下定论。部分场景里，界面可能越来越少被打开；另一些场景里，它可能变得更丰富、更贴合当下的任务。

入口集中，不等于所有界面都要消失。

未来的产品，会围绕怎样的分工生长？

沿着前面的推导，我更看好两种相互依赖的产品角色。

一种是任务入口。它理解用户目标，连接文件和工作环境，选择工具，组织执行，再把结果交回来。对用户来说，价值在于减少组织工作的负担：不用每次都亲自安排所有软件如何配合。

另一种是专业能力提供者。它把搜索、数据分析、演示文稿、设计等某一类事情做好，让入口可以可靠调用。对它来说，价值在于专业交付的质量。

两种角色不必对应两家不同公司。同一个产品，可以在自己的专业场景里直接服务用户，也把能力开放给其他 Agent。一个入口平台，也可以提供运行环境，让开发者在上面构建专业 Agent。

例如，做 PPT Agent 的团队未必需要从头重建全部运行框架。它可以使用已有的模型、执行环境和工具，把主要精力放在内容组织、布局、检查、行业模板和真实任务评测上。但依然要为交付质量负责，不能把“写了一份 Skill”当成产品已经完成。

图 6｜两种产品角色，而不是两类互斥的公司。专业服务也可以拥有自己的界面，并同时接入多个入口。

回到我自己的工作，这会改变产品设计时的提问顺序。除了“用户怎么点”，我还会问：Agent 能否发现这项能力？调用失败后能否知道原因？结果是否方便检查？用户能否在关键位置接管？

软件的竞争仍然落在交付价值上，只是价值抵达用户的路径在变化。

对我来说，这正是未来 AI 产品最值得投入的地方：让用户少承担组织工具、搬运信息和反复操作的工作，同时保留判断、选择和修改的能力。

当越来越多任务通过这样的入口完成，下一个问题就来了：谁能成为用户习惯交付任务的那个地方？这也是我理解大厂争抢办公 Agent 的起点。

若觉得内容有帮助，欢迎点赞、推荐、关注。别错过更新，给公众号加个星标★吧！祝您在2026年里天天开心，快乐，身体健康，万事如意！期待与您的下次相遇～