从 git 到智能体 · 讲稿
查看幻灯片 →

从 git 到智能体:AI 时代,你的工作流正在被重写

开场:为什么一个"非技术话题",要从 git 讲起

这次分享,我想先抛一个反直觉的事实:

你可能不会写代码,但你装 AI 工具之前,大概率得先装一个叫 git 的东西。

Cursor、Claude Code、Codex CLI、OpenCode——这些最近一年火起来的 AI agent 工具,几乎清一色要求你的电脑先有 git。一个非程序员从来没听过的工具,为什么成了 AI 时代的"必备前置"?

因为 git 已经不只是程序员的工具了,它正在变成"人和 AI 协作的底层语言"。 你不一定需要会写 git 命令,但你需要懂它背后的逻辑——因为这背后的逻辑,正在重塑每一个岗位的日常工作。

这次分享的目的不是教你用 git,而是借 git 这条主线,让你看清两件事:

  1. AI 工具背后的协作模式是怎么运作的——看懂了,你才知道怎么把 AI 用得更好
  2. 你的工作流正在被怎么重写——产品、研发、运营、市场,没有任何岗位能置身事外

听众里有研发、有产品、有运营、有市场。我尽量避开技术细节,把所有概念翻译成"日常工作里的真实环节"——开会、对需求、改方案、走审批、协作。

40 分钟,我们开始。

第一篇 · 一个被所有人忽略的现象

1.1 装一个 AI 工具,为什么要先装 git

我们先看三个最近一年最火的 AI agent 工具,看它们在"工作目录"这件事上各自怎么处理——这个细节会暴露一个所有岗位都该知道的事实。

观察一:Claude Code 的 AI,默认和你在同一份"文档"上改。

Claude Code 是 Anthropic 出的命令行 agent,目前社区讨论最多。它的子智能体(subagent)机制有一个反直觉的默认行为——所有 subagent 和主会话共享同一个工作目录。也就是说,如果你让两个 AI 同时去改代码,它们会互相踩脚:后写的覆盖前写的,一部分改动直接消失。

要避免这个,你得显式开启一个叫 "worktree" 的功能(后面会讲)。换句话说,AI 默认并不知道"协作时要各干各的"这件事——它默认是"一群人挤在同一份文档上乱改"。

观察二:Codex CLI 给每个任务都开一份"草稿副本"。

OpenAI 的 Codex CLI 走得更激进——每个任务在 sandbox 里跑,而它的隔离单元就是 git worktree:每个任务自动开一份独立的工作副本,默认就是"一个任务一份草稿"。它把 Claude Code 里需要 opt-in 才能启用的能力,直接做成了默认行为。

观察三:OpenCode 让"独立草稿"成了生态共识。

OpenCode 是 sst 出的开源 CLI agent。它本身没把 worktree 写死在核心里,但社区围绕它长出了一整套 worktree 插件——每个会话自动建一份独立工作副本、单独开一个终端跑。当一个能力从"官方功能"变成"生态标配"时,说明它真的戳中了刚需。

1.2 这三个观察合起来说明什么

三个主流 AI 工具,都绕不开同一个问题:怎么让多个 AI 不互相打架。

而它们给出的答案,惊人地一致——用 git 的分支和工作副本隔离。

这背后是一个所有岗位都该意识到的事实:

git 已经不是"代码版本管理工具"了,它是"多个 AI(以及人和 AI)怎么协作"的底层协议。 就像 HTTP 之于网页、SQL 之于数据库——你可以换浏览器、换工具,但你绕不开这套协议。

1.3 这意味着什么

如果 git 是协作的底层协议,那它的地位就从"程序员的事"上升到了"所有人都要懂一点的事"。这件事对每个岗位都有具体含义:

这次分享的三个收获预告:

  1. 看懂 AI 产出怎么 review——为什么这是新时代每个人的基本能力
  2. 知道怎么给 AI 派活——派得对,AI 帮你;派得不对,AI 帮倒忙
  3. 理解未来工作流怎么变——你的岗位不会消失,但工作内容会完全不同

