新同事第一天入职，你会不会只对他说一句：

把这个项目优化一下。

大概率不会。

你至少会告诉他：项目放在哪里、当前问题是什么、哪些文件不能动、如何启动服务、改完要跑什么测试。否则，再聪明的人也只能一边猜一边干，最后交出来的东西很可能是“代码确实变了，但问题没有解决”。

使用 Codex 也是一样。

Codex 不是一个只能补全下一行代码的输入法，而是一个能进入项目、阅读文件、修改代码、运行命令、检查结果并持续接受反馈的编程智能体。你可以把它理解成一位坐在工位旁边的项目搭档：它动手很快、不怕重复劳动，也愿意查完整个调用链；但它并不知道你脑子里的隐藏需求，更不应该在没有边界的情况下拿到整台电脑的“万能钥匙”。

这篇文章不准备罗列一堆菜单，而是从一个真实问题出发，讲清楚怎样把任务交给 Codex、怎样让它安全地动手，以及怎样判断它是不是真的把活干完了。

本文依据 2026 年 8 月 4 日获取的 OpenAI 官方 Codex 手册整理。Codex 更新较快，部分界面、实验功能和可用范围可能随版本、套餐或工作区策略变化。文中的本地命令使用 codex-cli 0.144.5 核对。

---

一、先认识 Codex：它和普通聊天机器人有什么区别

普通聊天机器人更像坐在会议室里的技术顾问。你把一段代码复制给它，它可以解释、建议或生成一份修改方案，但它通常看不到项目的其余部分，也不知道建议能不能编译。

Codex 更像真正进入了项目组的开发者。在你授权的工作区中，它可以完成一条更长的工作链：

1. 阅读目录、代码、配置和项目说明；
2. 搜索调用关系，定位问题可能出现的位置；
3. 修改一个或多个文件；
4. 运行格式化、编译、测试或静态检查；
5. 根据报错继续修正；
6. 汇总改了什么、如何验证、还剩什么风险。

图 1：Codex 的价值不只是生成代码，而是形成“理解—修改—验证—交付”的闭环。

两者最关键的区别不是“会不会写代码”，而是有没有形成完整闭环。

1.1 Codex 能做什么

常见任务包括：

• 解释陌生项目的请求链路；
• 根据复现步骤修复 Bug；
• 添加单元测试和回归测试；
• 完成小型功能或批量重构；
• 检查未提交的改动或某次提交；
• 根据截图实现页面；
• 更新 README、接口说明和迁移文档；
• 使用浏览器、插件或 MCP 查询项目外的信息；
• 把成熟流程包装成 Skill，或者设为定时任务。

1.2 Codex 不是什么

Codex 不是一个“按一下按钮就对所有事情负责”的全自动程序员。

它仍然可能：

• 在需求含糊时作出错误假设；
• 写出能够编译、但不符合业务规则的代码；
• 只修表面症状，没有找到真正根因；
• 因为缺少依赖、权限或网络而无法完成验证；
• 在大型改动中漏掉兼容性和上线风险。

所以最好的使用姿势不是“把责任丢给 AI”，而是把目标、边界和验收标准讲清楚，让 Codex 承担查找、实现和验证的重活，你负责业务判断和最终决定。

---

二、四种使用方式：就像给搭档安排不同的工位

Codex 可以出现在桌面 App、命令行、IDE 和云端环境中。它们不是谁淘汰谁，而是适合不同工作场景。

使用方式	像什么	适合的任务	主要特点
ChatGPT 桌面 App 中的 Codex	带项目看板的独立工位	跨文件任务、长时间协作、文档和浏览器操作	能围绕本地项目持续工作，方便查看任务和改动
Codex CLI	坐在终端旁的搭档	后端、脚本、服务器项目、批处理	离构建命令和日志最近，适合键盘工作流
Codex IDE 扩展	坐在编辑器旁的结对程序员	围绕当前文件、选中代码的小步修改	自动获得当前编辑器上下文，适合边看边改
Codex Cloud	独立的远程施工队	耗时重构、并行任务、隔离环境中的实现	在云端隔离环境执行，不占用本地工作区

图 2：四种入口是不同工位，选择离任务上下文和验收方式最近的一种。

官方手册给出的定位也很直接：桌面 App 适合项目、文件和长任务；CLI 面向终端与脚本；IDE 扩展贴近代码编辑；Cloud 用于把任务委托到隔离的云环境。Codex 使用入口说明

