Conventional Commits 的格式很多团队都熟：<type>[optional scope]: <description>。
fix、feat、refactor 站在最前面。scope 可以写，也可以不写。
现在有软件工程作者公开反对这套写法，并上线 scopedcommits.com，主张 scope-first：先写改动影响的区域，再写描述。
这事的刺点不在“哪种 commit 更好看”。反常处在于：一个声称让提交信息更语义化的规范，可能把最有工程语义的信息放到了次要位置。
争议点：type 靠前，scope 反而可选
Conventional Commits 没有被行业抛弃。它在很多开源项目里仍然流行。Angular、Electron、freeCodeCamp、Nuxt、Vite 等项目都采用过类似约定。
它的吸引力也很明确：格式整齐，工具好解析，发布流程容易接上。
问题是，它默认把 type 当成第一信息。
| 写法 | 示例 | 最先读到什么 | 对排障的帮助 |
|---|---|---|---|
| Conventional Commits | fix(auth): 修复登录问题 | type：这是 fix | 需要继续扫 scope |
| scope-first | auth: 修复登录问题 | scope：动了 auth | 直接定位影响区域 |
作者的核心论点很简单：贡献者、debugger、事故响应者看 commit log 时，最关心的是“改了哪里”，不是“这条提交自称是什么类型”。
一次 refactor 可以引入线上事故。一次 fix 也可能制造新 bug。type 是作者对意图的归类，scope 才是别人追溯影响面的入口。
“名不正，则言不顺。”放在这里，名不是标签仪式，而是信息顺序。谁最先被看见，谁就决定了读者怎么理解这条提交。
自动化承诺：有用，但边界很窄
Conventional Commits 最好卖的部分，是自动化。
自动生成 changelog。自动判断语义版本号。自动触发 CI 或发布流程。
作者批评的不是所有自动化。他批评的是 type-driven 的外推：把 commit log 直接当 changelog，把 type 直接当发布风险。
这两件事不是一个粒度。
commit log 面向开发者，记录代码库怎么变化。changelog 面向用户，回答版本之间到底多了什么、删了什么、破坏了什么。
一个用户可见的功能，可能由十几条 commit 拼出来。用户不需要知道中间哪条是 chore、哪条是 refactor。一条后来被 revert 的提交，对开发者有历史意义，对用户可能等于没发生。
语义版本自动 bump 也一样脆。
breaking change 可能一开始没人意识到。也可能后来被 revert。还可能被后续修复消掉影响。工具读到的是单条 commit 的 type，真实风险却藏在一组 diff 的合成结果里。
用 docs:、chore: 这类标签决定跑不跑检查，也要谨慎。更可靠的依据通常是 git diff 触碰了哪些文件、模块、依赖，而不是标题里写了什么。
这不是说 semantic-release 或自动 changelog 没价值。它们适合做辅助，适合降低重复劳动。不适合替代维护者对变更影响面的判断。
对维护者和团队负责人，动作不同
开源项目维护者要看的，是 commit history 能不能帮人快速定位责任区域。
如果项目已经用了 Conventional Commits，不必为了 scopedcommits.com 立刻迁移。它只是一个新倡议，不是成熟标准，也不是行业共识。
更现实的动作是三件事：
- 要求 scope 尽量必填，而不是可写可不写；
- 给常见 scope 建清单，例如 package、subsystem、area；
- 不把自动 changelog 原样当用户发布说明，发布前仍要人工整理。
工程团队负责人要看的，是规范有没有压低协作成本。
如果团队每天在争 feat 还是 refactor，却没人能从 commit log 里看出最近谁动了 billing、auth、infra，这套规范就在消耗注意力。
Linux、FreeBSD、Git、Go、NixOS 等项目长期使用的做法更朴素：subsystem: description、package: description、area: description。它们不完全一样，但共同点很清楚：把影响面放到前面。
这不是复古。大型工程里，排障和审查靠的是路径、模块、子系统。标签再整齐，也不能替代上下文。
当然，scope-first 也有成本。
scope 怎么命名？跨模块改动怎么写？企业里的 ticket number 放哪里？如果一个团队没有清楚的模块边界，强推 scope-first 也会变成另一套形式主义。
所以这场争论最有价值的地方，不是让大家换一个 commit 模板。
它逼团队问一个更难的问题：我们到底在为谁写提交信息？
为工具写，就会迷恋短标签。为维护者写，就必须把影响面、审查路径和发布风险写清楚。
工程规范最怕形式赢过语义。标签越整齐，越容易给人一种“流程已经可控”的错觉。可真到事故复盘时，大家找的从来不是 feat，而是“最近谁动了这块”。
刀口应该落在这里。