AI重构了我的工作流｜Git

大家好，我是 Ricky X。

过去这段时间，我深度使用了 Claude Code 这款 Agent 应用，积累了不少实践经验，也沉淀了一些思考。其中最触动我的一点是，它促使我重新审视自己的工作方式——面对那些固定、重复、却又无法完全忽略的日常任务，人与 AI 之间到底该如何分工协作，才能既高效又稳定？

正是这个思考，催生了「AI重构工作流」这个专栏。如果这也是你关心的问题，欢迎持续关注。

这是专栏的第一篇。接下来，我会在这里记录自己在真实开发与学习场景中使用 AI 工具的实战经验：不仅探讨模型本身的能力边界，更关注它如何融入现有工具链、重构具体的工作流程，以及在效率提升之外，带来了哪些新的工程习惯与需要警惕的风险。

废话不多说，今天就先从开发者最熟悉、也最容易被日常操作消耗精力的 Git 和 GitHub 工作流聊起。

---

前言

Git 和 GitHub 是开发协作中最基础、也最高频的一组工具。

无论是个人项目还是团队协作，提交代码、管理分支、创建 Pull Request、回溯历史，几乎每天都会发生。

这些操作本身并不复杂，但它们会频繁打断编码上下文：写完代码后，我们需要确认 diff、组织 commit message、执行 add/commit/push；创建 PR 时，还要切换到浏览器填写标题、描述和 reviewer。

这类问题并不是 Git 本身的能力不足，而是命令行、浏览器和项目上下文之间缺少一个统一的操作层。对于熟悉 Git 的开发者来说，真正消耗精力的往往不是理解版本控制模型，而是把一个明确的工程意图转换成一组机械命令和界面操作。

Claude Code 这类 Agentic Coding 工具提供了一种新的交互方式：开发者用自然语言描述目标，模型读取当前仓库状态，并通过本地工具调用 Git 或 GitHub CLI 完成具体操作。例如：

“把我的改动提交一下”
“创建一个 PR 到 main 分支”
“帮我审查一下这个 PR 的代码”

这篇文章会以 Git 和 GitHub 为例，拆解 Claude Code 如何参与一个完整的开发协作流程：从本地提交、分支管理，到 PR 创建、再到代码审查。

本文重点不在于“让 AI 替你记命令”，而是观察当 AI 具备工具调用能力后，开发者应该如何重新设计自己与工具链之间的协作方式。

一、执行机制：基于智能体循环的工具调用

1.1 Agent Loop：从意图到执行

要理解 Claude Code 为什么可以参与 Git 和 GitHub 工作流，可以先从 Agent Loop 的角度看它的执行过程：

plan → act → observe → repeat

当你输入”帮我提交代码”时，Claude Code 并不是把这句话简单映射成某一条固定命令。它通常会先读取当前仓库状态，例如检查工作区是否有未提交改动、查看 diff 内容、判断是否已经存在 staged changes，然后再规划后续操作：生成 commit message、执行 add/commit、根据命令输出确认结果。

这里的关键在于，每一次工具调用都会产生新的观察结果。模型会把这些结果重新纳入上下文，再决定下一步是继续执行、调整计划，还是向用户请求确认。也正因为有这个循环，它才能处理比单条 shell 命令更复杂的工作流。

1.2 Git/GitHub 操作链路

Claude Code 对 Git/GitHub 的操作能力主要来自工具调用（Tool Use）。在这个场景下，可以把它理解成下面这条链路：

自然语言意图 → 模型规划 → 工具调用 → git / gh CLI → 本地仓库 / GitHub

具体来说：

• Git 操作：Claude Code 通过本地 shell 调用 git 命令，例如 git status、git diff、git add、git commit、git log 等，本质上仍然是在当前仓库中执行标准 Git 操作。
• GitHub 操作：Claude Code 可以通过 GitHub CLI，也就是 gh，执行 PR 创建、Issue 查询、PR diff 读取、仓库状态查看等操作。

它的价值不在于绕过这些工具，而是在于根据当前上下文选择合适的命令、参数和执行顺序。

