ChatGPT、Codex教程：Record & Replay怎么把重复操作变成可复用Skill？

很多重复工作并不难，却非常消耗时间。

例如每周都要登录同一个后台、选择日期范围、下载错误报告、整理文件名称，再把结果提交到项目管理系统。整个流程可能只有十几步，但每一次都要重新操作。

以前想让Codex完成这类工作，通常需要写一段很长的提示词：

先打开哪个页面，再点击哪个菜单，日期怎么选择，文件保存到哪里，最后怎样判断任务成功。

只要页面结构、字段名称或操作顺序与提示词略有差异，Agent就可能执行失败。

Record & Replay提供了另一种思路：

不再只用文字描述流程，而是亲自演示一次，让ChatGPT或Codex根据操作过程生成可复用Skill。

它特别适合步骤比较稳定、经常重复，并且"演示起来比描述起来更简单"的工作。官方列出的典型场景包括提交报销、预订车位、创建规范Issue、发布视频和下载周期报告。

一、Record & Replay到底是什么？

Record & Replay可以记录你在Mac上完成一项工作的过程。

录制结束后，ChatGPT或Codex会检查这次演示，并生成一个可检查、可编辑的Skill。这个Skill会说明：

什么情况下应该使用；
每次运行需要哪些输入；
应该按照什么步骤执行；
怎样确认结果是否正确。

以后再次执行相同工作时，不需要重新描述所有步骤，只需调用这个Skill，并提供本次发生变化的参数，例如日期、文件、项目名称或Issue内容。

它不是传统意义上的屏幕录像。

普通录像只能让人重新观看；Record & Replay的目标，是从操作过程中提取出一套可以重复执行的方法。

二、哪些流程适合录制？

并不是所有电脑操作都适合立刻做成Skill。

比较合适的流程通常具有四个特点。

1. 经常重复

例如：

每周下载测试报告；
创建格式统一的Bug Issue；
整理CI失败信息；
发布版本说明；
更新固定格式的数据表；
在后台创建测试账号。

如果一个流程只执行一次，没有必要专门录制。

2. 操作步骤相对稳定

页面入口、字段名称和执行顺序不能每次都完全不同。

如果每次运行都需要大量临时判断，Skill仍然会依赖频繁人工指导。

3. 输入内容会变化，但流程不变

例如创建Issue时，项目、标题和错误信息会变化，但创建入口、标签规则和字段结构基本一致。

这类流程最适合参数化。

4. 成功结果容易判断

例如：

文件成功下载；
Issue成功创建；
表单出现提交成功提示；
报告保存到指定目录；
页面出现正确状态。

官方建议优先选择自己已经熟悉、步骤稳定且成功标准清晰的流程。

三、开始前需要准备什么？

Record & Replay当前通过macOS上的ChatGPT桌面应用使用，初始可用地区不包括欧洲经济区、英国和瑞士，同时需要Computer Use功能可用并已开启。

录制前建议先准备一张简单任务单：

复制代码

流程名称：
创建规范化Bug Issue

固定步骤：
1. 打开项目Issue页面
2. 选择Bug模板
3. 填写标题和复现步骤
4. 添加bug与priority标签
5. 指定所属项目
6. 检查内容
7. 提交Issue

每次变化的输入：
- 项目名称
- Bug标题
- 复现步骤
- 优先级
- 日志或截图

成功标准：
Issue创建成功，并包含正确模板、标签和项目。

提前分清"固定流程"和"动态输入"，生成的Skill会更容易复用。

四、怎样开始录制一个Skill？

官方提供的录制流程可以概括为七步。

第一步：进入支持录制的工作界面

打开ChatGPT桌面应用。

可以选择ChatGPT并开启Work，也可以直接进入Codex，然后打开Plugins。

第二步：打开新增菜单

点击"+"菜单，选择：

复制代码

Record a skill

第三步：检查建议提示词

系统会先根据当前上下文生成一段录制说明。

不要直接开始，可以补充：

这项工作解决什么问题；
哪些输入每次会变化；
哪些规则必须始终遵守；
最终成功状态是什么。

第四步：批准录制权限

当聊天请求录制操作时，确认已经准备好，再允许开始。

第五步：完整演示流程

像平时一样操作电脑，把任务从开始做到结束。

