AI写代码，但Commit描述必须手写
Commit Description as a Thinking Tool
在AI时代，代码和Commit描述都能由Agent自动生成，但我坚持手写Commit描述。这不仅是记录变更，更是深度思考的过程。AI可能缺乏上下文，编造出看似合理实则错误的'为什么'。只有当我能清晰解释变更背后的原因时，我才真正理解了自己正在交付的代码。手写描述迫使我审视临时决策的退出条件，验证AI生成的代码是否符合预期。如果无法解释'为什么'，就意味着在交付自己不理解的东西，未来维护将极其困难。Commit描述是检验理解程度的试金石。
Agent可以写代码和描述，但只有当你亲自写下'为什么'时，你才能发现自己是否真正理解了正在交付的内容。
HN 评论区
60- WD-42
在任何情境下，写作都是思考的过程，绝不仅限于 Commit 描述。这是一个事实，我担心人们正在遗忘它，或者更糟糕的是，从一开始就从未真正理解过。
- kccqzy
很久以前，我将默认的 Commit 信息模板改为了包含 'Why?'（为什么）和 'How?'（怎么做）这两个标题，以此提醒自己：需要解释为什么要做这个改动（也就是本文关注的重点），以及是如何做的（考虑过哪些不同的实现方案）。我坚持这种格式很长一段时间，在公司里我的 Commit 信息长度排在前 1%。
题外话：我曾经担心 Commit 信息太长会导致某些功能失效。我试过极长的 Commit 信息，结果什么都没坏：https://github.com/kccqzy/long-commit-messages/commit/ccfda4...
- dkarl
早在 AI 出现之前，我就被迫放弃写 Commit 描述了，因为其他人写得实在太烂，我干脆爽快地同意所有 PR 都应该 squash（合并）commits。
至少那时候 squash 后的信息通常还过得去。但后来人们开始用 AI（或者说 AI 开始利用人）来生成那些极其庞大的 Commit 信息，在 git blame 里根本没法快速浏览，对人类来说简直灾难。
AI 在几乎所有其他方面都取得了巨大进步。为什么它们还要继续用这种浪费资源、反人类的方式写作？
如果我们不怀疑这是故意的，那未免太天真了。AI 公司明确的目标就是在软件开发流程中取代人类，而它们正在主动让开发流程本身变得对人类不友好。
它们向客户的开发流程中注入了海量文本，这些文本随后变成了 token，客户还得反复付费让它们来处理。这就像是一个排放二氧化碳的二氧化碳清除器。
- arialdomartini
除此之外，在写代码之前先写好 Commit 信息是划算的。
https://arialdomartini.github.io/pre-emptive-commit-comments
- evnp
> 当 AI 不知道 '为什么' 时，它会自己编造理由。我觉得这很危险。当我们稍后读到这些内容时，它们可能毫无逻辑，因为真实原因完全不是那样。
甚至更危险的是：当这些文字本身读起来通顺合理，却与现实完全脱节时。