技能使用指南

changelog-automation（变更日志自动化）Skill 是什么？如何下载使用？

变更日志自动化Skill帮你把提交记录自动变成规范的 CHANGELOG 与发布说明：内置 Keep a Changelog 格式、Conventional Commits 规范与语义版本控制，覆盖 commitlint、standard-version、semantic-release、git-cliff、commitizen 六种落地方案与可复制配置模板。本文详解安装步骤、使用方法、竞品对比与真实场景体验，助你十分钟搭好发布流水线。

变更日志自动化Skillchangelog-automation
20 个章节 约 20 分钟阅读 AI 智能生成

变更日志自动化Skill：让每一次提交都自动沉淀成规范的版本日志

  • 一句话定位：这是一个把「Conventional Commits 提交规范 + Keep a Changelog 日志格式 + 语义版本控制」打包成可执行方案的 AI 技能，帮你在几分钟内搭起一条从提交到发布的自动化流水线。
  • 解决的核心痛点：版本日志靠人手写、提交信息五花八门、版本号拍脑袋决定、发布说明东拼西凑——这些重复劳动可以被彻底标准化。
  • 覆盖多种技术栈：技能同时提供 Node.js（commitlint、standard-version、semantic-release）、Rust（git-cliff）、Python（commitizen）以及 GitHub Actions 等多条落地路径，可直接复制使用。
  • 产出的是"能直接用的配置"：不是泛泛而谈的方法论，而是含 commitlint.config.js、.versionrc.js、release.config.js、cliff.toml、发布工作流 YAML 等完整模板。
  • 适合人群：需要维护版本发布节奏的前端/后端/全栈工程师、开源项目维护者、DevOps 与研发效能同学。

该技能叫什么？如何下载安装 AI 技能提升开发效率？

基本信息

项目 内容
技能中文名 变更日志自动化Skill
技能英文名 changelog-automation
技能 ID 13248
官方描述 自动化从提交、PR 和发布中生成变更日志，遵循 Keep a Changelog 格式。用于设置发布工作流、生成发布说明或标准化提交约定。

它到底解决什么问题

在一个正常的项目里，版本发布往往要经历这些"手工环节"：

  1. 翻看最近几十条提交，凭记忆整理"这次改了什么"；
  2. 判断这次是补丁、次版本还是主版本；
  3. 手写 CHANGELOG.md，格式每次都不太一样；
  4. 复制一份到 GitHub Release 页面，再改一遍措辞；
  5. 忘了标记破坏性变更，导致下游用户升级后报错。

这个技能的价值，就是把这 5 步变成"机器读提交、机器分版本、机器写日志、机器发 Release"。它把业界三套事实标准——Keep a Changelog（日志格式）、Conventional Commits（提交规范）、语义版本控制 SemVer（版本号规则）——整合成一套可落地的配置与流程。

一键安装与启用思路

AI 技能的安装通常遵循"搜索 → 安装 → 会话内调用 → 验证生效"四步。由于具体安装命令与入口地址随平台而异，以下为通用流程，具体命令与链接请以官方说明为准。

第一步：确认安装前提

  • 一个已用 Git 管理、且有提交历史的项目仓库（GitHub / GitLab 均可）；
  • 根据你选择的方案准备运行时：Node.js 方案需要 Node 环境，Python 方案需要 Python 环境，git-cliff 为独立的 Rust 二进制工具；
  • 仓库具备打标签（tag）的历史，或你愿意从当前版本开始建立标签约定。

第二步：找到并安装技能

在 AI 技能市场或技能中心搜索技能中文名「变更日志自动化」或技能 ID「13248」，进入详情页后点击安装/启用。安装后技能会出现在你的可用技能列表中，可在对话中直接调用。

第三步：在会话中调用

新开一个会话，用自然语言描述你的项目情况即可触发，例如：

“这是一个 Node.js 项目，团队提交信息比较随意。帮我按 Conventional Commits 规范搭建提交校验，并让版本发布时自动生成 CHANGELOG.md。”

第四步：验证是否生效

  • 让技能输出配置文件后，落地到仓库根目录；
  • 若配置了 commitlint + husky，故意提交一条 update some code 这样的不规范信息，观察是否被拦截；
  • 若配置了 git-cliff，先运行预览模式看输出结构是否符合预期，再写入文件；
  • 若配置的是 semantic-release，可先在测试分支验证一次完整发布流程，避免直接冲击主分支。

