Codex配合使用Git安全修改代码的完整流程完整指南

平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“Codex配合采用Git安全修改代码的完整流程”来说，它看着像小点，放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序，把思路、关键写法和容易踩坑的地方讲清楚，便于大家直接对照操作。

用 Codex 改代码时，我最强烈的建议是：一定要配合 Git 采用。

理解这一步时，Codex 很适合帮我们读代码、改代码、排查 bug、补文档、做 review。但只要它开始修改文件，问题就来了：你要知道它改了什么、哪些改动能够留下、哪些改动应该撤掉、出了问题能不能回到修改前。

这时候 Git 就很重要。

落到代码里，OpenAI 官方文档里也建议，在让 Codex 开始任务前后新建 Git checkpoint，便于后续回退；Codex 的 code review 功能也依赖 Git 仓库里的 diff 来检查改动。轻松说，Git 是你和 Codex 协作时的“安全绳”。

这篇文章就按实际采用流程讲清楚：

修改前应该做什么

• Codex 修改过程中怎么看 diff
• 修改后怎么检查和提交
• 回滚前应该怎么判断

一、为什么 Codex 一定要配合 Git

若你只是让 Codex 解释代码，不一定需 Git。

但只要你让它做这些事，就建议先准备好 Git：

• 修改业务代码
• 重构模块
• 新增文件
• 删除无用逻辑
• 调整依赖和设置
• 批量改文档
• 修复 bug

原因很轻松：Codex 能够帮你做事，但你仍然需判断它做得对不对。Git 能让你看到完整改动，也能让你在不满意时撤回。

我自己的习惯是：

• 没有 Git，不让 Codex 大改。
• 工作区不干净，不让 Codex 直接动手。
• 任务太大，不让 Codex 一次做完。

二、修改前：先确认工作区是否干净

第一步永远是看状态。

git status

理解这一步时，如果输出里有 modified、deleted、untracked，就说明当前工作区已经有改动。

这时候先别急着让 Codex 修改。你要先判断这些改动是谁做的：

• 是你刚才手动改的
• 是上一轮 Codex 改的
• 是编辑器自动格式化的
• 是临时文件或构建产物

结合项目来看，若你在一个已经很乱的工作区里继续让 Codex 改，后面很容易分不清“哪些是它改的，哪些是原本就有的”。

三、修改前：最好新建一个分支

若任务稍微复杂一点，建议单独开分支。

git switch -c codex/fix-login-error

分支名能够按任务来起：

codex/fix-login-error
codex/add-readme
codex/refactor-auth
codex/update-api-client

这样做的好处是：

• 当前任务有独立边界
• 不会直接污染主分支
• 后续能够单独提交、单独回滚
• 若改坏了，直接丢弃这个分支也更轻松

若你不想建分支，至少也要保证当前分支已经有一个干净的提交点。

四、修改前：把已有改动先处理掉

如果 git status 显示有未提交改动，通常有三种处理方式。

方式一：先提交

如果这些改动已经完成，能够先提交：

git add .
git commit -m "保存当前工作进度"

然后再让 Codex 开始新任务。

方式二：先 stash

若这些改动还没完成，但又想临时放起来，能够用：

git stash push -m "临时保存修改"

后面需恢复时再看：

git stash list
git stash show -p stash@{0}
git stash apply stash@{0}

落到代码里，Git 官方文档里对 stash 的描述很直接：它适合临时保存当前工作目录和暂存区状态，随后让工作区回到干净状态。

方式三：先开新 worktree

落到代码里，若你手头的改动不能动，但又想让 Codex 做另一个任务，能够考虑单独开一个 worktree。

理解这一步时，这个方式更适合熟悉 Git 的用户。它的好处是：你能够给 Codex 一个干净目录，让它只在那个目录里做当前任务。

五、给 Codex 的第一个提示词：先看状态，不要动手

在真正修改前，能够先这样问：

请先检查当前项目的 Git 状态，不要修改任何文件。
告诉我：
1. 当前分支是什么
2. 是否有未提交改动
3. 是否有未跟踪文件
4. 是否适合开始新的修改任务

这个提示词很实用。

它能让 Codex 先帮你看一眼当前现场。

若状态不干净，你能够继续让它解释：

请根据当前 Git 状态，帮我判断哪些文件可能是本次任务无关改动。
不要修改文件，只做分析。

六、修改中：让 Codex 小步提交思路，而不是一次改到底

不要一上来就说：

帮我重构整个登录模块。

更稳的方式是拆成三步。

第一步，定位：

请先定位登录模块相关文件，不要修改代码。
列出相关组件、接口调用、状态管理和错误处理位置。

第二步，方案：

请给出最小修改方案。
要求说明准备修改哪些文件、每个文件改什么、可能有什么风险。
暂时不要动手。

第三步，执行：

可以按方案修改。
只修改刚才列出的文件。
不要做无关优化。
修改后告诉我实际改了哪些文件。

这样 Git diff 会更清楚，后续 review 和回滚也更容易。

七、修改中：随时看 diff

Codex 改完一轮后，不要急着继续给新任务。

先看 diff。

看所有改动概览：

git diff --stat

看具体未暂存改动：

git diff

看已经暂存的改动：

git diff --staged

Git 官方文档里说明，git diff 能够查看工作区相对于暂存区的变化，git diff --staged 则用来查看已经暂存、准备提交的变化。

如果你只想看某个文件：

