Codex 能做什么和不能做什么：能力边界、使用条件与验证方法

难度：基础

类型：能力边界

这篇文章适合谁

这篇文章写给准备把真实任务交给 Codex 的读者。

前两篇已经解释了 Codex 是什么，以及 哪些人适合使用 Codex。接下来需要把能力边界讲清楚：它能执行哪些工作，完成这些工作需要什么条件，哪些判断仍然必须由人负责。

先说结论

Codex 可以理解项目、修改文件、运行命令、调用工具并检查结果。它能否完成某个具体任务，还取决于四件事：有没有足够的上下文、是否获得必要权限、当前环境能不能运行，以及有没有明确的验证方法。

“Codex 能修改代码”是一项能力。“这次代码修改正确”是一个需要证据的结论。

这两句话不能混在一起。

判断能力时要看四个条件

少了其中任何一项，任务都可能停在中间。

例如，Codex 可以阅读测试失败信息并修改相关代码。但如果依赖没有安装、测试环境无法启动，或者报错只出现在生产环境，它就无法在当前环境中证明问题已经解决。

Codex 能做什么

理解项目和查找信息

Codex 可以读取你允许访问的项目文件，分析目录结构、依赖、配置、源码、测试和文档。

常见任务包括：

• 说明项目解决什么问题，以及本地如何启动。
• 找到某个页面、接口或功能的主要入口。
• 追踪一个函数、配置项或数据结构在哪里被使用。
• 根据 README、依赖文件和代码整理技术栈。
• 比较当前实现与项目规则是否一致。

它的结论来自能够读取的内容。如果关键文档没有放进项目、代码由远程服务动态生成，或者真实逻辑在另一个仓库，回答就可能不完整。

修改代码和文件

在授权范围内，Codex 可以新增、编辑和删除文件。它适合处理范围明确的功能开发、Bug 修复、重构、文档和配置任务。

例如：

• 修改一个前端组件及其样式。
• 给现有接口增加参数校验。
• 修复能够稳定复现的错误。
• 补充单元测试和使用说明。
• 调整构建配置或自动化脚本。
• 批量修改格式一致的文件。

大范围修改需要更清楚的限制。没有说明哪些目录不能动、哪些接口必须保持兼容时，Codex 可能选择一个技术上可行、但不符合项目预期的方案。

运行命令和开发工具

Codex 可以在权限允许时执行终端命令，例如安装依赖、运行测试、构建项目、执行 Lint 和查看 Git 状态。

这类能力让它可以形成完整过程：先查找问题，再修改文件，随后运行检查。如果命令失败，它还可以根据输出继续排查。

命令能否执行取决于当前环境。缺少运行时、系统依赖、网络、账号或环境变量时，Codex 只能说明缺少什么，不能凭空补出真实环境。

调试问题和补充测试

当你能提供报错、日志、复现步骤或失败测试时，Codex 可以沿着代码路径查找原因，并提出修改。

它还可以：

• 把一个问题整理成稳定的复现步骤。
• 根据已有测试风格补充回归测试。
• 比较修改前后的错误信息。
• 检查边界条件和异常分支。
• 运行相关测试，确认原问题是否消失。

如果问题无法复现，正确做法是记录假设和未确认部分，而不是把最可能的猜测写成确定原因。

阅读差异和辅助代码审查

Codex 可以查看 Git diff、提交历史和 Pull Request 修改，寻找明显的逻辑错误、测试缺口、安全风险和维护问题。

代码审查适合用它做第一轮扫描，但不应该省略项目负责人或领域专家的判断。很多问题与业务规则、历史兼容和线上数据有关，这些信息未必存在于代码中。

使用浏览器、搜索和外部工具

根据使用入口和配置，Codex 可以使用浏览器、网络搜索、MCP、插件或其他集成读取外部信息并采取操作。

这些能力不是默认无限开放的。能否使用某个工具，取决于工具是否安装、是否完成认证、当前权限策略和组织要求。

Codex 不能做什么

“不能”有两种情况。一种是技术条件不具备，另一种是风险和责任不应该交给它。

不能读取没有提供或没有授权的数据

Codex 不会自动知道私人仓库、线上数据库、内部文档和第三方账号中的内容。需要访问这些信息时，必须先通过项目文件、授权连接或明确的工具配置提供上下文。

即使工具已经连接，也只能在授予的权限范围内操作。

