这个页面上的其中一个工具是我们做的。我们尽量按其他工具是为了什么而构建来描述它们，而不是它们缺少什么，而关于我们自己产品的部分则明确说明了谁不应该使用它。
三种类别
托管的 widget 和页面
你在他们的编辑器中撰写条目，他们负责托管页面并提供一个应用内 widget。上线速度最快，但条目存放在他们的基础设施上，而不是你的。Beamer 和 AnnounceKit 是最典型的例子。
附带 changelog 的反馈套件
changelog 是功能投票、公开 roadmap 和反馈收件箱旁边的一个模块。如果你希望从一家供应商那里获得整个闭环，这样做是值得的；但如果你只想发布发布说明，那就显得过重了。Canny、Frill 和 Featurebase 属于这一类。
从你的仓库生成
changelog 由提交、pull request 或 issue 生成，而不是手动输入。范围从在 CI 中构建的文件，到经过撰写、审核、发布的条目不等。git-cliff 和 github-changelog-generator 处于文件那一端；LaunchNotes、Released 和我们自己的产品则处于已发布那一端。
一览
| 工具 | 类型 | 最适合 |
|---|---|---|
| Beamer | 托管 widget | 想在今天下午就让应用内的新功能面板上线、而且不占用工程时间的团队。 |
| AnnounceKit | 托管 widget | 同上，但更注重细分哪些人能看到哪条公告。 |
| Canny | 反馈套件 | 想要功能投票和公开 roadmap，并把 changelog 作为闭环最后一步的团队。 |
| Frill | 反馈套件 | 想要与 Canny 相同的形态、但更轻量的小团队。 |
| LaunchNotes | 从仓库生成 | 需要跨团队协调公告的大型组织，通常以 Jira 为核心。 |
| Released | 从仓库生成 | 日常都在 Jira 中工作、希望不离开 Jira 就能从 issue 生成 changelog 的团队。 |
| git-cliff | 文件生成器 | 想在 CI 中根据 conventional commits 构建 CHANGELOG.md、完全不需要任何托管服务的开源项目。 |
| Changeloop | 从仓库生成 | 希望根据已合并的 pull request 起草条目，再由自己的前端从 JSON feed 渲染的团队。 |
如何选择
- 先从 changelog 需要出现在哪里开始考虑。如果它必须看起来像你产品的一部分，那么无论编辑器多好，一个你只能链接过去的托管页面都会让人失望，你需要的要么是一个可以重新调整样式的 widget，要么是一个你自己渲染的 feed。如果一个带链接的页面就足够了，托管型工具所需的工作量会小得多。
- 接下来问一问谁来撰写条目。如果答案是“完成合并的工程师”，就选一个能读取你仓库内容的工具，因为其他任何方式都会在所有人都很忙的那一刻额外增加一个手动步骤。如果答案是根据发布计划工作的产品市场人员，那么一个编辑器会更合适，而仓库自动化只会碍事。
- 接下来问一问你是否需要闭环的其余部分。功能投票和公开 roadmap 确实有用，但也确实是更大的投入。为了 changelog 模块去购买一整套套件，正是团队最终为了用一样东西而花钱买四样东西的原因。
- 最后，确认一下如果你离开，你的条目会怎样。一个能将条目导出为结构化数据的工具，与一个条目只存在于你需要自己抓取的托管页面上的工具，二者有本质区别。
我们自己的工具适合什么场景，不适合什么场景
Changeloop 会读取每一个已合并的 pull request，撰写一条面向用户的条目，过滤掉依赖更新和重构，并将草稿保留供审核。发布的内容会进入一个公开 JSON feed，旁边还有一个 roadmap feed，另外还提供一个两行代码的 widget 和一个托管页面作为备用方案。feed 才是重点：预期的使用方式是你在自己的产品中，用自己的组件渲染 changelog。
以下情况请不要选择它：
- 你的发布并非来自你的仓库。它根据合并起草，或在推送模式下根据推送起草，因此在 Git 工作流程之外交付的团队将没有任何内容可供审核。
- 你想要功能投票和由用户投票决定的 roadmap。这里确实有一个 roadmap feed，但它是由带标签的 issue 驱动的，而不是用户投票。对此，反馈套件才是正确的类别。
- 你想要一个精致的编辑器，并把托管页面作为主要产品。托管页面在这里只是作为备用方案存在，围绕自己页面构建的工具会做得更好。
- 你是一个只想在仓库中放一个 CHANGELOG.md 文件的独立开源项目。使用 git-cliff 吧，它是免费的，而且正是为此而生的。
常见问题
我们真的需要一个工具吗？
一段时间内不需要。一个 markdown 文件，或者你自己网站上的一个页面，就是一份相当不错的 changelog，而且不花任何成本。工具开始产生价值的临界点，是撰写条目变成了一个经常被跳过的步骤，或者你希望在三个地方拥有相同的条目，却不想维护三份副本。
以后我们可以从这些工具中的某一个迁移出来吗？
这完全取决于条目能否以结构化数据的形式导出。请在开始之前问清楚，而不是事后才问：这是列表中唯一一个答错了会代价高昂的问题，因为 changelog 是一个不断增长的档案库，重新输入两年的内容不会是任何人会批准的项目。
用 AI 助手来撰写它们呢？
目前大多数工具都在某个环节使用模型来撰写内容。这远不如模型被给予了什么输入重要。一个只能看到提交主题的工具，也只能重写那个主题；而一个能看到 pull request 标题和描述的工具，则拥有足够的信息，能从对用户有什么作用的角度来描述这个变更。要问的是输入是什么，而不是是否用了 AI。
延伸阅读：changelog 自动化及其局限，了解四个步骤中哪一个应该自动化。