2.1 第一次使用 CLI

如果你习惯终端，可以按照官方 CLI 文档安装：

npm install -g @openai/codex

登录并检查状态：

codex login
codex login status

进入项目根目录后启动交互界面：

cd your-project
codex

也可以在启动时直接交任务：

codex "解释这个项目从 HTTP 路由到数据库的完整调用链"

Codex CLI 还提供非交互执行、代码审查、会话恢复和诊断等命令：

# 非交互执行，适合脚本或 CI
codex exec "运行单元测试并总结失败原因"

# 审查工作区中尚未提交的修改
codex review --uncommitted

# 恢复最近一次会话
codex resume --last

# 检查安装、配置、认证和运行环境
codex doctor

命令和参数会持续演进，使用前可以通过 codex --help 与官方 CLI 命令参考核对。

2.2 什么时候该换一个工位

一个简单判断方法是：

• 你正在盯着两三个文件改细节：用 IDE；
• 你主要和日志、测试、Git、容器打交道：用 CLI；
• 任务还涉及图片、文档、浏览器或较长协作：用桌面 App；
• 本地还有别的活，不想让大重构占住当前目录：考虑 Cloud 或独立 worktree。

不要纠结“哪一种最专业”。能让上下文最自然、验证最方便的入口，就是当前最合适的入口。

---

三、不会写提示词也能用，但这四件事最好说清楚

把 Codex 当新同事后，提示词就不再神秘了。一次靠谱的任务交接通常只需要四部分：

任务信息	对应问题	示例
Goal	最终要解决什么	修复重复扣库存的问题
Context	去哪里看、怎样复现	重点查看 order/，并附上错误日志
Constraints	哪些边界不能越过	不改变现有 API，不新增生产依赖
Done when	做到什么才算完成	新增回归测试，相关测试与 lint 全部通过

官方提示词指南也建议，大任务重点说明 Goal、Context、Output/结果形式和 Boundaries，而不是堆砌特殊语法。OpenAI：Prompting

3.1 一个含糊的任务

优化一下订单代码。

“优化”可能是提高性能、减少重复、改进结构，也可能只是让代码好看一点。Codex 必须猜，你也很难判断它是否完成。

3.2 一个可以直接开工的任务

修复订单服务在并发确认时可能重复扣减库存的问题。

上下文：
- 复现步骤在 docs/inventory-race.md
- 重点检查 internal/order 和 internal/inventory
- 参考现有事务测试的写法

约束：
- 不改变对外 HTTP API
- 不新增生产依赖
- 不顺手重构无关模块

完成标准：
- 先复现问题，再说明根因
- 实现最小修复
- 添加能覆盖该竞争条件的回归测试
- 运行相关测试和 go test -race
- 最后列出修改文件、验证结果和剩余风险

这段话没有什么“提示词黑魔法”，但它让 Codex 知道去哪找、什么不能碰、怎样证明自己完成了任务。

3.3 先说结果，不必遥控每一步

新手很容易把提示词写成二十条操作指令：先打开 A，再搜索 B，然后修改 C。问题是，你指定的路线可能本来就是错的。

如果过程不是硬性要求，优先告诉 Codex结果和边界，让它自己探索：

找出登录接口偶发返回 500 的根因并修复。先复现，保留现有响应结构，改完运行最小相关测试。

只有当某个过程关系到安全或业务规则时，才把它写成必须遵守的步骤。

---

四、复杂任务先别急着改：先让搭档画施工图

修一个拼写错误不需要开设计评审，但涉及数据库迁移、认证重构或跨服务修改时，直接动手很容易越改越大。

此时可以使用 Plan 模式，或者明确要求“先调查并给计划，未经确认不要修改文件”。官方手册说明，Plan 模式适合复杂、含糊或难以一次描述清楚的任务，可以先收集上下文、提出问题并形成实现方案。OpenAI：Codex 最佳实践

先不要修改代码。

调查支付回调目前的幂等实现，画出请求链路，找出重复入账的可能路径。
然后给出一份分步骤修改计划，计划中必须包含：
- 涉及的文件
- 数据兼容方式
- 测试方案
- 回滚方案
- 上线风险

一个好计划不是“第一步分析、第二步开发、第三步测试”这种套话，而是应该具体到：改哪个边界、数据如何流动、哪一项测试证明哪一个风险已经被覆盖。

