## 1
1. The Old Problems Managers Face
Last year, my team took over a project that had been under continuous development for over three years. On the handover day, the previous lead left with one sentence—"the code is all in the repo, the history is complete"—and was never heard from again.
As a manager, the problem I faced wasn't "can we read the code," but three trickier issues:
No one could explain the feature evolution order. When the product manager asked "was the payment module built first or added later," nobody could answer. Digging through PR records meant clicking through them one by one—the answer was buried in thousands of commits, but no one had time to excavate it.
High onboarding costs for new hires. Every new team member required a veteran to verbally walk them through "how this project grew into what it is today." The person explaining got exhausted, the listener couldn't retain it all, and the version told was different every time.
No basis for risk assessment. We wanted to refactor a module, but had no idea how many times it had been modified historically, why, or whether it was a stable zone or an accident-prone area. Acting blindly made it easy to step on a landmine.
What these three issues have in common: the answers are all in the Git history, but the cost-benefit of manually organizing it is completely unjustifiable. So we decided to let AI do it.
2. How We Did It with AI
Step 1: Export the Git History
AI doesn't directly read the repository (at least our workflow doesn't depend on that), so we first exported structured data locally:
git log --pretty=format:"%h|%ad|%an|%s" --date=short > git_history.txtA medium-sized project typically exports to a few thousand lines of plain text—exactly within the range a model's context window can handle. If the project is too large, you can export it in segments by directory or time period.
Step 2: Use a Prompt Template to Have AI Organize It
Here's a prompt template we refined over several rounds, ready to copy and use:
你是一位资深技术管理者,请根据我提供的Git提交历史,梳理这个项目的功能演进时间线。
要求:
1. 按时间划分为若干阶段(如:奠基期、扩展期、重构期),每个阶段说明核心目标和代表性变更;
2. 识别出3-5条主要功能线的演进脉络(如:核心业务、支付、权限体系等),分别说明每条线的起点和关键节点;
3. 标注出提交频率异常的时段(可能的救火期或大重构),并给出你的推断;
4. 指出历史上被反复修改的模块,作为后续重构风险评估的参考;
5. 输出格式:先给一页管理者摘要(不超过300字),再给详细时间线,最后列"建议深入了解的问题清单"。
Git历史数据如下:
{粘贴git log输出}The most critical detail in the template is item 5—forcing AI to give a summary before the details, and to end with a list of questions to investigate. This means we're not passively receiving information, but getting a handle on the next round of investigation.
Step 3: Organize Team Collaboration to Digest It
We put the AI-generated timeline draft directly into team documentation, then held a calibration meeting: veteran members added context (e.g., a period of密集 commits was actually for a client's custom requirements) and corrected the AI's inference biases. The AI's draft was about 80% accurate, with the remaining 20% filled in by humans—but an 80% accurate draft was already far more valuable than starting from scratch.
3. Before and After Using AI
| Dimension | Before AI | After AI |
|---|---|---|
| Organizing the timeline | Dedicated person digging through records, ~2-3 days | Export + generate + calibrate, done within half a day |
| New hire onboarding | Word of mouth, half a day per person | Self-read timeline doc in 1 hour + Q&A |
| Refactoring risk assessment | Gut feeling | A "frequently modified modules" list for reference |
| Knowledge retention | Lives in individual heads | Team documentation, continuously updatable |
From a management perspective, the biggest gain isn't the time saved, but turning the project knowledge scattered across individual experience into a team asset that can be captured once and for all. And the process is reusable: rerun it after every major version merge, and the timeline rolls forward.
4. Three Risk Warnings Beyond the Process
As someone who has stepped in these pits, I should also be clear about the boundaries of this approach:
1. AI output must be verified by humans. AI makes inferences based on commit messages, and commit messages themselves may be sloppy or even misleading. All key conclusions in the timeline—especially anything involving decisions—need human confirmation.
2. Don't feed sensitive data directly to the model. Git history may contain internal personnel names and internal system codenames. We anonymize the data before exporting, or use services that support private/compliant deployments. When using third-party APIs, choose services with an explicit no-training-on-your-data commitment (per their official policy page), and confirm pricing and quotas (per their official pricing page).
3. What AI organizes are "leads," not "conclusions." It helps you compress thousands of records into a readable structure, but "why this decision was made" is often not in the commit messages—you need to take AI's leads and go ask people and dig through documents.
5. Final Thoughts
What managers most easily underestimate is the cost of losing the implicit asset of "project historical knowledge." In the past, we could only rely on veterans, memory, and luck; now AI can activate dormant data like Git history into usable decision inputs.
If your team also has a legacy project with an "unclear history," start with a git log export and the prompt template above. If you want to integrate AI capabilities more systematically to handle this kind of workflow, you can register and try it out first at https://api.thistoken.ai/register, and run through this process to see the results.
---
Every example in this post runs with a single API key — get yours at https://api.thistoken.ai/register and start in minutes.
Token.AI を試してみませんか?
プロジェクトレベルの API Key を作成し、コンソールでチャネルを有効にして、ルーティング、予算、監査ログを設定しましょう。
注册 ThisToken.AI 并获取 API Key