图 1Codex 十大技巧总览。本文基于图片中的 10 个技巧展开同时补充 Codex 的能力介绍、代码操作实例、提示词模板和团队落地建议。图片为网上下载1. 文档目标这份文档不是只讲概念而是帮助你把 Codex 真正用到日常开发里。读完之后你应该能解决下面几件事知道 Codex 适合做什么不适合做什么知道怎样给出高质量需求让 Codex 更贴近项目实际知道怎样让它读代码、改代码、查问题、补文档知道怎样把单次使用升级为稳定的团队协作方式2. Codex 是什么Codex 可以理解为一个面向真实工程环境的开发协作助手。它和普通对话式 AI 的区别不只是“会写代码”而是更擅长在项目上下文中完成任务例如阅读仓库并总结项目结构理解已有代码后进行定点修改协助排查日志、报错和接口异常生成脚本、文档、测试和重构建议按要求逐步执行而不是只给一段演示代码换句话说Codex 更像一个可以配合你工作的“开发搭档”。3. Codex 常见能力介绍在实际使用中可以把 Codex 的能力理解为下面几类。3.1 代码理解适合做的事阅读项目结构并解释模块职责说明某个接口、类、方法的调用链分析配置文件、SQL、脚本和依赖关系示例请先帮我理解这个项目。 重点阅读 README、pom.xml、启动类和 yudao-module-system 模块。 输出项目结构、模块职责、主要技术栈和后续开发注意事项。3.2 代码修改适合做的事修复 bug实现小型功能做局部重构补充校验、日志、异常处理示例请帮我修改用户分页查询逻辑。 目标支持按手机号模糊查询 约束不要改接口入参不影响已有姓名和状态筛选 先分析相关代码再给最小修改方案。3.3 问题排查适合做的事根据报错日志定位问题分析空指针、SQL 异常、接口 500、序列化问题帮你提出验证路径和修复建议示例下面是报错日志和复现步骤请帮我判断根因。 我希望你先定位问题再给出最小修复方案和验证步骤。3.4 文档与规范沉淀适合做的事生成模块说明文档整理接口说明编写团队 AI 使用规范生成AGENTS.md/CLAUDE.md3.5 自动化执行当目标、边界和规则足够清晰时Codex 还可以直接执行更完整的开发流程例如先读代码再给计划按计划修改多个文件运行验证命令输出结果和风险说明这类能力很强但前提一定是目标清晰、上下文完整、约束明确、可回退可验证。4. 图中 10 个技巧详解4.1 先让 Codex “理解项目”技巧要点在动手前先让 Codex 读懂目录结构、关键模块、技术栈和约束文件。实操建议从README、依赖配置、启动类和核心业务目录开始让它总结模块职责、依赖关系和代码规范明确告诉它哪些目录最重要示例提示词先不要改代码先帮我理解项目。 请阅读 README、pom.xml、启动入口和主要业务模块 输出项目结构、模块职责、技术栈、后续开发约束。4.2 学会拆任务技巧要点复杂任务不要一次性全部抛给 Codex而要拆成多个小目标。实操建议按“分析 - 定位 - 修改 - 验证”拆分一次只解决一个核心问题每一步都保留检查点示例提示词这个任务分四步完成 1. 先定位相关代码 2. 再分析修改点 3. 然后实施最小改动 4. 最后给出验证步骤 每一步先输出结果再进入下一步。4.3 小步迭代比一次生成更强技巧要点先拿到可用版本再逐步增强通常比一次追求“完美大改”更稳。实操建议先做最小可用版本每轮只改一个主要问题每次改完都验证4.4 Git commit 是“保命技巧”技巧要点让每个关键阶段都可回退尤其是在 AI 辅助高频改动的场景里。实操建议关键修改前先形成快照一个 commit 对应一个目标commit 信息尽量描述业务意图4.5 善用 Suggest / Auto Edit / Full Auto建议理解方式Suggest适合拿方案、问思路、做评估Auto Edit适合精确改动指定文件Full Auto适合边界清晰、流程较完整的复杂任务使用建议需求没想清楚时先Suggest已明确改哪里时用Auto Edit已有计划、规则、验证路径时再考虑Full Auto4.6 给完整上下文技巧要点上下文越完整结果越贴近真实需求。建议提供的信息目标当前现象相关文件约束条件期望结果4.7 用日志帮 Codex Debug技巧要点日志、堆栈、请求体、返回值是定位问题最直接的线索。实操建议提供完整错误信息说明复现步骤附带关键代码和参数4.8 Prompt 要写“目标 约束”技巧要点好 Prompt 不只是提需求而是把目标、边界和输出格式说清楚。通用结构目标上下文约束输出要求4.9 让 Codex 先出计划技巧要点复杂任务先审计划再执行可以显著减少误改风险。适合场景多模块联动涉及接口和数据库你自己也还没完全确定方案4.10 用CLAUDE.md/AGENTS.md固化规则技巧要点把团队约束写进规则文件能让 Codex 每次都更稳定地按照同一套标准做事。可沉淀内容项目结构说明代码风格和命名规范提交规范测试要求禁止修改项5. 代码操作实例这一部分是本文最重要的“上手区”。下面给出几个最常见的 Codex 代码协作场景每个场景都包含目标、提示词写法和预期收益。5.1 实例一先读代码再解释模块关系场景你刚接手一个仓库不知道从哪里开始看。可以这样问请先不要改代码先帮我理解这个项目。 重点阅读 1. README 2. pom.xml 3. 启动类 4. yudao-module-system 模块 输出要求 1. 项目整体结构 2. 每个核心模块负责什么 3. 模块之间大致调用关系 4. 如果我要改用户管理功能应该优先看哪些文件你会得到什么一份项目阅读路径一份模块职责说明一套更高效的后续排查入口5.2 实例二让 Codex 帮你定位 Bug场景某个接口报 500但你暂时没看出根因。可以这样问请帮我定位一个接口报错问题。 现象 用户提交订单时接口返回 500。 复现步骤 1. 登录后台 2. 提交订单 3. 服务端返回异常 已知信息 1. 下面附上完整报错堆栈 2. 相关代码在 OrderController、OrderServiceImpl、OrderMapper 要求 1. 先判断根因 2. 再告诉我需要重点排查哪些代码 3. 如果能确认问题请给最小修复方案 4. 最后给验证步骤代码操作思路Codex 通常会先读报错堆栈定位大致异常点结合控制器、服务层和数据层分析调用链判断是参数、SQL、空值还是事务问题输出修改建议和验证方法5.3 实例三让 Codex 做最小范围改代码场景你已经知道问题在哪希望它只做精准修改不要扩散。可以这样问请帮我修改这段逻辑。 目标 给用户列表增加“手机号模糊查询”能力。 涉及文件 1. UserPageReqVO 2. UserServiceImpl 3. UserMapper.xml 约束 1. 不修改接口路径 2. 不影响已有姓名、状态筛选 3. 优先最小改动 4. 不做无关重构 输出要求 1. 先说明准备改哪些地方 2. 再实施修改 3. 最后告诉我如何验证预期收益修改范围可控风险更低便于 review 和回退5.4 实例四让 Codex 帮你补日志场景线上问题不好复现想通过日志先增强可观察性。可以这样问请帮我在这段订单提交流程中补充关键日志。 目标 让我能判断失败发生在参数校验、库存校验、还是落库阶段。 约束 1. 不打印敏感信息 2. 日志要能串起整个请求过程 3. 不要加入无意义的重复日志 4. 保持现有代码风格适合补哪些日志请求入口参数摘要关键分支判断结果外部接口调用结果异常捕获点最终成功或失败状态5.5 实例五让 Codex 帮你生成测试思路场景你改完了代码但不想只靠“看起来没问题”来判断。可以这样问这次改动已经完成请帮我补充验证方案。 要求输出 1. 需要覆盖的正常场景 2. 需要覆盖的异常场景 3. 如果要写单元测试建议测试哪些方法 4. 如果要做接口测试建议准备哪些输入价值帮你从“实现完成”走到“验证完成”特别适合代码 review 前做自查6. 一个完整的代码协作示例下面给出一个比较完整的示例展示怎样和 Codex 一步步完成一个需求。需求给用户列表增加手机号模糊查询。第一步让它理解上下文请先帮我看用户管理相关代码不要急着改。 我想给用户列表增加手机号模糊查询。 请先定位相关接口、请求参数对象、Service 和 Mapper。第二步让它先出计划请输出这个需求的实施计划 1. 需要改哪些文件 2. 每个文件大概改什么 3. 风险点是什么 4. 如何验证是否成功第三步再让它修改按刚才的计划执行修改。 要求 1. 只做最小必要改动 2. 不改接口结构 3. 不做无关重构 4. 修改后告诉我影响范围第四步让它补验证方案请基于这次改动补充验证清单。 包括 1. 正常查询场景 2. 空参数场景 3. 与姓名筛选组合场景 4. 可能的边界场景这套流程的优点每一步都可检查修改目标清晰不容易走偏特别适合团队协作和代码 review7. Java / Spring Boot 项目专用实例这一部分更贴近后端 Java 项目尤其适合 Spring Boot、MyBatis、分层架构项目使用。7.1 实例一定位 Controller - Service - Mapper 调用链场景你接手一个接口问题但只知道入口 URL不清楚它具体经过哪些类。可以这样问请帮我梳理这个接口的调用链。 目标接口用户分页查询接口 请从 Controller 开始继续往 Service、Mapper、XML 或 SQL 方向追踪 输出 1. 入口控制器 2. Service 调用链 3. Mapper/SQL 位置 4. 分页、筛选条件、数据转换分别在哪一层处理适合的项目结构controller/admin/...service/...dal/dataobjectdal/mysql/...Mapper.javaresources/mapper/*.xml价值快速读懂后端链路明确应该改 Controller、Service 还是 SQL减少“改错层”的概率7.2 实例二分析 MyBatis / Mapper XML 查询问题场景接口返回结果不对很可能不是 Java 逻辑问题而是 SQL 条件拼接问题。可以这样问请帮我检查这个分页查询为什么结果异常。 重点查看 1. 请求参数对象 2. Service 查询组装逻辑 3. Mapper 接口 4. Mapper XML 中 where 条件拼接 要求 1. 判断问题是在 Java 层还是 SQL 层 2. 如果是 XML 条件问题请指出具体条件 3. 给出最小修复方案 4. 说明是否会影响其他查询条件常见排查点like写法是否正确null和空字符串判断是否完整动态if条件是否遗漏分页排序字段是否正确联表字段别名是否冲突7.3 实例三补充统一异常处理和错误日志场景项目里报错信息不统一前端看到的提示混乱后端日志也不好排查。可以这样问请帮我评估当前异常处理是否规范。 重点查看 1. 全局异常处理器 2. 业务异常定义 3. Controller 层异常抛出方式 4. 关键日志记录位置 输出 1. 当前问题 2. 推荐优化点 3. 最小改造方案 4. 哪些地方需要补日志哪些地方不应该重复打印日志适合关注的类GlobalExceptionHandlerServiceExceptionErrorCode各业务 Service 实现类价值提升问题定位效率让接口错误返回更一致避免重复打印异常导致日志污染7.4 实例四排查事务不生效问题场景你已经加了Transactional但数据看起来还是部分成功、部分失败。可以这样问请帮我分析这个事务为什么可能没有生效。 请重点检查 1. 事务注解加在什么方法上 2. 是否存在同类内部调用 3. 异常是否被 try-catch 吃掉 4. 是否涉及异步、事件或远程调用 5. 回滚条件是否满足 输出要求 1. 可能原因按优先级排序 2. 每个原因对应的验证方式 3. 如果确认问题请给修复建议常见原因同类内部方法调用导致代理失效捕获异常后没有继续抛出回滚异常类型不匹配事务边界划分不合理7.5 实例五让 Codex 帮你补接口联调清单场景功能写完了但你希望更系统地准备接口联调和回归测试。可以这样问请基于这个 Spring Boot 接口实现帮我输出联调清单。 包括 1. 正常请求示例 2. 参数缺失场景 3. 权限不足场景 4. 分页边界场景 5. 并发或重复提交风险点 6. 需要重点关注的日志和数据库结果价值非常适合提测前自查也适合直接发给前端或测试同学联调7.6 实例六生成 Spring Boot 项目专用规则文件场景你希望 Codex 每次都按后端项目规范做事而不是每次重新说明。可以这样问请帮我生成一份适用于 Java / Spring Boot 项目的 AGENTS.md。 要求包含 1. Controller、Service、Mapper 的职责边界 2. DTO / VO / DO 的命名规范 3. SQL 修改注意事项 4. 日志和异常处理约束 5. commit 和验证要求建议写入的规则Controller 不写复杂业务Service 负责业务编排Mapper XML 改动后要检查分页和动态条件涉及数据库改动时说明影响范围和回滚方案改动优先最小范围不做无关重构8. 常用 Prompt 模板7.1 理解项目请先帮我快速理解这个项目。 重点阅读 README、依赖配置、启动入口和核心模块目录。 输出项目结构、主要模块职责、技术栈和后续改动注意事项。7.2 修复 Bug请帮我修复一个 bug。 目标解决 [具体现象] 上下文[相关模块/文件/日志] 约束只做最小修改不改接口定义不影响其他功能 输出根因分析、修改方案、验证步骤7.3 实现功能请帮我实现一个功能。 目标[功能目标] 背景[业务背景] 涉及文件[文件路径] 约束[性能/兼容/风格/权限要求] 请先给执行计划再按计划实施。7.4 重构优化请帮我评估这段代码是否值得重构。 先分析当前问题、风险和收益再给最小可行的重构方案。 如果收益不大请明确告诉我不建议重构。9. 推荐工作流先理解项目让 Codex 读懂结构、模块、入口和约束。再拆任务把需求拆成多个可执行小目标。先出计划复杂任务先确认路径和风险。再执行修改优先最小改动避免无关扩散。及时验证检查编译、测试、日志和接口结果。最后沉淀把有效 Prompt、规则和经验写成文档。10. 使用 Codex 时的安全提醒不要直接提供生产密钥、账号和敏感数据涉及支付、权限、删除、迁移时先做风险分析外部代码不要直接照搬先让 Codex 解释再落地自动化修改完成后关键代码必须人工复核数据库和脚本类操作优先要求它给出回滚方案11. 团队落地建议如果你想把 Codex 从“个人工具”变成“团队能力”建议这样推进统一一套常用 Prompt 模板沉淀一份AGENTS.md或团队 AI 协作规范从理解项目、修 bug、实现小需求三个高频场景先落地用真实案例沉淀最佳实践强调“先计划、再执行、可验证、可回退”12. 一句话总结Codex 不是只会生成代码的工具而是可以帮助你理解项目、操作代码、分析问题、推进交付的开发协作伙伴。13. 快速上手清单先让 Codex 理解项目不急着改代码每次只给一个清晰目标复杂任务先让它出计划提供完整上下文、日志和约束优先小步迭代不追求一步到位关键节点及时 commit把有效规则沉淀到AGENTS.md或团队文档