企业官网建设流程全解析

最近AI编程工具圈子里最绕不开的两个名字就是 Claude Code 和 Codex。我身边不少朋友从“手动写代码”切换到了“给AI描述需求、让它自己改代码”的模式之后，都会遇到同一个尴尬问题：AI帮我改了一堆文件，我不确定它动了什么，更不敢直接提交。等到项目出了bug，想回退到某个稳定版本，看着一长串提交记录，整个人都是懵的。

这篇文章就把我在实际项目里把 Claude Code / Codex 和 Git 配合使用的完整流程写清楚。不聊虚的，直接讲怎么做、为什么这么做、遇到问题怎么查。无论你是刚装好Git的新手，还是已经在用AI工具但一直被版本管理困扰的开发者，这都能帮你把工作流理顺。

1. 为什么这两个AI工具都绕不开Git

1.1 AI工具本质上在“替你做修改”，Git是你最后的保险丝

Claude Code 和 Codex 这类终端里的AI编码工具，跟你在网页聊天框里问问题最大的区别是：它们可以直接读写你本地的项目文件，可以执行命令，可以在你的仓库里制造大规模改动。

这听起来很爽，但风险也很直接——AI一旦改错，或者改了一堆你不想要的逻辑，你是很难靠肉眼把所有变化都找回来的。我在实际使用中见过太多人，让Claude改一个需求，结果发现它顺手重构了三个不相关的函数。你要不是盯得紧，这个问题得等上线之后才能暴露出来。

Git在这里扮演的角色，就是那个“后悔药”和“对照镜”。每次AI动手之前，你先确认当前工作区是干净的，或者已经提交到一个临时分支；AI改完之后，你用git diff去审查它的每一次改动，满意了再提交。这个流程听起来多了一步，但恰恰是这一步让你对AI产出的代码拥有掌控权。

1.2 两个工具的定位差异：Claude Code重协作，Codex重会话

从Git集成的角度来看，这两个工具的侧重点并不一样。

Claude Code 更像是一个“结对编程搭档”，它的工作模式是在你已有的代码上下文里持续修改。你跟它在同一个仓库里对话，它可以跨多个文件追踪代码逻辑，也会在改动时提示你哪些文件变了。对于日常开发，它更像“驻场工程师”。

Codex 则更偏向于“任务型执行者”，你给它明确的指令，它在一个对话session里完成任务。它也能改代码、执行命令，但它整体设计上更倾向“做完就交付结果”。这倒不是说哪个好哪个坏，而是决定了你跟它们配合时，工作流的松紧程度不一样。

跟 Claude Code 配合，你可以更放心地让它做跨文件的逻辑调整；跟 Codex 配合，你最好把任务拆得足够小，每完成一小步就检查一次Git状态。这不是能力问题，是工具设计哲学带来的使用习惯差异。

2. 环境准备：一次装齐Git、Claude Code和Codex

2.1 Git安装与基础配置，别跳过这一步

很多教程默认你已经装好了Git，但我在帮人排查问题的时候发现，大量诡异报错的根源就是Git版本太老或者环境变量没配好。

Windows用户去Git官网下载安装包，一路Next就行。需要注意两个地方：

• 安装过程中选择“Git from the command line and also from 3rd-party software”，确保PATH被正确写入。
• 换行符转换选“Checkout as-is, commit as-is”，否则在Windows上拉下来的代码会出现大量CRLF/LF差异，git diff会变得没法看。

macOS用户如果有Homebrew，直接brew install git是最干净的。Linux用户各自用各自的包管理器，Ubuntu就是apt install git。

装完先验证版本并配置身份信息，这是所有提交的基础：

git --version git config --global user.name "Your Name" git config --global user.email "you@example.com"

提示：如果以前配过别的用户名，后续提交的时候一定要留意，很多AI工具生成的commit会默认读取这个全局配置。我之前就见过有人用自己的身份提交了AI写的代码，在多人协作的项目里很容易引起误会。

2.2 Claude Code安装与初次鉴权

Claude Code 的安装方式比较统一。在终端里执行：

npm install -g @anthropic-ai/claude-code

如果你Node环境比较干净，这一步很快。装完之后执行claude进入交互界面，首次启动会要求你登录Anthropic账号完成鉴权。这里有个坑：如果系统默认shell不是bash或zsh，可能会出现启动异常。我建议在终端里先确认echo $SHELL的输出，确保用的是标准shell。