下面,我们从 git 最核心的概念开始,但我会用大家天天在用的文档协作工具来翻译——飞书、石墨、Notion,都是 git 的"民用版本"。

一句话:git 正在变成全公司的协作语言。你不需要会写命令,但你需要懂它背后的协作逻辑。

第二篇 · git 的核心概念,用文档协作翻译

这一篇打地基。我尽量不出现技术术语,把 git 翻译成大家天天在做的事。

2.1 git = 团队共享文档的"历史版本"

你天天在用飞书、石墨、Notion——它们都有一个功能叫**"历史版本"**。点一下,你能看到这份文档上周三长什么样、谁改了什么、什么时候改的。

git 就是程序员版的"历史版本",但强了 100 倍。

强在哪里?我帮你翻译三个核心概念:

概念一:版本库(Repository)= 文档的完整历史。

你每次"保存",git 都会给整个项目拍一张完整的快照——不是记"改了哪几行",而是记"那一刻整个项目长什么样"。这意味着任何时候,你都能让项目"回到上周三 10 点的状态"。飞书的历史版本只能看,git 的版本库能完整还原。

概念二:commit("提交")= 一次"保存"。

commit 不是"改了什么",而是"那一刻整个项目的状态"。每一次 commit 都是一个可恢复的版本,你可以随时回到任何一个 commit 看那时候项目长什么样。

概念三:分支(Branch)= 另起一份草稿自己改。

这是 git 最反直觉、也最强大的概念。你不想直接改主文档(怕搞坏),于是复制一份自己改,改完再决定要不要合并回去。这份"复制的草稿",就叫分支。

在 git 里,分支几乎是零成本的——开一个分支,就像贴一张便利贴一样快。所以 git 鼓励你"频繁开分支、频繁实验、频繁合并"。这是 git 和它前辈(SVN)最大的区别,也是后面讲 AI 协作的基础。

至于 DAG、SHA-1、对象模型——不重要,你不需要懂。 你只要记住:git 让一群人(或一群 AI)能同时改一个项目,还能随时回到任何一个历史版本。这就是它的全部价值。

2.2 PR = 申请把草稿合并回主线

讲完分支,我们讲 PR——这是这次分享最关键的概念之一,因为它直接关系到你怎么 review AI 的产出。

想象这个场景:你在飞书里复制了一份产品方案,自己改了三天,改完想合并回主文档。

你会怎么做?直接覆盖主文档吗?当然不会。 你会:

  1. 点"申请合并"
  2. 写一段"我改了哪些地方、为什么改"
  3. 等文档负责人 review
  4. 他点头,草稿才合并进主文档

PR(Pull Request)就是这个"申请合并"动作的标准化版本。 它有三个核心要素:

重点不是"合并"这个动作,而是"申请合并 + 等待 review"这个仪式。

这个仪式解决了一个根本问题:任何改动进入主线之前,都要经过另一个人的审视。 不是为了挑刺,是为了:

PR 不是研发的专利。它是"协作成果如何进入主线"的标准流程——任何团队协作,本质上都需要这个环节。 市场改文案给审校、产品改方案给评审、运营改活动规则给法务——这些都是 PR 的"民用版本"。

2.3 GitHub Flow:开源项目是怎么开发出来的

讲完了分支、PR 这些零件,我们把它们拼起来看一个完整的协作流程——这就是 GitHub Flow,GitHub 推广了 10 年的标准工作流,也是几乎所有现代开源项目都在用的开发方式。

VS Code、React、Kubernetes 生态——这些大家天天在用的开源项目,基本都按这套流程开发。它的核心是一条铁律加六个步骤。

铁律:main 分支永远可部署。

main(主线)是项目的"正式版",任何时候它都应该是能跑、能上线、能发布的状态。这意味着——任何改动都不能直接进 main,必须走完整的流程。这条铁律保证了主线随时能发布,不会因为某个半成品搞崩整个项目。

