真正拖慢程序员的，不是不会写代码，而是还没看懂就开始改

需求一下来，项目经理已经排好了 sprint，你打开一个两年没碰过的仓库，几十万行代码、上百个文件。时间紧，你直接找到目标文件开始改。改完了，跑通了，提了 PR——然后就开始等。等 review，等另一个模块因为你的改动报错，等有人告诉你"这个文件当初为什么要写成这样"。

问题不出在代码上。review 变慢，是因为评审者也不确定你的改动会波及什么。回滚增加，是某个当初的设计决策被无意中打破了。团队估时越来越保守——不是功能复杂，是"那个文件"太吓人，每次小改动的爆炸半径都不可预测。

我越来越觉得，很多团队慢下来不是执行力差，是上下文理解的顺序搞反了。改代码之前，你至少应该先搞清三件事：这段代码被谁改过最多次、它为什么变成现在这样、谁对它最熟悉。但大多数人打开仓库的第一个动作是找到目标行，直接开干。

<figure> <img src=“compare.png” alt=“对比图：大多数团队 vs 先建上下文” /> </figure>

其实不用任何新工具，五个 git 命令就能在五分钟内给一个陌生仓库做完初步诊断。

第一步，查过去一年改动最多的 20 个文件。排最前面的那个，几乎就是团队里大家互相提醒"别碰"的那个。高频改动不一定有问题，但如果一个文件改得多、没人愿意负责、bug 还反复长在它身上——那就是代码库里最大的单点风险。有研究早就指出，代码变更频率对缺陷的预测能力，比复杂度指标还强。

第二步，git shortlog -sn --no-merges，按人头统计 commit 数量。一个人占 60% 以上，那就是你的 bus factor。再把提交量按月画出来，如果某个月数量断崖式下跌，去查一下——大概率那个月走了关键人。这不是代码数据，是团队数据。

第三步，用 commit message 里的 fix、bug、broken 筛出 bug 热点文件，和高频改动列表交叉比对——两个榜单都出现的文件就是最高风险。第四步，按月统计提交量，看项目在加速还是失速。第五步，搜 revert、hotfix、emergency，判断团队是不是在持续救火。每隔两三周就有 revert，说明团队不信任自己的部署流程；一条都没有也是信号——要么真的稳，要么没人写描述性的 commit message。

<figure> <img src=“workflow.png” alt=“五步诊断法” /> </figure>

但跑完命令只是起点，数据得带着判断力去看。我见过排名第一的"高产"提交者其实是代码质量最差的人——commit 多只因为他每改一行就提交，还经常出错，人早被开掉了。也见过有人加入团队一周刷了 124 个 commit，走后留下一堆技术债。数字不等于真相。

更实用的做法是把变更频率和代码复杂度放在同一张图上看。改得多但简单的，可能是配置文件，没风险。改得少但复杂的，也还好，没人碰它。真正危险的是那些又频繁变更、又高度复杂的模块——bug 最多，PR 最容易卡，测试覆盖最差。很多团队嚷着要"重写整个应用"，真正的原因就是那几个高 churn 高 complexity 的文件在拖垮所有人。

过去两年，Copilot、Cursor 这些工具让"写代码"的速度提了不止一个量级。但写代码变快了，理解代码的速度没有变。你可以用 AI 十分钟写出一个功能模块，但你没法用 AI 十分钟搞清楚这个仓库过去三年的关键决策、哪些文件被反复修补但从没真正重构过、上次大规模回滚是因为什么。生产速度上去了，消化速度没跟上，人工 review 反而成了合码的最大瓶颈。

说白了，上下文不是个人习惯，是团队效率的基础设施。每次有人接手新模块都从零摸索，工具再快也没用。这五个命令的价值不在命令本身——在于它代表的工作顺序：先诊断，再动手。这个顺序反过来，就是返工和扯皮的起点。

你有没有遇到过没看懂就改、结果越改越慢的项目？