Codex 的使用效果，关键不在于模型本身有多强大，而在于你给出的指令是否足够清晰、易于理解。很多人习惯直接说一句“帮我加个日志”，结果 Codex 可能修改了三处无关文件、删除了配置项，甚至还生成了一段无用的装饰器——这并非模型能力不足，而是你没有明确传达目标、上下文和边界条件。
先分清模式：别把 Agent 当作 Chat 来用
在终端直接输入 codex 回车，与输入 codex "写个脚本" 是两种完全不同的运作机制。前者进入交互模式，Codex 能够读取项目结构、修改文件、执行命令并持续迭代；后者则是命令模式，仅做一次调用，没有上下文，也不保存状态。如果你想补全一个 API 的错误处理逻辑，必须进入交互模式。在命令模式下，即使你反复输入“加上 try-except 并记录 error code”，它也不会记住你刚刚修改过的 auth.py 文件位置。
如何判断是否处于交互模式？看提示符即可。如果看到类似 codex ➤ 的符号，并且支持多轮连续指令（例如“分析这个函数→重写异常分支→添加测试用例”），那才是正确的交互入口。
用“情境-疑问-请求”三阶法组织提示词
这个方法非常简单，只需三步即可完成：
第一步描述当前情境（包含项目状态和技术栈）。例如：“这是一个基于 FastAPI + SQLAlchemy 构建的用户服务，代码位于 ./src/user_service/ 目录下，已存在 models.User 和 schemas.UserIn 模块。”
第二步指出具体的疑问或问题点。“目前 POST /users 接口在邮箱重复时返回 500 错误，而非预期的 400 状态码，日志中也没有捕获 IntegrityError 异常。”
第三步明确请求动作与交付物。“请修改 create_user endpoint，在数据库异常时正确捕获 IntegrityError，返回 {'error': 'email already exists'} 及 400 状态码，并在 logs/ 目录下追加一行错误日志记录。”
关键要点：必须包含具体路径、状态码、字段名和日志位置。 缺少任何一项，Codex 都可能往 config.py 里添加日志，或者返回 {"message": "..."} 这种不兼容的格式。
复杂任务必须拆解，并让 Codex 自行规划
如果你直接输入“实现完整的权限控制系统”，Codex 很可能会卡住或者胡乱生成代码。正确的做法是主动拆解任务，并启用 /plan 模式：
① 首先输入：/plan 实现 RBAC 权限控制，需支持角色创建、用户绑定角色、接口级权限校验
② Codex 会自动列出执行步骤，例如：
• 步骤1：新增 roles 表和 role_permissions 关联表
• 步骤2：添加 RoleCreate 和 UserRoleLink 的 Pydantic 模型
• 步骤3：编写权限校验依赖函数 check_permission()
• 步骤4：在 GET /api/v1/projects 接口加入 @check_permission("project:read") 装饰器
③ 确认无误后输入 执行步骤1——它只会操作数据库迁移和模型定义；等你验证通过后，再输入 执行步骤2。每一步都可以独立验证和回退，即使出错也不会影响其他模块，这比一次性提交一个庞大需求要可靠得多。
给 Codex “看得见”的上下文，而不是依赖猜测
方法一：使用 ls -R 和 cat 主动提供信息。在交互模式中先运行 ls -R src/ | head -n 50，再执行 cat src/core/deps.py，这样 Codex 就能真实“看到”你的依赖注入结构。仅仅说“参考已有依赖写法”是没用的，它分不清 deps.py 和 utils.py 的区别。
方法二：粘贴关键代码片段，长度不超过 20 行。例如你要扩展一个验证函数，直接粘贴原函数定义并附上两行调用示例，Codex 才能准确对齐函数签名、参数顺序和返回类型。粘贴太多内容反而会干扰判断，粘贴太少它又会自行脑补参数名称。
特别提醒：不要粘贴包含敏感信息的代码（如密钥、内网地址等）。虽然 Codex 本地运行时不会上传数据，但剪贴板内容若被其他工具捕获仍存在安全风险。
验证输出前，必须完成三件事
Codex 输出代码后，不要急于复制粘贴：
• 首先运行 git status 查看它修改了哪些文件，确认没有触碰你不应更改的配置目录；
• 然后输入 diff src/api/endpoints/user.py 检查具体的变更行，重点确认是否引入了未声明的 import；
• 最后对照原始需求逐条核对：状态码是否正确、字段名拼写是否无误、日志路径是否真实存在。
只要有一项不符合预期，立即输入 撤销上一步 或 重写第3行异常处理，保持原有日志格式 进行修正。