一个只读的更新日志生成器

我构建了 ChangelogGenie，一个轻量级开源 GitHub Action 和命令行工具，用于直接从 GitHub 提交历史生成分类的技术 Markdown 更新日志。它最想绕开的约束，就是要求仓库先采用某种提交规范才能使用。

打开网易新闻 查看精彩图片

很多更新日志工作流依赖 Conventional Commits、PR 标签、发布标签或其他仓库特定约定。ChangelogGenie 走了更简单的路线：给它一个 GitHub 仓库和一个明确的日历日期范围，它读取该区间内的提交，并生成确定性的技术更新日志。它不会修改仓库。

它具体做什么

ChangelogGenie 能处理普通 Git 提交，不要求 Conventional Commits。它把变更分类为功能、缺陷修复、性能、文档、维护、依赖、CI/CD、重构、破坏性变更以及其他技术类别。它记录请求的日期范围和实际提交日期范围，保留提交元数据并链接到源提交。

整个运行过程是只读的，不会创建提交、修改仓库文件或打开拉取请求。GitHub Action 在工作流内部生成一个 Markdown 文件，后续工作流可以把该文件作为构件上传，或用于下游处理。

真实仓库验证

我用已发布的 Action 对公开的 outline/outline 仓库进行了测试，时间范围是 2026 年 3 月 15 日至 18 日。它收集了 21 个公开提交，并生成了分类的 Markdown 更新日志。实际生成的输出被持久化在仓库中，可以直接查看。

快速开始配置也很直接：在 workflow 中调用 Ubuntu-123/changeloggenie-prototype@v0.1.7，传入 owner、repo、start_date、end_date、version、output_path 和 github_token，再用 actions/upload-artifact@v4 上传生成的 changelog-output.md 即可。

当前限制与边界

目前的分类是确定性的、基于模式匹配，而不是语义理解。免费的 GitHub Action 有意保持窄范围：它只生成技术更新日志，不决定哪些内容应该变成面向客户的发布沟通。我倾向于把这条边界保持明确，而不是把编辑决策隐藏在自动改写背后。

项目采用 MIT 许可，代码托管在 GitHub，也上架了 GitHub Marketplace。反馈尤其欢迎针对生成格式、分类方式，以及这种只读工作流是否适合真实发布流程。