六个步骤(每个 PR 都走一遍):

  1. 拉分支——从 main 复制一份自己的草稿(比如 feature/login)
  2. 提交——在草稿上写代码、commit 改动
  3. 开 PR——申请把草稿合并回 main(就是上一节讲的 PR)
  4. review——团队成员在 PR 上讨论、提意见、要求修改
  5. 合并——review 通过后,草稿合并进 main
  6. 删分支——草稿用完即弃,保持仓库干净

这就是 GitHub Flow 的全部。极其简单,但极其有效。

为什么这么简单的工作流能成为全球开源项目的事实标准?因为它解决了协作的几个根本问题:

更关键的是——这也是 AI agent 默认采用的工作流。 你后面会看到,Claude Code、Cursor、Devin 这些工具,内部再怎么花哨,对外都按 GitHub Flow 跟人协作:开分支、提交、自动起草 PR、等人 review。它们完全复用了人类用了 10 年的协作方式——这是为什么我们今天要先讲清楚这套流程。

一句话:GitHub Flow 是一条铁律(main 永远可部署)+ 六个步骤(分支→提交→PR→review→合并→删分支)。它是现代开源项目的事实标准,也是 AI agent 默认的协作方式。

2.4 review 不是找茬,是把关

讲到 PR,绕不开 review。很多人对 review 的刻板印象是"挑刺、找毛病、卡流程"。这是误解。

真正的 review 是什么?是质量共同体。

我们看一个具体场景:你写完一段代码,提交了一个 PR。reviewer(审查者)会逐行看你的改动,可能会:

这个过程里,你不是在被审判,你是在和一个同事共同对这块内容负责。 一旦他 approve,这块内容就不只是你的责任了——他也背书了。这就是为什么好的团队都强调"集体代码所有权"。

AI 时代,review 有了一个全新的角色:review AI 的产出。

这是后面要重点讲的内容。先记住一个判断:

review AI 产出,不只是研发的事,是所有人的新能力。 产品要 review AI 写的方案、运营要 review AI 写的文案、市场要 review AI 做的创意。你不需要懂技术细节,但你需要懂业务——这是 AI 替代不了的。

一句话:git 的核心是"让一群人(和 AI)能同时改一个项目,还能随时回到任何一个历史版本"。PR 是"协作成果进入主线"的标准仪式,review 是"质量共同体"的核心机制。

第三篇 · AI agent 怎么参与协作

前两篇铺垫完了。这一篇我们正式进入 AI 时代——看 AI 是怎么参与这套协作流程的。

3.1 派活给 AI,就像带实习生

你是项目负责人,接到一个大任务。你会怎么干?

不会自己一个人闷头干,你会拆给团队。 把大任务拆成几个小任务,分给不同的人,各自干,各自汇报,你统筹。

AI 时代一模一样。你不是自己写所有东西,你是管 AI 的人。我们用一个核心类比来理解整个 AI agent 的工作模式:

一个典型的派活流程:

  1. 你把大任务拆成 3 个小任务(比如"改登录页""改注册页""改个人中心")
  2. 派给 3 个 AI,每个一份独立草稿
  3. 它们各自干,各自提交 PR
  4. 你逐个 review:approve 的合并,不行的打回重做

听起来很美好,对吧?但这里有一个所有用 AI 的人都会撞上的坑。

3.2 翻车现场:AI 互踩的真相

假设你给 Claude Code 下指令:

你:"开两个 subagent,一个改登录页,一个改注册页,并行干。"

Claude Code:(派出两个 subagent,开始干活)

10 分钟后:你打开项目里的配置文件 config.js,发现里面的配置被改了两遍——后写的覆盖了前写的,一半的改动没了。

你:"……发生了什么?"

真相是:两个 subagent 都需要碰 config.js,但它们默认共用同一份草稿,就像两个实习生在同一张桌子上抢同一份文件——你写一笔,他擦一笔,最后谁也写不全。

这就是 Claude Code 那个"默认不隔离"的设计带来的代价。

解法是什么?让每个 AI 用独立 worktree(独立草稿)。 在 Claude Code 里,你只需要在 prompt 里加一句话:"用 worktree 来管理你的 subagents",它就会自动给每个 AI 一份独立草稿。

