codex需分清交互模式与命令模式，用“情境-疑问-请求”三阶法明确目标、上下文和边界条件，复杂任务须拆解并启用/plan模式，辅以主动提供上下文和严格验证输出。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你在 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")
通过本地 Codex 或 OpenClaw OAuth 凭证直接调用 ChatGPT/Codex Responses 的 image_generation 工具来生成或编辑光栅图像，然后保存
③ 确认后输入：执行步骤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行异常处理，保持原有日志格式。
