摘要

很多开发者升级 ChatGPT Pro 后，会尝试让 Codex 直接完成完整需求。但真实项目往往包含业务规则、目录规范、接口限制、测试要求和代码审查流程，不能只靠一句“帮我实现功能”。本文以“订单导出功能”为例，演示如何把一个真实需求拆成分析、方案、实现、测试和交付五个阶段。

---

很多人使用 Codex 时，会直接输入：

帮我增加一个订单导出功能。

这句话看起来没有问题，但信息远远不够。

Codex 不知道：

• 导出哪些字段；

• 是否支持筛选条件；

• 导出 CSV 还是 Excel；

• 数据量有多大；

• 由前端还是后端生成文件；

• 是否需要权限控制；

• 导出失败如何提示；

• 是否允许重复提交。

如果这些问题没有提前明确，AI 只能按照自己的理解生成方案。

真实项目中，更稳定的方式不是让 Codex 一次完成所有工作，而是分阶段推进。

一、第一阶段：只做需求分析

先让 GPT 或 Codex 把需求拆清楚。

可以这样写：

需求：订单列表增加导出功能。

请先不要修改代码，只分析：

1. 用户操作流程；
2. 需要导出的字段；
3. 是否复用当前筛选条件；
4. 前端和后端分别需要做什么；
5. 权限和数据安全风险；
6. 异常场景；
7. 验收标准。

这一步非常重要。

例如，AI 可能会提醒你确认：

• 是否允许普通员工导出全部订单；

• 手机号、地址等字段是否属于敏感信息；

• 导出数量是否有限制；

• 大数据量是否要使用异步任务；

• 文件链接是否需要有效期。

这些问题如果等到代码写完才发现，返工成本会更高。

二、第二阶段：让 Codex 分析现有项目

需求确认后，再让 Codex 阅读相关目录。

请分析当前订单模块，不要修改代码。

允许读取：

- src/views/order
- src/api/order.ts
- src/types/order.ts
- tests/order

请输出：

1. 订单列表页面入口；
2. 当前筛选条件存放位置；
3. 接口请求封装方式；
4. 是否已有文件下载工具；
5. 建议修改哪些文件；
6. 哪些文件不建议修改。

这一步的目标不是生成代码，而是判断现有项目能否复用已有能力。

比如项目可能已经有：

• 通用下载函数；

• 权限指令；

• 请求 loading 状态；

• 文件名处理工具；

• 导出接口封装。

如果不先分析，Codex 很可能重复实现已有功能。

三、第三阶段：确定技术方案

订单导出通常有两种方案。

方案一：前端生成文件

适合数据量较小，且当前页面已经拿到全部数据的场景。

优点：

• 实现简单；

• 不需要额外后端接口；

• 交互响应快。

缺点：

• 大数据量容易卡顿；

• 可能无法导出全部数据；

• 敏感字段控制较弱。

方案二：后端生成文件

适合数据量较大、权限复杂或需要导出全部数据的场景。

优点：

• 更适合大数据量；

• 权限和字段控制更集中；

• 可以支持异步导出。

缺点：

• 需要后端配合；

• 需要处理任务状态；

• 实现链路更长。

可以让 Codex 输出方案对比：

请根据当前项目情况，对比前端导出和后端导出。

输出：

1. 两种方案的优缺点；
2. 当前项目更适合哪一种；
3. 涉及文件；
4. 主要风险；
5. 推荐的最小实现方案。

先确定方案，再进入编码，可以避免实现到一半才发现方向不合适。

四、第四阶段：限制修改范围

假设最终选择后端导出，可以这样下任务：

本次只实现订单列表导出入口。

允许修改：

- src/views/order/List.vue
- src/api/order.ts
- src/types/order.ts
- tests/order

禁止修改：

- 用户模块
- 支付模块
- 路由配置
- package.json
- 全局样式

要求：

1. 复用当前筛选条件；
2. 不新增第三方依赖；
3. 不改变已有订单列表接口；
4. 导出期间按钮显示 loading；
5. 接口失败时恢复按钮状态；
6. 防止重复点击；
7. 使用现有文件下载工具。

任务写得越明确，Codex 越容易生成符合项目结构的代码。

五、第五阶段：提前设计测试场景

导出功能不只是“点击后能下载”。

至少要覆盖下面这些场景：

请为订单导出功能设计测试场景：