4.1 什么时候不用计划

下面这些小任务通常可以直接做：

• 修改一个明确的文案；
• 给现有函数补一个边界测试；
• 按项目已有写法添加一个简单接口；
• 修复已经定位到具体行的空指针问题；
• 执行格式化或机械性重命名。

计划本身也有成本。任务越明确、改动越局部，就越应该让 Codex快速完成并验证。

---

五、权限和沙箱：门禁卡与临时审批不是一回事

让一个新同事进入公司，不代表直接把机房、财务系统和所有仓库的钥匙都交给他。

Codex 的本地安全机制可以用两个概念理解：

• Sandbox（沙箱）：门禁卡本身能打开哪些门；
• Approval（审批策略）：遇到门禁外的操作时，是否必须找你确认。

官方说明中，本地 Codex 默认通过操作系统级沙箱限制文件和网络访问，常见的 workspace-write 允许它在当前工作区读写，但网络访问和工作区外写入通常需要额外批准。OpenAI：Agent approvals & security

图 3：沙箱决定技术边界，审批决定跨越边界前是否必须停下来确认。

5.1 为什么安装依赖经常要确认

例如执行：

npm install

看起来只是一条普通命令，但它可能访问网络、下载并执行包的安装脚本、修改锁文件，甚至间接影响大量文件。因此 Codex 停下来告诉你“这条命令为什么需要网络、可能产生什么副作用”，不是卡住，而是在跨越原有安全边界。

5.2 审批时看什么

不要只看“允许/拒绝”两个按钮，先看清楚：

1. 操作目的是否与当前任务一致；
2. 命令会不会上传数据或访问陌生域名；
3. 会修改哪些目录；
4. 是只批准一次，还是以后同类命令都批准；
5. 有没有更窄的授权范围。

官方沙箱指南建议，遇到多种授权范围时，应选择足以完成任务的最小范围，并尽量把工作限制在当前项目或独立 worktree 中。OpenAI：Sandbox

5.3 不要为了省一次点击就开“全权限”

CLI 确实提供绕过审批和沙箱的高风险选项，但官方明确建议只在外部已经充分隔离的环境中使用。日常开发采用工作区可写、按需批准，通常已经能兼顾效率和安全。

简单说：

权限应该随着任务扩大，而不是随着 impatience（不耐烦）扩大。

---

六、AGENTS.md：给搭档一本不会丢的员工手册

如果你每次都要重复：用 pnpm、不要改生成文件、提交前跑测试、数据库字段必须写注释，那么这些内容就不应该永远留在聊天记录里。

AGENTS.md 是面向 Codex 的项目说明文件。Codex 会在开始工作前读取它，把里面的规则作为持久项目上下文。它特别适合记录：

• 项目目录和关键入口；
• 启动、测试、构建与 lint 命令；
• 编码约定和架构边界；
• 禁止修改的文件；
• PR 或代码审查要求；
• “完成”的判断标准。

一个够用的例子：

# AGENTS.md

## 项目说明

- `cmd/api` 是 HTTP 服务入口。
- `internal/domain` 不允许依赖 `internal/transport`。
- `generated/` 中的文件由脚本生成，不要手工修改。

## 常用命令

- 单元测试：`go test ./...`
- 数据竞争检查：`go test -race ./...`
- 静态检查：`go vet ./...`

## 修改约束

- 修改公开接口时同步更新 `docs/api.md`。
- 未经确认不要增加生产依赖。
- 不要在日志中输出 Token、Cookie 或完整手机号。

## 完成标准

- 相关测试通过。
- 新行为有回归测试。
- 最终说明修改范围、验证命令和剩余风险。

6.1 规则可以分层

官方规则是：Codex 会先读取全局说明，再从项目根目录一路读取到当前工作目录；越靠近当前目录的说明优先级越高。OpenAI：Custom instructions with AGENTS.md

例如：

~/.codex/AGENTS.md                 个人通用习惯
project/AGENTS.md                  整个项目规则
project/services/pay/AGENTS.md     支付服务规则

如果你在 services/pay 工作，支付服务的局部规则可以覆盖更上层的通用规则。

6.2 什么不该写进去

不要把下面这些内容塞进 AGENTS.md：

