你喜欢注释丰富， Commit Message 详尽，还是反之？

[Had]

作为一个大龄 Ops ，喜欢简洁的代码和注释，但是写起帖子又特别碎碎念（开头就有点跑题了

本人算是古法 Vibe Coding 了，基本上除了自己的一个重构小 skill 以外，也没有安装市面上流行的 skill 。 Claude Code 和 Codex 配合其最新模型，在近两个月我前者烧了 170 亿+后者烧了 200 多亿，近四百亿 token （当然缓存命中率在 95.5%+），所以默认是怎样我还是挺清楚的，简而言之就是，

Codex 注释很少，Commit Message 你若是不稍稍加点限定，可能就只有标题，body 都没有 Claude Code 狂写注释，一个 feature 做完你不做冗余注释清理，看起来就是废话连篇，而且 Commit Message 也写的特别长

WDL本体早期使用 Claude Code ，后来因为 Opus 4.7/4.8 确实没有 GPT5.5 强，就换了 Codex 至今，基本上 CC 早期的注释痕迹已经清理的差不多了，因为是主 Coder+多 Reviewer 的结构，做为 Reviewer 的 CC 并不存在看不懂 Codex 代码的问题，但是又常常会给一些 NIT 诸如再补点注释，或者这个变更要在 Commit Message 里面体现之类

而在写大的 dogfooding 的 demo ，也就是 WDL-CHAT ，基本上都是用 CC rush 出来的，CC 默认真的会是那种高频提交+海量注释的类型，现在的结果也是我做了几轮注释清理才得到的，哪怕是这样，就看具体的文件也能看到依然有大块大块的注释在里面

不知道诸位喜欢哪种风格？

[Nasdaq]

Claude behind me

[jko123]

“古法 vibe coding”，“两个月烧了 370 一 token”，这真的是古法吗😲

[ronman]

你这算古法？！

[canyue7897]

不看代码
不管注释
完成任务
省 token 省钱
就是我的目标

[darksword21]

直接用 emacs 的 commit message 规范

[wiekern]

我倾向于代码内注释，commit 消息相对简洁一些，当然要能说明提交的主要改动，不能为了精简而精简。如果你希望有 commit 消息来生成 changelog 文档，那在 commit body 里写详细一点也 OK 吧，还是要适合自己。你可以写规则让 AI 提交代码时遵守

[Had]

@jko123
@ronman
古法 vibe coding 指不用复杂的 skills:)

[Had]

@wiekern 写规则就不够古法了:)
不过 commit message 写全的意义也在于让 llm 根据提交进行阶段性总结时，不用去一个提交一个提交去 diff

[ershierdu]

95%的 Claude code 注释都是没必要的，太啰嗦了。

再进一步讲，注释是模型基于你的 prompt 生成的，那理论上另一个模型基于同样的 prompt 也能理解代码？所以真正有价值的是把人的输入保留下来，通过注释或文档

[Had]

@ershierdu 我觉得稍稍有点偏差 cc 是很主动写注释的，它和 user prompt 没啥关系？
另外其实代码都能理解 codex 写的 cc 也能理解 但是它就是建议你再补点注释或者解释性内容
好代码应该是自解释的

[unused]

注释也算 token 哦

[shitshit666]

我觉得代码自解释最重要，注释只写'为什么'而不是'是什么'，commit message 简洁说明改动即可。

[dwhh]

@ronman 他说的是古法 vibe coding ，不是古法 coding 。。。

[weiwenhao]

我觉得注释太多是有点费 token 的，费 token 还好，但是浪费 context 是大问题，context 一大整体效果就会变差。

[lucays]

除了关键部分业务需求一行注释啥的
什么大段的函数注释类注释本来就没有用，骗骗自己得了，AI 出来了彻底没用了，浪费 token

[defaw]

Commit message 还是尽量详细一点比较好，因为对于 AI 来说，如果他不能从 commit message 里面拿到它的信息的话，它就只能制造非常多轮对话(工具调用)来寻找你所说的信息。这个不仅是消耗上下文，而且每一轮对话都会收每一轮对话的钱。

[mogita]

这是我的全局 CLAUDE.md 里关于代码注释的一条，加上之后注释再也不废话了。

- Comments document the contract a caller must respect, not the internal mechanism, downstream effects, or motivating examples.

[mogita]

咋发出去了。提交信息也可以类似的方式简单约束一下，不然全是小作文。

[craftsmanship]

@canyue7897 +1 请问目前的最佳实践是什么

[clemente]

写 changlog 就行

[OneLiteCore]

大多数时候 Commit Message 基本没啥人看，代码的话也只有重构或者出问题的时候才去看，此时代码内的注释作用更大些，但也不是说注释越多越好。个人感觉代码内的注释只要解释清楚为什么这么做以及这么做的用处是啥，那就算足够了。

[THESDZ]

不是注释本身多少，而是代码本身的就该自解释
而自解释也有讲究，如：方法名完备，参数名正确，主方法行数少，但逻辑清晰，避免 if/else （用适配器或者 if return ）
注释只做补充，比如明明可以用 bitmap 来压缩内存，但出于 xxx 考虑不压缩等，类似这种的。

[IMengXin]

注释丰富，Commit Message 简洁
注释是为了让以后的自己能看懂，Commit Message 是为了以后来查哪个功能是哪天更新的

[kristofer]

不管注释，那是我的 AI 该想的问题。