第六步：停止录制

流程完成后，通过菜单栏、录制浮层停止，也可以直接告诉聊天录制已经结束。

第七步：检查生成结果

停止录制后，ChatGPT或Codex会分析操作步骤并生成Skill草稿。你可以继续要求它修改触发条件、输入参数、验证步骤或人工确认点。

五、录制时最容易犯什么错误？

Record & Replay并不是录制时间越长，生成结果越完整。

错误一：把无关操作一起录进去

例如下载报告后，又顺手回复邮件、整理桌面和查看其他网页。

这些操作可能干扰系统对任务边界的判断。

正确做法是：

从正式流程开始录制，完成成功验证后立即停止。

错误二：使用真实密码或敏感数据

录制过程中应使用真实结构的测试数据，但不要主动展示密码、访问令牌、客户隐私或生产环境机密。

官方同样建议使用现实输入，但避免秘密和敏感信息。

错误三：没有说明隐藏规则

有些偏好无法从点击行为中直接看出来。

例如：

Issue标题必须以模块名开头；
高优先级问题必须添加负责人；
报告文件名必须包含日期；
发布前必须先保存草稿；
生产操作必须人工批准。

录制结束后，应把这些隐含规则补充到Skill中。

错误四：演示过程中反复试错

如果点错页面、重复填写或临时改变方案，最好停止并重新录制一遍更干净的流程。

Skill要学习的是推荐方法，不是你的整个排错过程。

六、实战：把"创建Bug Issue"录成Skill

假设团队每天都要把测试环境发现的问题创建为GitHub Issue。

首先告诉Codex本次录制目标：

复制代码

我要录制一个创建Bug Issue的流程。

每次运行会变化的内容包括：
项目名称、Bug标题、复现步骤、实际结果、预期结果和优先级。

固定要求：
必须使用Bug模板；
必须添加bug标签；
高优先级问题需要添加priority-high标签；
提交前必须让我确认；
创建完成后返回Issue编号和链接。

随后开始录制，并完成一次标准操作：

打开目标仓库；
进入Issues；
选择Bug模板；
填写标题；
填写复现步骤；
填写实际结果和预期结果；
添加标签；
指定项目；
检查预览；
确认后提交；
检查Issue是否创建成功。

录制结束后，不要立即投入日常使用。

先让Codex整理出以下内容：

复制代码

请检查刚生成的Skill，并明确列出：

1. Skill的适用场景；
2. 每次必须提供的输入；
3. 默认标签规则；
4. 提交前的人工确认点；
5. 成功验证方式；
6. 失败时应该停止的位置；
7. 不允许自动执行的操作。

这样可以把一次演示，转化成结构更加明确的工程流程。

七、生成的Skill应该检查哪些内容？

Skill本质上是一组可复用指令。

Codex的Skill通常以一个目录存在，其中至少包含SKILL.md，还可以附带脚本、参考文档、模板和其他资源。SKILL.md需要包含Skill名称、描述和执行说明。

重点检查五部分。

1. 名称是否清晰

例如：

复制代码

create-standard-bug-issue

不要使用my-skill、daily-work这类范围模糊的名称。

2. 描述是否说明触发条件

描述不仅要说它能做什么，还要说明什么时候使用、什么时候不使用。

例如：

复制代码

用于根据团队Bug模板创建GitHub Issue。
适用于已经提供复现步骤和预期结果的问题，
不用于功能需求、技术讨论或安全事件。

ChatGPT和Codex可以根据Skill描述自动判断是否调用，因此描述范围越清晰，误触发概率越低。

3. 输入是否参数化

不要把演示时使用的具体日期、项目和文件名写死。

应抽取为：

复制代码

project
title
reproduction_steps
expected_result
actual_result
priority
attachments

4. 是否包含验证步骤

例如创建Issue后，应重新读取页面并确认：

Issue编号存在；
标签正确；
内容没有缺失；
项目归属正确。

5. 是否保留人工确认

涉及发布、删除、付款、生产环境或对外提交时，Skill必须在关键操作前暂停。

八、怎样Replay刚生成的Skill？

生成后，可以开启一个新的ChatGPT或Codex聊天，明确调用该Skill，并提供本次不同的输入。

例如：

复制代码

使用create-standard-bug-issue Skill。