该技能的主要功能和特点

  • Keep a Changelog 标准模板：提供完整的中文版日志骨架，包含「新增 / 更改 / 弃用 / 移除 / 修复 / 安全」六大分区，并附带版本对比链接的页脚写法，让日志结构长期稳定。
  • 提交类型到日志分区的映射表：把 feat、fix、docs、style、refactor、perf、test、chore、ci、build、revert 等类型，明确映射到"新增"“修复”“更改”“移除"或"通常排除”，避免团队各写各的。
  • 语义版本控制的判断规则：清楚说明什么情况该升主版本号（破坏性变更 feat! 或 BREAKING CHANGE 页脚）、什么情况升次版本号（feat）、什么情况升修订号（fix），让版本号不再是"感觉差不多"。
  • 六种实施路径全覆盖：从最轻量的 commitlint 提交校验，到半自动的 standard-version，再到全自动的 semantic-release，以及高性能的 git-cliff、Python 生态的 commitizen，按团队规模和技术栈自由选择。
  • 可直接复制的配置模板：commitlint.config.js、.versionrc.js、release.config.js、cliff.toml、pyproject.toml 中的 [tool.commitizen] 段、GitHub Actions 的 release.yml，均以完整代码块给出，改几个参数就能用。
  • 发布说明模板双份：一份面向 GitHub Release 的公开模板（带 emoji 分区、贡献者致谢、完整对比链接），一份面向内部的发布说明模板（含总结、亮点、破坏性更改、升级指南、已知问题、依赖变更表）。
  • 提交信息示例库：给出带范围的功能提交、带问题引用的修复提交、带 ! 的破坏性提交、多段落正文提交四种范例，团队新人照着写就不会错。
  • 最佳实践清单：用"应做/不应做"对照的方式，把"一次提交一件事"“不手动改生成的日志”"忘记标记破坏性更改"等常见坑点一次性讲清楚。

和普通工具比强在哪：普通工具只解决"生成日志"这一个点，而这个技能提供的是"规范 + 校验 + 生成 + 发布 + 模板"的完整链路，并且会根据你的技术栈给出对应方案的取舍建议，相当于一位懂发布流程的工程顾问。

如何使用该技能？

步骤一：先统一"语言"——实施 Conventional Commits

这是整条流水线的地基。提交格式为：

<类型>[可选范围]: <描述>

[可选正文]

[可选页脚]

示例（可直接参考）：

# 带范围的功能
feat(auth): 添加 Google 登录的 OAuth2 支持

# 带问题引用的错误修复
fix(checkout): 解决支付处理中的竞争条件

关闭 #123

# 破坏性更改
feat(api)!: 更改用户端点响应格式

破坏性更改：用户端点现在返回 userId 而不是 id。
迁移指南：更新所有 API 消费者使用新字段名。

如果你希望"强制"而不是"倡议"，让技能帮你配置 commitlint + husky，把不合规的提交挡在本地：

npm install -D @commitlint/cli @commitlint/config-conventional
npm install -D husky
npx husky init
echo "npx --no -- commitlint --edit \$1" > .husky/commit-msg

步骤二：选择你的自动化方案

你的情况 推荐方案 理由
小团队、想先手动控制发版节奏 standard-version 本地一条命令升版本 + 生成日志，可控性高
希望打 tag 后全自动发布 semantic-release 自动判定版本、发 npm、发 GitHub Release
仓库大、提交多、追求生成速度 git-cliff 基于 Rust，生成快，模板可高度定制
团队主力是 Python commitizen 交互式提交 + cz bump 一键升版本并更新日志

步骤三：配置版本与日志的映射关系

以 standard-version 为例，通过 .versionrc.js 把英文类型映射成中文分区，并隐藏不需要出现在日志里的类型：

module.exports = {
  types: [
    { type: "feat", section: "功能" },
    { type: "fix", section: "错误修复" },
    { type: "perf", section: "性能改进" },
    { type: "revert", section: "还原" },
    { type: "docs", section: "文档", hidden: true },
    { type: "chore", section: "杂项", hidden: true },
  ],
  releaseCommitMessageFormat: "chore(release): {{currentTag}}",
};

同时在 package.json 中补齐脚本：

{
  "scripts": {
    "release": "standard-version",
    "release:minor": "standard-version --release-as minor",
    "release:major": "standard-version --release-as major",
    "release:dry": "standard-version --dry-run"
  }
}

输入示例：npm run release:dry 输出说明：不会真正改文件，只预览"本次会升到哪个版本、日志里会出现哪些条目"，这是上线前最值得养成的习惯。

步骤四：接入 CI，把发布变成流水线动作