这里有一个对所有岗位都很重要的认知:

AI 不智能不智能,很多时候不是模型的问题,是你有没有给它正确的"协作环境"。 你给两个 AI 一份共享草稿,它们注定打架;你给它们各自一份独立草稿,它们才能真正并行。这个认知,产品、运营、市场在用 AI 时同样适用——只是场景不同。

3.3 多个 AI 怎么协作:三种模式

刚才讲的是"两个 AI 各干各的"。但现实里,有时候我们需要多个 AI 之间也协作——一个写代码,一个写测试,一个写文档。这就涉及到"多智能体协作"的工程问题。

业界目前有三种主流模式,我用"团队管理"来翻译:

模式一:文件系统隔离派——"每个员工独立工位"

每个 AI 有自己的一份独立工作副本(用 worktree、VM 或容器实现),互不打扰,各自产出 PR,最后由人合并。

模式二:消息总线派——"不分工位,靠群消息协调"

AI 不隔离工作空间,靠"消息总线"协调角色——一个 AI 当产品经理,一个当架构师,一个当工程师,通过消息互相派活。

模式三:共享状态派——"共用一张任务清单"

AI 共享工作目录,但靠磁盘上一个共享的"任务清单文件"协调——谁领了哪个任务、做到哪一步,都写在清单里。

这三种模式的本质区别在哪?

无论哪种模式,最后和人对接的接口,都是 git 的分支和 PR——AI 干完活,都是开分支、提交 PR、等人 review。这就是为什么 git 成了 AI 协作的底层语言。

一句话:派活给 AI,就像带实习生——你要拆任务、给独立空间、逐个 review。AI 不打架的关键,不是模型多智能,而是协作环境设计得对不对。

第四篇 · 工作流被重写:过去 vs 现在

这一篇是全场的高潮。前面铺垫了那么多,就是为了看清楚一件事:AI 到底怎么改变了我们的日常工作。

我们直接看一张对比表。

4.1 五个核心环节,全被重写了

环节 过去(纯人) 现在(人 + AI)
写方案/需求 产品写 3 天 产品 + AI 半天出初稿
评审 全员开会 1 小时 看 AI 的 PR diff,留 comment
开发/制作 前后端各 3 天 1 人 + AI 并行,1 天
测试/校对 QA/审校 2 天 AI 自动检查 + 人 review
上线/发布 手动操作 自动化 + 人审批

看出来了吗?不是某个岗位消失了,是每个岗位都加了一个 AI 副驾驶。

这就是工作流被重写的真相:不是替代,是放大。

放大了什么?放大了那个"懂业务、会拆任务、能 review"的人的价值。同样用 AI,有的人产出提升 3 倍,有的人产出提升 0.3 倍——差距不在工具,在使用工具的能力。

4.2 那 AI 的产出质量到底怎么样?——一个真实数据

可能有人会问:"AI 这么快,产出靠谱吗?"我们看一个 2026 年最新的研究数据,让大家冷静一下。

