前十一章覆盖了 Codex CLI 的核心能力体系。本章聚焦三个高级实战场景:数据库交互、多项目/多语言开发、以及提升日常效率的独特技巧。
codex "根据以下需求,生成 Prisma schema: 系统是一个博客平台,需要: - 用户表(邮箱、密码哈希、昵称、头像、角色) - 文章表(标题、内容、摘要、发布状态、阅读量) - 评论表(内容、关联文章和用户) - 标签表(名称、关联文章多对多) - 所有表自动包含 createdAt、updatedAt - 软删除使用 deletedAt"
codex "将以下业务需求转换为高效的数据库查询: '查询最近 30 天内,每个分类下阅读量最高的前 5 篇文章,包括作者信息和评论数' 请先给出 Prisma 查询,再给出等价的 SQL。如果涉及 N+1 问题,说明如何避免。"
codex "审查 prisma/migrations/ 目录中最新的迁移文件: 1. 是否会导致数据丢失(DROP COLUMN、类型变更) 2. 是否有破坏性变更需要分步迁移 3. 索引是否合理 4. 是否有锁表风险(大表 ALTER) 5. 给出生产环境安全迁移步骤"
# 分析慢查询 codex "数据库慢查询日志中有以下 SQL,请分析和优化: SELECT * FROM orders o JOIN users u ON o.user_id = u.id WHERE o.status = 'pending' ORDER BY o.created_at DESC 分析: 1. 该查询的执行计划(哪些索引能提升性能) 2. 改写为更高效的查询 3. 如果数据量达百万级,如何分页"
codex "编写数据迁移脚本: - 将 users 表中 phone 字段从字符串 '13800138000' 格式清洗为 E.164 格式 '+8613800138000' - 对于格式不正确的 phone 值,记录到 error_log 表而非中断迁移 - 分批处理,每批 1000 条 - 使用 Prisma 或 TypeORM"
codex "审查 src/repositories/UserRepository.ts 的数据库操作: 1. 是否存在 N+1 查询 2. 是否缺少必要的索引提示 3. 事务边界是否合理 4. 是否有连接泄漏风险 给出重构方案"
# 同时分析前后端项目 codex "同时分析 frontend/ 和 backend/ 目录: 1. 检查 API 契约一致性:frontend 调用的接口在 backend 中是否都有定义 2. 检查前后端类型定义是否同步 3. 列出不匹配的地方 frontend 在 ./web/,backend 在 ./api/"
codex "在当前 monorepo 中添加一个新包 @myorg/shared-types: 1. 参考 packages/utils 的 package.json 结构 2. 配置 TypeScript 构建 3. 更新根目录的 tsconfig.json paths 4. 更新 CI 配置"
codex "将 src/utils/helpers.js 从 JavaScript 迁移到 TypeScript: 1. 保持函数签名 100% 兼容 2. 推断并添加准确类型(拒绝 any) 3. 导出类型接口供其他模块使用 4. 如果发现 JavaScript 特有的动态模式不兼容 TS,使用类型守卫"
codex "将 Express 路由迁移到 Fastify: 1. 一次迁移一个路由文件 2. 将回调风格改为 async/await 3. 请求验证从 Joi 改为 JSON Schema 4. 每迁移一个文件就运行对应测试"
codex "项目包含 Go 后端和 TypeScript 前端。请: 1. 分析 Go 的 API handler 定义 2. 为前端生成对应的 TypeScript API 客户端类型和方法 3. 确保 request/response 类型与 Go struct 一致"
codex "初始化一个全栈 SaaS 项目: - 前端:Next.js 14 + TypeScript + Tailwind CSS + shadcn/ui - 后端:Express + TypeScript + Prisma + PostgreSQL - 认证:NextAuth.js + JWT - monorepo 使用 pnpm workspace - 包含 Docker Compose 开发环境 - 添加基础 ESLint + Prettier 配置"
codex "根据已有文件 src/components/dashboard/StatsCard.tsx 的模式,\ 生成 src/components/dashboard/ 下的其他组件: - ActivityFeed.tsx - RecentOrders.tsx - RevenueChart.tsx 每个组件遵循相同的结构: - 接受 data prop - 包含 loading 和 error 状态 - 使用项目中的 Card 和 Skeleton 组件"
codex "分析 package.json 的依赖: 1. 列出可能不再使用的包 2. 列出可升级的包及其 breaking changes 3. 检查是否有重复依赖(同一包的不同版本) 4. 推荐替代方案(如用 date-fns 替代 moment.js)"
# 为 API 生成文档 codex "基于 src/routes/ 目录下的 Express 路由定义,生成 OpenAPI 3.0 规范: - 提取路由路径、方法、参数 - 从 Joi/Zod schema 提取请求体结构 - 从返回类型推断响应结构 - 输出为 openapi.json"
codex "将项目中的 ESLint 配置从 .eslintrc.js 迁移到 eslint.config.mjs(Flat Config): 1. 分析现有规则和插件 2. 转换为 Flat Config 语法 3. 确保规则行为一致 4. 验证迁移后 lint 结果无变化"
> 我想创建一个命令行工具,用 Go 写,功能是批量重命名文件 Codex: 好的,我先创建项目结构。你希望: 1. 支持哪些重命名模式?(序号、正则、替换) 2. 是否支持 dry-run 模式预览? 3. 配置文件格式偏好?(YAML/JSON/TOML) > 支持序号和正则替换,要有 dry-run,用 YAML 配置 Codex: 明白了。我先创建 main.go、rename 包、配置解析。 [Codex 开始创建文件] > 看了一下,再加个递归处理子目录的选项 Codex: 好的,我在配置中增加 recursive 选项,修改 Walk 逻辑...
使用 Codex 在以下任务上的典型时间对比:
| 任务 | 手动 | Codex | 节省 |
|------|------|-------|------|
| 生成 CRUD API | 2-4 小时 | 5 分钟 | 95%+ |
| 编写单元测试 | 1-2 小时/模块 | 2 分钟 | 95%+ |
| 代码审查 | 30 分钟/PR | 1 分钟 | 95%+ |
| 重构大函数 | 30-60 分钟 | 2 分钟 | 95%+ |
| 生成 API 文档 | 2 小时 | 1 分钟 | 99% |
| 修复 lint 错误 | 15-30 分钟 | 30 秒 | 98% |
| 写数据库迁移 | 30 分钟 | 2 分钟 | 93% |
# team-codex.yaml(团队共享,提交到仓库)
model:
provider: openai # 团队统一使用 OpenAI
execution:
policy: ask # 强制安全策略
sandbox: docker # 强制沙箱隔离
mcp:
servers:
github: # 统一配置 GitHub MCP
command: npx
args: ["@anthropic/mcp-server-github"]
AGENTS.md 作为团队编码规范,Codex 确保每个团队成员都在同一套规范下开发。
| 章 | 主题 | 核心能力 |
|----|------|----------|
| 1 | 安装与初始化 | 环境搭建、认证登录 |
| 2 | 配置体系 | codex.yaml、AGENTS.md |
| 3 | 模型提供商 | 75+ 模型接入与切换 |
| 4 | 命令执行 | exec 命令、策略、自定义命令 |
| 5 | 沙箱安全 | Docker/Podman 隔离 |
| 6 | 生命周期 Hooks | 自动化质检管线 |
| 7 | MCP + Skills | 外部工具集成、可复用工作流 |
| 8 | 编辑器与版本控制 | VS Code、Git 深度融合 |
| 9 | 提示词工程 | AI 对话方法论 |
| 10 | 代码质量 | 审查、重构、调试 |
| 11 | 测试与 CI/CD | 自动化测试、流水线集成 |
| 12 | 高级实战 | 数据库、多语言、效率技巧 |
Codex CLI 的能力远不止"写代码"。它是一整套 AI 驱动的软件开发方法论的载体——从安装到生产部署,从代码生成到质量保障,从单人开发到团队协作。掌握这十二大章,你就能将 AI 从一个"建议者"提升为一个"合作者",真正实现人机协同的高效开发。