企业官网建设流程全解析

莫拉维克悖论这个概念，最早是从机器人学和认知科学里冒出来的，但这两年因为"Computer Use"这类让模型直接操作图形界面的能力火了，它又被反复翻出来讨论。我第一次认真琢磨这件事，是在一个自动化流程的项目里：让模型去点按钮、填表单、拖滚动条，结果发现它做这些"人闭着眼睛都能干"的事，反而磕磕绊绊，而让它去解一道复杂的逻辑题、写一段结构化代码，却顺得不行。这个反差，就是莫拉维克悖论在当下最鲜活的注脚。

所谓莫拉维克悖论，说的是：对人类而言越难的高阶推理，对机器反而越容易；而人类觉得毫不费力的感知、运动、手眼协调，对机器却异常困难。放到Computer Use这个场景里，就是模型能读懂一段复杂的业务规则，却可能在一个下拉框里选错选项，或者把鼠标点到相邻的按钮上。这篇内容我想聊的就是这个悖论到底怎么在"让模型操作计算机"这件事上体现出来，它背后的机制是什么，以及我在实际项目里是怎么绕开这些坑的。不管你是刚接触Computer Use的开发者，还是已经在做界面自动化、想搞清楚为什么模型总在"简单动作"上翻车的人，下面这些经验应该都能对上你的场景。

1. 莫拉维克悖论在Computer Use里的真实投影

1.1 为什么"点按钮"比"写代码"更难

先把这个悖论讲透。人类进化了几亿年，才把抓握、定位、判断距离这些感知运动能力打磨成本能，大脑里为这些能力预留的算力是海量的，只是我们自己感觉不到。而抽象推理、符号运算这些能力，人类是近几千年才发展出来的，用到的脑区相对"新"，反而没那么耗本能资源。机器正好反过来：符号运算、逻辑推理是它的主场，因为它本质就是靠精确的符号处理起家的；而感知和运动控制，需要处理的是连续、高维、充满噪声的物理世界信号，这才是真正的硬骨头。

放到Computer Use上，这个反差特别明显。模型读一段JSON、理解一个业务状态机、生成一段SQL，这些是离散符号操作，天然契合它的能力结构。但"看着屏幕截图，找到那个'提交'按钮，把鼠标移过去点一下"，这里面包含了一连串它不擅长的事：从像素里识别出哪个区域是按钮、判断按钮的边界、理解当前界面处于什么状态、预测点击后会发生什么。每一步对人类都是下意识的，对模型却是一堆需要显式建模的难题。

我在项目里做过一个粗略的对比统计，同一个模型，处理纯文本的逻辑任务，成功率能到九成以上；但换成需要看截图定位控件的操作任务，成功率直接掉到六成左右，而且失败的案例里，绝大多数不是"想错了"，而是"看错了"或"点偏了"。这个数据不一定普适，但它很直观地说明了悖论的存在。

1.2 感知层的脆弱性：截图里藏着多少陷阱

Computer Use最主流的交互方式就是"看截图、做动作"，这个范式本身就踩在悖论的痛点上。截图是一个二维像素矩阵，模型要从里面提取出结构化的界面语义，这中间的信息损失和歧义非常多。

举个我踩过的坑：一个表单页面，两个按钮挨得很近，一个是"保存草稿"，一个是"提交审核"，视觉上只有文字差异，位置几乎并排。模型在截图里识别出了两个按钮区域，但因为分辨率压缩和文字渲染的细微差别，它把两个按钮的语义搞反了，结果点成了"提交审核"。对人类来说，扫一眼文字就分得清，对模型来说，这需要在低分辨率图像里做精确的OCR加语义匹配，任何一环出问题都会导致误操作。

还有一类更隐蔽的陷阱：动态加载。页面刚打开时按钮是灰的（禁用态），等某个异步请求回来才变亮。模型如果在这一瞬间截图，看到的是灰色按钮，它可能判断"当前不可操作"而卡住，或者更糟，它没意识到灰色代表禁用，直接去点，然后困惑于为什么没反应。这类状态时序问题，人类靠经验能预判，模型却需要显式地被告知"等某个条件满足再操作"。

1.3 动作层的精度问题：坐标、滚动与焦点

就算模型正确识别了目标，动作执行这一层还有一堆坑。最典型的是坐标定位。模型输出的往往是一个相对坐标或归一化坐标，要映射到实际屏幕分辨率上，这中间的换算误差、截图缩放比例、多显示器偏移，任何一个没对齐，点击就会偏。

我遇到过一次很典型的问题：在高分屏上，系统缩放是150%，截图是按物理像素截的，但模型拿到的坐标是按逻辑像素理解的，两者差了1.5倍，结果所有点击都往左上角偏。排查了半天才发现是缩放系数没统一。这种问题在纯文本任务里根本不存在，但在Computer Use里是家常便饭。

