Codex 干货使用技巧：从会用到用好

Codex 不只是一个“帮我写代码”的工具，更像一个可以读项目、改代码、跑命令、查问题、写文档、做重构的开发协作助手。对有经验的工程师来说，真正的价值不是让它替代判断，而是让它帮你加速探索、减少重复劳动、提高交付质量。

下面按常见应用场景，用 FAQ 的方式整理一套实用技巧。

1. Codex 适合做什么？

适合：

• 阅读陌生项目，快速了解结构、入口、模块关系
• 查找 Bug，分析报错，定位根因
• 编写新功能、补接口、补单元测试
• 重构旧代码，统一风格，降低重复
• 生成 SQL、数据迁移脚本、接口文档
• 分析日志、配置文件、CI 报错
• 搭建原型、写工具脚本、批量处理文件
• 做代码审查，发现潜在风险

不适合：

• 完全不说明业务背景，让它凭空猜核心逻辑
• 直接处理生产数据库或高风险操作
• 在没有验证的情况下直接上线它生成的代码
• 让它替代架构决策、权限设计、资金结算等关键判断

建议：
把 Codex 当作“高级开发助理”，你负责目标、边界和判断，它负责搜索、分析、实现和验证。

2. 如何让 Codex 更懂我的项目？

可以在项目根目录写一个 AGENTS.md，告诉 Codex 项目背景、技术栈、代码规范和注意事项。

示例：

# 项目说明

这是一个宽带客户运营支撑系统，核心模块包括：
- 客户资料
- 套餐计费
- 工单处理
- 缴费记录
- 客服知识库

## 技术栈

- 后端：PHP / .NET
- 数据库：MSSQL / MySQL
- 前端：Vue / jQuery
- 部署：Windows Server + IIS / Nginx

## 编码要求

- 不要随意修改数据库字段名
- 修改 SQL 前必须说明影响范围
- 涉及计费、余额、缴费逻辑时必须特别谨慎
- 尽量保持现有代码风格

这样 Codex 每次进入项目时，会先参考这些说明，减少重复解释。

3. 如何让 Codex 快速理解一个旧系统？

可以这样问：

请先不要改代码。帮我阅读这个项目，整理：
1. 项目目录结构
2. 主要入口文件
3. 核心业务模块
4. 数据库相关代码位置
5. 你认为后续维护最需要注意的风险点

适合场景：

• 接手老项目
• 准备重构
• 准备加新功能
• 项目文档缺失

Codex 会先搜索文件、阅读代码，再给你一份项目画像。这个步骤很重要，因为它能避免一上来就乱改。

4. 如何让 Codex 帮我定位 Bug？

不要只说“程序报错了”，最好提供三类信息：

现在登录接口报错，错误信息如下：
[粘贴错误日志]

请帮我：
1. 定位可能出错的文件和函数
2. 分析根因
3. 给出最小修改方案
4. 修改后帮我检查是否影响其他逻辑

如果有复现步骤，效果更好：

复现步骤：
1. 打开客户管理
2. 搜索手机号 138xxxx
3. 点击缴费记录
4. 页面报 500

Codex 比较擅长从日志、调用链、SQL、配置中找问题。你给的信息越接近现场，它越容易定位。

5. 如何让 Codex 改代码更稳？

推荐使用这个提问模板：

请实现 xxx 功能，要求：
1. 尽量保持现有代码风格
2. 修改范围尽量小
3. 不要改无关文件
4. 涉及数据库变更时先说明方案，不要直接执行
5. 修改后运行相关测试或给出验证方法

如果是关键业务，比如计费、余额、权限，建议再加一句：

这是核心业务逻辑，请先分析现有流程，再给出修改计划，确认风险点后再动代码。

6. 如何让 Codex 写 SQL 更安全？

可以这样要求：

请根据现有表结构写一个查询 SQL：
需求：查询最近 30 天欠费用户，显示客户编号、姓名、手机号、套餐、欠费金额。

要求：
1. 先分析相关表关系
2. 不要使用 SELECT *
3. 说明索引建议
4. 如果 SQL 可能慢，请给出优化方案

如果是更新或删除 SQL，必须要求它先给预览 SQL：

请先生成 SELECT 预览语句，确认影响数据范围后，再生成 UPDATE 语句。

这是数据库工程中非常重要的习惯。

7. 如何让 Codex 帮我做代码审查？

可以直接说：

请以代码审查的方式检查最近的修改，重点关注：
1. 业务逻辑错误
2. SQL 注入风险
3. 空值异常
4. 权限绕过
5. 性能问题
6. 是否缺少测试