• 只对今天这个 Bug 有用的临时需求；
• 密码、Token、私钥等敏感信息；
• 上百条没人维护的空泛原则；
• 与项目实际命令不一致的过期说明；
• 本来应该由 lint、测试或 CI 强制执行的机械规则。

一本十页但过期的员工手册，不如一页准确的值班清单。

---

七、让 Codex 真正完成任务：一定要给它“验收动作”

“代码写完了”不等于“任务完成了”。

一个订单接口改完后，至少可能需要验证：

• 能否编译；
• 单元测试是否通过；
• 原 Bug 是否能够复现并确认消失；
• 是否破坏其他调用方；
• 是否出现数据竞争；
• 页面是否真的和截图一致；
• 文档中的命令和链接是否可用。

7.1 把验证写进完成标准

与其最后再问一句“测了吗”，不如开工时写清楚：

完成后运行：
- go test ./...
- go test -race ./...
- go vet ./...

如果某项无法执行，不要把它写成已通过；说明阻塞原因、已完成的替代检查和我需要做的下一步。

7.2 要求它复查自己的改动

测试覆盖的是已知行为，代码审查更容易发现遗漏和风险。可以追加：

在结束前审查本次 diff，重点检查：
- 是否修改了无关文件；
- 是否存在资源未释放；
- 错误路径是否遗漏；
- 测试是否真的覆盖修复点；
- 是否引入兼容性变化。

CLI 中还可以使用 /review 或 codex review 审查未提交修改、某个提交或相对基线分支的差异。OpenAI：Code review

7.3 失败结果也要诚实交付

好的 Codex 交付应该区分：

• 已运行并通过；
• 已运行但失败；
• 因环境原因未运行；
• 只做了静态检查或推断。

“我认为应该没问题”不能替代真实测试，“环境里没有数据库”也不能伪装成“集成测试通过”。

---

八、聊天过程中怎样纠偏：别等它盖完楼才说图纸错了

Codex 工作时，你仍然可以继续发消息。

官方手册把两种行为区分为：

• Steer：把新信息加入当前执行，用于立即改方向；
• Queue：把消息排到下一轮，等当前工作结束后再处理。

例如 Codex 正在排查支付问题，你突然确认“不允许改数据库结构”，这属于 Steer，应立即告诉它：

补充约束：本次不能新增或修改数据库字段，请在当前方案中排除迁移方案。

如果你只是想让它修完后再补一份上线说明，可以 Queue：

当前修复完成后，再补一份灰度发布和回滚清单。

8.1 好的负面反馈要具体

不要只说：

写得不行，重来。

更有效的说法是：

当前方案有两个问题：
1. 为了一个局部 Bug 改了公共接口，影响范围太大；
2. 测试只覆盖成功路径，没有复现并发重复扣减。

保留已完成的根因分析，撤回公共接口修改，改成最小补丁并补并发回归测试。

反馈越接近“可验证的差异”，Codex 越容易修正。

8.2 什么时候继续原聊天，什么时候新开

同一个问题的调查、修改、测试和复查，最好留在同一个聊天中，避免上下文断裂。

当工作真正分叉时再新开，例如：

• 当前聊天修后端 Bug，另一个聊天重新设计前端页面；
• 一个分支做方案 A，另一个分支实验方案 B；
• 原任务已经完成，现在开始一个完全独立的需求。

CLI 可以通过 /resume 恢复、/fork 分叉、/compact 压缩过长上下文，使用 /status 查看当前会话与工作区状态。OpenAI：CLI slash commands

---

九、Skill、Plugin 和 MCP 到底是什么：菜谱、工具箱和供应商

Codex 的扩展能力名词很多，用餐厅来类比就容易理解了。

图 4：Skill 负责方法，MCP 负责实时通道，Plugin 负责打包，Automation 负责时间。

9.1 Skill：一份标准菜谱

Skill 是一套可复用的工作流程。它告诉 Codex：什么情况下使用、先做什么、再做什么、输出应该长什么样，还可以附带脚本、模板和参考资料。

例如你每周都要根据 Git 记录生成发布说明，与其反复复制一大段提示词，不如把规则做成 Skill：

读取版本区间内的提交
→ 按功能、修复、破坏性变更分类
→ 忽略合并提交
→ 对照 issue 链接
→ 输出固定 Markdown 模板

官方建议，每个 Skill 聚焦一个清晰任务；当同一提示词反复使用，或者你总在纠正同一套步骤时，就值得做成 Skill。OpenAI：Build skills

