⚠️ 如果你平时只会用 GPT、Claude 这种聊天框，让它帮你改代码，这条比一堆工具新闻更该先看。你刚刷到这类讨论时，很容易觉得“注释越多越负责”。但这个判断一旦错了，后面浪费的就是时间、注意力，还会把模型带去错误方向。
我原来也是这么想的，所以一开始最爱补注释。后来我更常拿一句话反问自己：你喜欢注释丰富， Commit Message 详尽，还是反之？[C001] 这里的 Commit Message，就是每次提交代码时写的提交说明。我的答案越来越偏向后者：长注释常替坏设计还债，长 Commit 才保存决策。[C002]
让我改观的，不是情绪，而是两份老牌规范。Git 的补丁提交说明《SubmittingPatches》直接说，Git 项目提交指南明确说，log message 和代码同样重要，未来维护者更需要知道 why，而不是只看代码 how。[C003] 翻成人话就是：代码能看出你怎么改，提交历史才更容易留下你为什么改。
另一份是谷歌（Google）C++ 风格指南的注释章节《Comments》。它反对用注释复述显而易见的代码，建议用更高层信息解释原因，或者让代码自己更清楚。[C004] 所以我现在会把两件事分开：接口约定、异常行为、边界条件，这些该认真写；只是把代码再翻译一遍的注释，我更愿意删掉，换成更清楚的命名。
一条更新值不值得看，不看它列了多少功能，先看它会不会改掉你下一步的判断。对我来说，这次改掉的判断很具体：少写“翻译代码”的注释，多写能保存决策的提交说明。如果你也在让模型连续改同一段代码，这条更值钱；如果只是一次性小脚本，感受可能没那么强。先收藏这条，下次改代码时问自己一句：你写下来的，到底是在解释代码，还是在保存决策？