例如，你说”提交代码”，它通常会先检查工作区状态，再分析 diff，生成 commit message，最后执行提交；你说”创建 PR”，它会先确认当前分支和远程状态，再生成 PR 标题与描述，并调用 gh pr create 完成创建。

二、环境准备：先启动 Claude Code，再检查工具链

在开始之前，至少需要先完成 Claude Code 的安装和登录。因为只有 Claude Code 可以正常启动，后面的 Git、GitHub CLI 和认证状态检查，才可以反过来交给它协助完成。

1. 安装并登录 Claude Code

如果你还没有安装，可以参考 Claude Code 官方中文快速开始文档。官方文档会持续更新不同平台的推荐安装方式。以 macOS / Linux / WSL 为例，可以使用：

curl -fsSL https://claude.ai/install.sh | bash

如果你使用 Homebrew，也可以使用：

brew install --cask claude-code

安装完成后，在项目目录中启动 Claude Code，并按提示完成登录：

cd your-project
claude

2. 让 Claude Code 检查本地环境

Claude Code 启动后，可以把后续环境检查作为第一个任务交给它。例如：

请检查当前项目的 Git 和 GitHub CLI 环境是否配置完整。你可以执行相关的检查命令，如果发现缺少 Git 用户名、邮箱或 gh 登录状态，请告诉我需要补充哪些信息，再继续完成配置。

也可以更进一步，让它在确认后协助配置：

帮我检查并配置当前项目的 Git 提交身份，并确认 gh CLI 是否已经登录 GitHub。

Claude Code 会根据当前环境调用 git config、git status、gh auth status 等命令，判断哪些配置已经存在，哪些需要补齐。这样做的好处是，环境准备本身也变成了一个 Agent 协作任务，而不是一份需要你手动记忆的命令清单。

3. 手动配置方式参考

如果你希望手动完成配置，可以按下面的方式检查。

首先安装 GitHub CLI。它是 Claude Code 操作 GitHub 的关键工具，安装方式可以参考 GitHub CLI 官方文档。

# macOS
brew install gh

# Windows
winget install --id GitHub.cli

# Linux (Ubuntu/Debian)
sudo apt install gh

然后配置 Git 提交身份：

git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

如果你只想在当前仓库中配置身份，可以去掉 --global。

最后登录并验证 GitHub CLI：

gh auth login
gh auth status

完成这些配置后，Claude Code 就可以在当前项目目录中读取仓库状态，并通过你的本地 Git 和 GitHub 凭证执行对应操作。

三、本地 Git 工作流

本地 Git 操作很适合用来观察 Claude Code 对工作流的改变：很多任务并不难，但需要多条命令组合完成，而且每一步都依赖当前仓库状态。Claude Code 的价值在于把这些命令序列收敛成一个更接近开发意图的自然语言指令。

3.1 提交改动：从命令序列到提交意图

传统方式：

git status
git diff
git add <files>
git commit -m "改动提示"

Claude Code 方式：

> 检查当前改动，生成一个合适的 commit message，并在我确认后提交。

Claude Code 会读取当前工作区状态，分析 diff 内容，归纳本次提交的主题和影响范围，然后生成 commit message。你确认后，它再执行 git add 和 git commit。

比如你改了一个用户认证的 bug，它可能生成这样的 commit message：

fix: resolve token validation failure in auth middleware

这类提交信息的价值在于，它不是简单的 “update” 或 “fix bug”，而是基于实际 diff 归纳出修改对象、问题原因和行为变化。后续回溯历史时，这种信息密度会明显高于手写的临时描述。

3.2 创建和切换分支

传统方式：

git status
git checkout -b feature/user-auth
git branch --show-current

Claude Code 方式：

> 检查当前工作区状态，创建一个新分支 feature/user-auth，并切换过去。

Claude Code 会先确认当前工作区是否存在未提交改动，再执行分支创建和切换。

3.3 合并主分支

传统方式：

git status
git fetch origin
git merge origin/main

Claude Code 方式：

> 检查当前分支状态，然后把 main 分支的最新改动合并到当前分支。

