AI世界的地基一直移动，筹码下在哪里？

本文来自微信公众号： AIGC从0到1 ，作者：王零壹

从GUI、CLI与机器人争论，看AI时代的“移动地基”

--

这两天AI群里有一场很有意思的争论。

一边有人说，GPT-6 Astra这样的模型已经开始直接操作GUI：看屏幕、移动鼠标、点按钮、处理异常。过去大家认真设计的CLI、MCP、API wrapper，似乎一下都显得没那么必要了。

另一边的人很快泼来冷水：

“能上手GUI是一回事，跑在哪是另一回事。我们的Agent全在没有桌面的服务器上运行，CLI不是设计偏好，是唯一能起得来的入口。”

还有人问得更直接：

“机器人你能等它每一步想几分钟、花几刀吗？”

这些话表面上在争GUI、CLI、MCP，争Computer Use到底是不是未来，争机器人是不是还需要VLA。

但放在一起，会发现大家不安的是另一件事：

当底层模型越来越聪明，今天被认为不可缺少的一层工程，半年后会不会忽然变成多余？

过去几年，AI工程师做了大量工作：写prompt、搭workflow、做router、建RAG、封装API、设计MCP、训练专用policy、给模型加记忆、加verifier、加状态机。

其中有些工作会沉淀为长期基础设施。

也有些工作，可能只是因为模型当时还不够聪明。

模型一旦跨过某个能力阈值，那些精心搭起来的结构，就像施工完成后还没来得及拆掉的脚手架：突然失去了承重意义。

这不是一个纯技术问题，这是一个关于技术品味、产品判断、创业下注，甚至职业选择的问题。

因为今天的AI世界，很像一块正在移动的地基。

你刚把房子盖好，地面已经抬升了一层。

一、GUI、CLI与MCP的争论，三方其实都没有错

激进的一派说得很痛快：

脑子够用，就直接硬解。

在他们看来，GUI本来就是人类已经为软件世界建好的通用环境。几十亿个应用、后台、ERP、旧系统、网页工具，原本都需要被重新包装成API、CLI、MCP，Agent才能使用。

现在，如果模型能够理解屏幕、规划动作、点击按钮、看见反馈、修正错误，那么中间那一层层“翻译工程”就可以被绕过去。

过去的路径是：

软件→API→wrapper→tool→Agent

现在似乎有了另一种路径：

软件GUI→Agent

这背后的直觉很强：人类已经造好了一个巨大的软件世界，为什么还要再为机器重建一遍？

于是有人说了一句很有代表性的话：

闭环本身就是接口。

模型只要拥有观察通道、行动通道和反馈通道，就可以在“看见—行动—看结果—再修正”的循环里自己解决问题。

这个观点很有冲击力，但工程现实派说的也没错。

GUI是一种为人类视觉、鼠标和手眼协调设计的界面。从机器角度看，“点击右上角的小齿轮”，显然不如settings.update()高效、便宜和确定。

如果一个任务可以用一次API调用、一次shell命令完成，为什么要让模型反复截图、理解页面、移动鼠标、点击、再截图确认？

更重要的是，很多Agent根本不运行在桌面环境里。

它们运行在无界面的服务器、容器、沙箱、云端工作区中。它们要处理的是批量任务、代码仓库、日志、数据库、定时任务和长期工作流。此时CLI不是审美偏好，而是现实约束。

所以，GUI能不能用，和GUI是不是应该成为默认选择，是两回事。

还有第三种立场，我认为更接近未来。

不是GUI打败CLI。

不是MCP打败GUI。

而是：模型不再必须通过一种固定接口才能触达世界。

未来的Agent很可能拥有一个“接口选择能力”：

它自己判断：

• 这一步需要看屏幕，因为状态只在页面上出现；

  
  

• 这一步需要shell，因为命令最快、最稳；

  
  

• 这一步需要API，因为成本最低、结构最清楚；

  
  

• 这一步需要结构化state，因为不能只靠视觉猜；

  
  

• 这一步需要人类确认，因为动作不可逆。

  
  

真正可能被淘汰的，是“世界必须先被包装成某一种固定接口，模型才能使用”的默认前提。

这是一种很深的工程哲学变化。

过去是：

先把世界整理成模型能理解的样子，再让模型做事。

现在正在变成：

先把世界暴露给模型；只有它处理不好的部分，再加结构。

这并不意味着结构没用了。

它意味着，结构的位置变了。

二、AI的特殊之处在于：地基不只是变快，而是在向上长