9.2 MCP：连接外部系统的供应通道

MCP Server 为 Codex 提供实时数据和受控操作。例如：

• 从 GitHub 获取 PR 与 Issue；
• 从数据库读取表结构；
• 从监控系统查询错误；
• 从内部知识库获取最新规范；
• 调用业务系统创建或更新记录。

Skill 决定“怎样完成这道菜”，MCP 决定“从哪里拿到新鲜食材、允许做哪些操作”。

如果信息会频繁变化，或者动作必须通过真实系统完成，就更适合 MCP，而不是把旧数据长期粘贴在提示词里。OpenAI：Model Context Protocol

9.3 Plugin：打包好的整套工具箱

Plugin 可以把 Skill、Connector、MCP Server、Hook 等能力打包在一起，让用户安装后获得一整套工作流。

例如一个团队发布插件可能同时包含：

• 发布检查 Skill；
• 查询 CI 的 Connector；
• 创建发布单的 MCP 工具；
• 发布前执行检查的 Hook；
• 每周版本汇总的定时任务模板。

官方文档提醒，安装包含外部连接或 Hook 的插件时，要分别检查权限、认证方式和可能产生的副作用；安装后通常需要在新聊天或新 CLI 会话中使用新增能力。OpenAI：Plugins

9.4 Automation：每天准时来上班的值班员

当一个流程已经稳定，可以把它设为定时任务：每天检查 CI、每周汇总提交、定期扫描可能的 Bug。

这里有一个很实用的边界：

Skill 定义“怎么做”，Automation 定义“什么时候做”。

如果一个任务每次都需要你来回纠正，它还不适合自动执行。先把流程在普通聊天里跑顺，再做 Skill，最后才考虑定时。OpenAI：Scheduled tasks

---

十、五个可以直接复制的实战模板

10.1 快速读懂陌生项目

请先阅读这个项目，不要修改文件。

目标：让我理解一次 HTTP 请求从路由进入、经过业务层、访问数据库并返回响应的完整过程。

请输出：
1. 关键模块及职责；
2. 按顺序列出的请求链路；
3. 涉及的文件路径；
4. 数据在哪些位置被校验或转换；
5. 修改该链路时最容易踩的三个坑。

如果存在多个入口，请说明你选择分析哪一个以及原因。

10.2 修复能够复现的 Bug

Bug：用户连续点击保存时，页面提示成功，但刷新后数据偶尔恢复旧值。

复现步骤：
1. 启动项目：npm run dev
2. 打开 /settings
3. 连续修改并保存两次
4. 刷新页面

约束：
- 不改变后端 API 格式；
- 不新增依赖；
- 不改无关页面。

请先复现并说明根因，再实现最小修复，补充回归测试，最后运行相关测试和 lint。报告真实执行结果。

10.3 安全地完成重构

把认证模块拆分为 Token 解析、Session 加载和权限判断三个职责。

先进入计划阶段，不要立即修改：
- 列出当前依赖关系和循环依赖；
- 给出分阶段迁移方案；
- 保持公开 API 和用户可见行为不变；
- 每个阶段说明涉及文件、测试和回滚点。

等我确认计划后再实现第一阶段。

10.4 审查自己刚写完的代码

审查当前未提交改动，不要直接修改。

重点检查：
- 并发安全和资源释放；
- 错误路径与边界条件；
- 是否存在行为回归；
- 测试是否真正覆盖改动；
- 是否修改了无关文件。

按严重程度列出发现，每条包含文件、位置、影响和修复建议。没有发现也要说明检查范围和仍未覆盖的风险。

10.5 根据截图实现页面

根据附件截图实现设置页面。

技术约束：
- 使用项目现有 React、TypeScript 和样式方案；
- 优先复用已有组件；
- 不引入新的 UI 库；
- 同时适配桌面端和移动端。

截图没有表达的行为：
- 保存期间按钮禁用；
- 校验失败在字段下方提示；
- 支持键盘操作和可见焦点。

完成后启动开发服务器，告诉我访问路径，并检查页面是否存在控制台错误。

---

十一、最常见的十个误区

误区 1：提示词越长越专业

长不等于清楚。真正有用的是目标、关键上下文、边界和完成标准。

误区 2：给了仓库就不用提供复现步骤

