摘要

现在很多人用 AI 写代码，但真正能提升效率的，不是让 AI 随便生成一段代码，而是把 AI 放进完整开发流程里：读项目、拆需求、写代码、跑测试、做 review、整理 PR。本文以 Codex 为例，介绍一套适合个人开发者和团队使用的 AI 编程工作流。

一、为什么不要只让 AI “写代码”？

很多新手使用 AI 编程工具时，第一句话通常是：

帮我写一个登录功能。

这类提示词看似直接，但问题很多：

• AI 不知道你的项目结构；
• AI 不知道你使用什么框架；
• AI 不知道现有接口规范；
• AI 不知道哪些文件可以改；
• AI 不知道最后如何验收。

所以更好的方式是：让 AI 先理解项目，再开始动手。

Codex 官方文档中也把 Codex 覆盖到 App、IDE Extension、CLI、Web 等不同使用场景，并包含配置、权限、自动化等开发工作流能力。(developers.openai.com)

二、推荐工作流

1. 先让 Codex 读代码

请先阅读当前项目结构，不要修改文件。 帮我说明： 1. 项目入口在哪里； 2. 前端和后端分别在哪些目录； 3. 测试命令是什么； 4. 登录相关逻辑在哪些文件。

这一步的目标不是产出代码，而是建立上下文。

2. 再让 Codex 拆需求

我要新增 GitHub 登录功能。 请先给出实现方案，包括： 1. 需要修改哪些文件； 2. 前后端分别做什么； 3. 可能的风险点； 4. 如何验证。 暂时不要改代码。

复杂需求一定先看方案，尤其是认证、支付、权限、数据库迁移这类功能。

3. 控制修改范围

按照刚才的方案实现。 要求： 1. 只修改必要文件； 2. 不引入新的 UI 风格； 3. 不重构无关代码； 4. 保留现有登录方式。

这一步很关键。很多 AI 代码问题不是“不会写”，而是“改太多”。

4. 让 Codex 自己验证

请运行相关测试和构建命令。 如果失败，请先分析原因，再决定是否修改。

AI 写完代码后，必须验证。常见验证方式包括：

npm run test npm run build npm run lint

不同项目命令不同，以项目实际配置为准。

5. 最后让 Codex 生成 PR 总结

请总结本次修改： 1. 修改了哪些文件； 2. 实现了什么功能； 3. 如何验证； 4. 是否还有风险。

这段内容可以直接改成 PR 描述。

三、一个完整提示词模板

请帮我实现：[功能名称] 工作方式： 1. 先阅读相关代码，不要立即修改； 2. 给出实现方案和影响范围； 3. 经确认后再做最小必要修改； 4. 修改后运行测试/构建； 5. 最后输出修改总结、验证结果和风险点。 约束： - 不改无关文件； - 不引入不必要依赖； - 保持现有代码风格； - 如果需求不明确，先问我。

四、适合 Codex 的任务

Codex 很适合：

• 修复测试失败；
• 增加小型功能；
• 梳理陌生模块；
• 编写单元测试；
• 做代码 review；
• 整理 README；
• 生成 PR 描述。

不建议一开始就让它做超大任务，比如“一次性重构整个系统”。大任务要拆成小任务。

五、避坑指南

第一，不要只说“优化一下”。
要明确是优化性能、结构、可读性，还是用户体验。

第二，不要跳过 review。
AI 生成的代码也要像普通代码一样检查。

第三，不要让 AI 独自决定核心业务逻辑。
支付、权限、风控、数据迁移等功能，建议先看方案。

第四，不要把多个目标塞进一个任务。
“修 bug + 改 UI + 升级依赖 + 写文档”最好拆开做。

总结

Codex 的核心价值不是替你写几行代码，而是帮你完成一条完整链路：

理解项目 -> 拆解需求 -> 修改代码 -> 运行验证 -> 总结交付

如果你把 Codex 当成“开发协作者”，而不是“代码生成器”，它的稳定性和效率会明显提升。