Claude Code 会检查当前工作区状态、拉取远程分支信息，并执行合并。如果遇到冲突，它可以读取冲突文件，说明冲突位置、两侧变更差异，并给出可选的解决方案。最终是否接受某个合并结果，仍然需要开发者结合业务语义确认。

3.4 回溯历史

传统方式：

git log --oneline --since="1 week ago"
git log -p -- path/to/file
git blame path/to/file

Claude Code 方式：

> 看看最近一周这个项目主要改了什么，按作者和模块整理一下。

或者：

> 找出 auth.py 这个文件的修改历史，看看谁改过 validate_token 这个函数。

Claude Code 会组合 git log、git blame、grep 等命令，把原始输出整理成更适合阅读的结论。这类场景中，它的价值不只是执行命令，而是把“我要追溯某个行为变化”转换成一组查询命令，并完成结果归纳。

四、GitHub 协作流程

如果说本地 Git 工作流主要发生在终端里，那么 GitHub 协作流程的问题更多来自跨工具切换：终端、浏览器、PR 页面、Issue 页面和代码审查界面之间来回跳转。Claude Code 的优势在于，它可以通过 gh CLI 把这些远程协作动作也纳入同一个对话上下文。

4.1 提交、推送与 PR 创建

传统方式：

git status
git diff
git add <files>
git commit -m "..."
git push origin feature/xxx
打开浏览器，进入 Pull Request 页面，手动填写标题、描述和 reviewer。

Claude Code 方式：

> 检查当前改动，提交并推送当前分支，然后创建一个到 main 分支的 PR。PR 描述请基于实际 diff 生成。

Claude Code 会把这个目标拆解为一组明确的操作：分析 diff、生成 commit message、提交本地改动、推送当前分支，并调用 gh pr create --base main 创建 PR。

PR 描述的质量取决于它能否准确总结变更动机、实现方式和影响范围。Claude Code 的优势在于，它可以直接读取本地 diff 和提交历史，再据此生成结构化描述，而不是依赖人工临时填写。

4.2 Pull Request 辅助审查

传统方式：在浏览器中处理，通常需要打开 PR 页面，逐个文件查看 diff，再手动整理 review comment。

Claude Code 方式：

> 帮我审查 PR #42，重点关注逻辑错误、安全风险、性能问题和测试覆盖。

Claude Code 会：

1. 通过 gh pr view 获取 PR 信息
2. 通过 gh pr diff 获取代码差异
3. 并行分析多个维度：
   • 逻辑错误：边界条件、空指针、类型问题
   • 安全问题：注入风险、敏感信息泄露
   • 性能问题：N+1 查询、不必要的循环
   • 代码风格：命名规范、代码组织
4. 输出审查结果，按严重性分级，例如 Important / Nit / Pre-existing

这类审查不能替代团队成员的最终 review，但它可以提前暴露一部分低级错误、边界条件遗漏和潜在设计问题。对于大 PR，它尤其适合作为人工审查前的第一轮过滤。

4.3 Issue 到修复任务的转换

传统方式：

然后开发者需要在 Issue、代码编辑器和终端之间来回切换，手动把问题描述转换成代码定位和修复计划。

Claude Code 方式可以拆成两个阶段。先让它分析问题，不直接修改代码：

> 阅读 issue #42，先总结问题、复现条件和可能相关的代码位置，不要直接修改代码。

确认分析方向后，再让它执行修复：

> 根据刚才的分析实现修复，并在修改后说明改动范围和验证方式。

Claude Code 会通过 gh issue view 读取 Issue 内容，分析问题描述，定位相关代码，再根据确认后的方向修改代码。这个流程的价值在于减少上下文切换：Issue 内容、代码定位、修改、提交和 PR 创建都可以在同一个交互环境中完成。

五、工作流模型对比

