Codex 替你填表？我花两小时测了「多步骤表单」，结论比你想的更复杂
Codex 替你填表？我花两小时测了「多步骤表单」，结论比你想的更复杂
Codex 能帮你写代码这件事你已经知道了。
但它能不能替你填表？我花了两个小时测试，结论比我预期的更复杂。
不是"能"，也不是"不能"——是"要看情况，而且情况比官网说的更苛刻"。
市面上关于 Codex 的评测，九成以上停在代码生成层面：写个函数、重构一段逻辑、补全单元测试。这些我都见过，写得也不错。但 Codex 还有一个被低调提及的能力——computer use，也就是直接操控电脑界面、执行 GUI 任务。
这个能力在中文圈几乎没有系统性的场景测试。所以我自己做了一个。
---
为什么选「多步骤表单填写」作为测试场景
选这个场景不是随机的。
多步骤表单是日常效率任务里最能暴露 AI 操控能力边界的类型之一，因为它同时考验四个维度：
- 视觉识别：能不能准确定位到目标输入框、按钮、下拉菜单
- 元素定位：在动态渲染的界面上，能不能找到"当前可交互"的元素
- 状态跟踪：填到第三步时，还记不记得第一步填了什么
- 异常处理：填错一个字段，能不能自己发现并回退修正
单纯的代码任务不需要这四项。但表单填写，一个都不能少。
我设计的测试表单包含：文本输入框（姓名、邮箱）、下拉菜单（国家/地区选择，JavaScript 动态渲染）、日期选择器（弹出式日历控件）、文件上传（本地图片）、分页提交（共三步，每步有验证逻辑）。
测试环境：MacBook Pro M3，macOS Sonoma，Chrome 最新版，Codex API 通过 computer use 模式调用。
---
任务过程实录：它在第几步卡住的
第一步：文本输入（顺利）
Codex 接到任务指令后，首先截取当前屏幕，识别出表单结构。
[action] screenshot
[observe] Detected form with 5 fields on current viewport
[action] click(x=412, y=238) // 姓名输入框
[action] type("张伟")
[action] click(x=412, y=312) // 邮箱输入框
[action] type("[email protected]")
这一步干净利落，定位精度比我预期高。它没有点错位置，文字输入也没有出现乱码或截断。
耗时：约 23 秒（人工完成同步骤：约 8 秒）第二步：下拉菜单（首次翻车）
国家选择是一个 JavaScript 渲染的自定义下拉组件，不是原生 标签。
Codex 点击了下拉触发区域，下拉列表展开。但接下来出问题了：
[action] click(x=412, y=398) // 下拉触发区
[observe] Dropdown opened, 195 options visible
[action] click(x=412, y=520) // 尝试点击"中国"
[observe] Dropdown closed, selected value: "智利" // ← 选错了
[action] click(x=412, y=398) // 重新打开
[observe] Dropdown opened
[action] click(x=412, y=518) // 再次尝试
[observe] Dropdown closed, selected value: "中非共和国" // ← 还是错
[action] click(x=412, y=398) // 第三次
...
它陷入了循环重试。原因很清楚：这个下拉列表在展开时会触发一次滚动动画，导致选项的 Y 坐标在动画结束前和结束后不一致。Codex 在动画未完成时就执行了点击，坐标偏移了几个像素，每次都选到了相邻的错误选项。
这个循环持续了将近 4 分钟，最终我手动介入中止了它。第三步：日期选择器（磕磕绊绊但过了）
日期选择器是弹出式日历控件。Codex 点击输入框后，日历弹出，它识别出了年月切换按钮，依次点击到目标月份，再点击目标日期。
这一步有两次小失误：第一次点击月份切换时多点了一次，跳过了目标月份，它自己发现后回退了一个月。这个自我纠错的能力让我有点意外——后面会单独说。
耗时：约 67 秒（人工：约 12 秒）第四步：文件上传（意外顺利）
调用系统文件选择对话框，Codex 通过键盘输入路径的方式绕过了 GUI 文件浏览，直接在路径栏输入文件路径后确认。这是一个聪明的策略，避开了复杂的文件树导航。
耗时：约 31 秒（人工：约 10 秒）第五步：分页提交（基本正常）
点击"下一步"按钮，等待页面验证，继续填写第二页。Codex 在等待页面加载时有明显的"等待确认"行为——它会截图确认当前状态再继续，而不是盲目执行下一个动作。这个设计是对的。
---
3 个真实感受，不掺水
感受一：识别准，但"手感"慢，慢到让人焦虑
视觉定位的精度超出我的预期。在静态界面上，Codex 几乎没有点错过位置。它识别表单结构的方式不是靠 DOM 解析，而是纯视觉截图分析——这意味着即使是自定义样式的组件，它也能大致找到。
但操作延迟是真实的痛点。
| 操作步骤 | Codex 耗时 | 人工耗时 | 倍率 | | 文本输入（2个字段）| 23秒 | 8秒 | 2.9x | | 日期选择器 | 67秒 | 12秒 | 5.6x | | 文件上传 | 31秒 | 10秒 | 3.1x | | 分页提交（含等待）| 44秒 | 15秒 | 2.9x |整体下来，Codex 完成这个表单（不含下拉卡死的时间）约需 3.5 分钟，人工约需 50 秒。
如果你的任务是"批量处理 200 份表单，不在乎时间"，这个速度可以接受。如果是"我现在要赶紧提交一个申请"，那还是自己填更快。
结论：Codex 的 computer use 不是效率工具，是解放双手的工具——这两者不一样。
感受二：遇到动态加载，直接失智
这是当前最硬的天花板，没有之一。
JavaScript 渲染的动态组件——自定义下拉、懒加载列表、动画过渡——会让 Codex 陷入坐标偏移的死循环。根本原因在于：它的操作是基于截图坐标的，而动态渲染会在操作执行的瞬间改变元素位置。
这不是 Codex 特有的问题，是所有基于视觉坐标操控的 AI 的共同软肋。但在 2025 年，绝大多数 Web 表单都有动态组件。这意味着"能不能用"这个问题的答案，高度依赖于你面对的具体表单的技术实现。
原生 HTML 控件（、）？Codex 应付得来。
React/Vue 自定义组件、带动画的 UI 库？大概率卡住。
感受三：错误恢复能力比想象中强——这是真惊喜
这是整个测试里最让我意外的部分。
在日期选择器那一步，Codex 多点了一次月份切换按钮，跳过了目标月份。它没有继续往前走，而是：
[observe] Current month: 2026-04, target: 2026-03
[action] click(prev_month_button) // 主动回退
[observe] Current month: 2026-03
[action] click(x=287, y=445) // 点击目标日期
[observe] Date selected: 2026-03-15 ✓
它自己发现了偏差，自己修正了。
这说明 Codex 在执行过程中有持续的"状态验证"机制——每一步操作后都会截图确认结果是否符合预期，不符合则触发修正逻辑。这个能力在实际使用中非常关键，因为 GUI 操作本来就充满意外。
如果这个机制能覆盖更多异常类型（比如动态加载），Codex 的可用性会有质的提升。
---
能力边界画像：什么任务适合它，什么不适合
用一个简单的 2×2 矩阵来定位：
界面复杂度
低 ◄──────────► 高
│ │
状 高 │ ⚠️ 谨慎 │ ❌ 不适合
态 │ (登录态企业系统) │ (动态渲染+多状态)
依 │ │
赖 ├────────────────┤
程 │ │
度 低 │ ✅ 适合 │ ⚠️ 有条件
│ (静态表单/ │ (复杂静态界面,
│ 本地文件处理) │ 需要人工确认节点)
│ │
- ✅ 静态 HTML 表单：适合，定位准确，执行稳定
- ✅ 本地文件批处理：适合，路径输入策略有效规避 GUI 复杂度
- ⚠️ 动态渲染表单：有限适合，原生控件可以，自定义组件大概率卡住
- ❌ 需要登录态的企业系统：不适合，Session 管理和多因素认证是额外的坑
- ❌ 时间敏感的实时任务：不适合，延迟倍率太高
如果你想自己复现这个测试，或者把 Codex 的 computer use 能力接入你自己的工作流，需要一个稳定的 API 访问渠道。我目前用的是 [api.884819.xyz](https://api.884819.xyz)，支持 OpenAI 全系模型，按量计费，国内直连，没有月租——对于想在正式接入前先探探边界的人来说，测试成本比较可控。新用户注册即送体验 token，国产模型（Deepseek、通义千问 Qwen3 等）完全免费。
---
现在值得用吗？给不同读者的建议
小白用户：先观望
操作门槛不低。你需要理解 API 调用、处理 action log、在任务卡住时手动介入。如果你没有一定的技术背景，现在用 Codex computer use 的体验会让你沮丧多于惊喜。
等它再成熟六个月，会有更友好的封装工具出现。
开发者 / 效率极客：值得现在接入
踩坑红利期。现在研究清楚它的能力边界，等生态成熟时你已经有了一套可用的工作流模板。
建议从静态表单批处理开始，避开动态组件，先跑通一个真实场景，再逐步扩展。
企业采购决策者：不要用于生产流程
不是说它不好，是说它现在的稳定性不适合生产环境。动态组件的失败率太高，没有可靠的错误恢复机制（自我纠错能力还太初级），无法保证 SLA。
适合的场景是：内部工具原型验证。用它快速验证一个自动化流程的可行性，然后用传统 RPA 或定制脚本做生产实现。
---
它是一个正在学走路的助手。你得知道什么时候该扶它一把——扶对了，它能帮你省不少力气；扶错了地方，你会比自己做还累。
---
下一篇我在想：
>
Codex 的 computer use 和 Claude Sonnet 4.6 的 computer use，在完全相同的表单任务上，谁更靠谱？
>
Anthropic 在 computer use 上投入了相当多的工程资源，Claude 的视觉定位策略和 Codex 有明显的架构差异——这个横向对比很可能会有意外的结论。
>
我打算用这次完全相同的测试表单做对比，数据说话。如果你有特别想看的测试场景，评论区告诉我，高赞的我优先做。
---
本文由8848AI原创，转载请注明出处。关注8848AI，带你从零开始学AI。#AI测评 #Codex #ComputerUse #AI自动化 #效率工具 #8848AI #AI实测 #人工智能