滚动也是个大坑。模型要"看到"页面下方的元素，得先滚动，但滚动多少？滚一屏还是滚到某个元素可见？滚动之后焦点在哪？这些对人类是肌肉记忆，对模型是需要精确计算的。滚多了元素跑出视野，滚少了没露出来，而且滚动本身可能触发懒加载，改变页面结构，形成连锁反应。

2. 拆解悖论背后的机制：符号与感知的算力错配

2.1 离散符号处理为何是模型的主场

要理解这个悖论，得先明白模型擅长什么。当前这类模型的核心能力建立在token序列的预测上，token是离散的符号单元。文本、代码、结构化数据，天然就是离散符号的序列，模型处理起来如鱼得水。它能在长上下文里维持逻辑一致性，能做多步推理，能精确匹配模式，这些都是符号层面的操作。

Computer Use里那些"高阶"部分，比如理解一个复杂的操作流程、根据当前页面状态推断下一步该做什么、处理异常分支，本质上都是符号推理。模型在这些环节表现好，是因为它把界面理解成了一个状态机，用语言和逻辑去推演，而不是真的在"看"。

这也解释了一个现象：如果你把界面信息用结构化的方式喂给模型，比如直接给它一个可访问性树（accessibility tree）或者DOM结构，它的操作准确率会显著提升。因为它不用再从像素里猜结构了，直接拿到了符号化的界面描述，回到了它的主场。

2.2 连续感知信号的天然难点

反过来，像素、坐标、时序这些是连续信号，模型处理它们的方式是把它们离散化、token化，这个过程中信息损失不可避免。一张1920x1080的截图，压缩成模型能处理的输入，分辨率往往要降，文字变模糊，小图标糊成一团。模型要在这种降质信息上做精确判断，难度陡增。

更麻烦的是，感知任务往往没有明确的"正确答案"边界。文本任务里，一个变量名对不对是明确的；但"这个按钮的边界在哪"、"这个图标代表什么功能"，存在大量模糊地带。模型在这种模糊性面前，容易产生看似合理实则错误的判断，而且它自己往往意识不到错了。

我在项目里总结出一条经验：凡是需要模型"从像素里精确提取信息"的环节，都要尽量用其他手段替代或增强。比如能用DOM就不用截图，能用可访问性标签就不用视觉识别，能给出明确的元素选择器就不让模型自己找。这不是偷懒，是顺应模型的能力结构，避开它的短板。

2.3 反馈闭环的缺失放大了误差

人类操作计算机时，有一个强大的实时反馈闭环：眼睛看着屏幕，手在动，随时根据视觉反馈微调。点偏了立刻能看到，马上修正。模型做Computer Use时，这个闭环是断裂的或者延迟的。它执行一个动作后，需要重新截图、重新理解，才能知道结果，这个循环慢且容易累积误差。

而且模型对"动作是否成功"的判断本身就不牢靠。它点了一个按钮，页面没变化，它可能以为成功了，也可能以为失败了，缺乏人类那种"我感觉点到了"的即时体感。这种反馈缺失，让小的感知误差容易滚雪球，最终导致整个流程跑偏。

3. 我在项目里绕开这些坑的具体做法

3.1 优先走结构化通道，把视觉识别当兜底

这是我最核心的一条实践原则。只要目标系统提供了结构化的界面描述通道，就优先用它，把纯视觉识别放到兜底位置。具体来说，如果操作的是网页，优先拿DOM或可访问性树；如果是桌面应用，看有没有暴露可访问性接口；实在没有，才退回截图识别。

这么做的好处很直接：模型拿到的是符号化的界面结构，元素有明确的角色、名称、状态，它不用再从像素里猜。我在一个后台管理系统的自动化项目里做过对比，纯截图方案的任务成功率大概六成出头，换成可访问性树为主、截图兜底的混合方案后，成功率提到了八成五以上，而且失败案例的可诊断性大大增强，因为能明确看到是哪个元素的哪个属性没对上。

当然，结构化通道不是万能的，有些自绘控件、Canvas渲染的界面拿不到结构信息，这时候还是得靠视觉。所以我的做法是分层：结构化优先，视觉兜底，两层都失败才报错并记录现场。

3.2 给动作加"确认步"，别让模型盲点

针对反馈闭环缺失的问题，我的做法是给关键动作强制加确认步。模型执行一个点击或输入后，不直接进入下一步，而是先做一次轻量的状态校验：截图或读结构，确认目标状态确实变了，再继续。

这个确认步看起来增加了开销，但实际收益很大。它把"盲操作"变成了"有反馈的操作"，误差不会无声地累积。具体实现上，我会为每个关键动作定义一个预期状态，比如"点击提交后，应该出现成功提示或页面跳转"，模型执行后去校验这个预期，对不上就重试或报错。

