摘要

不少开发者升级 ChatGPT Pro 后，会明显增加 GPT 和 Codex 的使用频率。但实际使用过程中，很多人仍然停留在“写代码、修 Bug”的阶段，没有真正发挥 AI 在项目分析、需求拆解、代码审查和开发协作中的价值。本文结合真实开发场景，分享 5 个很多开发者容易忽略，但能够明显提升效率的使用技巧。

---

很多开发者第一次接触 ChatGPT 时，主要用它做这些事情：

• 查询语法；

• 解释报错；

• 写几个工具函数；

• 翻译技术文档；

• 修改 SQL。

这些场景当然有帮助，但随着项目越来越复杂，AI 的价值也不应该只停留在代码生成。

尤其是在升级 Pro 后，更适合把 GPT 和 Codex 放进整个开发流程，而不是只在写代码的时候打开一次。

一、不要直接写代码，先让 AI 帮你拆需求

很多开发任务返工，并不是代码写错，而是需求理解不一致。

例如：

增加订单退款功能。

真正开发时，还需要考虑：

• 是否支持部分退款；

• 是否允许重复申请；

• 是否限制退款时间；

• 是否需要管理员审核；

• 是否影响库存；

• 是否需要通知用户。

开始写代码之前，可以先让 GPT 输出需求分析。

例如：

请分析订单退款功能。

输出：

1、业务流程；

2、涉及页面；

3、涉及接口；

4、状态变化；

5、异常场景；

6、测试方案。

需求越清楚，后面的开发越稳定。

---

二、让 Codex 先阅读项目，而不是直接修改

很多开发者喜欢：

帮我修改这个项目。

其实更推荐：

先分析项目。

不要修改代码。

请说明：

项目结构；

模块关系；

主要入口；

可能涉及的文件；

风险点。

Codex 理解项目以后，再开始修改，成功率通常更高。

尤其是大型项目，这一步非常重要。

---

三、固定一套任务模板

如果每天都让 Codex 做项目，可以准备一套固定模板。

例如：

任务目标：

允许修改：

禁止修改：

执行步骤：

测试命令：

输出总结。

每次只修改任务内容。

相比临时想到什么写什么，这种方式更容易保持稳定。

---

四、不要忽略代码审查

AI 写完代码以后，不建议直接提交。

建议固定执行：

git diff

然后重点检查：

• 修改范围；

• 是否影响旧功能；

• 是否新增依赖；

• 是否改变接口；

• 是否存在重复逻辑。

如果发现 Diff 很大，可以继续让 Codex：

请压缩改动范围，只保留必要修改。

很多时候，经过一次审查，代码会更容易维护。

---

五、把 GPT 当成开发助手，而不是代码生成器

很多开发者认为：

AI = 写代码。

实际上，更推荐这样分工：

GPT：

• 拆需求；

• 写方案；

• 总结文档；

• 输出测试用例；

• 编写 PR 描述。

Codex：

• 阅读项目；

• 修改代码；

• 分析日志；

• 修复问题；

• 输出 Git Diff。

这样两者各自发挥优势，开发效率会更高。

---

一套推荐的 AI 开发流程

建议形成固定工作流：

需求分析

↓

GPT 输出方案

↓

Codex 阅读项目

↓

Codex 修改代码

↓

运行测试

↓

Git Diff

↓

GPT 输出交付总结

整个流程固定以后，后续每个项目都可以重复使用。

---

总结

很多开发者升级 ChatGPT Pro 后，最大的变化不是代码写得更快，而是开始把 AI 放进整个开发流程。

相比只让 AI 写代码，更推荐：

• 用 GPT 分析需求；

• 用 Codex 理解项目；

• 用 GPT 整理方案；

• 用 Codex 修改代码；

• 用 Git Diff 做最终审查。

真正提升效率的，不是版本本身，而是一套可以长期复用的 AI 工作流。

---

参考资料

1. OpenAI Codex 官方文档

2. OpenAI Developers：Codex CLI

3. Git 官方文档

4. GitHub Docs：Pull Request Best Practices