老实说,很多人用AI编程Agent的方式都不太对——把它当一次性工具用,问一句答一句,然后反复修改提示词,搞得自己很累,输出质量也不稳定。OpenAI官方最近发了一篇Codex最佳实践,读完之后挺有收获,不是什么花哨技巧,都是经过验证的工作流和经验,用其他AI编程Agent其实也都适用。
核心思路其实一句话:别把Codex当一次性助手,要把它当能随时间成长的队友,通过持续配置让它越来越贴合你的工作方式。
写提示词这件事,没想象中那么复杂
Codex的基础能力已经够强,就算提示词不够完美,也能给出有用的结果。清晰的提示词不是获取价值的门槛,但确实能让结果更稳定——尤其是在大型代码库或者高风险任务里。
一个好提示词通常包含四个部分:目标(想改什么或构建什么)、上下文(哪些文件、文档、报错信息是相关的,用 符号可以直接引用具体文件)、约束(架构规则、安全要求或编码规范)、完成标准(比如测试通过、Bug不再复现)。
推理强度也可以按任务难度来调:简单清晰的任务用低强度跑更快;复杂调试和大改动用中高强度;需要长时间主动推理的任务才用极高——最强不等于最好,找到适合你工作流的档位更重要。
复杂任务别急着写代码,先规划
任务模糊或者难以描述的时候,建议先进Plan模式(/plan或Shift+Tab切换),让Codex先收集上下文、提问、制定方案,再动手。这步很多人跳过,但差别真的挺大的。
还有一个不常用但挺好使的方法:直接让Codex反过来问你问题。如果你对想实现的功能只有模糊的想法,告诉它"先不要写代码,帮我把这个想法问清楚",它会挑战你的假设,把模糊需求转化成可执行的任务描述。
AGENTS.md:把有效经验沉淀下来
发现一个提示词奏效了,不要每次手动输入,把它写进AGENTS.md,它会自动加载进上下文,相当于给Codex的长期工作手册。
实用的AGENTS.md通常包含:仓库结构与关键目录、项目运行方式、构建/测试/lint命令、工程规范、禁止操作模式、验收标准。CLI命令/init可以在当前目录自动生成一个基础版本,你再按实际情况改。
AGENTS.md支持多层级目录并存:~/.codex/AGENTS.md作为个人全局默认,仓库根目录的用于团队共享规范,子目录里可以写更具体的局部规则。
有个原则挺值得记住:保持文件简洁。一份短而准确的文件,比塞满模糊规则的长文件有用得多。先从基础规则开始,遇到重复性错误再补充。如果Codex犯了两次同样的错,让它自己回顾并更新AGENTS.md。
用MCP打通外部系统
当你需要的上下文在代码库之外——比如数据库、监控系统、项目管理工具——不要反复往提示词里粘贴信息,用MCP直接把这些系统接进来。
适合用MCP的场景:信息来源在代码库外、数据变化频繁、需要跨用户或跨项目的可重复集成。Codex同时支持STDIO和Streamable HTTP服务器,以及OAuth鉴权。在Codex应用的"设置→MCP服务器"可以查看和配置,CLI里用codex mcp add命令也行。
重复工作抽成技能,再稳定的流程做成自动化
有一个判断经验比较实用:如果你发现自己不断重复使用同一套提示词或者反复纠正同一个工作流,那这个流程适合做成技能(Skill)。
每项技能封装一件事,用SKILL.md文件存储,CLI、IDE插件和Codex应用都能调用。技能存放位置:个人技能放$HOME/.agents/skills,共享技能放仓库内的.agents/skills。$skill-creator用于创建新技能,$skill-installer用于本地安装。
流程稳定之后,可以在Codex的Automations页面创建自动化,设置执行节奏、调用的技能、运行环境。适合自动化的场景包括:总结近期提交、扫描潜在Bug、起草发布说明、检查CI故障等。
记住一个原则:技能定义方法,自动化定义节奏。流程还不稳定的时候,先做成技能跑顺了,再考虑自动化,别反过来。
几个容易踩的坑,提前知道能省很多事
把持久规则塞进每次的提示词里,而不是移到AGENTS.md,这是最常见的浪费。还有就是多步骤任务不做规划就直接让它跑、流程还没跑稳就急着做自动化、在同一个文件上并行跑多个线程却不用git worktree……
最后一个很多人会犯:用一个项目一个线程,导致上下文越积越长、质量越来越差。正确的做法是一个任务一个线程,需要分支时用/fork,线程太长时用/compact做摘要。
Codex不是一个需要你盯着它一步步执行的工具,而是可以和你并行工作的队友。花时间把配置和工作流做好,它给你带来的价值会持续累积。