夜雨聆风产研协作的新范式
AI 之后，产品经理不再只是站在代码外面描述需求了。
你会开始进入代码发生的地方。
以前产研协作，核心是 PRD。
产品经理写业务背景、交互流程、异常状态、验收标准。然后开需求评审，研发评估方案，测试补用例，大家一起推进上线。
这套方式当然还重要。
但现在变了。
你不一定能从零搭完整系统，但你可以用 Cursor 改一个页面，用 Claude Code 补一段逻辑，用 Codex 查一个仓库里的调用链。你可以跑 demo，调 prompt，补埋点，看 Langfuse trace。
产品经理开始从「描述需求的人」，变成「参与工程交付的人」。
新的产研协作，也不再只是产品写 PRD，研发写代码。
而是产品和研发在同一个仓库、同一套分支规则、同一个发版流程里，把一个功能交付出去。
所以我才想写这篇「专门给产品经理的 Git 文章」。
市面上的 Git 教程已经很多了，但大部分只是在教命令。
很少有人从产品经理的视角，讲清楚这些命令背后的产研协作逻辑。
比如我为什么要切分支？
为什么我和研发同时改一个项目，最后不会乱？
测试在 develop 上发现 bug，我到底应该改 develop，还是改 feature？
hotfix、release、CI、PR、ticket 这些词，和产品经理每天推进需求到底有什么关系？
这篇文章想讲的就是这些问题。
后面我会再单独写一篇更偏 IDE 操作的教程，以真正产品经理的工作逻辑，讲怎么切分支、拉最新代码、提交、同步、挑拣 commit、处理冲突。
这篇先把地图讲清楚。
为什么两个人可以同时改同一份代码
很多产品经理第一次听 Git 分支，都会有一个疑问。
我拉了一个分支，研发同学也拉了一个分支，我们都在改同一个项目，最后都要合回去，那不会乱吗？
一般不会。
因为 Git 不是让所有人直接在同一张纸上写字。
它更像是每个人都从同一本书上复印了一份草稿。
你在你的草稿上改登录按钮，研发同学在他的草稿上改支付逻辑，另一个同学在他的草稿上改消息列表。
只要大家改的是不同页面、不同文件、不同函数，最后合并的时候，Git 大概率能自动拼回去。
这就是分支的意义。
分支不是把代码复制成一堆无关项目。
分支是从同一个基准点出发，给每个人一条独立的施工通道。
你在自己的通道里开发、提交、试错，不影响别人，也不直接影响线上。
等这条通道里的东西可以交付了，再通过 PR 或 MR 申请合并回公共分支。
什么时候会出问题呢？
冲突。
冲突就是两个人改了同一个地方，而且 Git 判断不出来应该保留谁的版本。
比如你把一个按钮文案改成「立即生成」，研发把同一个按钮文案改成「开始创作」。
或者你让 Codex 顺手重构了一个组件，研发同学刚好也在这个组件里补业务逻辑。
这时候 Git 会停下来，把两个版本摆出来。
它不是坏了。
它是在提醒你，这里需要人来判断。（当然你也可以让AI判断哈哈哈）
所以冲突不可怕。
真正要看的是业务逻辑。
分支到底在隔离什么
很多产品经理看研发规范，最容易被一堆分支名劝退。
main，master，develop，feature，release，hotfix，bugfix。
换成产品语言就很好懂。
main 或 master 是线上世界。这里的代码默认稳定，至少应该随时可发布。它不是草稿纸。
feature 是每个需求自己的施工区。一个 ticket，一个功能，一条 feature 分支。
develop 像总装车间。很多团队会把多个 feature 先合到 develop，让测试在集成环境里看效果。
release 像质检车道。进入 release 的代码，原则上就是这一版准备发布的内容。这里主要做验收、修 bug、控风险。
hotfix 是急诊通道。线上出问题了，支付挂了，IM 聊天阻断了，核心链路走不通了，就走 hotfix。
分支的核心价值，是隔离风险。
普通需求不能污染线上。
下一版功能不能污染当前 release。
线上紧急修复不能顺手带上未来版本的代码。
如果边界没守住，就很容易污染分支。
比如你只是想修一个按钮 bug，结果从 develop 切了分支，而 develop 里已经混了下一版本还没测完的新功能。那这个 bugfix 就不干净了，后面很难安全合进 release。
一个需求怎么进入工程流程
假设你现在有个需求，叫 AI 会话按钮状态优化，对应 ticket 是 PROJ-123。
你不应该直接在 main 上改。
也不应该本地随便改完，发给研发说，哥你帮我粘一下。
更合理的做法是，先确认 ticket，再从团队约定的目标分支切出一条 feature 分支，比如 feature/PROJ-123-ai-chat-button。
你在这条 feature 分支上改代码，改完点一次提交。
commit 就是 Git 里的一次存档。
你在 IDE 里改了一些文件，然后点一次「提交」或者「Commit」，写一段提交消息，这就生成了一次 commit。
提交，是把这次改动存在你本地的 Git 历史里。
同步，或者 push，是把你本地的 commit 推到远端仓库。
很多 IDE 里的「提交并同步」，就是先 commit，再 push。
每个 commit 都有一个提交哈希。
你可以理解成这次存档的身份证。
你在 Git 图表里右键某一次提交，看到「复制提交哈希」，复制出来那串字符，就是它的 ID。
这个概念很重要。
因为有些时候，我们不是合并一整条分支，而是只同步某一次 commit。
你写完 feature 之后，就发 PR 或 MR。
PR 是 Pull Request，MR 是 Merge Request。不同平台叫法不一样，先理解成同一类东西就行。
它的意思是，我申请把我这条分支的代码合进某条公共分支。
PR 不是一句「我写完了，你帮我合一下」。
PR 是一次正式交接。
这次改动对应哪个 ticket，改了什么，影响范围是什么，自己测过什么，需要研发重点看哪里，都应该写清楚。
产品经理用 AI 写代码时，很容易有一种错觉，本地跑起来了，好像就完成了。
不是的。
本地跑起来，只是你自己电脑里的一个小胜利。
PR 通过，CI 全绿，Review 通过，合进目标分支，测试验证通过，再进 release，再到 main，再上线观察，这才叫交付。
几个常见词也放一下。
ticket，就是需求、任务、bug 在项目管理系统里的编号和记录。比如 PROJ-123。
SLA，就是这类问题必须在多长时间内响应、修复、上线。
TL，就是团队负责人或技术负责人。发版窗口、风险判断、紧急修复这些事，通常需要 TL 拍板。
CI，就是代码平台自动跑的一组检查，比如构建、测试、代码规范。CI 全绿，就是这些检查全部通过。
不用背概念。
能听懂研发同学在说什么，就够了。
develop 测出 bug 后该修哪里
接下来讲一个最容易绕晕的场景。
feature 已经合到 develop 测试了，测试发现这个 feature 有 bug，怎么办？
先看你们团队的流程。
如果你们的 release 是从 develop 切出来，那 develop 就是当前版本的来源，从 develop 修 bug 很正常。
但如果你们的流程是，feature 先合到 develop 测试，测试通过后，再把这条 feature 合到 release。
那做法就不一样。
这时候 develop 只是测试场。
feature 才是后面要进 release 的源头。
所以 bug 要先修在 feature 上。
流程很简单。
回到原来的 feature/PROJ-123-ai-chat-button。
修 bug。
提交一个新的 fix commit。
把这个 fix commit 同步到 develop 复测。
复测通过后，再把修好的 feature 合到 release。
关键点在于。
feature 以后要进 release，所以 feature 本身必须是修好的。
develop 只是用来复测，不是这个功能最终进入 release 的源头。
那怎么把 fix commit 同步到 develop？
看你们之前 feature 合 develop 的方式。
如果用的是普通 merge，可以让修好的 feature 再进一次 develop。
这不是把同样代码合两遍。
普通 merge 会保留 commit 历史。Git 能识别出来，前面的 A、B、C 已经合过了，这次真正新增的是 D，也就是这个 fix commit。
如果之前用的是 squash merge，就建议别直接拿原 feature 再提 develop。
因为 squash merge 会把 A、B、C 压成一个新的 S。
develop 里有代码内容，但没有 A、B、C 这几个 commit 的身份证。
你后面再拿 A、B、C、D 去合 develop，平台可能会展示一堆旧改动。
不一定冲突，但 PR 会很脏。
这时候更稳的做法，是 cherry-pick。
中文界面里一般叫「挑拣」。
它的意思就是，我不要整条分支，我只要这一次 commit 里的改动。
操作也很简单。
先切到目标分支，比如 develop。
在 Git 图表里找到 feature 上那个修 bug 的 fix commit。
不确定的话，右键它，点「复制提交哈希」，确认是不是那次提交。
然后右键这个 commit，点「挑拣」。
IDE 会把这个 commit 里的改动应用到你当前所在的分支上。
你当前在 develop，它就摘到 develop。
你当前在 feature，它就摘到 feature。
所以挑拣前一定要看清楚自己在哪条分支。
如果有冲突，就看业务逻辑解决。
不确定就找研发一起看。
这块别靠猜。
怎么少制造冲突
冲突完全避免不了，但可以少很多。
不要长期占着一个 feature 分支。
分支放得越久，和公共分支偏离越远，冲突概率越高。
开始写之前，先更新到最新代码。
不要拿上周的 develop 切今天的需求。
开发过程中，也要定期跟上公共分支。
如果功能做了一两天，或者看到别人合了很多代码，就让研发同学带你 rebase（变基）一下，或者你自己在确认安全的前提下操作。
rebase 可以先理解成，把你 feature 分支上的几次提交拿起来，重新放到最新公共分支后面排队。
它不是把 develop 粗暴合进你的 feature，而是让你的 feature 站到最新代码的基础上，再提前看看有没有冲突。
所以提 PR 前做一次 rebase，就是提前对齐公共分支，提前暴露冲突，提前解决冲突。
rebase（变基）更像是重新排队。
merge 更像是把两条线打一个结。
团队禁止在 feature 上反向 merge develop 或 main，通常就是为了让提交历史更干净。
历史干净，出事时才好查。
还有，一个分支只做一个需求。
不要把文案、埋点、样式、接口重构、bug 修复全塞进一条分支。
动公共文件前，先打招呼。
路由、全局配置、公共组件、接口类型定义、数据库字段，这些地方特别容易撞车。
你动之前在群里问一句，我这边要改某某公共组件，谁现在也在动吗？
就这一句话，可能省掉很多冲突。
还有产品经理用 Codex、Claude Code、Cursor 时最容易踩的坑。
不要让 AI 顺手优化。
你本来只是让它改一个按钮文案，它可能顺手格式化整个文件，再把几个函数重排一下。
你看着觉得很干净。
研发看着可能血压上来了。
因为 PR 里出现了大量无关 diff。
无关 diff 越多，冲突概率越高，Review 成本越高，问题也越难定位。
所以给 AI 的指令要非常克制。
只改当前 ticket 相关的最小代码。
release 和 hotfix 是两条通道
再往后，就是 release 和 hotfix。
产品经理只要记住一个点。
常规需求和线上紧急修复，是两条不同通道。
常规需求进 release，按窗口、审批、测试、观察来走。
线上出问题走 hotfix，基于当前线上版本修，只解决正在出血的问题。
不要在 hotfix 里顺手带新需求。
也不要拿一个混了未来功能的 develop 分支去修线上问题。
很多 bug 修了又回归，不一定是代码没修好。
有时候是分支流转没闭环。
比如 hotfix 合进 main 之后，没有同步回当前迭代分支。下一次常规发版，旧代码又把这个修复覆盖掉了。
这些细节，产品经理不一定要亲手操作，但要听得懂风险在哪里。
AI 产品经理要看懂三条链路
最后接回 AI 产品经理这件事。
以前产品上线后，我们主要看页面、数据、用户反馈。
AI 产品上线后，还要看模型链路。（我之前写过全网最全的langfuse看产品链路的教程系列！可以移步那一个系列）
如果你能把三条链路串起来，情况就不一样了。
一条是需求链路。
从 PRD 到 ticket，到验收标准，到测试用例。
一条是代码链路。
从 feature，到 PR，到 release，到 main，到线上部署。
一条是 AI 链路。
从用户输入，到 prompt，到模型调用，到工具调用，到 Langfuse trace，到用户反馈。
这三条链路合在一起，才是 AI 产品真正的交付闭环。
如果你只会写 PRD，你只能站在需求入口。
如果你只会用 Cursor 写几行代码，你可能只是停在代码草稿。
但如果你能看懂研发流程，再看懂 Langfuse 里的模型链路，你才开始接近一个真正的 AI 产品工程师。
或者说，AI 产品全干工程师。
这不是产品经理要变成传统程序员。
而是产品经理需要更靠近工程现场。
以前这些可能是研发和测试的内部语言。
现在会越来越变成 AI 产品经理的基本语言。
以前我们补的是 PRD。
现在可能要补 PR 了。
好产品经理和研发协作的新反思已经讲清楚了！现在你已经熟悉了这套地图和每一步的原理。
下一篇我会单独写一篇在 IDE 中的具体操作教程，以真正产品经理的工作逻辑，讲怎么切分支、拉最新代码、提交、同步、挑拣 commit、处理冲突。
大家点个收藏关注赞！端午爆肝连更两期讲清楚专属于产品的 git 的 UI 实操方案，和 terminal 命令行的实操方案，让你在和研发协作过程中既能自己做，看研发敲命令行也不会一脸懵！
（话说我其实觉得研发敲命令行去执行操作挺酷的哈哈哈）
