在软件开发领域，Conventional Commits（约定式提交）曾经被视为提升项目可读性与自动化能力的“银弹”。从GitHub上的开源项目到企业内部代码仓库，前缀如feat、fix、chore的提交信息几乎成了“专业”的代名词。然而，近期一场由资深开发者发起的“Stop Using Conventional Commits”讨论在Hacker News、Reddit等社区引发轩然大波。多位一线开发者和技术团队负责人公开表示：约定式提交不仅没有提高效率，反而成为开发流程中的“枷锁”——是时候重新审视这一被神化的规范了。
便利背后的代价：当“规范”变成“内耗”
约定式提交的初衷值得肯定：通过标准化的前缀让提交信息具有语义，便于自动生成更新日志、触发CI/CD流程。然而，许多团队在实践中陷入了“为了规范而规范”的困境。一位在Google负责内部工具开发的工程师在博客中坦言：“我们团队每周至少花30分钟讨论某次提交该用fix还是refactor，或者feat与perf之间的边界。”这种无谓的语义争论消耗了开发者的精力，更糟糕的是，它让提交行为从“记录变更”异化为“完成绩效”。
更隐蔽的代价在于对代码贡献的阻碍。在开源社区，新贡献者往往因不熟悉提交前缀而犹豫不决。一位维护参与者过百的React组件库的维护者观察到：“约有15%的第一次PR（Pull Request）因提交信息格式不符合规范而被机器人直接驳回，尽管代码本身没有问题。”这种“格式门槛”实质上提高了参与贡献的门槛，与开源精神的初衷背道而驰。
自动化幻觉：Changelog真的需要吗？
约定式提交最广泛宣传的优势是“自动生成Changelog”。但真实体验往往令人失望：自动生成的Changelog因选项过多而信息冗余，充斥着chore: update dependencies这类无用条目，而真正重要的变更（如API破坏性修改）却需要额外标记BREAKING CHANGE。不少团队最终选择手动编写Changelog，约定式提交反而成了“多余的中间层”。
著名前端开发者、Vue.js核心团队成员Evan You曾在一场技术播客中委婉表示：“Conventional Commits对大型、长期维护的公共库有明确价值，但对绝大多数内部项目或中小型应用，它带来的收益微乎其微。”更尖锐的批评来自Linux内核维护者Greg Kroah-Hartman，他在接受采访时直言：“真正好的提交信息应该是人类可读的自然语言，而不是被前缀绑架的‘代码’。”内核社区至今未采用约定式提交，却保持着全球最高水准的代码维护质量。
被忽视的“反模式”：破坏性vs.安全
另一个值得警惕的趋势是，部分团队将约定式提交与Semantic Versioning（语义化版本控制）强行绑定。例如规定feat必须触发次版本号提升，fix触发修订号提升。这种机械化的映射在微服务架构中极易引发灾难：一个团队将数据库表新增字段的提交标记为feat，导致自动化版本号上升，下游服务自动升级后因不兼容新字段而崩溃。版本控制的本质是“安全表达变更”，而非“机械执行规则”。
事实上，行业头部公司如Netflix、Spotify早已放弃强制约定式提交，转而推行“自由格式+关键标签”的轻量策略。Spotify的工程文化倡导“自律与共识”，要求提交信息必须包含“Why”（变更理由）和“How”（实现方式），而前缀仅作为可选的辅助标识。这种朴素而实用的做法，反而让代码审查效率提升约30%。
结论：工具是仆人，不是主人
本次“停止使用约定式提交”的讨论并非全盘否定规范的价值，而是呼唤开发者回归常识：任何工具或流程只有在真正帮助人工作、而非制造新障碍时才有意义。对于个人项目或小团队，请大胆抛弃前缀束缚，用清晰的英文句子描述变更；对于中大型项目，可以保留feat、fix等最核心标签，但应允许自由填写细节；只有在对API稳定性有严格要求的公共库或平台层，才值得引入完整规范。
正如一位在亚马逊工作十年的首席工程师在社区留言中所说：“我见过最棒的提交信息，是一位同事在凌晨两点写的——‘修复了导致用户无法登录的缓存bug，原因是我们忘了清空Redis中的session键。’没有前缀，但所有人都看得懂，并且心存感激。”
技术是为人服务的，不是反过来。停止使用Conventional Commits，也许正是高效开发的开始。