让技能生成 GitHub Actions 工作流（.github/workflows/release.yml），核心动作包括：检出完整历史（fetch-depth: 0，否则拿不到 tag）、安装依赖、配置 Git 机器人身份、执行发布命令、推送标签。

如果是手动触发式发布，还可以通过 workflow_dispatch 提供 patch / minor / major 的下拉选项，让发版变成点一下按钮的事。

步骤五：预览、校对、归档

无论用哪种方案，正式写入前先跑一次"干跑"（dry-run）或 --unreleased 预览；生成后再人工扫一眼易读性，尤其是破坏性变更和升级指南部分。技能提供的内部发布说明模板，正好用来补上"总结、亮点、已知问题、依赖变更表"这些机器写不出来的内容。

同类型竞品对比分析

需要说明的是，本技能本身是一个"知识 + 模板 + 配置生成"的 AI 技能，而下面表格中的工具是它推荐的落地实现。对于"我要怎么把变更日志自动化起来"这个目标而言，它们构成可相互替代或组合的方案。

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
变更日志自动化Skill（changelog-automation） 方案顾问 + 配置生成器 提供格式标准、类型映射、六种实施路径、发布模板与最佳实践 门槛低，安装后在会话中用自然语言描述需求即可 首次搭建发布流程、需要对比选型、团队规范落地 优势：一次讲清全链路并直接产出可复制配置；不足：最终仍需你在仓库中执行配置与验证
standard-version 半自动版本与日志工具 根据提交自动升版本、生成 CHANGELOG、打 tag 需 Node 环境，安装依赖并配置 .versionrc 希望人工把控发版时机的团队 优势：简单可控、可 dry-run；不足：需手动触发，破坏性变更需严格标注
semantic-release 全自动发布引擎 自动判定版本、生成发布说明、发布 npm 与 GitHub Release 需 Node 环境、CI 环境与 Token 权限配置 高频发布、追求完全无人值守的开源或产品项目 优势：真正零手工；不足：配置与权限复杂，出问题排查成本高
git-cliff 高性能日志生成器 基于 Rust，用模板引擎高度定制日志输出，支持范围生成 需安装二进制，学习 cliff.toml 模板语法 大仓库、需要多套日志样式（对外/对内） 优势：速度快、模板灵活；不足：模板语法有学习曲线
commitizen Python 生态提交与发版工具 交互式创建合规提交、cz bump 升版本并更新日志 需 Python 环境，配置 pyproject.toml Python 项目、希望新人零成本写出规范提交 优势：交互式引导友好；不足：生态偏 Python，前端项目需另选方案
手动维护 CHANGELOG 传统做法 人工回忆并撰写日志 无门槛 极低频发布的小型项目 优势：灵活；不足：易遗漏、格式不统一、随项目增长成本急剧上升

选型建议：先用本技能把规范和模板定下来（这一步最难也最有价值），再按团队规模选一个工具落地；小团队从 standard-version 起步，跑顺了再迁移到 semantic-release 或 git-cliff。

该技能的典型应用场景与实际体验情况

场景一：开源项目维护者被 Issue 追问"这次更新了什么"

角色与痛点：个人开源作者，每周发一次版，每次都要手动整理提交、写 Release Notes，经常漏掉社区贡献者，导致贡献者体验差。 使用方式：让技能生成 Keep a Changelog 格式的 CHANGELOG.md 骨架和 GitHub Release 模板（含"新贡献者"致谢区块与完整对比链接），再配置 semantic-release 在打 tag 时自动发布。 实际体验：上手难度低，配置一次后基本不用再管；日志中"由 @某某 在 #123 提交"的自动致谢，对社区氛围提升明显。注意事项：首次接入时建议在测试分支跑通，确认 Token 权限与分支保护规则不冲突。

场景二：中型研发团队的提交规范落地

角色与痛点：10 人左右的前后端混合团队，提交信息有中文有英文、有 fix bug 也有 update，Code Review 时很难快速判断改动性质。 使用方式：由技能提供 commitlint 配置与 husky 钩子脚本，先做"提交时拦截"，再逐步推进到自动生成日志。 实际体验：效果立竿见影，不合规提交在本地就被挡住，团队两周内形成习惯。注意事项：subject-max-length 之类的规则要结合中文提交习惯调整，过严会引发抵触；建议先在团队内公示规则再启用。

场景三：SaaS 产品的对外版本公告