复现步骤往往比“我怀疑是某个文件”更有价值。它让 Codex 能验证根因，而不是只按你的猜测改代码。

误区 3：先让它改，最后再要求测试

验证应该从开工时就进入完成标准，否则实现很容易围绕“看起来合理”而不是“可以证明”。

误区 4：批准网络访问就是批准所有操作

网络、文件范围、外部系统权限是不同边界。每次批准都应该对应具体目的和范围。

误区 5：为了不卡住，直接开启全部权限

默认沙箱是在降低意外修改和数据泄露风险。应优先批准最小必要动作，而不是取消所有护栏。

误区 6：Codex 说测试通过，就不看命令

最终交付应列出运行了哪些命令、结果是什么。高风险修改还需要人工审查业务语义。

误区 7：一条聊天承担整个项目的一切

聊天上下文无限膨胀后，早期临时信息会干扰当前任务。一个聊天最好对应一个连贯结果。

误区 8：每次重复规则，不维护 AGENTS.md

反复口头交代不仅浪费时间，还容易漏掉。稳定规则应该沉淀到项目说明或 Skill。

误区 9：定时任务可以把不稳定流程变稳定

自动化只会定期重复现有流程。如果普通执行还需要大量纠偏，定时运行只会稳定地产生问题。

误区 10：Codex 只能写代码

理解项目、复现问题、运行实验、代码审查、整理文档和解释风险，往往比生成代码本身更有价值。

---

十二、Codex 卡住时，按这张清单排查

12.1 它一直找错项目

检查当前工作目录和工作区范围：

pwd
git status
codex --cd /path/to/project

交任务时明确相关目录，必要时用 @文件路径 提供关键上下文。

12.2 它说没有权限

先判断操作是否确实需要越过工作区、访问网络或调用外部系统。需要时批准最小范围；不需要时，让它改用工作区内的临时目录或只读检查。

12.3 安装或登录异常

codex login status
codex doctor
codex --version

codex doctor 会检查安装、配置、认证、Git、运行时和会话等信息，适合在提交支持请求前生成诊断结果。

12.4 指令没有生效

检查：

• AGENTS.md 是否为空；
• 是否存在更高优先级的 AGENTS.override.md；
• 当前目录是否在预期项目中；
• 是否修改配置后没有启动新会话；
• 指令文件是否过大而被截断。

12.5 测试无法运行

不要急着扩大权限。先确认缺的是哪一层：

• 缺少本地依赖；
• 网络被沙箱禁用；
• 数据库或服务没有启动；
• 环境变量未配置；
• 当前系统不支持某项测试；
• 命令本身就是错的。

然后让 Codex说明：它准备执行什么、为什么需要额外权限、可能修改哪些内容。你再决定是否放行。

---

十三、总结：真正的诀窍是把“完成”说清楚

把 Codex 想成项目搭档后，很多问题就变简单了：

• Prompt 是任务单，重点是目标、上下文、边界和验收标准；
• Plan 是施工图，适合高风险或跨模块任务；
• Workspace 是它能工作的办公室；
• Sandbox 是门禁卡，Approval 是临时审批；
• AGENTS.md 是项目员工手册；
• 测试、lint 和代码审查是验收流程；
• Skill 是标准菜谱，MCP 是外部系统通道，Plugin 是整套工具箱；
• Automation 是按时上班的值班员；
• App、CLI、IDE 和 Cloud，只是为同一位搭档准备的不同工位。

最重要的一条不是“学会一套万能提示词”，而是：

不要只告诉 Codex 要做什么，还要告诉它什么不能破坏，以及拿什么证据证明任务已经完成。

当 Codex 能读到正确上下文、在清楚的边界中行动，并亲自运行验收动作时，它就不再只是一个代码生成器，而会真正成为可以协作、可以复查、也可以不断磨合的项目搭档。

---

参考资料

• OpenAI：Codex 与 ChatGPT 快速开始
• OpenAI：Codex 最佳实践
• OpenAI：Prompting
• OpenAI：Codex CLI
• OpenAI：CLI 命令参考
• OpenAI：Agent approvals & security
• OpenAI：Sandbox
• OpenAI：Custom instructions with AGENTS.md
• OpenAI：Code review
• OpenAI：Build skills
• OpenAI：Model Context Protocol
• OpenAI：Plugins
• OpenAI：Scheduled tasks

---

• 个人小游戏