这里有个细节要注意：确认步本身也要设计得轻，不能每次都全量截图加全量理解，那样太慢。我的做法是只校验关键区域，比如只看页面顶部有没有出现提示条，或者只看某个特定元素的状态属性。这样既保证了反馈，又不至于拖垮整体速度。

3.3 坐标问题用相对定位和元素锚点解决

坐标偏移这个坑，我最终的解法是尽量不用绝对坐标，改用相对定位和元素锚点。具体来说，让模型输出的不是"点击(500, 300)"，而是"点击名称为'提交'的按钮"，由执行层去解析这个语义，找到实际元素再计算坐标。

如果必须用坐标，比如视觉兜底场景，那就要做好坐标系的统一。我的做法是在截图时记录当前的缩放比例、显示器偏移、窗口位置，把这些元信息和截图一起给模型，让它输出的坐标能正确映射回物理屏幕。同时，点击前做一次小范围的位置校验，比如在目标坐标附近采样，确认那里确实是预期的元素，再点。

还有一个实用技巧：点击时不要只点一个像素点，而是点元素区域的中心，并且留一点容错余量。如果元素识别有轻微偏差，点中心比点边缘更容易命中。

3.4 时序问题靠显式等待和状态轮询

动态加载、异步状态这些时序坑，解法是显式等待加状态轮询。不要让模型"看到什么就操作什么"，而是让它先等待某个条件满足，再操作。

具体做法是，为每个操作定义一个前置条件，比如"等待'提交'按钮变为可点击状态"，然后执行层轮询这个条件，满足后再让模型操作。轮询要有超时和重试上限，避免死等。这个思路其实就是把人类操作时的"等一下，等它加载出来"显式化了。

我在一个涉及大量异步请求的系统里用过这套，效果很明显。之前模型经常在页面还没加载完就操作，导致各种莫名其妙的失败；加上显式等待后，这类失败基本消失了。代价是整体流程变慢了一点，但稳定性提升带来的收益远大于这点延迟。

4. 从悖论出发的能力边界认知与方案取舍

4.1 哪些任务适合交给Computer Use，哪些不适合

理解了莫拉维克悖论，就能更清醒地判断任务边界。我的经验是，判断一个任务适不适合用Computer Use，看它落在"符号推理"和"感知运动"这条轴上的哪个位置。

偏符号推理的任务，比如根据规则填写表单、按流程走审批、处理结构化的数据录入，这些适合交给模型，因为它主要在做逻辑判断和状态推演。偏感知运动的任务，比如在复杂图形界面里精确拖拽、在密集的图标里找特定控件、处理高度动态的可视化界面，这些要谨慎，因为踩在模型的短板上。

还有一类任务，表面看是操作，实质是推理，比如"根据当前页面信息判断该走哪个分支"，这种其实很适合，因为核心难点在推理不在操作。反过来，表面看是推理，实质是感知，比如"看看这个图表说明了什么"，这种就要小心，因为模型得先从像素里准确读出数据。

4.2 混合方案：让模型做决策，让确定性代码做执行

基于上面的认知，我越来越倾向于混合方案：让模型负责"想"，让确定性代码负责"做"。模型输出的是结构化的操作意图，比如"点击名称为X的按钮"、"在字段Y输入Z"，由一段确定性的执行代码去落实这些意图，处理坐标、等待、重试这些脏活。

这样分工的好处是，把模型放在它擅长的符号决策层，把感知和执行的精度问题交给传统代码去解决。传统代码在处理坐标映射、元素定位、状态轮询这些事上，比模型可靠得多，而且行为可预测、可调试。

我在几个项目里都用了这个架构，整体稳定性比让模型端到端操作高出一大截。模型偶尔会输出错误的意图，但执行层能通过元素校验发现并拒绝，不会造成误操作；而执行层的确定性保证了同样的意图总能得到同样的结果，便于复现和排查。

4.3 评测要分层，别用总分掩盖短板

最后说个评测上的经验。因为悖论的存在，模型在Computer Use上的能力是分层的，感知层、决策层、执行层各有各的表现。如果只用一个总分来评，很容易掩盖短板。

我的做法是分层评测：单独测感知准确率（能不能正确识别界面元素和状态）、单独测决策正确率（给定正确感知，能不能选对动作）、单独测执行成功率（给定正确动作，能不能准确落实）。三层分开看，才能定位问题到底出在哪。

实测下来，很多模型决策层很强，感知层是瓶颈。这意味着优化方向应该是增强感知输入（结构化通道、更高分辨率、更明确的元素标注），而不是一味换更强的模型。搞清楚瓶颈在哪，投入才有效率。

这套分层评测的思路，其实也是莫拉维克悖论给我们的启示：不要假设模型的能力是均匀的，它在符号和感知上的表现差异巨大，只有分开度量，才能扬长避短，把Computer Use用在刀刃上。