自从有了 AI 之后， Commit 数量是不是已经不适合衡量开发效率了

[DiKaErJi]

感觉自从有了 AI ，大家一年写的 commit 数量应该都比以前多很多吧。

以前写代码，很多东西得自己慢慢想、慢慢敲、慢慢改。现在有 AI 之后，很多样板代码、测试、重构、小 bug ，基本都能很快搞出来。结果就是代码改得更频繁了，commit 也更密了。

但我也有点好奇：commit 变多，到底是真的效率变高了，还是只是“生成一版、改一版、再修一版”的次数变多了？

以后看程序员产出，可能真的不能只看 commit 数量了。毕竟 AI 可以帮你写很多代码，但最后能不能把东西做稳、做好、做对，还是得看人。

[connor123]

在大公司外包，甲方对外包的考核是每周一千行代码，我直接 ai 干两千行单元测试

[Felldeadbird]

后者。大部分 commit 是为了保存抽卡结果。

[kulove]

效率高了 因为抽卡不合格不需要 commit

[chen15798]

是的。AI 帮助研发“升维”，相应衡量指标也一样

[Quarter]

正经人谁看 commit 啊，这玩意水分也太大了

[DiKaErJi]

确实，越来越难评估工作量，以后应该更加看重质量

[DiKaErJi]

@Felldeadbird 运气好一次命中

[DiKaErJi]

@connor123 确实，越来越难评估工作量，以后应该更加看重质量

[DiKaErJi]

@kulove commit 次数少也可能是运气好了

[DiKaErJi]

@chen15798 应该更加看重代码质量了

[DiKaErJi]

@Quarter 哈哈哈很多公司还看代码行数呢

[teaguexiao]

现在衡量开发效率更应该看“问题解决密度”：一天内解决了多少个真正有难度的问题，而不是 commit 了多少次。vibe coding 一个下午可以 commit 几十次，但能不能真正交付一个功能才是关键。

[DiKaErJi]

@teaguexiao 没错，代码质量才是关键

[Jiajin]

以前也不能吧

[383394544]

superpowers 每个子任务就会 commit 一次，我都让它提 PR 再 squash merge 。不然 commit 数会指数上升

[DiKaErJi]

@Jiajin 以前有些大公司会用代码量来评估开发效率。

[DiKaErJi]

@383394544 听说过这个 skills ，但还没有用过

[383394544]

@DiKaErJi 过时的管理方法就该被淘汰，“以前的大公司”从来如此便对吗？要向前看。感觉很多 V 友都是看得太少想得太多。