目标
手工改版本号总会与事实漂移：有人把特性标成补丁、漏掉破坏性变更、或把变更日志修饰得更体面。把版本与日志都从约定式提交推导，发布就变成“已记录意图”的函数，任何人都能审计，没有人再手碰版本文件。
步骤要点
- 装 commitlint 约定式配置加 commit-msg 钩子与 CI 检查，确保 feat、fix、BREAKING CHANGE 完整到达工具。
- 配置 semantic-release 插件链：提交分析、变更日志、npm 或产物发布、git 标签。
- 对最近历史做 dry-run，对比机器算出的版本跃迁与分组和人类会写的是否一致。
- 在 main 流水线测试通过后接入发布步骤，条件限定分支必须恰为 main 且构建为绿。
- 验证发布链：产物版本、git 标签、变更日志条目三者指向同一提交哈希，无人工修正痕迹。
排错提示
出现意料之外的大版本跃迁，多半是一条漏写感叹号或 footer 的破坏性提交，查提交格式而不是关掉自动化；发布跑了但产物没上去是凭据作用域问题，把 publish 权限收进专用机器人账号并审计其作用域；双发布或烧掉版本号说明分支门禁不严，发布条件要精确比对 ref 名而不是信任调用方。
适用边界
自动化只消化守规矩的提交历史，格式执法不严的仓库要先补钩子再上自动化；每次合入即发布会放大低价值噪音版本，库适用、应用场景可评估批次发布。
代码示例
history -> computed release
-------------------------------------------
feat: add coupon engine
fix: correct rounding -> 1.9.0 (minor)
feat!: drop legacy API -> 2.0.0 (major, BREAKING)
chore: update deps -> (no release)
changelog: generated, grouped
feat / fix / BREAKING, with commit links