上周二，我需要更新我们内部知识库中的三个文档。我没有打开文档工具。我打开了克劳德。我让它从线性票据中抓取最新内容，总结变化，找到相关页面并更新它们。在我煮咖啡的时候，它通过 MCP 完成了所有这些工作。而实际产品的浏览器标签页却从未打开过。
这已经不是什么稀奇事了。这就是现在正常星期二的样子。对于任何仍将用户界面视为重头戏的 SaaS 产品开发者来说，这都应该是一种无声的恐惧。
数字表明用户界面失去了多数
让我们从一些令人不舒服的事情开始。根据Imperva发布的《2026年恶意机器人报告》，自动化流量目前占所有网络流量的**超过53%，这是十年来人类首次成为互联网上的少数群体。在这部分自动化流量中，人工智能代理流量在2025年增长了近8000%。网络上增长最快的东西不再是一个人在四处点击。它是一个代表某人完成工作的代理。
在协议方面，情况更加明显。Anthropic的MCP在2025年初还几乎不存在，但截至2026年第一季度，已有78%的企业人工智能团队投入生产，而一年前只有31%。公共MCP服务器注册量从2025年第一季度的约1200台服务器增加到2026年4月的超过9400台。2025年12月，Anthropic将该协议捐赠给了Linux基金会下新成立的[Agentic AI Foundation]（https://www.cdata.com/blog/2026-year-enterprise-ready-mcp-adoption），OpenAI、谷歌、微软和AWS都加入了该基金会。从那时起，MCP 不再是 Anthropic 的专利，而开始成为集成层。
除此之外，Gartner 现在预测，到 2026 年底，**40% 的企业应用将配备特定任务的人工智能代理，而目前这一比例还不到 5%。
一起来读读这些数字。您产品的使用管道正在您的脚下重建，而很大一部分新流量将永远看不到按钮。
大多数产品在引擎盖下仍以用户界面为先
每次看到新的 SaaS 工具，我都会注意到这一点。
用户界面非常华丽。而应用程序接口（API）却是事后才想到的。在用户界面使用的 40 个端点中，有一个 /docs_页面，其中有 12 个端点。没有 MCP 服务器。CLI 即使存在，也是一个每半年就会被放弃的社区辅助项目。入职流程假定你是一个人类，正在点击向导，因为该产品的设计初衷就是让人类登录。
这种模式运行了 15 年。2026 年开始失效，以后每个季度都会更加严重。
以下是我一直观察到的情况。一个团队采用了一种新工具。他们在最初几周使用了用户界面。然后，团队中有人将 Claude 或 ChatGPT 插入他们的工作流程。突然之间，问题不再是_"我如何打开用户界面并更新这个东西"。问题是"我的代理能否帮我完成这项工作"_。如果答案是否定的，那么该工具的使用率就会开始下降。不是因为用户界面变差了。而是因为入口转移了。
根据Imperva的同一份报告，2025年，以API为目标的僵尸流量跃升至僵尸流量的**27%。这个数字还将逐年攀升。每个代理工作流都是 API 调用的堆叠，每个不公开这些调用的产品都将被淘汰出工作流。
##"无需用户界面即可工作 "的实际意义
这不仅仅是 "有一个应用程序接口 "那么简单。大多数产品都有应用程序接口。大多数应用程序接口也很糟糕。
没有用户界面也能运行的产品则要通过更难的测试。我认为大概有四种测试方法。
- 用户界面中每一个有意义的操作都可以通过应用程序接口调用。没有 "这只能由管理员在用户界面中配置 "的框。如果人类能做到，代理也能做到。
- 有一个 MCP 服务器，它是第一方的，而不是一个社区项目。它不是一个社区项目，也不是某个人上周末构建的包装。这是一个真正的、自有的、版本控制的 MCP 服务器，它以代理可以推理的方式，暴露出与 API 相同的表面。
- 因为 CLI 是工程师编写脚本的方式，也因为 CLI 也是很多代理框架在 MCP 不可用时调用工具的方式。
- **服务账户、范围令牌、代理可代表用户完成的 OAuth 流程。不是 "点击电子邮件中的这个神奇链接"，因为代理没有电子邮件客户端。
如果您的产品不能满足上述任何一项要求，那么您构建的只是一个带有后台的用户界面，而不是一个产品。这种区别将越来越重要。
在 Rasepi，我们不得不做出这样的决定，而且并不含糊
老实说，这就是我们以这种方式构建 Rasepi 的原因，这是一个真正的架构决定，而非营销路线。
2025 年初，当我们绘制产品草图时，很明显要构建的是另一个 Confluence 型用户界面。一个漂亮的编辑器，一个漂亮的阅读器，顶部还有一个搜索栏。我们几乎做到了。让我们停下脚步的是，我们看到团队已经在使用 Claude、GPT 和类似的代理来阅读和编写内部文档，而无需打开现有工具。用户界面并不是瓶颈。缺乏编程表面积才是瓶颈。
因此，Rasepi 的设计以 API 为先，用户界面建立在任何代理或脚本都能访问的同一界面之上。MCP 服务器、REST API 和 CLI 都共享相同的身份验证、相同的权限模型和相同的内容层。用户界面只是消费者之一。我们通过编写脚本来测试产品，而不是通过点击来测试产品。
这对我们的构建产生了影响，有好的影响，也有略微痛苦的影响。每个新功能都必须与应用程序接口相匹配。我们不能只是 "添加一个按钮 "就算完成了。这样做的好处是，当客户将 Claude 插入他们的 Rasepi 实例时，一切都能正常工作。不会出现 "啊，那个功能只有用户界面，抱歉 "的情况。
如果您正在开发新产品，这意味着什么？
如果非要总结实用性的话，有以下几点。
停止仅通过用户界面活动来衡量使用情况。分别测量 API 和 MCP 流量，并将其作为增长指标进行跟踪，而不是作为运营噪音。如果您的仪表板使用量持平，但 API 流量却翻了一番，这不是问题。未来将如期而至。
在社区为你建立一个糟糕的 MCP 服务器之前，先建立一个第一方 MCP 服务器。公共注册表中的 9,400 台服务器并不都是好的。无论是否由你编写，用户都会根据集成的质量来评判你的产品。
不要再把应用程序接口当作产品的廉价版。一年后，对于很多客户来说，API 就是你的产品。
2026 年的赢家将是那些用户可以通过 API、CLI、MCP 服务器或用户界面完成所有操作，并且永远不会觉得选错了门的公司。
用户界面不会消失。人类将继续使用用户界面来完成可视化工作，这很好。但它不再是前门。它只是几扇门中的一扇，而其他几扇门的发展速度要快于前门。
如果你的产品在用户界面关闭时无法站立，那么首先要解决的就是这个问题。