高效 Prompt 写法
Codex 是一个"按指令执行"的工具。Prompt 质量直接决定输出质量。一个好的 Prompt 包含三要素:
- 动词 + 对象:做什么操作,作用在哪个文件/函数上
- 范围限定:只处理哪些文件,不碰哪些文件
- 完成标准:输出需要满足什么要求
| ❌ 模糊 Prompt | ✅ 精确 Prompt |
|---|---|
| 优化这段代码 | 重构 src/utils.js 中的 parseDate 函数,消除重复逻辑,为所有参数添加 TypeScript 类型注解 |
| 修复 bug | 修复 src/api/auth.ts 中 validateToken 函数的问题:当 token 过期时应抛出 TokenExpiredError 而非返回 null |
| 写测试 | 为 src/services/userService.ts 中的 createUser 函数编写 Jest 单元测试,覆盖:邮箱重复、密码太短、成功创建三种场景 |
| 加注释 | 为 src/db/migrations/ 目录下所有 .ts 文件中的每个函数添加 JSDoc,说明参数、返回值和副作用 |
经验法则:如果你需要解释"到底修哪个函数",那说明 Prompt 还不够精确。精确的 Prompt 让 Codex 不需要猜测。
常用 Prompt 模式
# 批量操作模式:用"所有"但限定范围
为 src/controllers/ 目录下所有文件中的所有 async 函数添加 try-catch 错误处理,
错误统一传给 next(err),不要修改 src/middleware/ 下的文件。
# 先分析后操作模式:减少意外修改
先列出 src/models/ 目录下所有使用了裸 SQL 查询的函数,然后等我确认后再替换成 Sequelize ORM 写法。
# 约束 + 输出模式:明确不能做的事
重构 src/auth/passport.ts 中的 OAuth 回调函数,提高可读性。
约束:不要修改函数签名,不要改变错误处理逻辑,函数名保持不变。
# 渐进式模式:大任务分步
第一步:只分析 src/legacy/ 目录,列出哪些函数超过 50 行且没有类型注解,不要修改任何文件。
模型选择策略
不同任务适合不同模型。盲目用最贵的模型会浪费成本,用太便宜的模型会降低质量。
| 任务类型 | 推荐模型 | 原因 |
|---|---|---|
| 快速修复、加注释、写简单测试 | gpt-4.1-mini |
最快、最便宜,够用 |
| 日常功能开发、重构 | gpt-4.1 或默认 |
质量与成本平衡好 |
| 复杂架构推理、大型代码库理解 | o4-mini 或 gpt-5.x |
推理能力更强 |
| CI/CD 批量自动化任务 | o4-mini |
成本与质量最佳平衡 |
| 探索性分析(不急结果) | gpt-5.x 或 o3 |
深度推理,不计时间 |
# 交互模式:用斜杠命令临时切换(只影响当前会话)
/model gpt-4.1-mini
# 命令行参数(单次生效)
$ codex --model o4-mini "重构认证模块"
# 配置文件(永久默认)
# ~/.codex/config.toml
model = "gpt-4.1"
AGENTS.md 实战模式
AGENTS.md 是 Codex 的项目记忆——但很多人写得太少或太多。以下是几个能显著提升效果的实战模式:
模式 1:禁止清单优先
最重要的内容不是介绍项目,而是明确禁止做什么。Codex 会主动避免触发这些规则:
## 禁止事项(Codex 必须遵守)
- 不要修改 generated/ 目录,这些文件是自动生成的
- 不要直接操作 prisma/schema.prisma,迁移通过 `pnpm db:migrate` 执行
- 不要在路由文件里写业务逻辑,统一放 services/
- 不要修改 .env.example 和 .env,密钥在这里
- Stripe webhook 处理逻辑在 webhooks.ts,修改前告诉我
模式 2:命令速查表
把最常用的开发命令直接写在 AGENTS.md 里,Codex 在需要运行测试或启动服务时会自动使用正确的命令:
## 常用命令
```bash
pnpm dev # 启动开发服务器,热重载,端口 3000
pnpm test # Vitest 单元测试
pnpm test:watch # 测试监听模式
pnpm build # 构建生产包
pnpm db:migrate # 执行 Prisma 迁移
pnpm lint # ESLint 检查(提交前必须通过)
```
更多 AGENTS.md 技巧参考:AGENTS.md 完整指南。
上下文管理
上下文窗口满了是最常见的进阶问题之一。以下策略帮你高效利用上下文:
策略 1:任务分解(最有效)
把一个大任务拆成多个聚焦的小任务,每次只做一件事:
# ❌ 一次做太多
重构整个 src/ 目录,添加类型注解,优化性能,更新文档
# ✅ 分步来
# 第一轮:只加类型
为 src/services/ 目录下的所有函数添加 TypeScript 类型注解,不做其他修改
# 确认后第二轮
在第一轮的基础上,为 src/services/ 目录下已有类型注解的函数识别性能瓶颈并优化
策略 2:指定文件路径
在 Prompt 里明确指定文件路径,避免 Codex 自己探索文件树(每次探索都消耗 token):
# ❌ 让 Codex 自己找
找到所有处理用户认证的文件并重构
# ✅ 直接告诉它在哪里
重构以下文件中的认证逻辑:
- src/api/routes/auth.ts(路由层)
- src/services/authService.ts(业务逻辑层)
- src/middleware/jwtMiddleware.ts(JWT 验证中间件)
策略 3:轻量 AGENTS.md
AGENTS.md 越长越占上下文。把不常用的背景信息拆分到子目录的独立 AGENTS.md,只有根目录的 AGENTS.md 保持精简(300 行以内)。
codex exec 自动化模式
codex exec 是把 Codex 嵌入脚本和 CI 流水线的关键。以下是几个实战模式:
#!/bin/bash
# 批量为所有未添加类型的文件加注解
for file in src/services/*.ts; do
echo "处理 $file ..."
codex exec "为 $file 中所有无类型注解的函数添加 TypeScript 类型,不修改逻辑"
done
#!/bin/bash
# 只在 git diff 有内容时运行
DIFF=$(git diff HEAD~1 --name-only '*.ts')
if [ -z "$DIFF" ]; then
echo "没有 TypeScript 文件变更,跳过"
exit 0
fi
codex exec "根据 git diff HEAD~1 的 TypeScript 变更,更新对应的 JSDoc 注释"
#!/bin/bash
set -e # 任何命令失败立即退出
# codex exec 失败时退出码非 0,set -e 会自动终止脚本
codex exec "修复 src/api/ 目录下所有 ESLint 错误,不修改逻辑"
# 确认 lint 通过
npm run lint
echo "✓ 所有 lint 错误已修复"
完整的 CI/CD 集成(GitHub Actions、GitLab CI)参考:CI/CD 集成指南。
交互模式实用技巧
快捷键
| 快捷键 | 功能 |
|---|---|
| Ctrl+C | 中断当前任务(Codex 停止执行,不影响已完成的修改) |
| Ctrl+D | 退出 Codex 交互界面 |
| ↑ / ↓ | 浏览历史输入 |
| Tab | 自动补全(文件路径、斜杠命令) |
| Esc | 取消当前输入,回到空状态 |
审批模式 vs 全自动
默认沙箱是 workspace-write,Codex 会在执行某些操作前询问你。在你信任任务的情况下,可以临时调整:
# 在交互模式内用斜杠命令调整
/permissions
# 或在 config.toml 中设置默认值
# ~/.codex/config.toml
approval_policy = "auto-edit" # 文件修改自动批准,命令执行仍需确认
多项目与会话管理
在多个项目间切换时,注意以下几点:
每个项目的 AGENTS.md 独立
每个项目根目录有自己的 AGENTS.md,Codex 启动时自动读取当前目录的文件。在项目 A 目录里启动 Codex,就只读项目 A 的 AGENTS.md,不会混入项目 B 的规则。
全局个人偏好用 ~/.codex/AGENTS.md
# 这里写的内容对所有项目生效
- 代码注释用中文
- 解释方案时先给结论,再展开细节
- 遇到不确定的地方先问我,不要自己猜
## 我的代码风格
- 优先使用函数式写法
- async/await 优先于 Promise.then
- 变量命名用 camelCase
常见坑与规避方法
坑 1:Codex 修改了不该改的文件
原因:Prompt 范围不明确,或 AGENTS.md 没有写禁止清单。
解法:在 Prompt 里明确"只修改 X 文件",在 AGENTS.md 的"禁止事项"里列出不能碰的文件。如果已经发生,用 git checkout -- <文件路径> 回滚。
坑 2:任务做到一半 Codex 停了
原因:任务太大,上下文满了或遇到需要确认的操作。
解法:把大任务拆小。如果是等待确认,在终端里查看提示并输入 y 继续,或用 /permissions 调整审批策略。
坑 3:Codex 的输出格式不符合项目规范
原因:代码规范没有写在 AGENTS.md 里,或 Prompt 没有说明格式要求。
解法:在 AGENTS.md 里写具体规范(不要 any、JSDoc 必填、命名规则),在 Prompt 里也可以补充"遵循项目的 ESLint 配置"或"函数必须有返回类型注解"。
坑 4:Codex 理解了但执行方向偏了
解法:用"先分析后操作"模式。在 Prompt 末尾加一句"先列出你计划修改哪些文件和函数,等我确认后再动手"。Codex 会先给出操作计划,你确认没问题再继续。
坑 5:在 CI 里 codex exec 突然失败
常见原因:① OPENAI_API_KEY 未设置;② Node.js 版本过低(需 18+);③ codex 版本过旧;④ 网络不通(CI 服务器需要访问 OpenAI API)。
排查方法:在脚本开头加 codex --version 确认版本,加 echo $OPENAI_API_KEY | cut -c1-6 确认 Key 已注入(只显示前几位,不泄露完整 Key),用 curl https://api.openai.com/v1/models -H "Authorization: Bearer $OPENAI_API_KEY" 测试 API 连通性。
高效日常工作流
以下是几个经过验证的日常工作流,可以直接套用:
工作流 1:Feature 开发
- 先用 Codex 生成功能骨架(
/init确保 AGENTS.md 是最新的) - 审查骨架,向 Codex 提出修改意见
- 让 Codex 生成单元测试
- 运行测试,把失败的用例粘给 Codex 让它修复
- 最后让 Codex 补充 JSDoc 注释
工作流 2:Bug 修复
- 把错误信息和堆栈贴给 Codex,让它定位问题("先分析,不要修")
- 确认定位正确后,让 Codex 修复并解释修改原因
- 要求 Codex 同时写一个能复现这个 bug 的回归测试
工作流 3:代码审查辅助
codex exec "分析 git diff HEAD~1 的变更,从可读性、潜在 bug、边界条件三个角度给出 code review 意见,只给意见不修改文件"- 参考意见决定是否需要改动
- 如果需要,让 Codex 按意见修复
想把上面的工作流接入 GitHub Actions?参考 CI/CD 集成指南,包含完整的 YAML 配置示例。