如果你只想看问题，不想听客套话，可以加：

请只列出具体问题，按严重程度排序，并给出文件和行号。

适合提交前自查、合并前复查、上线前风险扫描。

8. 如何让 Codex 帮我重构旧代码？

重构不要一口气让它“大改”。推荐分阶段：

请先分析这个模块的重复代码、复杂函数和潜在风险，不要修改。

然后：

请只重构 xxx 函数，要求：
1. 保持外部行为不变
2. 不改变数据库结构
3. 不改变接口返回格式
4. 重构后说明前后差异

最后再补测试或验证方法。

旧系统重构尤其要控制范围。Codex 很适合做“小步重构”，不适合一次性“大换血”。

9. 如何让 Codex 帮我写文档？

可以让它基于代码生成真实文档：

请根据当前项目代码，整理一份接口文档，包含：
1. 接口地址
2. 请求方式
3. 请求参数
4. 返回字段
5. 错误码
6. 业务说明

也可以整理维护文档：

请根据代码整理这个模块的维护说明：
1. 模块职责
2. 主要流程
3. 涉及的数据表
4. 常见问题
5. 修改注意事项

这对老项目非常有价值，尤其适合补齐历史欠账。

10. 如何让 Codex 帮我生成测试用例？

可以这样问：

请为这个缴费逻辑设计测试用例，覆盖：
1. 正常缴费
2. 欠费缴费
3. 重复缴费
4. 金额为 0
5. 金额为负数
6. 客户不存在
7. 数据库异常

如果已有测试框架，可以继续：

请按照项目现有测试框架补充自动化测试。

如果没有测试框架，也可以让它先写手工测试清单。

11. 如何让 Codex 不乱改？

你可以明确边界：

只允许修改以下文件：
- xxx.php
- xxx.sql

不要修改其他文件。

或者：

请先给出修改计划，不要直接改代码。

再或者：

如果需要新增依赖、修改数据库结构、调整接口返回格式，必须先问我。

Codex 很听边界。边界越清楚，结果越稳定。

12. 如何让 Codex 解释复杂代码？

可以这样问：

请解释这个函数的业务逻辑，不要逐行翻译代码。请按：
1. 输入是什么
2. 处理流程是什么
3. 输出是什么
4. 有哪些异常分支
5. 可能有什么风险

这比“解释这段代码”效果好很多。

13. 如何用 Codex 做运维排查？

适合分析：

• Nginx / IIS 配置
• PHP / .NET 报错日志
• MySQL / MSSQL 慢查询
• 定时任务失败
• Windows 服务异常
• CI/CD 构建失败

示例：

这是服务启动失败日志，请帮我分析：
1. 根因可能是什么
2. 需要检查哪些配置
3. 给出排查顺序
4. 哪些操作有风险，不能直接执行

14. Codex 最好用的工作方式是什么？

推荐流程：

先读代码 -> 再分析 -> 再计划 -> 再修改 -> 再验证 -> 再总结

你可以直接这样要求：

请按以下流程处理：
1. 先阅读相关代码
2. 总结现有逻辑
3. 给出修改方案
4. 实施最小改动
5. 运行验证
6. 最后说明改了什么、如何测试

这套流程特别适合复杂项目。

15. 一些高质量提示词模板

分析项目：

请阅读当前项目，整理项目结构、核心模块、技术栈、主要入口和维护风险。先不要修改代码。

修 Bug：

请根据错误日志定位问题，找出根因，给出最小修复方案，并修改代码。修改后请说明验证方法。

加功能：

请实现 xxx 功能，保持现有代码风格，修改范围尽量小。涉及数据库或接口兼容性时先说明风险。

审查代码：

请以资深工程师代码审查的方式检查本次修改，重点关注 Bug、安全、性能、兼容性和测试缺口。

生成 SQL：

请根据表结构生成 SQL。要求不要使用 SELECT *，说明查询逻辑、索引建议和潜在性能问题。

写文档：

请根据代码生成模块维护文档，包括模块职责、业务流程、涉及表、接口说明和修改注意事项。

总结

Codex 的核心用法不是“让 AI 替我写代码”，而是让它参与完整的软件工程流程：

• 帮你读代码
• 帮你找问题
• 帮你做小步修改
• 帮你补测试
• 帮你写文档
• 帮你沉淀经验

对经验丰富的工程师来说，Codex 最有价值的地方在于：它能把大量重复、繁琐、低价值的工作自动化，让你把精力放在架构判断、业务边界、数据安全和系统长期演进上。