过去的技术也一直进步。

CPU更快，内存更便宜，带宽更高，云计算更普及。

但这些进步大多是在做同一件事：让原来的任务变得更快、更便宜、更大规模。

AI的变化不同。

模型能力提升，不只是“同一项任务成本下降”。

它会获得过去属于上层软件、上层流程、上层人的能力。

模型开始理解长文本，于是某些复杂的检索拼接工作变得不再必要。

模型开始具备更强的规划和工具调用能力，于是一些硬编码workflow显得笨重。

模型开始看懂界面、使用鼠标键盘，于是“所有软件都必须先提供机器API”这个前提松动了。

模型开始具备语义理解、错误恢复和任务拆解能力，于是机器人领域里一部分原本必须靠专项训练解决的问题，开始被通用推理模型侵入。

这就是“移动地基”最特殊的地方。

底层不只是变快。

底层在持续获得上层曾经赖以存在的能力。

于是，抽象边界不断上移。

昨天你还觉得必须存在的一层，今天可能变成优化项；昨天你以为是长期基础设施的东西，明天可能只是一个过渡期产品。

技术圈里常说“共识的保质期只有半年”，听起来像玩笑。

放在这里，却很准确。

因为AI时代真正变化的不是功能列表，而是：

哪一层复杂度，仍然值得由人长期维护。

三、很多工程复杂度，本质上是一种“智能不足税”

1987年，Fred Brooks在《没有银弹》里提出过一个经典区分。

有些复杂度来自问题本身，无法被消除；有些复杂度来自我们选择的工具、方法与表达方式，因此可以被改进。

这套区分放到AI时代，仍然有用。

今天至少可以把复杂度分成三类。

第二类，我愿意给它起一个很直白的名字：

Intelligence Scarcity Tax，智能不足税。

模型还不够聪明时，人就必须用大量工程结构去补。

你要告诉它每一步怎么做。

你要把复杂任务拆成固定流程。

你要设计router，决定什么任务交给什么模型。

你要把软件包装成工具，把工具包装成schema，把schema包装成prompt。

你要用规则和状态机，把模型可能犯的每一种错误提前堵住。

这些东西在当时往往是非常优秀、非常务实的工程。

问题只在于：它们解决的是世界的约束，还是当时模型的约束？

如果只是后者，那么模型能力一旦上来，它们就会迅速折旧。

很多人最容易犯的错，不是做了会过时的东西。

而是把暂时性的能力缺口，误认为长期存在的产业结构。

四、所谓“脚手架坍缩”，并不是某个技术死了

今天最容易看到的，就是一层层脚手架正在发生不同程度的坍缩。

但“坍缩”不等于“死亡”。更准确地说，一项技术通常有四种命运：

• 真正消失；

  
  

• 从必要条件变成优化项；

  
  

• 暂时被绕过，但仍然会回来；

  
  

• 因为模型变强，反而变得更重要。

  
  

1.Prompt：从“给模型编程”到“给模型交代环境”

2023年到2024年，大家热衷于各种magic prompt。

角色设定、步骤拆解、思维链、几十条注意事项、复杂few-shot、禁止模型做这个、要求模型做那个。

当时模型能力有限，提示词确实承担了大量“行为补偿”工作。

但模型越来越强后，工程重心开始从prompt engineering转向context engineering。

Prompt仍然重要，只是它不再那么像“给模型写程序”。

它更像是在交代：

• 目标是什么；

  
  

• 你处在什么环境；

  
  

• 哪些信息可信；

  
  

• 哪些动作不能做；

  
  

• 什么时候应该停下；

  
  

• 什么结果才算完成。

  
  

过去很多复杂prompt，是为了牵着模型的手走。

未来更重要的，是让模型知道自己在什么地方、可以做什么、不能做什么。

这就是脚手架的第一种坍缩。

它没有消失，只是从主结构退成了薄层。

2.RAG：不是死亡，而是职责收缩

RAG也很像。

过去大家默认认为：只要是私有知识、企业知识库、长文档任务，就要做chunk、embedding、vector database、top-k、rerank、citation。

随着long context、模型检索能力和原生搜索能力提高，最简单的RAG管线不再天然是唯一答案。

但这不意味着RAG没有价值。

大规模知识库、精确事实检索、成本控制、实时更新、权限隔离、来源追溯，这些需求都不会因为模型更聪明而消失。

RAG只是从“所有问题的默认解”，变成“在特定约束下更好的解”。

这是AI工程里一个值得反复记住的模式：

