OpenAI 给 Codex 加了个新功能：看一遍就会 by Mofei
昨天看到 OpenAI 给 Codex 加了 Record & Replay，我第一反应是：这个功能很厉害。
它厉害的地方，不是“录下来再放一遍”这么简单。
真正有意思的是，你在电脑上完整做一次任务，Codex 会看你怎么点、怎么填、怎么切页面、怎么选文件。任务结束后，它会把这套操作整理成一个可以复用的 Skill。下次再遇到类似任务，你给它新的输入，它就能结合当前页面状态，按上次学到的流程继续往下做。
这就不太像传统意义上的录屏了。
录屏只是把画面保存下来。宏录制也只是更机械地重复“点这里、输这里、再点那里”。Record & Replay 更像是把一次人的示范变成一段可重放的工作流。
如果用工程一点的方式写，大概是这样：
示范一次 -> 记录操作轨迹 -> 推断稳定流程 -> 抽出可变参数 -> 生成 Skill -> 带着新输入重放
这一步把问题从“怎么写提示词”，换成了“怎么把操作路径留下来”。过去我们教 AI 做事，主要靠 Prompt。你要把目标写清楚，把上下文写清楚，把边界条件写清楚，最好还要补几条异常情况怎么处理。对于写代码、写文档、分析问题，这套方式还可以。很多事情你其实会做，但你说不清每一步为什么这么做。你知道入口藏在哪个菜单下面，知道某个下拉框不能用默认值，知道保存以后页面卡两秒不是失败，也知道某个字段虽然没标必填，但不填后面一定会出问题。这些东西写进文档很啰嗦，写进 Prompt 很脆弱，写成脚本又太重。Record & Replay 刚好卡在这个中间。官方演示用的是上传 YouTube 视频。这个例子选得挺准，因为上传视频就是一种很典型的重复 UI 流程：选视频文件、传缩略图、传字幕、填标题和描述、设置隐私选项。每次内容都不一样，但路径基本固定。如果只是手动做，这事不难。可如果你真想把它工程化，就没那么轻了。你要找 API，处理 OAuth，理解视频元数据，处理上传失败，还要维护脚本。很多时候算一圈下来，结论很现实：算了，我自己点吧。我看到这个功能时，想到的也不是 YouTube，而是工作里那些更碎的事情。比如创建一个同类型的 Jira issue。比如发一次内部 demo。比如发布前点开几个固定页面确认功能没坏。比如去后台更新一个配置，再顺手看一下 Dashboard。这些事情都不复杂，但每次都要占一点注意力。它们烦不到值得专门开一个工程任务，又重复到让人不甘心一直手动做。这类流程以前很尴尬。继续手动点，浪费时间；写脚本，成本偏高；写一个很长的 Prompt 让 AI 自己摸索，又不稳定。尤其是后台页面这种东西，你很难在 Prompt 里把每个按钮、每个等待状态、每个隐藏坑都描述清楚。Record & Replay 给了第四种方式：先别解释那么多，直接做一遍。这个顺序对我来说比较顺。因为很多内部流程本来就不是靠文档学会的，而是靠人带着点一遍。新同事入职时，你通常不会先给他一份后台 API 文档，而是打开页面边点边说：这里进去，这个别选默认，这里保存后等一下，这个弹窗直接确认。这些话看起来很碎，但它们其实就是流程里最容易丢的部分。写下来嫌啰嗦，写成脚本又不值得，最后就都留在人的记忆里。Record & Replay 比较有意思的地方，是它试图把这部分拿出来。不是把鼠标轨迹一格一格记住，而是从这次操作里整理出哪些步骤是固定的，哪些输入下次会变，哪里需要等页面响应，哪里需要确认结果。所以我不会一开始就把它当成正式自动化。更现实的用法是：先录一个小流程，跑几次看看。如果稳定，就让它继续用；如果总是卡住，那说明这个流程本来就需要脚本，或者需要人来判断。当然，我不会把它想得太万能。需要大量上下文判断的流程，不适合简单 replay；页面经常改版的系统，也很容易不稳定；涉及付款、删除数据、修改生产配置这种高风险操作，确认权最好还是留在人手里。所以我更愿意把它看成一种轻自动化入口，而不是正式自动化的替代品。稳定、高频、关键链路，该接 API 还是接 API，该进 CI 还是进 CI，该写测试还是写测试。Record & Replay 更适合先收那些重复、低风险、步骤固定、又懒得专门开发的小流程。我现在最想拿它试的，就是那些每次都会让我皱一下眉头的后台操作：创建同类工单，发内部预览，检查固定页面，更新一组配置。能稳定跑几次，再考虑扩大范围；如果中间总是要人介入，那就说明这个流程本来不适合 replay。以前这种事情通常就放着，反正手动点几下也能做。现在至少可以先录一次看看。
原文链接