1. 无筛选条件时正常导出；
2. 带订单状态筛选时正确传参；
3. 带时间范围时正确传参；
4. 接口失败时显示错误提示；
5. 连续点击时只发送一次请求；
6. 导出成功后恢复按钮状态；
7. 无导出权限时不显示按钮；
8. 文件名包含当前日期。

如果项目已有测试框架，可以继续让 Codex 编写测试。

测试场景提前确定，也能反过来检查需求是否完整。

六、第六阶段：运行验证命令

代码完成后，不要只看页面能不能点击。

建议运行：

npm run type-check
npm run test
npm run build

还要手动验证：

• 筛选条件是否正确传递；

• 按钮 loading 是否正常；

• 失败后能否恢复；

• 下载文件是否可打开；

• 文件名是否正确；

• 无权限用户是否看不到入口。

对于导出这类功能，接口成功不代表任务完成，文件内容也需要检查。

七、第七阶段：查看 Git Diff

建议执行：

git status
git diff --stat
git diff

重点看：

• 是否修改无关文件；

• 是否重新实现已有下载工具；

• 是否改变订单查询接口；

• 是否引入新依赖；

• 是否遗漏错误处理；

• 是否补充必要测试。

还可以让 Codex做一次审查：

请审查本次订单导出功能的 Git Diff。

重点检查：

1. 是否存在无关修改；
2. 是否正确复用筛选条件；
3. 是否有重复提交风险；
4. loading 是否能在异常时恢复；
5. 是否改变旧接口；
6. 是否缺少权限和异常测试。

先输出风险，不要直接修改代码。

先审查，再决定是否调整，能够避免 AI 在自查过程中继续扩大修改范围。

八、第八阶段：输出交付说明

最后，让 Codex 输出一份团队可读的总结。

## 本次任务

增加订单列表导出功能。

## 修改文件

- src/views/order/List.vue
- src/api/order.ts
- src/types/order.ts
- tests/order

## 主要实现

- 增加订单导出按钮；
- 复用当前列表筛选条件；
- 增加导出接口封装；
- 增加 loading 和重复提交保护；
- 补充导出相关测试。

## 验证结果

- 类型检查：通过
- 测试：通过
- 构建：通过
- 手动下载验证：通过

## 注意事项

- 导出字段由后端控制；
- 无权限用户不显示导出按钮；
- 大数据量导出策略需后端继续评估。

这份说明可以直接用于 Pull Request、任务记录或团队同步。

九、升级 Pro 后，更适合处理哪类任务？

如果只是偶尔写一个函数、解释报错、改一个文件，Plus 通常已经够用。

如果经常处理类似订单导出这种任务，需要连续完成：

• 需求分析；

• 项目阅读；

• 方案设计；

• 多文件修改；

• 测试验证；

• Git Diff 审查；

• 交付总结；

那么更高版本更容易体现价值。

升级 Pro 的意义不是让 Codex 一次写更多代码，而是让完整工程任务更容易连续推进。

十、一套可以复用的真实任务模板

任务名称：

业务目标：

允许读取：

允许修改：

禁止修改：

项目规则：

执行阶段：
1. 需求分析；
2. 项目分析；
3. 方案设计；
4. 最小范围实现；
5. 测试验证；
6. Git Diff 审查；
7. 输出交付总结。

验收标准：

风险项：

这套模板可以用于：

• 订单导出；

• 文件上传；

• 用户资料编辑；

• 权限控制；

• 列表筛选；

• 消息提醒；

• Bug 修复；

• 模块重构。

总结

升级 ChatGPT Pro 后，Codex 的正确打开方式不是直接接管整个项目，而是接手一个边界清楚、结果可验证的开发任务。

更稳定的流程是：

先拆需求，再看项目；先定方案，再改代码；先跑测试，再看 Diff；最后输出交付总结。

当 Codex 能够稳定参与这些环节时，它才真正从代码生成工具变成开发协作工具。

版本提供的是使用空间，工程流程决定的是最终质量。

---

CSDN 文章描述

升级 ChatGPT Pro 后，Codex 如何接手一个真实开发任务？本文以订单导出功能为例，完整演示需求分析、项目阅读、方案设计、代码实现、测试验证、Git Diff 审查和交付总结流程。

推荐标签

ChatGPT Pro Codex AI编程 项目实战 软件开发

参考资料

1. OpenAI Codex 官方文档

2. OpenAI Developers：Codex CLI

3. GitHub Docs：Pull Request 与代码审查实践

4. TypeScript 官方文档