模型能力提升，通常不会立刻杀死一个层；它会先把这个层从必要条件降级成条件性优化。

3.GUI、CLI与MCP：不是接口消失，而是“必须先封装”消失

GUI很可能会成为Agent的通用兜底能力。

因为现实世界里有太多系统没有API，没有干净的CLI，没有人为Agent准备的MCP。

模型能看懂界面，意味着它能进入这些原本封闭的环境。

但GUI不会因此成为最优接口。

只要有结构化API，只要有可靠CLI，只要有明确权限边界，生产系统仍然会偏爱更快、更便宜、更可审计的通道。

所以未来的主角不是GUI，也不是CLI。

而是一个更成熟的Agent：它会自己挑选接口。

一项这轮研究引用的实验也很说明问题：同一模型只更换Agent scaffolding，token消耗就可能出现极大差异；而MCP和CLI本身并没有简单的固定胜负关系。

这意味着，大家可能一直问错了问题。

不是：

哪种接口赢？

而是：

哪些结构真的在帮助模型，哪些结构只是在把模型绑住？

4.机器人：通用智能会吃掉上层，专用控制还会留在底层

机器人是最容易看清边界的地方。

关于VLA的表述很激烈，带着“几十个PhD干了一年，全被通用模型一下打穿”的情绪。

这种讲法指向的问题确实存在。

更强的通用模型，正在展示出一种能力：不经过任务专门微调，也可以进行语义理解、任务拆解、错误恢复、工具选择，甚至尝试高层机器人控制。

这会迅速侵蚀一部分原本需要专用模型承担的工作。

但实验也同时显示，精细插入、动态控制、复杂双臂协同、力反馈、实时轨迹控制，仍然远不稳定。

所以更可能的未来是重新划分边界：

通用模型

语义理解/任务规划/异常恢复

↓

高层策略

↓

专用控制器

实时动作/力控/轨迹/安全

↓

机器人

通用intelligence可能迅速吃掉System 2。

但System 1并不会因此自动消失。

模型越聪明，越需要我们知道：它究竟该负责到哪里。

五、真正发生的，是复杂度迁移

很多人看到模型能力提升，会自然得出一个结论：

模型变强，工程会越来越少。

这也不准确。

更接近现实的图景是：

模型变强→能力补偿工程减少→真实世界约束工程增加

过去的技术栈大致是：

模型能力不足

↓

Prompt/Workflow/Router/Planner

RAG/Wrapper/专用Policy

↓

现实世界

未来可能更接近：

模型

推理/规划/工具选择/错误恢复

↓

更薄的接口层

↓

状态/权限/身份/安全

评估/审计/成本/治理

↓

现实世界

上面那一层会被压薄。

下面那一层反而会变厚。

原因很简单。

模型越聪明，它能运行得越久。

运行得越久，它能调用的工具越多。

工具越多，它能造成的影响越大。

影响越大，失败路径就越复杂。

系统问题，不会因为模型更聪明而消失。

恰恰相反，模型越强，问题越急迫。

所以，未来真正厚重的基础设施，很可能不是替模型补智力的那一层。

而是帮助人类管理模型能力的那一层。

State、permission、identity、sandbox、observability、evaluation、authorization、auditability。

听起来不如“Agent会自己点鼠标”性感。

但它们更接近真实世界。

六、创业者最该问的

对于AI创业来说，这件事尤其残酷。

传统软件创业会问：

• 用户有没有需求？

  
  

• 市场够不够大？

  
  

• 产品体验是不是更好？

  
  

• 获客成本是否能承受？

  
  

AI创业还多了一个问题：

等我们把产品做出来的时候，这个需求还存在吗？

假设有两家创业公司。

第一家公司的核心价值是：

“模型处理不了200页合同，所以我们帮它切chunk、做向量检索、搭一套复杂的prompt pipeline。”

第二家公司的核心价值是：

“企业里的合同、审批规则、历史决策、员工身份、系统权限、财务预算都散落在不同系统里。我们负责把这些东西变成可信的context、权限与执行闭环。”

两家公司今天看起来都在做AI基础设施。

但它们面对的风险完全不同。

第一家公司解决的是：模型现在不会。

第二家公司解决的是：模型再聪明，也无法天然知道。

模型能力增强十倍后，第一种价值可能下降。

第二种价值反而可能上升。

因为模型越能行动，企业越需要确认它是谁、能看什么、能花多少钱、能替谁做决定。

这就是两类产品最重要的区别：