UCL(伦敦大学学院)的 Pinna 等人在 2026 年发表了一项实证研究(被 MSR'26 会议收录),基于 AIDev 数据集,严格过滤后分析了 7,156 个 AI 生成的 PR,横跨 5 大主流 agent——OpenAI Codex、GitHub Copilot、Devin、Cursor、Claude Code,全部来自 GitHub 上 100+ star、MIT/Apache 许可的仓库。

先看工具对比(在所有 agent 都活跃的 11 周公共时间窗内,各家的 PR 接受率):

工具 接受率 最擅长的任务
OpenAI Codex 79.9% 最稳定(9 类任务全在 60%–89%)
Cursor 74.4% 修 bug 最强(fix 任务 80.4%)
Claude Code 72.6% 写文档最强(docs 92.3%、feat 72.6%)
Devin 68.0% 唯一持续提升的趋势(+0.77%/周)
GitHub Copilot 68.0% —

第一眼看上去,各家工具的差距其实没那么大(最高 79.9% vs 最低 68.0%,差 12 个百分点)。

但真正让人意外的是下面这个发现:

4.3 派什么任务,比用什么工具更重要

论文最核心的结论是——不同任务类型之间的接受率差距,远远大于工具之间的差距。

跨 9 类任务,接受率最高 vs 最低差了 29 个百分点:

任务类型 接受率
chore(杂务/维护) 84.0%
docs(写文档) 82.1%
feat(新功能开发) 66.1%
perf(性能优化) 仅 55.4%

看出来了吗?让 AI 写文档、做杂务,接受率高达 82%–84%——几乎是"做什么都能用";但让 AI 做新功能、优化性能,接受率直接掉到 55%–66%——近一半被打回。

这意味着什么?

  1. 工具之间的差距没你想的那么大——别花太多时间纠结"哪个 AI 最好"
  2. 任务类型的差距才是决定性的——同样用 Claude Code,写文档 92.3%、写新功能 72.6%,差 20 个百分点
  3. 没有任何一个 agent 在所有任务类型上都是最好——Codex 最稳、Claude 擅长文档/功能、Cursor 擅长修 bug,各有所长

4.4 这对所有人意味着什么

这个研究对每个岗位都有具体的含义:

这就是为什么 review AI 产出是所有人的新能力。 你不需要懂代码细节,但你需要懂业务——"AI 改的是不是我们要的""有没有遗漏边界""符不符合业务逻辑"——这些是 AI 替代不了的。

一句话:派什么任务,比用什么工具更重要——任务选对,AI 几乎不出错;任务选错,近一半要返工。而你的 review 能力,直接决定了团队能不能用 AI。

第五篇 · 怎么提升 AI 工具使用能力

讲完了"为什么"和"是什么",最后落到"怎么做"。这一篇给所有岗位都可以马上用的实操建议。

5.1 给 AI 派活的 4 条原则

不管你是产品、研发、运营还是市场,给 AI 派活时都遵循同样的原则:

原则一:任务要小而清晰。

AI 处理大任务容易跑偏,处理小任务又快又准。一个大任务,拆成 5 个小任务,分别派。 每个小任务对应一个 PR,方便你 review。

举例:不要说"帮我做一个完整的活动方案",要说:

每个任务小、清晰、可验证。这就是 git 鼓励的"一个分支一个任务"的精神。

原则二:给 AI 独立工作空间。

如果你要并行多个 AI 任务(尤其是会动同一份文件的任务),一定要让它们用独立 worktree。Claude Code 里就一句话:"用 worktree 来管理你的 subagents"。

这不是技术细节,是协作常识:你让两个实习生在同一张桌子上抢同一份文件,他们注定打架。

原则三:永远 review 再合并。

这是最重要的一条。 永远不要直接信任 AI 的产出——合并到主线之前,必须经过你的 review。

review 的标准就是 7,156 个 PR 研究揭示的 AI 短板:

原则四:把一次性的使用,沉淀成可复用的资产。

如果你发现某个 prompt 特别好用,存下来;如果你发现某个 review checklist 有效,文档化。用完即走的 AI 使用是纯成本,沉淀成模板的 AI 使用才是资产。

这四条原则的核心是一句话:

你的角色,从"执行者"变成了"管理者"。 执行者比的是"我会不会做",管理者比的是"我会不会拆、会不会派、会不会 review"。这两种能力,完全不同。

5.2 review AI 产出的 3 个抓手

很多人一听"review AI 产出"就慌——"我又不懂代码,怎么 review?"

这是一个误解。review AI 产出,不需要懂代码细节,只需要懂业务。 三个抓手:

抓手一:对不对——业务正确性。

AI 改的是不是你要的?符不符合业务逻辑?

这是 AI 最容易出错的地方——它不懂你的业务上下文。 7,156 个 PR 研究里,新功能(feat)任务接受率只有 66.1%、性能优化(perf)更是低到 55.4%——越是需要深度理解业务的任务,AI 越容易出错。 业务正确性,只有懂业务的人能把关。

抓手二:全不全——完整性。

AI 经常"做完主体,漏掉细节"。

7,156 个 PR 研究揭示了一个有意思的反差:AI 写文档(docs)接受率高达 82.1%、做杂务(chore)84.0%——这些任务"完整度"容易达标;但做新功能只有 66.1%、性能优化 55.4%——复杂任务里 AI 系统性"忘细节"。这是你必须主动补的。

抓手三:稳不稳——可维护性。

这个改动会不会埋下隐患?

这一条对非研发岗位稍微难一点,但你可以问 AI 自己:"这个改动有哪些潜在风险?"让 AI 帮你做风险自评。

这三个抓手合起来,就是"非研发也能 review AI 产出"的完整框架。 你不需要懂技术,但你需要懂业务、懂完整性、懂风险——这些是任何岗位的资深员工都该有的能力。

一句话:review AI 产出,不需要懂代码,只需要懂业务。对不对、全不全、稳不稳——这三个抓手,是 AI 时代每个人的基本能力。

结语:你的岗位不会消失,但你的工作内容会完全不同

回到开头的反直觉事实:装 AI 工具前,都要先装 git。

现在你应该明白为什么了——git 是 AI 协作的底层语言,而 AI 协作正在重塑每一个岗位的日常工作。

我们今天走了五步:

  1. 现象:三个主流 AI 工具,都绕不开 git 的分支和工作副本
  2. git 核心:版本库 + commit + 分支,翻译成文档协作就是"历史版本 + 保存 + 草稿"
  3. PR 与 review:协作成果进入主线的标准仪式,质量共同体的核心机制
  4. AI 怎么参与:派活给 AI 就像带实习生,要拆任务、给独立空间、逐个 review
  5. 工作流变化:不是岗位消失,是每个岗位都加了 AI 副驾驶;不是替代,是放大

这些结论指向同一件事:

你的岗位不会消失,但你的工作内容会完全不同。 产品从"写方案"变成"拆需求 + review AI 方案";研发从"写代码"变成"管 AI 写代码";运营从"等排期"变成"自己用 AI 搭工具";市场从"想一个创意"变成"让 AI 出 10 个,你挑最好的"。

真正变的,是你这个角色的定位——从"执行者"变成"管理者"。

执行者比的是"我会不会做",管理者比的是"我会不会拆任务、会不会派活、会不会 review"。后者需要的不是技术能力,是业务理解 + 协作设计 + 判断力——这些恰恰是 AI 最难替代的。

最后,给你四个可以马上开始做的行动建议:

第一,把 git 当协作语言来理解。 不需要会写命令,但要知道分支、PR、review 这套逻辑。这是未来所有岗位的通用语。

第二,建立"PR + review"的工作习惯。 哪怕是文档协作,也试着用"草稿 + 申请合并 + review"的流程。这是和 AI 安全协作的前提。

第三,学会拆任务。 大任务拆小,一个任务一个产出,方便 review。这是用 AI 用得好的核心能力。

第四,建立"不盲信 AI"的心态。 7,156 个 PR 研究告诉我们:派什么任务比用什么工具更重要,复杂任务 AI 近一半要返工。你的 review 能力,直接决定了你和 AI 协作的上限。

这四条都不需要技术能力,但都需要刻意练习。AI 时代,基本功的回报率最高。

分享就到这里。希望下次你打开任何一个 AI 工具时,能透过它的界面,看到背后那套熟悉的协作逻辑——任务在拆分、草稿在分支、PR 在等待 review。这些动作每天都在发生,但只有理解了它们,你才真正"驾驶"了 AI,而不只是"使用"它。

工具会换,主线不会断。 这条主线就是——怎么让一群人(和 AI)一起把事做成。 git 20 年前是程序员工具,今天是全公司协作语言,明天是你工作流的一部分。

来源汇总

Claude Code 官方文档

git 官方

其他 AI 工具

实证研究(7,156 PR 数据来源,2026 年最新)

补充研究(2025 年,Claude Code 单工具深度)

技术分享讲稿 · 配套幻灯片请访问 aishow.wtlhs.com