夜雨聆风发布说明是软件交付过程中一个经常被低估的环节。一份写得好的文档，能让测试人员快速确认覆盖范围，让产品经理了解本次交付的价值，让最终用户知道哪些问题被修复、哪些功能值得期待。
然而随着项目规模扩大、发版频率加快，手动整理发布说明逐渐变成一件让人头疼的事：面对成百上千条提交记录，在多个分支间来回切换，还要处理各种不规范的提交信息。最后的结果往往是文档遗漏、格式混乱，或者干脆因为"来不及写"而省略。
本文要解决的，就是这个问题。我们将利用 .NET 和 AI，通过分析 Git 提交历史自动生成结构清晰、分类准确的发布说明，把这项繁琐的手工活变成一个可靠的自动化流程。
AI 驱动的发布说明生成器是怎么工作的
这个系统的核心思路并不复杂：把 Git 的提交历史喂给 AI 大语言模型，让它来理解这些变更的含义，并生成结构化的摘要。
与简单罗列提交记录不同，AI 模型能够对内容进行语义理解和归纳。例如，它可以把"添加搜索框 UI"、"实现搜索接口"、"联调搜索功能"这三条提交，合并归纳为"新增客户搜索功能"这一条清晰的说明。
具体来说，它能做到：将零散的功能点聚合为新特性描述；识别并归纳 Bug 修复；标记可能影响现有功能的破坏性变更；以及根据受众角色（开发者、测试人员、最终用户）生成不同粒度的文档。
这种能力让开发团队从"翻 commit 记录、整理措辞"的工作中解放出来，把精力放在真正需要人来判断的地方。
系统架构与工作流
要构建一个完整的自动化流程，通常需要四个核心组件协同工作：
Git 仓库负责存储代码和提交历史，是原始数据的来源。ASP.NET Core 服务负责提取 Git 日志、构建 AI 请求、组织并输出最终文档。AI 大语言模型（如 Azure OpenAI）负责对提交记录进行语义分析和分类汇总。CI/CD 流水线（如 GitHub Actions）负责在合适的时机触发整个流程。
整个工作流的执行顺序如下：当代码合并到主分支并准备发布时，流水线被触发；脚本通过 Git 命令或 LibGit2Sharp 等 .NET 库提取两个版本标签之间的所有提交记录；.NET 服务将这些提交记录连同预设的提示词一起发送给 AI 模型；模型返回结构化的 Markdown 文档，最终被自动附加到 GitHub Releases 或其他版本发布页面。
整个过程无需人工介入，从代码合并到发布说明上线，全部自动完成。
第一步：读取 Git 提交历史
自动化的起点是准确获取特定版本范围内的所有变更记录。最简单的方式是直接运行 Git 命令：
git log v1.0..HEAD --oneline这条命令会输出从 v1.0 标签到当前 HEAD 之间的所有提交的简要信息，例如：
a1b2c3d 添加客户搜索端点e4f5g6h 修复支付超时问题i7j8k9l 改进身份验证中间件m0n1o2p 更新 API 文档在 .NET 应用中，你既可以通过 Process 类直接执行上述命令，也可以使用 LibGit2Sharp 这样的 .NET 库以编程方式访问 Git 仓库，后者更适合需要对结果进行进一步处理的场景。
这些原始提交信息，就是后续 AI 分析的"原材料"。
第二步：调用 AI 生成结构化说明
有了提交记录，下一步是把它们发送给 AI 模型，并告诉模型如何处理。以下是一个基础的生成器服务实现：
publicclassReleaseNoteGenerator{privatereadonly HttpClient _httpClient;publicReleaseNoteGenerator(HttpClient httpClient) { _httpClient = httpClient; }publicasync Task<string> GenerateAsync(string commits) {// 提示词设计是决定输出质量的关键var prompt = $""" 请根据以下 Git 提交记录，为本次软件发布生成一份结构化的发布说明。 要求： 1. 将变更按以下分类组织：新特性、缺陷修复、性能优化、安全更新、破坏性变更。 2. 某分类下没有相关变更时，省略该分类，不要输出空标题。 3. 使用 Markdown 格式返回结果，标题层级清晰。 4. 每条说明应面向用户，语言简洁，避免暴露内部实现细节。 提交记录： {commits} """;returnawait CallAiApiAsync(prompt); }privateasync Task<string> CallAiApiAsync(string prompt) {// 此处替换为实际的 Azure OpenAI 或其他 AI 服务调用// 可使用 Azure.AI.OpenAI NuGet 包thrownew NotImplementedException(); }}这里有一个细节值得强调：提示词的设计质量直接决定了输出的质量。通过明确要求按特定维度分类、省略空分类、使用面向用户的语言、强制输出 Markdown 格式，我们可以显著提升生成内容的专业性和可读性。提示词本身是一个需要持续迭代优化的部分，随着团队的使用，你会逐渐积累出最适合自己项目风格的版本。
AI 输出示例
经过 AI 处理后，上面那几行干燥的提交记录会变成这样的文档：
## 新特性- **客户搜索**：支持按姓名、邮箱和电话号码搜索客户。- **双因素认证**：引入基于 TOTP 的两步验证，提升账号安全性。## 缺陷修复- **支付超时**：修复了高并发场景下支付网关请求偶发超时的问题。## 文档更新- 补充了客户搜索端点的 API 使用示例。原本需要手动整理的内容，现在以用户能看懂的方式自动呈现出来。
第三步：集成到 CI/CD 流水线
让整个流程真正实现"零介入"，需要把生成逻辑嵌入 CI/CD 流水线。以 GitHub Actions 为例，典型的配置流程是：在流水线工作流中，首先计算版本差异并提取提交日志；然后调用封装了 ReleaseNoteGenerator 的 .NET 工具或 HTTP 端点；将生成的 Markdown 内容保存为文件；最后使用 GitHub CLI 或 REST API，在创建新 Release 时自动填入发布说明内容。
这样一来，每次软件交付，都能自动伴随一份准确、及时的文档更新，无需任何人工干预。
让效果更好的工程实践
首先，规范 Git 提交信息是最重要的前提。 AI 模型的输出质量高度依赖输入数据的质量。"fix bug"这样的提交信息和"fix: 修复高并发下支付超时问题"相比，生成的发布说明质量会有天壤之别。推荐团队推行 Conventional Commits 规范，要求每条提交信息清晰标明变更类型（feat、fix、docs、perf 等）。这是整个自动化流程能否产生高质量输出的基础。
其次，重大版本发布前安排人工复核。 AI 生成的文档可以大幅减少整理工作量，但它无法理解业务背景，也可能遗漏某些重要的上下文说明。对于面向外部用户的重要版本，建议在自动生成后安排一名同事花十分钟过一遍，确认技术细节准确，并补充必要的背景说明。
第三，针对不同受众定制不同版本。 开发者关心破坏性变更和 API 差异，测试人员关心修复了哪些问题，最终用户关心体验上有哪些改善。可以在提示词中加入受众角色参数，让同一批提交记录生成多份面向不同角色的说明。
第四，持续迭代优化提示词。 第一版提示词生成的结果往往不是最理想的。随着团队的实际使用，记录那些让你不满意的输出案例，针对性地调整提示词中的指令和示例。提示词工程是一个需要持续打磨的过程，但每一次改进都会让后续所有版本的文档质量得到提升。
总结
通过将 .NET、Git 和 AI 大语言模型组合在一起，我们可以把"手写发布说明"这件一直以来靠人力驱动的事，转变为一个高效、可靠的自动化流程。它不仅缩短了发版准备时间，也让文档的及时性和一致性得到了保障。
随着软件交付频率的不断提升，AI 辅助的文档自动化正在成为工程团队越来越重要的基础设施。这件事的技术门槛并不高，但收益是实实在在、每次发布都能感受到的。
参考资料
① Git. git-log 官方文档. https://git-scm.com/docs/git-log
② Microsoft. Azure OpenAI Service 文档. https://learn.microsoft.com/en-us/azure/ai-services/openai/
③ GitHub. GitHub Actions 文档. https://docs.github.com/en/actions
④ Conventional Commits. Conventional Commits 规范 v1.0.0. https://www.conventionalcommits.org/en/v1.0.0/
关注公众号↑↑↑：DotNet开发跳槽❀