有个热搜词特别有意思叫“claude code 超级小白入门指南”，说明这工具确实吸引了大量非专业开发者。如果你是第一次接触终端工具，我建议你不要急着让Claude直接改代码，先进入一个测试项目目录，执行claude，然后输入一句“describe this project”让它读README和项目结构。这一步能让你直观感受到它“理解项目”的方式。

2.3 Codex安装与登录

Codex 的安装同样走npm：

npm install -g @openai/codex

装完后执行codex，它也会引导你登录OpenAI账号，并生成对应的API key保存在本地。跟Claude Code一样，Codex也支持直接在终端交互式使用。

我自己在实际使用中，Codex和Claude Code都装在同一台机器上，它们各自有独立的配置目录，互不干扰。这一点可以放心。

2.4 用mise统一管理Node版本，环境问题少一半

很多人在安装这两个工具时遇到的“莫名其妙”的报错，根因都是Node版本过旧或过新。Claude Code 和 Codex 对Node的版本要求都在官方文档里写了，但很多人不看。

这里我推荐一个工具叫 mise（以前叫rtx），它是个多语言版本管理器。说得直白点，它就像一个Node版本的“中央空调”，你可以在不同项目目录指定不同Node版本，互不影响。

安装mise的常规方式：

curl https://mise.run | sh

然后把它加到shell配置里：

echo 'eval "$(~/.local/bin/mise activate bash)"' >> ~/.bashrc

接下来你只需要在项目目录里写一个.mise.toml，内容类似：

[tools] node = "20.12.0"

每次进入这个目录，mise会自动把Node切到20.12.0版本。这比我以前手动用nvm切换要省心很多，尤其是机器上同时跑了前端项目和后端项目的时候，版本切换不再靠脑子记。

实操心得：如果你已经在用nvm而且没出过问题，不一定要换。但如果你经常遇到“刚装好的工具过两天就启动报错”，大概率是Node版本在某个地方被动过。用mise锁住版本，能让你的AI工具环境稳定很多。

3. 核心工作流：如何让AI工具在Git仓库里“安全地干活”

3.1 先想清楚：AI工具到底该不该自动执行Git命令

这是使用AI编码工具时最核心的一个理念问题。

Claude Code 和 Codex 都有执行命令的能力。Claude Code 能直接运行git status、git diff，甚至帮你提交代码；Codex 也类似。但我要提醒你一个原则：让AI读Git信息是可以的，让AI自动提交代码要慎重，让AI做push更是要设红线。

为什么？

因为Git提交记录是你项目的“修改日志”，提交信息写得好不好，直接影响后来人（包括未来的你）排查问题的效率。AI生成的提交信息有时候很规范、有时候却非常泛泛，比如“Update files”这种提交，等于没写。

我自己的约定是这样的：

• AI可以自由执行git status、git diff、git log这些读取类命令。
• AI可以创建新分支、切换分支，但必须在任务开始前明确告诉我要做什么分支操作。
• AI不自动执行git commit，除非我明确在指令里说了“请提交到当前分支”。
• AI绝对不自动执行git push，推送到远端这个动作永远由我自己掌握。

这个约定可能看起来保守，但它能避免很多灾难。你想，如果AI理解偏了需求，改了一堆错误代码，然后它自己又自动提交并推送了，你在远端就留下了错误记录。虽然可以回退，但往往会带着一堆遗留成本。

3.2 Claude Code 的安全协作路径

Claude Code 在Git集成方面做得比较细腻。它在修改文件时会在对话里告诉你哪些文件被修改了。我通常的做法是让它每完成一个子任务，就主动执行一次git diff并给我展示变化。

你可以在Claude Code里直接跟它说：

请先查看 git status，然后告诉我当前工作区有什么改动。如果改动过多，请分批展示 git diff，重点关注逻辑变化，不要只列文件名。

Claude会照做。这个过程其实就是给AI加了一道“必须自证改动”的关卡，逼着它把改动逻辑讲清楚。我在实践里发现，只要你能让它说清“为什么改这一行”，80%的AI误改都能在commit之前被发现。

3.3 Codex 的分任务执行边界

Codex 更适合“一次只干一件事”的方式。比如你想让它修复某个具体的bug，可以这样组织：