不能保证生成的代码一定正确

Codex 可能误解需求、遗漏边界条件、使用不合适的 API，或者写出能够通过部分测试但仍有问题的代码。

代码看起来合理、命令返回成功、页面能够打开，这些都只是证据的一部分。最终还需要结合测试范围、实际业务和人工审查判断。

不能替你补全没有说出口的需求

如果任务只写“把登录功能优化一下”，Codex 无法确定你关注的是页面体验、登录速度、安全策略还是代码结构。

它可以根据代码提出建议，但不能替产品和业务负责人决定真正目标。需求越模糊，生成无关修改的概率越高。

不能在缺少环境时完成真实验证

没有数据库、浏览器、依赖、测试账号或线上日志时，Codex 无法复现依赖这些条件的问题。

它可以检查静态代码并给出推断，但需要明确写出验证范围。例如：“已通过代码检查和单元测试，尚未连接真实支付环境。”

不能绕过权限边界

OpenAI 官方文档把权限分为不同模式。权限决定 Codex 可以在什么范围内编辑文件、运行命令和使用网络，以及什么时候需要审批。

图片来源：OpenAI Permissions。

默认从需要审批的模式开始更合适。为了少点几次确认而直接开放全部权限，会扩大误删除、数据泄露和意外操作的影响范围。

权限扩大的是行动范围，不会让 Codex 的判断自动变得更准确。

不能承担最终责任

生产发布、数据库迁移、支付、安全、合规和客户数据处理都需要明确负责人。

Codex 可以帮助准备变更、执行检查和整理风险，但不能替团队承担业务后果。高风险操作应该有备份、审批、回滚方案和人工确认。

常见任务的能力边界

这张表里没有“完全自动、无需检查”的任务。任务越接近生产环境和重要数据，人工检查越不能省。

怎样判断 Codex 是否真的完成了任务

不要只看最后一句“已完成”。可以按下面的顺序检查。

查看它实际改了什么

• 查看 git status 和 git diff。
• 确认没有修改无关文件。
• 检查是否删除了原有逻辑、注释或配置。
• 注意新依赖、环境变量和权限变化。

查看它实际运行了什么

• 测试是否真的执行，而不是只建议你执行。
• 构建、Lint 和类型检查是否成功。
• 页面或接口是否在正确环境中验证。
• 命令是否只覆盖了部分模块。

查看还有什么没有验证

• 是否缺少真实账号、数据库或生产数据。
• 是否只测试了正常流程，没有覆盖异常情况。
• 是否存在跨平台、浏览器或版本差异。
• 是否有需要产品、设计、安全或业务人员确认的决定。

可靠的 Codex 结果会把这些限制写出来。只汇报成功、不说明检查范围的结果，需要继续追问。

一个更稳妥的任务写法

下面是一段真实任务写法，用来说明怎样把能力和验证条件放在一起。

请修复用户资料页在邮箱为空时出现的报错。

开始前先定位相关组件、接口和现有测试，不要修改其他页面。
请先复现问题，再进行最小范围修改。
完成后运行相关测试和类型检查，并告诉我：
1. 原因是什么；
2. 修改了哪些文件；
3. 运行了哪些检查；
4. 还有哪些情况没有验证。

这段任务没有要求 Codex“保证没有任何问题”，而是要求它提供可以检查的过程和证据。

什么时候应该先停下来

出现下面情况时，不要继续扩大权限或让 Codex 反复尝试。

• 它准备修改与任务无关的大量文件。
• 它无法解释修改原因，却建议直接发布。
• 测试持续失败，但它开始删除测试或降低检查标准。
• 它需要访问密钥、生产数据库或客户数据。
• 它把没有验证的推断写成确定结论。
• 你已经看不懂变化，也没有其他人可以审查。

此时应该缩小任务、恢复工作区，或者先补充环境和资料。

下一步学习

下一篇会比较 Chat、ChatGPT Work 和 Codex，帮助读者根据主要交付物选择入口。

准备实际操作的读者，可以进入 安装与首次使用；想先学会怎样描述任务，可以进入 核心概念与任务方法。

参考资料

• Codex Manual
• OpenAI Permissions
• OpenAI Prompting
• Agent approvals and security
• Sandbox
• Code review

具体能力会因使用入口、账号、项目配置、权限策略和功能成熟度而变化。