看懂 AI 产出怎么 review
不只是研发的事。产品 review 方案、运营 review 文案、市场 review 创意——本质都是 PR review。
技术分享 · 全员版
从 git 到智能体
协作 · 派活 · 把关
你的工作流正在被重写
为什么装 AI 工具前都要先装 git?看懂 AI 工具背后的协作逻辑,看懂你的日常工作正在怎么变。
研发 · 产品 · 运营 · 市场
git × AI 协作
40 分钟
一句话主线
git 已经不只是程序员工具,它是全公司协作的底层语言。
从代码协作 · 到全公司协作
第一篇 · 现象
一个被所有人忽略的事实
装 AI 工具前,都要先装 git
Cursor、Claude Code、Codex CLI、OpenCode——这些火起来的 AI agent 工具,几乎清一色要求你的电脑先有 git。
git 正在变成"人和 AI 协作的底层语言"——不只是程序员的事。
01
Claude Code · 默认共用一份"文档"
AI 之间默认共享工作目录,两个同时改会互相踩脚——后写的覆盖前写的。
02
Codex CLI · 每个任务一份"草稿"
每个任务自动开一份独立工作副本(worktree),默认就是隔离的。
03
OpenCode · "独立草稿"成了生态共识
社区围绕它做了一堆 worktree 插件——隔离成了标配,戳中了刚需。
不是教你写命令
是让你看懂 AI 怎么改变日常工作
git 背后的协作逻辑,正在重塑每一个岗位。今天我们避开技术细节,把所有概念翻译成日常工作里的真实环节。
知道怎么给 AI 派活
派得对,AI 帮你;派得不对,AI 帮倒忙。拆任务、给独立空间、逐个 review——像带实习生一样。
理解未来工作流怎么变
你的岗位不会消失,但工作内容会完全不同——从"执行者"变成"管理者"。
接下来,我们用大家天天在用的飞书、石墨、Notion,来翻译 git 的核心概念。
第二篇 · git 核心概念
用文档协作翻译
git = 团队文档的"历史版本"
你天天在用飞书、石墨、Notion 的"历史版本"功能。git 就是程序员版的,但强 100 倍。
01
版本库 = 文档完整历史
每次保存都给项目拍一张完整快照——随时能回到任何一个历史版本。
02
commit = 一次"保存"
记的不是"改了什么",而是"那一刻整个项目的状态"。
03
分支 = 另起一份草稿
复制一份自己改,改完再决定要不要合并回去。几乎零成本。
这次分享最关键的概念之一
PR = 申请把草稿合并回主线
想象你在飞书复制了一份方案改完,想合并回主文档——你不会直接覆盖,你会申请合并,等负责人 review。
PR 不是研发专利,是"协作成果如何进入主线"的标准流程。
diff
你改了哪些地方
文档里的"修订痕迹",代码里的"红删绿增"——一目了然。
评
讨论区 = 留批注
团队成员在你的草稿上留批注:"这里要不要再想想"。
批
审批 = 点头才能合并
你 approve,草稿才进主文档。质量保障、知识共享、责任分担同时解决。
把上一页的 PR 放到完整流程里
GitHub Flow:开源项目是怎么开发出来的
VS Code、React、Kubernetes 生态——这些大家天天用的开源项目,基本都是这么开发的:一条铁律 + 六个步骤。
01拉分支从 main 复制一份草稿
02提交在草稿上 commit 改动
03开 PR申请合并回主线
04review团队讨论 + 改
05合并通过后进 main
06删分支草稿用完即弃
铁律:main 分支永远可部署
任何改动都不能直接进 main——必须走分支 → PR → review 的完整流程。这条规则保证了主线随时能上线、随时能发布,不会因为某个半成品搞崩整个项目。
这也是AI agent 默认采用的工作流——它们开分支、提交、自动起草 PR,完全复用人类用了 10 年的协作方式。下一篇我们就看 AI 怎么参与。
颠覆一个刻板印象
review 不是找茬,是把关
很多人觉得 review 是"挑刺、卡流程"。这是误解——真正的 review 是质量共同体。
质量保障
多一双眼睛能发现盲点——逻辑错误、边界遗漏、潜在风险。
知识共享
通过看你的草稿,其他人了解了"为什么这么改"。被动文档化。
责任分担
一旦 approve,这块内容就是集体背书。降低个人英雄主义风险。
AI 时代:review AI 产出,不只是研发的事,是所有人的新能力——你需要懂业务,这是 AI 替代不了的。
第三篇 · AI 怎么参与协作
一个核心类比
派活给 AI,就像带实习生
你是项目负责人,接到大任务,不会自己闷头干——你会拆给团队。AI 时代一模一样。
你的角色,从"执行者"变成"管理者"——比的不是"会不会做",是"会不会拆、会不会派、会不会 review"。
AI
subagent(子智能体)
= 你派出去的实习生。各自有任务,各自干活。
WT
worktree(工作树)
= 每个实习生一份独立草稿。互不打扰。
PR
Pull Request
= 实习生把成果交给你 review。你点头才能合并。
所有用 AI 的人都会撞上的坑
翻车现场:两个 AI 互踩
你让 Claude Code 开两个 subagent,一个改登录页、一个改注册页——10 分钟后,配置文件被改了两遍,一半改动没了。
AI 不智能,很多时候不是模型问题,是你没给它正确的协作环境。
你
"开两个 subagent,并行干"
指令发出,AI 开始干活……
!
10 分钟后,配置文件乱套了
两个 AI 都碰了 config.js,后写的覆盖前写的——一半改动消失。
解
让每个 AI 用独立草稿(worktree)
Claude Code 里就一句话:用 worktree 管理 subagents。协作常识,不是技术细节。
用团队管理翻译三种 agent 协作模式
多个 AI 怎么协作:三种模式
无论哪种模式,最后和人对接的接口,都是 git 的分支和 PR——这就是为什么 git 成了 AI 协作的底层语言。
文件系统隔离派
"每个员工独立工位"——每个 AI 一份独立工作副本,各自产出 PR。
代表:Claude Code / Codex / Cursor消息总线派
"不分工位,靠群消息协调"——AI 之间靠消息总线分工,不隔离文件。
代表:MetaGPT / AutoGPT共享状态派
"共用一张任务清单"——共享工作目录,靠任务清单协调谁干什么。
代表:Claude Code Agent Teams
第四篇 · 工作流被重写
全场高潮
五个核心环节,全被重写了
| 环节 | 过去(纯人) | 现在(人 + AI) |
|---|---|---|
| 写方案/需求 | 产品写 3 天 | 产品 + AI 半天出初稿 |
| 评审 | 全员开会 1 小时 | 看 AI 的 PR diff,留 comment |
| 开发/制作 | 前后端各 3 天 | 1 人 + AI 并行,1 天 |
| 测试/校对 | QA/审校 2 天 | AI 自动检查 + 人 review |
| 上线/发布 | 手动操作 | 自动化 + 人审批 |
不是某个岗位消失,是每个岗位都加了 AI 副驾驶——不是替代,是放大。
2026 年最新研究,让大家冷静一下
派什么任务,比用什么工具更重要
UCL 的 Pinna et al. 2026(MSR'26),基于 AIDev 数据集严格过滤后7,156 个 AI 生成 PR,横跨 5 大主流 agent,来自 GitHub 100+ star 仓库。
| 工具(对齐 11 周窗口) | 接受率 | 最擅长的任务 |
|---|---|---|
| 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% | — |
不同任务类型,接受率差 29 个百分点
写杂务(chore)84.0% · 写文档(docs)82.1% · 新功能(feat)66.1% · 性能优化(perf)仅 55.4%
没有任何 agent 在所有任务上都最好
别迷信"最佳工具排行榜"。你的 review 能力,才是决定 AI 产出质量的关键。
第五篇 · 怎么提升 AI 使用能力
不管什么岗位,都适用
给 AI 派活的 4 条原则
任务要小而清晰
大任务拆 5 个小任务,每个对应一个 PR。AI 处理小任务又快又准。
给 AI 独立工作空间
并行多任务时,让它们用独立 worktree——协作常识,不是技术细节。
永远 review 再合并
最重要的一条。合并到主线前,必须经过你的 review——不盲信 AI。
沉淀成可复用资产
好用的 prompt 存下来,有效的 checklist 文档化。用完即走是成本,沉淀才是资产。
你的角色从"执行者"变"管理者"——这需要的不是技术能力,是业务理解 + 协作设计 + 判断力。
"我不懂代码,怎么 review?"
review AI 产出,不需要懂代码
只需要懂业务——这是 AI 替代不了的。三个抓手,是 AI 时代每个人的基本能力。
对不对、全不全、稳不稳——这就是非研发也能 review AI 产出的完整框架。
对不对 · 业务正确性
AI 改的是不是你要的?符不符合业务逻辑?这是 AI 最容易出错的——它不懂你的业务上下文。只有懂业务的人能把关。
全不全 · 完整性
有没有处理边界?有没有覆盖异常?有没有写测试、更新文档?AI 系统性"忘细节",必须主动补。
稳不稳 · 可维护性
会不会影响别的功能?后续好不好维护?不懂技术也可以问 AI 自己:"这个改动有什么潜在风险?"
岗位不会消失
工作内容会完全不同
工具会换,主线不会断
这条主线就是——怎么让一群人(和 AI)一起把事做成。git 20 年前是程序员工具,今天是全公司协作语言,明天是你工作流的一部分。
把 git 当语言
不需要会命令,但要知道分支、PR、review 这套逻辑——未来所有岗位通用语。
养成 PR 习惯
文档协作也用"草稿 + 申请合并 + review"流程——和 AI 安全协作的前提。
学会拆任务
大任务拆小,一个任务一个产出。这是用 AI 用得好的核心能力。
不盲信 AI
7156 个 PR 告诉我们:派什么任务比用什么工具更重要。你的 review 决定协作上限。