Codex / 概念
Codex 提示词
高质量提示词应该让 Codex 知道目标、边界、验收标准和收尾格式。
提示词结构
Codex 提示词应像工程任务卡：目标、上下文、范围、限制、验收、验证、输出格式。
目标：
上下文：
范围：
禁止：
验收标准：
验证命令：
输出格式：常用模式
不同任务用不同提示结构。修 bug 给复现，做 UI 给截图和断点，重构给不变行为，审查给严重程度排序。
| 任务 | 提示重点 |
|---|---|
| 修 bug | 错误日志、复现步骤、期望结果、最小修复。 |
| 做页面 | 设计约束、响应式、验收截图、交互状态。 |
| 重构 | 不可改变的行为、迁移步骤、测试覆盖。 |
| 审查 | 按风险排序，只列真实问题和修复建议。 |
避免什么
避免模糊目标、超大范围、没有验证命令、让 Codex 猜业务规则，或在未审查 diff 时直接提交。
完整使用要点
补充官方文档中容易被压缩遗漏的核心概念、操作顺序、权限边界和验证要求，方便中文学习者按页面完整学习。
提示词要像工程任务
Codex 提示词的质量直接决定执行稳定性。官方最佳实践强调让模型知道上下文和成功标准。一个好提示不是“帮我优化页面”，而是明确告诉它问题、范围、禁止项和验收方式。
- 目标：用户或系统应该发生什么变化。
- 上下文：相关页面、文件、错误日志、设计约束、工单链接。
- 范围：允许修改哪些模块，哪些模块不要碰。
- 验收：测试、构建、截图、浏览器流程或人工检查点。
- 输出：要求总结改动文件、验证结果、风险和下一步。
复杂任务可以分两段提示：第一段“先阅读并计划，不要改文件”；第二段在确认计划后允许修改。这样能提前暴露误解和越界风险。
学习检查清单
把本页内容落到真实任务中，用入口、上下文、权限、验证和团队规则五个维度检查是否真正掌握。
学习检查清单
读完本页后，不要只记住概念名。你应该能把“Codex 提示词”放回 Codex 的真实工程流程里：任务从哪里发起，系统会加载什么上下文，哪些动作需要审批，结果如何验证，失败时如何回退。
如果这是概念页面，要特别确认它如何影响真实任务：它改变上下文、权限、执行路径、验证方式，还是改变团队协作流程。
- 能用自己的话说明本页解决的具体问题，而不是只复述标题。
- 能写出一个最小示例任务，并标明目标、范围、禁止事项和验收标准。
- 能判断哪些信息应该放进当前提示，哪些应该沉淀到项目规则或配置里。
- 能说明哪些长期规则应该写进 AGENTS.md，哪些运行行为应该交给 config.toml、permission profile、skills 和 MCP。
- 能在任务完成后检查 diff、命令输出、测试结果、截图或 PR 说明，而不是只相信自然语言总结。
如果要把本页用于团队培训，可以让学员用 Codex 完成一个小任务：先只读解释，再提交计划，再执行最小改动，最后用真实验证命令和人工 diff 审查收尾。
Codex 实操注意事项
围绕本地环境、权限升级、远程入口、自动化失败和回滚补齐 Codex 使用中最容易被忽略的执行细节。
Codex 实操注意事项
这一页属于 Codex 的核心概念。学习时要把概念和真实执行联系起来：它会改变上下文、权限、任务拆分、验证路径，还是改变团队协作方式。
处理“Codex 提示词”相关任务时，建议始终先确认当前 Git 状态和工作目录。Codex 可以很快完成修改，但它不会自动知道哪些未提交改动来自用户、哪些文件不能碰、哪些命令会影响生产环境。
- 本地任务优先使用低风险分支或工作树，完成后用 git diff 审查。
- 涉及安装依赖、联网、数据库、部署、push、删除、reset 时，先要求 Codex 解释影响再批准。
- 远程或协作入口生成的结果，也要回到 PR、CI、构建日志和测试证据中确认。
- 自动化任务要提前定义失败输出和退出条件，避免 Codex 在错误方向上反复尝试。
把 Codex 当成能执行命令的工程队友，而不是只会写文本的助手。越靠近真实系统，越需要明确边界、证据和回滚。