先运行 git status 看看当前工作区状态，然后提取 index.js 文件里 handleSubmit 函数的逻辑，定位表单校验失败的原因，给出修复方案，不要动其他文件。

这里关键在“不要动其他文件”这句话。虽然AI不保证百分之百遵守，但明确约束范围之后，它的改动范围确实会收敛很多。

Codex 执行完任务后，我强烈建议你立刻运行：

git diff --stat

先看改了哪几个文件，再决定要不要继续深入看具体改动。如果git diff --stat显示改动的文件数量远超你的预期，别犹豫，直接git checkout -- .把改动全部丢弃，然后重新定义任务边界再来一次。

3.4 分支隔离：让AI在独立分支上施工

这是我在多个项目上验证过的最稳妥的方案：每次让AI做比较大的改动之前，先开一个新分支。

git checkout -b feature/ai-generated-fix

然后在这个分支上让Claude或Codex放开手脚去改。改完审查通过之后，再合并回主分支。这样做的好处非常多：

• 主分支保持干净，任何时候都能随时发布。
• AI改动可以随时整体丢弃，git branch -D就完事。
• 并行任务可以互不干扰，比如一个分支让Claude重构某个模块，另一个分支让Codex修另一个bug。

特别是当你同时用两个工具处理不同事情的时候，分支隔离几乎是唯一能保证不冲突的办法。我见过最惨的例子就是，有人让Claude和Codex同时在master分支上改代码，结果两者互相覆盖，最后出来的代码谁都不认识。

4. 高频场景实战：diff审查、commit规范和log追溯

4.1 用git diff喂给AI做代码审查，效果比让它直接看文件更好

这是我最推荐的一个用法：把diff内容直接贴给AI，让它做审查。

为什么比让它直接读文件更好？因为diff展示的是“变化”，而不是“全貌”。AI在审查diff时，会聚焦你实际改了什么，不容易被无关代码干扰。而且diff天然带有上下文，改动前后各几行，AI可以据此推断改动意图。

操作方式很直接，先把diff复制出来：

git diff

然后粘贴给Claude Code：

这是一次代码改动的diff，请帮我审查。重点检查： 1. 是否有逻辑错误或边界遗漏 2. 是否有潜在的性能问题 3. 是否符合项目现有代码风格 4. 是否有不必要的大范围重构

我试过很多次，这个用法比“你帮我看看这个项目有什么问题”要精准得多。AI在收到明确范围的diff后，给出的审查意见往往能击中要害。

4.2 用git log和git blame让AI理解修改历史

当你接手一个别人的项目，或者要改一段很久以前的代码，直接问AI“这个函数是干什么的”，它通常只能根据上下文猜。但如果让它先看提交历史，效果完全不同。

git log --oneline -10 -- path/to/file.js

把输出交给Claude Code，再问它这个文件最近的演进脉络，它的回答会更有历史纵深。类似的还有git blame，能看到每行代码是谁在什么时候改的。

这个习惯我是在一次线上事故排查里养成的。当时有个诡异的性能问题，怎么定位都找不到原因，最后是通过git log -p看一个函数的变更历史，发现是某次重构把缓存逻辑删掉了。从那以后，AI工具在我手里就不只是写代码的，也是查历史的。

4.3 git commit --amend 的正确使用场景

git commit --amend这个命令本身并不复杂，就是修改最近一次提交。它跟AI工具结合时，有个很实用的场景：你让AI改了代码，提交了一次，紧接着审查发现有个小问题，你让AI修掉之后，希望不要产生一个“fix typo”的垃圾提交，而是把修复合并到上一个提交里。

操作顺序是：

# 修改代码后暂存 git add . # 修改最近一次提交信息，或者保留原信息 git commit --amend --no-edit

--no-edit的意思是保留上一条提交信息不修改。这个组合几乎是我日常跟AI配合修改代码的标配：让AI改，我审查，小问题修复后amend，大问题就重新提交。

但要注意，amend会改写提交历史，如果你已经把提交push到了远端，就绝对不要再amend，否则会在协同开发时造成历史不一致。这条红线一定要记住。

5. 版本管理进阶：冲突处理、回滚策略和日志规范

5.1 AI遇到合并冲突，比你想的更常见

用AI改代码改了几天之后，你会发现一个没法避免的问题：合并冲突。特别是你让AI在分支上改了代码，主分支同时也有别的提交，合回来时冲突几乎是必然的。

