接手一个三年老项目时，我让AI先把Git历史读了一遍

一、管理者遇到的老问题

去年团队接手了一个持续开发三年多的项目。交接那天，前任负责人留下一句“代码都在仓库里，历史很全”，然后就再无音讯。

作为管理者，我面对的不是“能不能读懂代码”，而是三个更麻烦的问题：

没人说得清功能演进顺序。 产品经理问“支付模块是先做的还是后加的”，没人答得上来。翻PR记录要一条条点开看，几千条commit里藏着答案，但没人有时间挖。

新人培训成本高。 每个新成员上手都要老员工口述一遍“这个项目是怎么长成现在这样的”，讲的人累，听的人记不全，且每次讲的版本都不一样。

风险判断缺依据。 想重构一个模块，但不知道它历史上被改过多少次、为什么改、是稳定区还是事故多发区。盲目动手，很容易踩雷。

这三件事的共同点是：答案都在Git历史里，但靠人力整理的投入产出完全不划算。于是我们决定让AI来做。

二、我们是怎么用AI做的

第一步：导出Git历史

AI本身不直接读仓库（至少我们的工作流里不依赖这个），我们先在本地导出结构化数据：

git log --pretty=format:"%h|%ad|%an|%s" --date=short > git_history.txt

一个中型项目导出来通常是几千行纯文本，正好在模型上下文窗口能处理的范围内。如果项目太大，可以按目录或时间分段导出。

第二步：用提示词模板让AI梳理

这是我们打磨过几轮后的提示词模板，可直接复制使用：

你是一位资深技术管理者，请根据我提供的Git提交历史，梳理这个项目的功能演进时间线。

要求：
1. 按时间划分为若干阶段（如：奠基期、扩展期、重构期），每个阶段说明核心目标和代表性变更；
2. 识别出3-5条主要功能线的演进脉络（如：核心业务、支付、权限体系等），分别说明每条线的起点和关键节点；
3. 标注出提交频率异常的时段（可能的救火期或大重构），并给出你的推断；
4. 指出历史上被反复修改的模块，作为后续重构风险评估的参考；
5. 输出格式：先给一页管理者摘要（不超过300字），再给详细时间线，最后列"建议深入了解的问题清单"。

Git历史数据如下：
{粘贴git log输出}

模板里最关键的细节是第5条——强制要求AI先给摘要再给细节，并且最后反哺一份问题清单。这让我们不是被动接收信息，而是获得下一轮调查的抓手。

第三步：组织团队协作消化

我们让AI输出的时间线初稿直接进团队文档，然后开一次校准会：老成员补充背景（比如某次密集提交其实是客户定制需求），修正AI的推断偏差。AI的初稿大约八成准确，剩下两成靠人来补——但八成的初稿价值已经远超从零整理。

三、用AI前后的对比

从管理角度看，最大的收益不是省了时间，而是把散落在个人经验里的项目认知，变成了一次性可沉淀的团队资产。而且流程可以复用：每次大版本合并后重跑一遍，时间线就能滚动更新。

四、流程之外的三点风险提示

作为踩过坑的人，也要说清楚这个方案的边界：

1. AI输出必须经过人工校验。 AI会基于commit信息做推断，而commit信息本身可能写得潦草甚至误导。时间线里所有关键结论，涉及决策的部分都要有人确认。

2. 不要把敏感数据直接丢给模型。 Git历史里可能包含内部人员姓名、内部系统代号。我们导出时会先做脱敏处理，或者使用支持私有化/合规部署的服务。用第三方API时，选择有明确数据不训练承诺的服务（以官网政策页为准），并确认价格与额度（以官网价格页为准）。

3. AI梳理的是“线索”不是“结论”。 它帮你把几千条记录压缩成可读的结构，但“为什么做这个决策”往往不在commit信息里，需要拿着AI给的线索去问人、翻文档。

五、写在最后

管理者最容易低估的，是“项目历史认知”这项隐性资产的流失成本。以前我们只能靠老人、靠记忆、靠运气；现在AI可以把Git历史这种沉睡的数据激活成可用的决策输入。

如果你的团队也有一个“历史说不清”的老项目，不妨从一次git log导出和上面那个提示词模板开始。如果你想更系统地接入AI能力来处理这类工作流，可以先在 https://api.thistoken.ai/register 注册体验，把这条流程跑一遍看看效果。

---

本文的示例只需一个 API Key 就能复现：在 https://api.thistoken.ai/register 注册即用。