Codex 用例

用例选择标准

Codex 适合的用例通常有三个特征：目标可以描述清楚，结果可以验证，失败可以回滚。越接近生产数据、支付、权限、部署或不可逆操作，越需要把任务拆小并提高审批强度。

• 代码理解：让 Codex 输出架构、调用链、关键文件、风险点，适合新项目入门。
• Bug 修复：给错误日志、复现步骤、期望行为，要求先定位根因再改。
• 测试补齐：让 Codex 根据现有测试框架补回归用例和边界条件。
• 重构迁移：要求行为不变、分阶段提交、每步验证，不要一次性大改。
• PR 审查：让 Codex 按严重程度列风险，重点看回归、安全、数据边界和测试缺口。
• 发布准备：检查构建、链接、SEO、权限、环境变量、回滚说明。

不适合直接交给 Codex 的任务包括无验收标准的大型产品判断、未隔离环境里的生产写入、需要账号授权且边界不清的跨系统操作，以及没有回滚方案的数据迁移。

学习检查清单

读完本页后，不要只记住概念名。你应该能把“Codex 用例”放回 Codex 的真实工程流程里：任务从哪里发起，系统会加载什么上下文，哪些动作需要审批，结果如何验证，失败时如何回退。

如果这是概念页面，要特别确认它如何影响真实任务：它改变上下文、权限、执行路径、验证方式，还是改变团队协作流程。

• 能用自己的话说明本页解决的具体问题，而不是只复述标题。
• 能写出一个最小示例任务，并标明目标、范围、禁止事项和验收标准。
• 能判断哪些信息应该放进当前提示，哪些应该沉淀到项目规则或配置里。
• 能说明哪些长期规则应该写进 AGENTS.md，哪些运行行为应该交给 config.toml、permission profile、skills 和 MCP。
• 能在任务完成后检查 diff、命令输出、测试结果、截图或 PR 说明，而不是只相信自然语言总结。

如果要把本页用于团队培训，可以让学员用 Codex 完成一个小任务：先只读解释，再提交计划，再执行最小改动，最后用真实验证命令和人工 diff 审查收尾。

Codex 实操注意事项

这一页属于 Codex 的核心概念。学习时要把概念和真实执行联系起来：它会改变上下文、权限、任务拆分、验证路径，还是改变团队协作方式。

处理“Codex 用例”相关任务时，建议始终先确认当前 Git 状态和工作目录。Codex 可以很快完成修改，但它不会自动知道哪些未提交改动来自用户、哪些文件不能碰、哪些命令会影响生产环境。

• 本地任务优先使用低风险分支或工作树，完成后用 git diff 审查。
• 涉及安装依赖、联网、数据库、部署、push、删除、reset 时，先要求 Codex 解释影响再批准。
• 远程或协作入口生成的结果，也要回到 PR、CI、构建日志和测试证据中确认。
• 自动化任务要提前定义失败输出和退出条件，避免 Codex 在错误方向上反复尝试。

把 Codex 当成能执行命令的工程队友，而不是只会写文本的助手。越靠近真实系统，越需要明确边界、证据和回滚。