让AI去解决冲突，有一个很重要的问题：AI可能只从局部视角处理冲突，丢掉另一方的逻辑。比如你在分支上改了函数A，主分支上同事改了函数B，两者恰好有依赖关系。AI在解决冲突的时候，可能只保留了你的分支逻辑，完全忽略了同事在函数B里加的兼容处理。

我的建议是：

1. 把冲突文件用git merge --abort回退，重新审视两个分支的差异。
2. 手动处理冲突，或者先把冲突文件的最新版本展示给AI，让它明确看到两边的代码。
3. 让AI给出冲突解决方案，但你自己要能看懂方案的取舍逻辑，不能无脑接受。

冷静说一句，AI解决冲突的能力在快速进步，但现阶段仍然需要人工把关。把“解决冲突”这个任务完全交给AI，在我看来是风险最高的操作之一。

5.2 回滚操作：给AI的指令要精确到提交号

遇到AI改坏了代码要回滚，最容易手忙脚乱。这里的关键是先搞清楚要回到哪个状态。

# 查看提交历史 git log --oneline -10 # 对比某一个历史提交和当前差异 git diff <commit-hash> HEAD

如果你确定要放弃当前所有未提交的改动，回到上一次提交的状态：

git checkout -- .

如果要回到过去某个提交，并丢弃之后的所有提交：

git reset --hard <commit-hash>

这个命令极其危险，--hard会直接丢弃工作区未提交的改动。我一般会再三确认再执行。如果你在用AI工具，也可以让它帮你查看提交历史，但执行reset --hard这个动作，请一定自己来。

我碰到过有人让AI自行回滚，AI执行了git reset --hard之后，把一整天未提交的工作全丢了。那不是AI的问题，是人给AI的权限太大了。

5.3 让AI遵守你的提交信息规范

提交信息直接决定项目的可维护性。我在团队里推行过一个简单的规范，现在跟AI配合时同样适用：

任务名称: 简短描述 - 详细说明1 - 详细说明2 Refs: #123

用这个模板跟Claude或Codex沟通很有用。你可以在项目的CLAUDE.md或者自定义指令里写清楚提交规范，Claude Code读取项目内配置后，生成的提交信息就会尽量贴近你的格式。

比如在项目根目录的CLAUDE.md里写：

## Git Commit 规范 - 提交信息格式：<type>(<scope>): <subject> - type 可选：feat / fix / refactor / docs / chore / test - scope 写模块名，例如 auth, api, ui - subject 用中文，不超过50字

后续让它帮你写提交信息，它就会按这个模板来。Codex 也有类似的系统提示词设定，你可以在启动参数里带上指令。习惯这个东西，一旦AI帮你养成了，你后面的项目都会受益。

6. 常见报错与真实排查链路

6.1 “cc switch local proxy failed while handling codex endpoint /responses” 这类报错

这个热搜词一看就是个具体报错，很多人在从Claude Code切换或调用Codex接口时碰到过。这个报错的核心关键词是local proxy和endpoint /responses。我先说结论：问题大多数出在本地配置的接口路由上。

我自己遇到过类似的情况，排查链路如下：

第一步，确认是不是工具版本问题。先升级到最新：

npm update -g @anthropic-ai/claude-code npm update -g @openai/codex

第二步，检查本地的配置文件。Claude Code和Codex都会在用户目录下生成配置文件，如果你之前手动改过API地址或者代理相关配置，很可能是这里写坏了。打开配置文件，确认接口地址指向正确。

第三步，查看终端里的完整报错。这种错误往往会附带更详细的上下文，比如具体是哪个配置项有问题。把完整错误信息贴给AI工具本身，让它帮你分析，这招屡试不爽。

有一个细节要注意：如果你用的是第三方中转服务或者本地自定义的模型网关，这类报错十有八九是网关地址失效或者鉴权过期。别傻乎乎地去重装工具，先检查服务是否还活着。

6.2 “the 'gpt-5.6-sol' model is not supported” 模型不支持错误

这个报错很典型，模型名不被Codex支持。出现这个问题的原因通常是你设置的模型标识超出了当前版本支持范围，或者用了某个特定配置，但当前环境不支持。

我建议的处理方式：

1. 查看当前Codex支持的模型列表，可以在官方文档里确认。
2. 检查你的配置文件，看是否手动指定了模型名，改成支持的模型。
3. 如果项目里某个地方写死了模型名，全局搜索一下然后改掉。

