前几天团队里有同事问我“你怎么用 Codex 一天能干完我一周的活你是不是偷偷加了什么外挂”说实话我一开始也觉得 Codex 就是个高级版的 Copilot。直到我花了整整 30 天深度使用踩了无数坑之后才发现——大多数人只用了 Codex 不到 20% 的能力。你可能会遇到这些情况每次让 Codex 写代码都要反复纠正风格改了半天还不如自己写明明是个简单任务它却生成了一堆不必要的复杂代码让它跑测试结果把不相关的测试也改了更离谱的是有时候它会自作主张地创建 git 分支、提交代码搞得一团糟。但其实这些问题全都是因为——你不会教 Codex。本文将分享我在 30 天高强度使用中总结出的12 个实战技巧从入门配置到高级玩法每一个都经过真实项目验证。 先看看效果在我优化完所有配置之后指标优化前优化后提升首次生成正确率~40%~85%2 倍平均任务完成时间15-30 分钟3-8 分钟3-5 倍不必要的文件修改频繁几乎为零95% ↓代码风格一致性每次都要纠正自动遵守100%无效 token 消耗高低60% ↓核心结论Codex 的能力上限取决于你给它的上下文质量。技巧 1AGENTS.md — 你的项目说明书这是最被低估的功能没有之一。AGENTS.md是放在项目根目录的一个文件Codex 每次启动时都会自动读取它。你可以在里面写项目的编码规范、架构说明、常用命令等等。创建你的第一个 AGENTS.md# 项目规范 ## 技术栈 - 语言TypeScript 5.4 - 框架Next.js 14 (App Router) - 数据库PostgreSQL Prisma ORM - 测试Vitest Testing Library ## 编码规范 - 使用函数式组件禁止 class 组件 - 变量命名camelCase - 组件命名PascalCase - 常量命名UPPER_SNAKE_CASE - 每个函数不超过 50 行 ## 常用命令 - 启动开发服务器pnpm dev - 运行测试pnpm test - 运行单个测试文件pnpm test -- path/to/file.test.ts - 类型检查pnpm typecheck - Lint 检查pnpm lint ## 目录结构 - src/app/ — 页面路由 - src/components/ — 共享组件 - src/lib/ — 工具函数 - src/server/ — 服务端逻辑 - prisma/ — 数据库 schema为什么这么重要没有AGENTS.md的时候Codex 每次都要猜你的项目规范猜错了你还得纠正它。有了这个文件一次配置永久生效。⚠️注意AGENTS.md支持嵌套放置。子目录中的AGENTS.md会覆盖父目录的同名配置。比如你可以在src/components/下放一个专门针对组件开发的规范。技巧 2用角色 约束模式写提示词大多数人给 Codex 的提示词是这样的❌反面示例“帮我写一个用户注册功能”这种提示词太模糊了Codex 会按自己的理解随意发挥。✅正确姿势你是一个资深 Next.js 全栈工程师。请基于现有的 Prisma schema实现用户注册的 API 路由。要求使用src/app/api/auth/register/route.ts路径输入验证使用 zod密码使用 bcrypt 哈希返回标准 JSON 响应格式添加对应的 Vitest 单元测试公式角色定义具体任务技术约束输出要求为什么有效角色定义让 Codex 进入专家模式生成更专业的代码具体任务明确要做什么避免发散技术约束限制技术选型和项目保持一致✅输出要求确保结果可验证技巧 3善用不要做指令很多人只告诉 Codex “要做什么”却忘了告诉它不要做什么。这其实更重要。在AGENTS.md或者提示词中加上这些约束## 禁止事项 - 不要修改我没有提到的文件 - 不要添加 inline 注释除非我明确要求 - 不要创建 git commit - 不要使用 any 类型 - 不要引入新的依赖包除非我同意 - 不要使用 one-letter 变量名 - 不要添加 copyright 头 - 不要重构我没有提到的代码效果对比场景没有不要做约束有不要做约束修改一个函数顺手重构了整个文件只改目标函数添加新功能自动创建 git 分支并提交只修改代码修复一个 bug引入了 3 个新的 import最小化修改这条技巧的 ROI 是最高的。一个不要做的约束可以帮你省下 80% 的返工时间。技巧 4分阶段提需求而不是一次性甩大需求❌反面示例“帮我做一个完整的电商系统包括用户管理、商品管理、购物车、订单、支付”这种大需求Codex 大概率会生成一堆臃肿的、不符合你预期的代码。✅正确姿势分步执行第一步“先设计电商系统的数据库 schema包括用户、商品、购物车、订单四个表”第二步“基于刚才的 schema实现商品 CRUD 的 API 路由”第三步“给商品 API 添加分页和搜索功能”第四步“实现购物车功能支持添加、删除、修改数量”为什么分步更好✅ 每一步都可以 review 和调整✅ 避免一次性生成大量难以维护的代码✅ 上下文更聚焦生成质量更高✅ 发现问题可以及时纠正不会跑偏经验法则每次给 Codex 的任务控制在15-30 分钟人工工作量的范围内。太小了没效率太大了容易失控。技巧 5用 TODO 计划让 Codex 先想再做当你给 Codex 一个稍微复杂的任务时可以要求它先生成一个执行计划“先不要写代码。先分析一下实现这个功能需要哪些步骤列出你的计划。”Codex 会生成一个结构化的 TODO 列表类似这样1. [ ] 创建 API 路由文件 2. [ ] 定义请求/响应类型 3. [ ] 实现输入验证 (zod) 4. [ ] 实现业务逻辑 5. [ ] 添加错误处理 6. [ ] 编写单元测试 7. [ ] 运行测试验证你可以✅ 确认计划合理后再让它执行✅ 调整步骤顺序或增删步骤✅ 在每个步骤完成后 review进阶用法“按你的计划一步步来每完成一步就停下来告诉我进展。”这样 Codex 会进入分步执行模式你可以在每一步之后介入和调整。技巧 6利用 Git 历史给 Codex 提供上下文当你要修改或重构一段代码时让 Codex 先看看 Git 历史“请先用git log和git blame查看src/lib/auth.ts的历史了解这段代码为什么是这样的然后再做修改。”为什么有用 了解代码演变的背景和原因 发现之前修复过的相关 bug 尊重之前开发者的设计意图⚠️ 避免重新引入已经修复过的问题同样你也可以让 Codex 查看相关的 PR 和 commit message“看一下最近 10 个 commit了解项目最近的改动方向然后基于这个上下文来实现新功能。”技巧 7测试驱动开发TDD的正确姿势Codex 非常适合做 TDD但你得用对方法。方式一先写测试再让 Codex 实现“我已经写好了测试文件src/lib/__tests__/cache.test.ts里面有 8 个测试用例。请实现src/lib/cache.ts让所有测试通过。不要修改测试文件。”方式二让 Codex 同时写实现和测试实现src/lib/cache.ts的 LRU 缓存功能同时编写对应的测试。要求至少覆盖基本存取、过期淘汰、容量淘汰、并发安全测试文件放在src/lib/__tests__/cache.test.ts实现完成后运行pnpm test -- cache确认全部通过方式三用测试验证修改“修改src/lib/auth.ts的 token 过期逻辑从固定 24 小时改为可配置。修改完成后运行pnpm test -- auth确保现有测试全部通过。”⚡关键原则给 Codex 明确的测试运行命令让它能自己验证结果。这比让它自己觉得写对了可靠 100 倍。技巧 8善用 sandbox 模式控制权限Codex 提供了不同的沙箱模式来控制它的自由度。理解并正确使用它们非常关键模式说明适用场景full-auto自动执行无需确认信任度高的日常开发suggest每个操作都需要确认生产环境、敏感代码我的推荐配置生产代码 / 数据库操作 / API Key 相关使用suggest模式逐个确认日常功能开发使用full-auto提升效率测试代码 / 文档编写使用full-auto放心让它跑在提示词中也可以控制“这个任务涉及数据库 migration请在执行每条 SQL 之前先告诉我。”技巧 9让 Codex 当你的 Code Reviewer除了写代码Codex 还是一个非常优秀的 Code Reviewer。基础用法请 reviewsrc/lib/auth.ts最近的改动关注以下方面安全性SQL 注入、XSS、认证绕过性能N1 查询、不必要的内存分配错误处理边界情况、异常捕获代码可读性进阶用法对比式 Review对比main分支和当前分支的差异像资深工程师一样做 Code Review。重点关注是否有向后兼容性问题是否有遗漏的错误处理是否有更简洁的实现方式让 Codex 做安全审计“对src/app/api/下的所有路由做安全审计列出潜在的安全风险和修复建议。按严重程度排序。”小技巧Review 的时候让 Codex 用具体的代码示例来说明问题而不只是泛泛而谈。技巧 10复杂重构的安全网策略重构是最容易出事的操作。以下是我的安全重构流程第一步建立基线“先运行pnpm test记录当前所有测试的通过状态不要修改任何代码。”第二步小步重构“重构src/lib/auth.ts把回调风格改为 async/await。每次只改一个函数改完立即运行相关测试确认没有 regression。”第三步全量验证“所有函数都改完了运行完整的测试套件pnpm test如果有失败的测试逐个修复。”第四步类型检查 Lint“运行pnpm typecheck和pnpm lint确保没有类型错误和代码风格问题。”为什么这个策略有效✅ 每一步都有明确的验证标准✅ 出现问题可以精确定位到哪个函数✅ 不会一次性引入大量变更导致难以排查技巧 11多 Agent 协作模式Codex 支持同时运行多个 Agent 处理不同任务。这在大型项目中非常有用。场景同时开发前后端Agent 1“实现用户管理的后端 API包括 CRUD 和分页查询。”Agent 2“基于 API 接口文档如下实现用户管理的前端页面。API 接口如下…”场景同时写代码和文档Agent 1“实现支付模块的核心逻辑。”Agent 2“基于现有的src/lib/payment.ts编写 API 文档和使用示例。”⚠️注意事项多个 Agent 不要同时修改同一个文件明确划分每个 Agent 的职责边界定期同步进展避免冲突技巧 12高级 Prompt 模板库以下是我在实际项目中反复验证过的高效 Prompt 模板 Bug 修复模板我在src/components/UserList.tsx遇到了一个 bug当用户列表超过 100 条时页面会卡死。复现步骤打开用户列表页加载 100 条数据期望行为使用虚拟滚动流畅展示实际行为页面完全卡住无法滚动请分析原因并修复确保修复后不影响现有功能。️ 架构设计模板我需要设计一个通知系统要求支持多渠道邮件、短信、站内信、Webhook支持模板化消息内容支持发送重试和失败队列可扩展方便后续添加新渠道先给出架构设计方案不需要代码包括核心模块、数据流和技术选型。 性能优化模板src/lib/search.ts的搜索接口响应时间超过 2 秒。请分析性能瓶颈是否有 N1 查询、不必要的全表扫描等提出优化方案实现优化用 benchmark 对比优化前后的性能数据 迁移模板将项目从 Jest 迁移到 Vitest。要求逐个文件迁移每迁移一个文件就运行确认保持所有测试用例的行为不变更新package.json和配置文件迁移完成后删除 Jest 相关依赖全面对比新手 vs 老手维度新手用法老手用法项目配置没有 AGENTS.md完善的 AGENTS.md 嵌套配置提示词“帮我写个功能”角色 约束 输出要求任务粒度一次甩大需求分阶段执行每步 review约束条件只说要做什么明确不要做什么验证方式肉眼看代码测试驱动 自动化验证上下文管理从零开始描述利用 Git 历史 项目文档复杂任务直接开干先出计划逐步执行重构一次性大改小步重构 持续验证权限控制全开或全关按场景选择 sandbox 模式代码质量生成后手动检查让 Codex 自己 Review常见踩坑与解决方案QCodex 总是修改我不想改的文件怎么办A在AGENTS.md中明确写上## 禁止修改的文件 - src/config/database.ts — 数据库配置请勿修改 - prisma/migrations/ — 迁移文件请勿手动修改或者在提示词中加上“只修改src/lib/auth.ts不要碰其他文件。”QCodex 生成的代码太复杂了怎么办A加上简洁性约束“用最简单的方式实现不要过度设计。如果标准库能解决不要引入第三方包。”QCodex 总是忘记之前的上下文怎么办A在新对话开头提供关键上下文“当前项目使用 Next.js 14 TypeScript Prisma数据库是 PostgreSQL。请在这个前提下实现…”Q如何让 Codex 遵守团队已有的代码规范A把你们的 ESLint 配置、Prettier 配置和编码规范都写进AGENTS.mdCodex 会自动遵守。QCodex 跑测试把不相关的测试也改了怎么办A在AGENTS.md中加上## 测试规范 - 只修改与当前任务直接相关的测试文件 - 不要为了通过测试而修改测试用例的预期值 - 运行测试时使用精确路径pnpm test -- path/to/specific.test.ts总结经过 30 天的深度使用我的核心感悟是✅AGENTS.md 是 ROI 最高的投资— 一次配置永久受益✅不要做比要做更重要— 约束产生质量✅分步执行永远优于一步到位— 小步快跑持续验证✅给 Codex 足够的上下文— 它不是全知的但给它信息后它非常强✅让 Codex 自我验证— 测试驱动 自动化检查 人工 review最后提醒Codex 是一个强大的工具但它的能力上限完全取决于你如何教它。花 30 分钟写好AGENTS.md比花 30 天反复纠正代码风格要有效 100 倍。附录我的完整 AGENTS.md 模板# 项目规范 ## 技术栈 - [填写你的技术栈] ## 编码规范 - [填写你的编码规范] ## 常用命令 - 启动[命令] - 测试[命令] - Lint[命令] - 构建[命令] ## 禁止事项 - 不要修改未提及的文件 - 不要添加不必要的注释 - 不要创建 git commit - 不要引入新依赖除非明确要求 - 不要重构未提及的代码 - 不要使用 any 类型 - 不要使用单字母变量名 ## 测试规范 - 只修改与当前任务相关的测试 - 不要修改测试预期值来通过测试 - 运行测试时使用精确文件路径 ## 提交规范 - 不要自动 commit - 如果需要 commit使用 Conventional Commits 格式