角色与痛点：产品运营需要每月给客户发版本更新公告，但研发只给一堆 commit，运营看不懂、翻译成本高。 使用方式：使用技能提供的"内部发布说明模板"，要求研发在发版时补全"总结、亮点、破坏性更改、升级指南、已知问题、依赖变更表"，运营在此基础上改写成客户语言。 实际体验：把"翻译 commit"变成了"填充模板"，沟通成本显著下降。注意事项：机器只能生成"有什么变化"，"为什么重要"仍需人来写，不要指望全自动对外发布。

场景四：内部基础库的破坏性变更管理

角色与痛点：公司内部组件库被十几个业务线引用，某次悄悄改了字段名，导致下游线上故障。 使用方式：要求破坏性变更必须使用 feat! 或 BREAKING CHANGE 页脚，由技能配置的 commitlint 规则进行校验，同时日志中强制生成"破坏性更改"分区。 实际体验：这类事故基本被堵住。注意事项：规则只是"提醒"，真正生效依赖是否把校验接进 CI 并在合并前强制执行。

该技能能为用户带来的价值

  • 把"写日志"的时间降到接近零：以往每次发版花 1–2 小时整理日志与发布说明，接入自动化后通常压缩到 10 分钟以内的校对时间，按每月一次发版计算，一年可省下十几到二十多个小时。
  • 把"规范"从口号变成可执行的约束：类型枚举、主题长度、大小写规则都写进配置文件，配合提交钩子，新人第一天就能写出合规提交，减少 Code Review 中的无谓沟通。
  • 把版本号决策变成可推演的逻辑：哪次改动该升主版本、哪次只是补丁，由提交类型和页脚直接推导，避免"发布后才发现是破坏性变更"的返工。
  • 降低发布流程的整体门槛：不需要读完三份规范文档再动手，技能已经把 Keep a Changelog、Conventional Commits、SemVer 三者对齐，并给出多技术栈的实现路径，中小团队也能拥有大厂级的发布体验。
  • 长期价值在于可追溯性：结构化的变更日志沉淀下来，就是一份按时间排列的产品演进史，日后排查"某功能是哪一版引入的"、做合规审计、写升级迁移文档，都能直接复用。
  • 对协作链路的正向溢出：日志规范了，PR 描述、Release Notes、客户公告、内部周报都能从中取材，“一份输入、多处复用”，是整个研发流程的润滑剂。

常见问题 FAQ

Q1：这个技能怎么安装？在哪里能找到？

在 AI 技能中心或技能市场搜索技能中文名「变更日志自动化」或技能 ID「13248」即可找到详情页，点击安装/启用后，在新会话中直接描述你的项目情况就能调用。具体安装命令、入口地址与平台支持范围请以官方说明为准。

Q2：使用这个技能需要付费吗？

技能本身提供的是规范知识、配置模板与实施路径，是否收费取决于所在技能平台的定价策略，请以官方说明为准。需要注意的是，它生成的配置会用到 commitlint、standard-version、semantic-release、git-cliff、commitizen 等开源工具，这些工具本身多为开源免费，但部分托管平台（如 npm 私有包发布、CI 分钟数）可能产生费用，需自行评估。

Q3：我的项目不是 Node.js，还能用吗？

完全可以。技能提供了多技术栈路径：Python 项目可用 commitizen（cz commit 交互式提交、cz bump --changelog 升版本并更新日志）；语言无关的场景可用 git-cliff，它基于 Rust 二进制，通过 cliff.toml 配置提交分组与模板；GitHub Actions 工作流方式则与项目语言基本无关，只要能执行命令即可。

Q4：项目历史提交很乱，之前的 CHANGELOG 也不规范，怎么办？

建议"从今天开始规范"，不要试图回溯整理全部历史。做法是：先设定一个起始版本（例如在 commitizen 中配置 changelog_start_rev），此后的日志增量生成；旧日志整体保留为一条历史记录，用分隔说明"以下为规范化之前的记录"。文档与迁移说明部分，技能也会提示你如何在新旧之间做衔接。

Q5：它会不会自动改我的仓库？和 semantic-release、git-cliff 到底怎么选？

技能本身是"给方案、给模板"，不会擅自修改你的代码库，最终是否写入文件、是否提交、是否打 tag，都由你或你的 CI 流程决定——这也是它适合团队落地的原因。至于工具选择：想要"一条命令、人工把控"选 standard-version；想要"打 tag 后完全无人值守"选 semantic-release；想要"生成快、模板高度自定义、支持对内对外两套日志"选 git-cliff；Python 团队选 commitizen。最优路径通常是：先用本技能定规范与模板，再按团队规模选一个工具落地。