这类报错本身不复杂，但它提醒我们一个很重要的道理：AI工具迭代速度太快，配置文件很可能因为版本升级而失效。遇到奇怪的报错，先检查版本兼容性通常没错。

6.3 Windows下Codex安装未完成

Windows上安装Codex，常见的失败点有两个：一是Node环境问题，二是权限不足。

如果是npm安装时报权限错误，用管理员身份打开终端再装一次。如果是安装后执行codex提示找不到命令，八成是npm全局目录没加到PATH里。执行：

npm config get prefix

然后把输出的路径加到系统环境变量的PATH里，重新开一个终端就能用了。

另外一个很常见的问题是系统自带的老版本Node。Windows上用nvm-windows或者mise装一个LTS版Node，再重新安装Codex，基本能解决大部分问题。

6.4 配置Gitee密钥：推拉代码的“门禁卡”

既然用Git版本管理，代码托管平台是绕不开的。很多人用Gitee，配置SSH密钥是一道必须过的门槛。

生成的步骤：

ssh-keygen -t ed25519 -C "your_email@example.com"

然后查看公钥并复制：

cat ~/.ssh/id_ed25519.pub

接着去Gitee的设置页面，找到SSH公钥管理，把公钥粘贴进去。最后验证：

ssh -T git@gitee.com

如果看到欢迎信息，就说明配置成功了。之后你的git push和git pull走SSH协议，就不再需要频繁输密码。

这里有个细节容易被忽视：如果你同时用Gitee和GitHub，而且密钥都是ed25519算法，很可能冲突。到时候你需要在~/.ssh/config里分别指定不同的密钥文件，这事虽然不复杂，但第一次碰到时很容易卡住。

6.5 解决--no-optional-locks等奇怪Git参数

热搜词里有个git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks，这个看起来像一条完整的Git命令参数组合，一般是IDE或工具自动生成的。它本质上是在调用Git时临时覆盖一些配置：

• diff.mnemonicprefix控制diff中的前缀显示方式。
• core.quotepath控制非ASCII文件名的转义显示，false表示显示中文文件名而不是\346\265\213这种转义序列。
• --no-optional-locks告诉Git不要在只读命令中获取写锁。

这些东西大多数情况下你不需要手动敲，但如果你看到IDE的命令行输出里带这些参数，至少知道它们在干嘛。理解了之后，以后排查“为什么这个文件在diff里显示成乱码”这类问题就轻松了。

7. 从零开始的一整套可复刻工作流

到这里，理论、原理、命令和坑都讲完了，最后我送你一套可以直接照着用的完整工作流。这套流程是我自己近几个月来每天都在用的，稳定性和安全感都很高。

第一步：进入项目目录，确认工作区干净。

git status

如果工作区有未提交的改动，先提交（commit）或者暂存（stash），保证AI的改动可以独立审查。

第二步：创建独立分支。

git checkout -b ai-task/<任务名>

第三步：启动AI工具，给出任务描述，同时加上边界约束：

请帮我完成<具体任务>，只修改<指定文件或模块>，不要重构无关代码，改完后执行 git diff 展示改动。

第四步：审查git diff的输出。如果你看不懂某个改动，直接追问AI，让它解释为什么这么改。解释不清楚的改动，大概率有问题。

第五步：确认无误后，自己手动提交：

git add . git commit -m "feat(module): 描述本次改动"

第六步：合并回主分支并推送。

git checkout main git merge ai-task/<任务名> git push origin main

第七步：用git log --oneline确认提交记录符合预期。

这套流程看起来步骤多，但实际执行起来非常顺手，因为你把最耗精力的人工审查限制在了“只审diff”这个小范围内，AI负责干重活，你负责把关。这比让AI直接改主分支，或者让你自己一行行读代码，效率都高得多。

最后再说一个我个人的体会：AI编码工具的潜力，有很大一部分取决于你用没用好Git。不是因为Git本身有多神秘，而是因为Git给了你“放手让AI去试”的底气。你知道任何改动都能被追踪、任何错误都能被回退，所以你才敢让AI放开手脚。没有这层保护，AI工具用起来就像走钢丝，提心吊胆。

把Git这套基础打好，让AI和版本控制真正配合起来，你会发现自己写代码的速度和安全感，都会上一个台阶。