公司隔一段时间就会来一批新同事。
这本来不是什么值得写 blog 的事情，直到有一天，领导跟我说了一句我非常熟悉的话：
「你比较懂 Git，这次培训你来吧。」
这句话的问题在于—— 我确实懂 Git，但我并不喜欢给二十多个人反复讲 rebase。
1. 培训前，我对自己非常有信心
培训前，我是有心理准备的。
- PPT 很认真地做了
- Demo 仓库提前跑过
- 连「不要
git push -f」都写成了加粗红字
我当时的想法非常朴素：
讲清楚一次，大家以后各自安好。
现在回头看，这个想法多少有点理想主义。
2. 培训结束后，Git 才刚刚开始
培训那天进行得很顺利。
大家点头、记笔记、结束时说「学到了」。 我心里甚至有一点成就感。
然后，第二天一早，现实开始敲门。
- 「我刚 pull 了一下，为什么文件全红了？」
- 「我这个分支是从哪儿来的？」
- 「我只是改了一行，为什么冲突这么多？」
这些问题有一个共同点： 在 PPT 里都出现过，但当事人完全想不起来。
这不是他们的问题。 这是 Git 的问题。（至少我愿意这么相信）
3. 我逐渐变成了“Git 售后支持”
接下来的一周，我的工作节奏变成了：
- 写代码
- 回答 Git 问题
- 再写一点代码
- 再回答一次“其实和刚才那个是同一类问题”的问题
最微妙的是，新同事在提问前，往往会先补一句：
「这个问题是不是有点基础……」
然后我一边打字，一边在心里回答：
是的，但你已经是今天第六个问这个的了。
4. 我突然不想再回答了
转折发生在一个非常普通的傍晚。
我正准备下班，手机又震了一下：
「哥，我这个
rebase好像搞砸了。」
那一刻我突然意识到一件事：
这不是“某个人不会 Git”的问题， 而是这类问题出现得过于规律了。
而只要问题足够规律，就不应该一直靠人来顶。
4.5 插一句：我是怎么把这件事真的做出来的
说实话，那天我并没有打算“搭一个系统”。
我只是坐在工位上想了一件非常现实的事：
如果下一个人再来问我
rebase， 我能不能把这个回答，交给别的“东西”？
于是我做的第一步，并不是写代码，而是在纸上写了几条很随意的规则：
- 它只需要回答 Git
- 不用显得很聪明
- 解释要偏人话，而不是文档原文
- 同一个问题问十遍，也当成第一次回答
这些规则写完之后，我反而踏实了不少。 因为我意识到，我要的不是一个“什么都会”的助手， 而是一个可以长期放在那里的角色。
接下来这件事就变得很顺了。
我把这些设定丢进了 OpenPAI，一个新开源的智能体构建项目 顺手加了一点我们团队自己的 Git 使用习惯：
- 分支一般怎么起名
- 什么情况下我们会用 rebase
- 冲突解决到什么程度算“可以交差”
没有复杂的流程，也没有反复调参。 整个过程更像是在跟一个新人说清楚三件事：
你负责什么， 不负责什么， 出问题的时候应该怎么说话。
当我关掉页面的时候，突然意识到一件事：
真正花时间的，从来不是“把它搭出来”， 而是想清楚：你到底希望它替你扛哪一部分事。
5. 我给团队加了一个“不会烦的同事”
第二天，我把入口丢进了新同事群里，只说了一句话：
「Git 的问题，先问它。」
没有宣布上线，也没有仪式感。 看起来就像我随手甩了个链接。
6. 一周之后，我的世界安静了
过了几天，我发现事情有点不对劲。
- 群里明显安静了
- 私聊少了很多
- 我居然可以连续写完一段代码而不被打断
后来有同事跟我说：
「有些问题问它，比问人舒服。」
我听完非常理解。
因为它不会回你一句： 「这个上次不是讲过吗？」
7. 这件事让我重新理解了“工具”这两个字
这个 Git 助手本身并不神奇。
它不会替你解决所有问题， 也不会让你突然爱上 Git。
但它做了一件非常重要的事：
把那些高频、低价值、但又必须回答的消耗， 从人身上拿走了。
而 OpenPAI 在这件事里，更像是一个让我能快速把想法落地的工具。 不需要解释太多，也不需要折腾太久。
写在最后
现在，每来一批新同事，我都会重复同样的流程：
- 正常培训
- 正常讲 Git
- 最后补一句：
「出了问题，先去问那个。」
到目前为止，大家都还活得很好。
我也是。