维度	传统方式	Claude Code 方式
提交改动	status → diff → add → commit	“检查当前改动，生成 commit message，确认后提交”
创建分支	检查状态 → checkout -b → 确认当前分支	“检查工作区状态，创建并切换到新分支”
合并主分支	fetch → merge → 手动处理冲突	“检查当前分支状态，把 main 的最新改动合并进来”
回溯历史	log / blame / grep 组合查询	“帮我追溯某个文件或函数的修改历史”
创建 PR	push → 浏览器 → 填标题、描述、reviewer	“推送当前分支，并基于 diff 创建到 main 的 PR”
审查 PR	打开 PR 页面 → 逐文件看 diff → 整理意见	“审查 PR #42，关注逻辑、安全、性能和测试覆盖”
处理 Issue	读 Issue → 搜代码 → 制定修复计划	“先分析 issue，再定位代码并说明修复方案”

主要结论是：Claude Code 不是替代 Git 技能，而是把命令式操作转化为意图式协作。

传统方式下，开发者需要把目标拆成一组具体命令，并在终端、浏览器和编辑器之间不断切换。Claude Code 的介入，让这层转换可以由模型辅助完成：开发者描述目标，模型读取上下文、规划命令、执行工具，并把结果反馈回来。

但这并不意味着开发者可以忽略 Git 和 GitHub 的底层机制。你仍然需要理解分支、合并、PR review、Issue 修复等概念，也需要判断模型生成的操作是否合理。真正变化的是注意力分配：从“我要敲哪些命令”，转向“这个变更边界是否清晰、风险是否可控、结果是否符合预期”。

六、实践建议与风险控制

最佳实践

1. 把目标说完整：不要只说“提交一下”，而是说明是否需要先检查 diff、是否需要生成 commit message、是否需要等待确认后再提交。
2. 写操作前保留确认：涉及 commit、merge、push、创建 PR、修改 Issue 状态时，建议让 Claude Code 先展示计划或摘要，再确认执行。
3. 明确分支和目标仓库：创建 PR 或合并分支时，明确说明当前分支、目标分支和目标仓库，避免默认行为不符合预期。
4. 用 CLAUDE.md 固化项目规范：在项目根目录写入 commit message 格式、分支命名规则、测试命令、PR 描述模板等约定，让 Claude Code 在执行任务时有稳定依据。
5. 先分析，再修改：处理 Issue 或复杂 bug 时，先让 Claude Code 总结问题、定位代码和给出修复方案，再进入实际修改阶段。

注意事项

1. 凭证权限 = 你的权限：Claude Code 使用的是你本地配置的 Git 和 GitHub 凭证，它能做的事情和你在终端里能做的一样。因此，高风险操作必须保留人工确认。
2. 大 diff 不适合一次性提交：如果改动范围很大，建议先让 Claude Code 帮你拆分提交边界，而不是把所有修改一次性打包。
3. 冲突解决需要业务判断：Claude Code 可以解释冲突位置和两侧变更，但最终选择哪一侧逻辑，仍然要由开发者结合业务语义确认。
4. PR 审查不能替代人工 review：模型适合做第一轮风险扫描，但不能替代团队成员对产品逻辑、架构取舍和长期维护成本的判断。
5. 远程操作要注意可回滚性：本地 commit 可以修改，远程 push、PR 创建和分支合并的影响范围更大，执行前要确认目标分支和仓库。

七、总结与展望

本文以 Git 和 GitHub 为例，讨论了 Claude Code 如何参与开发者日常工作流：

• 本地 Git：提交生成、分支创建、主分支合并、历史回溯
• 远程 GitHub：PR 创建、PR 辅助审查、Issue 到修复任务的转换

几个月使用下来，我越来越明确地感受到：自然语言不只是一个更友好的入口，它也可以成为工程工具之间的编排层。

它的价值不在于“让开发者不用学 Git”，你仍然需要理解底层机制，但不必把大量注意力花在重复命令、参数组合和界面切换上。

如果想低风险地尝试，可以从最简单的本地提交开始：让 Claude Code 先分析 diff、生成 commit message，并在你确认后再执行提交。等这个流程稳定后，再逐步扩展到分支管理、PR 创建、PR 辅助审查和 Issue 处理。

这也是我开这个专栏想持续讨论的问题：AI 不只是一个更聪明的问答入口，它正在改变我们组织任务、调用工具和设计协作流程的方式。

Git 和 GitHub 只是第一个切口，后续我会继续记录 Claude Code 在更多真实工作流中的实践，敬请关注～