项目：mobile-app
标题：断网重连后消息重复显示
优先级：高

复现步骤：
1. 登录测试账号
2. 进入聊天页面
3. 关闭网络30秒
4. 恢复网络
5. 查看消息列表

实际结果：
最近两条消息重复显示。

预期结果：
恢复网络后，消息列表中不应出现重复内容。

提交前先展示完整草稿，等我确认后再创建Issue。

系统会把Skill作为可复用上下文，并结合当前环境中可用的Computer Use、浏览器操作和插件完成流程。

第一次Replay建议全程观察，不要直接完全放手。

重点看：

是否进入正确项目；
是否选择正确模板；
是否识别了动态输入；
是否保留人工确认；
是否正确验证最终结果。

九、Replay失败应该怎样排查？

找不到Record & Replay入口

首先检查：

是否使用macOS桌面应用；
应用是否为较新版本；
Computer Use是否已经开启；
当前地区或组织策略是否支持；
管理员是否通过requirements.toml关闭了computer_use。

组织配置中将computer_use设为false，也会让Record & Replay不可用。

Skill没有被自动调用

检查Skill描述是否过于宽泛，或者没有包含用户实际会说的触发词。

也可以先显式选择Skill。在ChatGPT中可以通过@选择；在Codex CLI或IDE扩展中，可以通过/skills或$引用Skill。

执行到一半找不到按钮

可能原因包括：

页面版本发生变化；
当前账号权限不同；
弹窗遮挡；
演示时依赖了固定屏幕状态；
Skill没有写明备用定位方式。

此时不要无限重试，应让Agent暂停并说明：

复制代码

停在当前页面，不要继续点击。
说明预期控件、实际页面和已经尝试的定位方式。

Skill总需要重复纠正

如果每次都要重新说明同一个规则，就把这条规则写入Skill，而不是继续依靠临时提示词。

官方建议：如果同一提示词被反复使用，或者同一流程总需要重复纠正，就应该将它整理为Skill。

十、Skill、Scheduled Task和Plugin怎么选？

这三个概念很容易混淆。

Skill：定义怎么做

Skill保存任务方法、输入、步骤和验证方式。

适合一个清晰、可复用的工作流程。

Scheduled Task：定义什么时候做

当Skill已经可以稳定执行后，可以再设置定时任务，让它每天、每周或按其他周期运行。

官方建议先手动测试流程。Skill负责方法，Scheduled Task负责执行时间；如果任务仍然需要大量人工纠正，就不应该急着定时运行。

Plugin：负责更完整的分发与集成

如果需要：

在团队中稳定分发；
打包多个Skill；
搭配连接器；
加入MCP服务；
管理安装信息和依赖；

就更适合把流程制作成Plugin，而不是只保留一个本地Skill。

可以记成一句话：

Record & Replay负责快速生成方法，Skill负责复用方法，Scheduled Task负责定时执行，Plugin负责完整分发。

十一、发布前检查清单

第一次把录制流程投入使用前，建议检查：

复制代码

□ 流程只解决一个明确任务
□ 演示完整但没有无关操作
□ 动态输入没有被写死
□ 没有记录密码和敏感信息
□ Skill描述包含明确触发条件
□ 高风险步骤保留人工确认
□ 成功结果具有验证方式
□ 失败时会暂停而不是无限重试
□ 已用第二组不同输入Replay
□ 已检查最终结果和副作用

只有第二组输入也能成功，才能证明Skill学到的是流程，而不是机械复现第一次操作。

结语

Record & Replay解决的并不是"怎样录制鼠标点击"，而是一个更实际的问题：

怎样把只有自己会做的重复操作，转化为ChatGPT和Codex可以稳定复用的工作方法？

正确流程应该是：

选择稳定的重复任务

→ 区分固定步骤和动态输入

→ 完整演示一次

→ 停止录制并生成Skill

→ 补充隐藏规则和人工确认点

→ 使用不同输入Replay

→ 验证稳定后再考虑定时执行

不要一开始就录制复杂、变化频繁的工作。

先从一个十步以内、成功标准明确的小流程开始。等Skill能够稳定执行，再逐步增加脚本、参考资料、插件和自动化。

演示一次并不难，真正有价值的是把这次演示整理成一套可以检查、修改、验证和长期复用的流程。