1
Prompting：先把任务交代清楚
任务要具体，不要只说“修一下”
说明目标、影响范围和期望结果，让 Codex 知道什么算完成。
主动给上下文和约束
给文件、路径、报错、示例输入输出、风格、性能和兼容性要求。
提前定义完成标准
说明要运行哪些检查、文档是否更新、手动验收看什么。
复杂任务先分析再执行
先让它拆解方案、风险和文件范围，再进入实现。
Codex 使用手册
如何把 Codex 真正用进日常开发流程，而不是只让它回答零散问题。
Codex 最擅长的不是单句问答，而是在明确目标、上下文、约束和验收标准后，协助完成真实工程任务。一个好的使用方式，应该让它先理解、再计划、再修改、最后验证。
2
一个好 Prompt 应该包含什么
要做什么用一两句话说明目标和最终结果。
相关文件、路径、报错、示例提供入口文件、日志、错误信息、输入输出样例。
限制条件哪些不能改、需要保持哪些风格、性能和兼容性。
Definition of done功能、质量、文档、测试或人工验收标准。
验证步骤例如 lint、tests、build、截图检查或手动检查路径。
3
Customization：让 Codex 贴合团队方式
AGENTS.md项目规则、运行命令、review 要求、目录说明。
Memories从过往工作中保留下来的偏好、背景和稳定约定。
Skills把可重复流程做成能力包，包含说明、脚本、参考资料和资产。
MCP连接外部工具和共享系统，让 Codex 读取更广的工作上下文。
Subagents把探索、测试、日志排查、文档更新等任务拆给专门线程。
这些层不是互相替代，而是互相配合：规则写进 AGENTS.md，稳定流程沉淀为 Skill，外部系统通过 MCP 接入，复杂任务再用 Subagents 并行。
4
AGENTS.md：最先建立的规则层
- 会跟随仓库存在，在 Codex 开始工作前生效。
- 适合写构建、测试命令、代码风格、目录边界和 review 标准。
- 当同类反馈反复出现、文件经常读错、PR 反馈超过一次时，就应该更新。
- 它不是百科，而是让团队规则自动进入上下文的入口。
仓库规则
当前目录
任务上下文
执行与验证
5
Workflows：日常开发怎么用
IDE
适合小范围修改、理解代码、重构和快速迭代。优势是上下文贴近当前打开文件。
局部修改 / 代码理解 / 轻重构
CLI
适合脚本化、批量任务、CI 检查、重定向和工具链集成。
批处理 / 自动化 / 命令链
Cloud
适合长任务、大规模分析、跨仓协作和需要隔离执行环境的任务。
长任务 / 大上下文 / 团队协作01Explain a codebase
说明入口、模块关系、调用链和风险点。
02Fix a bug / Write a test
给复现路径、预期行为和边界条件，最后运行检查。
03Plan a refactor
先做现状分析、阶段划分、影响评估，再逐步执行。
04Code review
从 bug、回归、测试缺口、可维护性角度检查。
05Update documentation
根据代码变化更新 README、使用说明和变更记录。
06Finish a branch
检查 diff、运行验证、总结风险，再提交或准备 PR。
通用任务模板
目标 → 上下文 → 约束 → 验证 → 小结
6
进阶专题：按需进入，不必一次读完
7
快速清单：一个好的 Codex 任务应该具备
01明确目标清楚说明要做什么和期望结果。
02提供上下文相关文件、路径、报错、示例和背景。
03说明约束范围、风格、兼容性、不能改的部分。
04定义完成标准功能、质量、文档、测试或验收标准。
05给出验证方式lint、tests、build、manual check。