git diff -- src/pages/Login.tsx

这个习惯很重要。

Codex 说它只改了 A 文件，但你最好自己用 Git 再确认一次。

八、修改后：让 Codex 写变更摘要

修改完成后，能够让 Codex 做一次总结：

请总结本轮修改：
1. 修改了哪些文件
2. 每个文件改了什么
3. 为什么这样改
4. 是否存在风险点
5. 如何手动验证

然后你再对照：

git diff --stat
git diff

若 Codex 的总结和 Git diff 对不上，就要提高警惕。

九、修改后：先 review，再提交

如果你用的是兼容 /review 的 Codex 环境，能够让它 review 当前改动。

/review

也能够手动写：

请 review 当前未提交改动。
重点检查：
1. 是否有回归风险
2. 是否有边界情况遗漏
3. 是否有无关修改
4. 是否有潜在安全问题
5. 是否需要补测试

在这个场景下，OpenAI 官方文档说明，Codex 能够 review uncommitted changes、commit 或 base branch，同时且 review 过程不会修改工作区。这个特性很适合提交前检查。

十、修改后：分批暂存，不要无脑 add .

若改动很小，git add . 问题不大。

但如果 Codex 改了多个文件，建议分批暂存：

git add src/pages/Login.tsx
git add src/utils/auth.ts

如果你想更精细一点，能够用：

git add -p

这样能够按 hunk 选择要提交的内容。

为什么不建议长期无脑 git add .？

因为它可能把这些东西也加进去：

• 临时文件
• 日志文件
• 本地设置
• 调试代码
• Codex 顺手生成但你不需的文件

提交前再看一次：

git diff --staged

确认没问题后提交：

git commit -m "fix: improve login error message"

十一、回滚前：先判断你要撤的是哪一种改动

回滚不是一个命令解决所有问题。

你先要判断自己要撤掉的是什么。

实际处理时，我不建议新手一上来就复制危险命令。尤其是 git reset --hard 和 git clean，它们会丢弃大量本地内容，除非你很确定，否则不要随手用。

十二、回滚前：让 Codex 先解释，不要让它直接删

若你不确定该怎么撤，能够先这样问 Codex：

请根据当前 Git diff，判断如果我要撤回本次修改，应该撤哪些文件。
不要执行任何回滚命令，只给我建议。

再让它具体一点：

请把当前修改分成三类：
1. 建议保留
2. 可以撤回
3. 需要我人工确认
不要修改文件。

这一步能避免你一冲动把有用改动也删掉。

十三、一个安全的回滚流程

若你想撤掉 Codex 的某次修改，能够按这个顺序来：

1. git status
2. git diff --stat
3. git diff
4. 让 Codex 解释哪些改动属于本次任务
5. 只 restore 明确不要的文件
6. 再次 git diff 确认结果

对应命令大概是：

git status
git diff --stat
git diff
git restore src/pages/Login.tsx
git diff --stat

重点是：先看，再撤。

不要在没看 diff 的情况下直接清空所有修改。

十四、一个完整示例：让 Codex 修登录报错

假设你要让 Codex 修登录失败提示。

第一步：准备 Git 环境

git status
git switch -c codex/fix-login-message

第二步：让 Codex 先定位

请先定位登录失败提示相关代码，不要修改任何文件。
告诉我相关页面、接口调用和错误处理分别在哪里。

第三步：让 Codex 给方案

请给出最小修改方案。
目标：登录失败时展示更明确的错误提示。
要求：不改变登录接口，不影响注册页面。
暂时不要修改代码。

第四步：允许修改

可以按方案修改。
只修改登录页面和错误提示相关文件。
不要做无关重构。

第五步：检查 diff

git diff --stat
git diff

第六步：让 Codex review

请 review 当前修改。
重点检查是否影响正常登录、注册跳转、表单校验和错误提示展示。

第七步：提交

git add src/pages/Login.tsx
git commit -m "fix: improve login error message"

这样一套下来，你会很清楚：

• 任务从哪里开始
• Codex 改了什么
• 改动有没有越界
• 如果出问题怎么回退

十五、适合收藏的提示词模板

修改前

请先检查当前 Git 状态，不要修改任何文件。
告诉我当前分支、未提交改动、未跟踪文件，以及是否适合开始新任务。

修改中

请只完成当前任务，不要做无关优化。
如果发现需要修改额外文件，请先说明原因，等我确认。

修改后

请总结本轮修改：
1. 改了哪些文件
2. 每个文件改了什么
3. 有哪些风险
4. 如何验证

回滚前

请根据当前 Git diff，判断哪些改动应该保留，哪些可以撤回，哪些需要人工确认。
不要执行任何回滚命令。

十六、总结

从实现思路看，Codex 和 Git 搭配起来，真正的价值不是“让 AI 随便改代码”，而是让整个过程可控：

修改前有 checkpoint
修改中能看 diff
修改后能 review
不满意能回滚
最终能提交成清晰 commit

我现在用 Codex 的基本原则是：

1. 先看 git status
2. 复杂任务先开分支
3. Codex 先分析，再修改
4. 改完先看 diff
5. 提交前让它 review
6. 回滚前先让它解释改动

这样用起来会稳很多，也更像一个正常的开发协作流程。

从实现思路看，总的来说，Codex适合结合实际项目边做边理解。先抓住核心思路，再逐步补上细节和边界处理，最后效果会更稳定，也更容易复用。