一个很有意思的问题，你们提交代码时，会要求把 commit msg 写成技术文章不

如果文章也是 ai 写的，图也是 ai 画的，不就是徒增 review 成本么。
没有意义。

现在不都是 AI 写的么

是有的人风格就这样，不喜欢写文档，全塞 git commit 。如果是你老板，你叽里咕噜有啥用？人家一言堂

都是 ai 写的了，commit 也是 ai 写的。即便要实现过程文档，也是 ai 在修改前总结出来再开始改代码的。

挺好的，不耽误工作的前提下，如果不是 ai 生成的话，要花挺久时间的。
如果是 ai 生成的，没有校对，价值不是很大。

这不沙雕么

沙雕。应该在开发前写，而不是开发完了才开始写

哪怕需要这些，也应该是 commit 指向项目的 task 或者仓库内相关文档，commit 本身写文档存在大量限制，这么做属于自作聪明。

我们组一个招的一个哥们 每次提交的 commit 都写个 1 ，被说了后 改成了 改 bug ,新需求 ，合代码 这 3 个循环。。。

没听过这么玩的，全塞 Commit Message 有点离谱。
我觉得 Commit Message 可以保留简短摘要 + 详细文档的链接（如果真的需要的话）。

这不成注释了么。

不会，但是会明确要按照 Conventional Commits 形式来提交。如果 header 的描述里面可以简单说清楚就不写正文。

如果是详细说明，是要求在 PRD 中说明，对应开发的部分落在对应模块的 README.md 或者 /doc 目录中。commit 的正文不应该详细描述实现过程。


https://www.conventionalcommits.org/zh-hans/v1.0.0/

全过程 AI, 全过程民主

用合适的工具做合适的事情，commit msg 显然不适合这样用。

文档是文档，commit 是 commit ，一个是详细说明，一个是提交概要，有毛病才会要求 commit 里面写细节。写 commit 了，那文档要不要写了

现在的 commit 我都是 AI 帮我写,满足固定格式要求,然后能概括我改了什么.特别的项目,还可以把多个仓的提交文件汇总列出来. 不比写 1 要好.也不费时间.

强制简写，但是不能写 "修复了一个错误" 等毫无价值的

很显然 commit message 不应该这么来用，commit 是用来补充代码无法提供的信息，业务背景上下文以及 trade off 。详细的实现细节或者架构，应该写成文档。

推荐个文章：How to Write a Git Commit Message
https://cbea.ms/git-commit/

linux 上有一个打印古诗的程序,我曾在自己的项目上每次提交的时候随机选择一句来提交.

Linux kernel 的提交有些很详细，还有附上崩溃日志的

写成文章有点过了，但如果只依赖于文档，大概率是完全不看 commit message 的主。排查问题的时候也不知道具体人当初遇到了什么问题，背景是什么，当前 commit 的设计思路是什么。