第 60 卷

• 是否有不确定的业务假设

1. 审查结论

请最后给出结论：

• 可以继续
• 需要小修
• 需要回退部分修改
• 需要重新制定计划

注意：

只审查，不要继续修改代码。

如果发现问题，请先说明问题和建议，等我确认后再改。

第六步：提交与复盘

代码测试通过、审查完成后，最后一步不是简单地说“完成了”。

真正完整的 Codex 工作流，还需要做两件事：

第一，把这次修改正式提交。第二，把这次经验沉淀下来。

很多人用 Codex 只做到“代码能跑”，但没有提交说明、没有 PR 描述、没有记录问题、没有更新文档。

这样短期看没问题，长期就会出现一个麻烦：

每次都像第一次做。每次都要重新解释。每次都重复踩坑。

所以第六步的核心是：

交付不是结束，复盘才是下一次效率提升的开始。

生成 commit

当这次修改已经通过测试和审查后，就可以让 Codex 帮你生成 commit。

commit 不是随便写一句“update”就行，而是要说明这次到底改了什么。

好的 commit 应该能回答：

问题说明

改了什么本次提交的主要内容

为什么改对应什么需求或问题

是否通过测试是否构建、lint、测试通过

常见 commit message 格式：

feat: add user profile page

fix: resolve login redirect issue

style: improve homepage responsive layout

refactor: simplify product card component

docs: update setup guide

如果是中文项目，也可以写成：

feat: 新增用户资料页

fix: 修复登录后跳转异常

style: 优化首页移动端布局

docs: 更新项目使用说明

写 PR

如果项目使用 GitHub、GitLab 或团队协作流程，提交后通常还要写 PR。

PR 的作用不是“走形式”，而是让别人快速知道：

PR 要说明什么作用

一个好的 PR 描述可以这样写：

• 优化首页首屏标题、副标题和 CTA 按钮
• 调整移动端首屏布局
• 保留原有跳转逻辑，没有修改接口和路由

## 测试结果

• npm run lint 通过
• npm run build 通过
• 手动检查首页桌面端和移动端显示正常
• 点击 CTA 按钮跳转正常

## 风险说明

• 本次涉及首页样式调整，需要重点确认移动端显示
• 没有新增依赖
• 没有修改登录、接口、数据库逻辑

记录问题

复盘时，要把这次过程中遇到的问题记录下来。

这一步非常重要。

因为 Codex 工作流里，真正有价值的不是“这次做完了”，而是：

下次遇到类似问题，可以少走弯路。

需要记录的问题包括：

问题类型示例

需求问题一开始需求描述不够清楚

计划问题Codex 计划里漏掉了移动端

修改问题Codex 顺手改了无关组件

测试问题项目没有 typecheck 命令

审查问题发现它误删了 fallback 逻辑

沟通问题提示词没有明确“不要新增依赖”

记录格式可以很简单：