当然，一个一年后可能被模型吞掉的产品，今天依然可能是一门好生意。

只要它：

• 价值产生得足够快；

  
  

• 开发周期足够短；

  
  

• 投入可以调整；

  
  

• 能在窗口期内回本；

  
  

• 能沉淀用户、数据、渠道或工作流；

  
  

• 能在下一次能力跃迁时转向别的层。

  
  

真正危险的不是做一座桥。

真正危险的是把一座桥，当作一百年的地基来建设。

七、在移动地基上，如何判断该把赌注下在哪里

如果要把这篇文章压缩成一套实际可用的判断框架，我会建议面对每个AI机会时，连续问七个问题。

1.它解决的是世界的复杂度，还是模型的复杂度？

权限、成本、物理约束、法规、组织流程、真实状态，这些通常更接近世界本身。

长prompt、手工分解、过度wrapper、模型不会某种操作，这些更可能是阶段性问题。

先分清这两类，很多误判会自动减少。

2.如果明天模型聪明十倍、便宜十倍，它的价值会上升还是下降？

这是最简单、也最残酷的测试。

价值下降的，说明你可能依赖能力缺口。

价值上升的，说明你更可能在帮助模型进入真实世界。

3.这层工程是不是“智能不足税”？

不要因为一个结构今天必要，就默认它明天也必要。

如果它存在的唯一理由是“模型目前做不到”，就应该把它看作高折旧资产。

它可以赚钱。

但不能被误认为永恒护城河。

4.Time-to-Value是否短于Time-to-Obsolescence？

一个能力补丁即使未来会被吃掉，只要三个月能上线、六个月能回本、一年后可以转型，也可能是好项目。

反过来，如果一个项目需要两年建设，而模型可能在半年内跨过能力边界，它就要被重新审视。

5.投入是否可逆？

Prompt、workflow、薄软件层，往往可以快速重写。

重资产数据采集、长期专用训练、深度绑定某个模型能力缺口的组织结构，则更难掉头。

在高度不确定的环境中，可逆性本身就是价值。

6.你有没有把下注放到稳定变量上？

模型能力变化很快。

但有些东西变化很慢：

• 用户真正要完成的工作；

  
  

• 信任；

  
  

• 分发；

  
  

• 私有数据；

  
  

• 组织流程；

  
  

• 权限；

  
  

• 身份；

  
  

• 状态；

  
  

• 反馈闭环；

  
  

• 成本；

  
  

• 物理世界；

  
  

• 人的激励。

  
  

越靠近这些变量，越不需要赌自己能准确预测下一代模型。

7.新模型发布当天，你的产品会自动变得更好，还是突然失去意义？

这是最重要的一问。

最好的架构，不是抵抗模型升级。

而是模型升级当天，什么都不用改，产品自然变强。

这才是真正意义上的“骑在能力曲线上”。

八、技术正确和商业正确，从来不是一回事

这里还有一个很容易被忽略的地方。

如果你在2024年判断：

“未来的前沿模型一定会直接操作GUI，所以现在的GUI automation产品终究会被吃掉。”

这个技术判断可能完全正确。

但如果另一个团队做了这件事，在两年里拿到了大量客户、赚到了真钱、积累了数据、建立了渠道，随后再转型，那么对方在商业上可能仍然是对的。

企业价值不是“永远不会被替代”。

企业价值更接近：

现金流×时间窗口×资本投入×可迁移资产

短周期不等于坏生意。

长期正确，也不必然等于当下的好生意。

因此，真正成熟的原则不是：什么都别做，等更强的模型出现。

而是：

今天要做能产生价值的事；架构上，要为能力曲线留出余地。

Build for today,architect for the slope，为当下而建，为斜坡而设计。

今天赚钱。

明天不被昨天的自己拖住。

九、技术品味，开始有了时间维度

我们过去理解技术品味，常常是：

感知复杂-发现异常-再把复杂放对地方

但在移动地基上，还要多一层判断：

这份复杂度，应该在那里待多久？

有些复杂度是现实本身的形状，模型再聪明也绕不过去。

有些复杂度只是今天模型还不够聪明的痕迹。

有些复杂度，则会因为模型越来越能行动，而变得比过去更重要。

所以，AI时代的技术品味，也许可以增加一点：

技术品味，是辨认哪些复杂度不会被智能吃掉的能力。

真正高水平的技术判断，不是更准确地猜GPT-7会做什么。

而是尽可能找到一个位置：

无论GPT-7最后会什么，你的下注仍然成立。